On 2/29/16, 11:26, "Paul Hoffman" <[email protected]> wrote:
>Please no. (Ed might disagree with me on this.) I think every document >that talks about the DNS in the IETF is about the IANA-administered DNS >except where loudly noted. I very much disagree coming from operating DNS on networks other than the global public Internet. This isn't about alternate versions of root zones, but about separating the operations ecosystem from the protocol engineering architecture. On 29 Feb 2016, at 6:12, Shane Kerr wrote: >Can't a couple sentences address this concern? > >"If the root zone is not DNSSEC signed with NSEC records then the >Cheese Shop is closed and this document does not apply. Resolvers MUST >continue to work in such an environment." I have problems with this. It's not that the proposal would be okay if wrapped in 15 layers of "this only works for this small problem, don't extrapolate". Setting a precedent for special handling of one zone would be a bad example for future expeditions. Some might take this as meaning that assembling an NXDOMAIN from DNSSEC negative answers can only ever be done for the root zone. The question I have is "why is the root zone special?" Why is it supposedly a simple use case? The draft document does not establish why the root is special. Quoting section 2: # The scope of this document is limited to the special case of # recursive DNSSEC validating resolvers querying the root zone. This # is because the root zone has some well known properties which make it # a special case - we know it is DNSSEC signed, and uses NSEC, the # majority of the queries are "junk" queries, the rate of change is # relatively slow, and there are no odd corner cases such as wildcards. For any zone I can discover any of these things. We can tell if the data set is supposed to be signed, from that the zone, the presence of wildcards, and so on. A cache could, in a few retrievals, obtain all of the relevant records to determine a name error. in Section 3: # For the limited use case of this document (the DNS root) we believe # that this is an acceptable trade off - the (current) TTL of the # "negative cache" (in the SOA) is the same as the NSEC TTL (1 day). Again - what's significant? The values - for any zone easily discoverable. The timing? The TTL setting here is one hand clapping, what's the rate of queries toward the zone? It's relative. My discomfort regarding fracturing the protocol is that the recommendation is to alter a core algorithm of DNS resolvers (not tools around the DNS) based on the qname believed to be managed from the root zone. Will the "only-root" remain, will this open the barn for other protocol hacks to be special for a particular zone? Those are future considerations that drive me to keep operation optimizations out of the core algorithm. More pragmatically, what happens to code drops that restrict this to just the root once it is opened up to the rest of the tree? More planned obsolescence? I don't see why aggressive use of DNSSEC negative answers is any more or less risky at other levels of the hierarchy. I don't see why the root is special. I'm not convinced by the draft that it is. And I don't see this as much of an interoperability issue. We know that not all resolvers are written to be equal - there are domain names that appear in the upper rankings of URL activity that cannot be resolved via conventional means - yet people get to the sites. Resolvers already do funky things - and as someone who has been on the authoritative side for a long time, there's no standard behavior across resolvers. (Server selection, anyone?) So, why worry about this in an IETF document? Why don't implementers just try it and then compare "performance" (in quotes because I leave it up to the viewer to define the measurement)? What about an "experimental" describing trying this, with metrics for success, to be follow up in a year or so with numbers on the trade off? The mere documentation of how might be enough for some developers to include this in their code.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
