> From: Lanlan Pan <abby...@gmail.com> > Don't judy other's motivation with meaningless skeptics. The endless > skeptics can also push on your RPZ to DNSSEC.
A significant difference between RPZ and the SWILD is that RPZ does not depend on non-participants doing anything. For example, RPZ works fine on a single, isolated resolver. (Of course, the owners of the IETF printing presses would have to agree to publish anything, but publishing a description is neither implementing nor deploying.) The history of RPZ might suggest a temporary solution. Why not implement SWILD using a private rtype or perhaps even TXT? An implementation and a few 1000 installations might convince some skeptics and render many objections moot. > DNSSEC deployment will sharply rise if global nameservers desire *dns > security*, but almost impossible because of an addtional wildcards feature. I don't understand that. My zones have plenty of wildcards, but as far as I can tell, no new wildcard features will break my DNSSEC signatures. I don't understand "global nameservers [desiring] dns security". Are "global nameservers" resolvers or authorities? If they are resolvers, then there is absolutely no immediate prospect of many (any?) resolvers that might be called "global" dropping unsigned DNS data. If they are authorities, then I thought that the reasons why almost all com zones are unsigned are well understood, recently listed here, and have nothing to do with wildcards. What am I missing? http://scoreboard.verisignlabs.com/ http://scoreboard.verisignlabs.com/percent-trace.png ....................... ] From: Mark Andrews <ma...@isc.org> ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks ] DNSSEC. I describe the same facts as the opposite, as "either DNSSEC breaks RPZ or DNSSEC and RPZ work together perfectly well" (in either case, assuming a trusted path such as (trusted) localhost name or 127.0.0.1 address to a trusted resolver, where "trusted resolver" includes "trusted to rewrite." Of course, without a trusted path to a trusted resolver or a verifying stub, DNSSEC doesn't mean much.) As Mark Andrews understands but many people don't, the common RPZ implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast that RPZ invalidates and removes signatures and so verifying stubbs and verifying downstream resolvers will not accept rewritten answers." Also, in the two RPZ implementations I've written, the default BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ. Vernon Schryver v...@rhyolite.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
