Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-7706bis-10: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. Such resolvers can greatly decrease the round-trip time and Can I suggest to s/Such resolvers/In both cases, resolvers/? Section 1 The primary goals of this design are to provide more reliable answers for queries to the root zone during network attacks, and to prevent queries and responses from being visible on the network. This design will probably have little effect on getting faster responses to stub resolver for good queries on TLDs, because the TTL for most TLDs is usually long-lived (on the order of a day or two) and is thus usually already in the cache of the recursive resolver; the same is true for the TTL for negative answers from the root servers. (Although the primary goal of the design is for serving the root zone, the method can be used for any zone.) Are there any considerations of note when using this method for a zone other than the root zone? Section 1.1 (I expect the RFC Editor will change things to use a consistent construction for the last five paragraphs, regarding "this document <X>" vs. just "<X>".) Section 2 only respond to queries from the same host. One way to assure not responding to queries from other hosts is to run an authoritative server for the root that responds only on one of the loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 nit(?): in principle there's nothing to stop such a service from responding on more than one loopback address ... not that I can think of a reason why one would want to. Section 3 There is a risk that a system using a local authoritative server for the root zone cannot refresh the contents of the root zone before the expire time in the SOA. A system using a local authoritative server for the root zone MUST NOT serve stale data for the root zone. To mitigate the risk that stale data is served, the local root server MUST immediately switch to using non-local root servers. Immediately ... upon what condition? Section 4 We should probably discuss the consequences for when the SHOULD NOT is ignored and the glue records in the root zone are changed. As stated in Section 1, this design explicitly allows the local copy of the root zone information to be available only from resolvers on that host. This has the security property of limiting damage to nit: "allows [...] to be available only from" or "requires [...] to be available only from"? (Or "only allows [...] to be available from", of course.) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
