On Fri, Aug 15, 2008 at 11:29:13AM -0700, David Conrad wrote: > However, because of DO, folks who don't configure their resolvers to > do DNSSEC shouldn't ever see any DNSSEC goop.
so, one question is whether the "DO" bit actually signals understanding of the correct version of DNSSEC and what that means for responses with RRSIGs absent any trust anchor at the resolver. Just as a random data point, DE servers "see" 20-35% of the queries carry the DO bit. > That is, if you don't care about DNSSEC, do you think it would be > bad(tm) if the root were to be signed (for the sake of argument, > ignore the time waste, administrative overhead, etc. associated with > DNSSEC-signing)? If so, why? Not flagging confirmed issues, but trying to focus on what _could_ be problematic, based on perceived change: For non-DO sending resolvers, only responses to ANY queries for the "." itself as well as all TLDs should grow. There is no good reason to ask for ANY in the first place, but we have seen reports mentioning problems with size issues and ANY before. Priming should not be affected since it is supposed to work by QTYPE NS only. All TLDs will have an NSEC RR as well as an RRSIG (assuming the root won't be signed using NSEC3), the signed TLDs will have an additional DS RR and its RRSIG RR. Also, at least the DS/RRSIG pair is now authoritative in the parent, so an ANY query for, say, a signed SE to the root name servers will result in data in the answer section. However, this behaviour isn't new because old software didn't really always send true referrals, but used the delegation NS RRs to fill the answer section. Of course, one might claim that anybody using ANY in any production system (pun intended) gets what they deserve. These effects should be visible now, but since we can't judge what query load the signed zones face today and whether the resolver population is representative in any way, it's hard to tell that issues would already have hit the surface. Apart from the priming all of the above would equally apply to TLDs, SLDs or otehr levels of the hierarchy. -Peter (hatless) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
