Hi Vernon, Thanks for your advice, :-)
Vernon Schryver <v...@rhyolite.com>于2017年8月15日周二 下午2:52写道： > > 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. > Yeah, TXT is my history plan: Recursive Resolvers that support wildcard detect method with TXT record <https://github.com/abbypan/dns_wildcard_on_intermediate_nameservers/blob/a4188548c87b6a10af45aa23575b86d9f33f39ec/draft.txt> > > > > 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. > Both recursives and authoritatives. I mean more and more recursives and authoritatives enable DNSSEC for dns query by default configuration, sorry for my poor English. 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 The deployment problem is on the Authoritative Nameservers of billions of second level domains, not on TLD. And Recursive must enable DNSSEC validation for dns query by default configuration. > > ....................... > > ] 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 > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
