> From: Ted Lemon <mel...@fugue.com> > I think the main reason attackers won't sign = > is that it's too much trouble, and provides no real benefit in the = > presence of an effective RPZ block.
Yes, but there is a reason more important than RPZ for miscreants to sign their attacks. It is the same reason that plenty of spam is sent with valid STARTTLS, DKIM, and/or SPF signatures and why spammers were the first significant SPF publishers. A large fraction of their targets support the silly notion that authenticated strangers differ from other strangers and that a certificate of authentication from a third party is a bankable guarantee of virtue. > The question is, does it make sense to add code to the = > validating resolver to detect and validate an RPZ block, so the user can = > be informed that a block occurred, and who did it? Would people = > actually code this up? That's the rub. RPZ has multiple independent interoperating implementations, is widely deployed, and is in common use because the customers of DNS recursive server implementators initially welcomed it and now demand it. Those customers are operators of DNS resolvers, especially large operators who pay real money (as opposed to hot air) for DNS server code, hire people to operate it, pay the secondary bandwidth, training, bug and other costs, and pay for RPZ blacklists. Where is the equivalent demand among resolver operators for doubling the size of DNSSEC responses to contain both the original and the RPZ rewritten rrsets including RRSIGs, and to pay the implied costs in bugs, CPU cycles, bandwidth, training, security, etc? People pay money for code implementing what the draft describes, but as Ted Lemon asks, who would pay for the suggested code in resolvers? If it were free, who would pay the costs of turning it on? (You'd also need to convince RPZ blacklist providers to include RRSIGs in their feeds, because you'd need signatures on rewritten responses.) Such considerations are why so many users are behind resolvers that validate DNSSEC but practically no domains are signed. DNSSEC is a good thing for operators of DNS clients, both resolvers and stubs, but it is far more cost than benefit to operators of authority servers. That's why we have the enduring, very discouraging picture at http://scoreboard.verisignlabs.com/percent-trace.png http://scoreboard.verisignlabs.com/ Such issues might also be why some of the most emphatic critics of RPZ in this mailing list nevertheless send their critiques from unsigned domains. Note that the vast majority of clients of RPZ rewriting resolvers are stubs that don't do validation but trust header bits saying that a resolver operated by a third party did the validation. I think that's wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah de blah de blah, but it's also something no one seems willing and able to change. Vernon Schryver v...@rhyolite.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop