Every morning I wake up, racked with guilt for not having actually reviewed this document. I open my mailbox, and one of Paul Hoffman's "Bi-weekly reminder of the documents for the WG" emails pops up, making me cringe... well, no more...
Below are some comment, in OPR/C format. Almost entirely nits, but also some comments on the outlined issues / questions... Now I am finally unburdened, and can get some rest... W Initializing a DNS Resolver with Priming Queries draft-ietf-dnsop-resolver-priming-04 Abstract This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. [O] supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. [P] supposed to emit, in order to initialize its cache with a current NS RRSet for the root zone, as well as the necessary address information. [C] Readability. This does make your abstract ~12 characters longer, which *might* make Ted Lemon. Whether this is a feature or a bug is left up to you :-P [ SNIP ] 1. Introduction Domain Name System (DNS) resolvers need a starting point to resolve queries. [RFC1034], section 5.3.2, defines the SBELT structure in a full resolver as: ``a "safety belt" structure of the same form as SLIST, which is [O] ``a "safety belt" [P] "a safety belt" [R] correct initial double quote - actually the quotes are somewhat odd throughout the document. initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The match count will be -1 to indicate that no labels are known to match.'' [O] match.' ' [P] match." [R] replaced two single quotes with a double quote. Section 5.3.3 of [RFC1034] adds ``the usual choice is two of the root servers and two of the servers for the host's domain'' Today's practice generally seperates serving and resolving functionality, so the servers ``for the host's domain'' might no [O] serving and resolving functionality, [P] serving and resolving functionalities [R] made plural because the point is that they are to separate items. longer be an appropriate choice, even if they were only intended to resolve ``local'' names, especially since the SBELT structure does not distinguish between local and global information. In addition, DNS server implementations have for a long time been seeded with not only two but an exhaustive list of the root servers' addresses. This list is either supplied as a configuration file (root "hints", an excerpt of the DNS root zone) or even compiled into the software. [ SNIP ] 2. Priming Queries This document only deals with recursive name servers (recursive resolvers, resolvers) for the IN CLASS. 2.3. Target Selection A resolver MUST select the target for a priming query randomly from the list of addresses (IPv4 and IPv6) available in its SBELT structure and it MUST ensure that all targets are selected with equal probability even upon startup. For resending the priming query to a different server the random selection SHOULD also be used. [O] For resending the priming query to a different server the random sele= ction SHOULD also be used. [P] The random selection SHOULD also be used for resending the priming qu= ery to a different server. [R] readability 3.3. Completeness of the Response Assuming an upper bound of thirteen root name servers and one address each for IPv4 and IPv6, the combined size of all the A and AAAA RRSets is 13 * (16 + 28) =3D=3D 572, independent of the naming scheme. Not even counting the NS RRSet, this value exceeds the original 512 octet payload limit. For an EDNS response, a resolver SHOULD consider the address information found in the additional section complete for any particular server that appears at all. In other words: if the additional section only has an A RRSet for a server, the resolver SHOULD assume that no AAAA RRSet exists. This is to avoid repeated unnecessary queries for names of name servers that do not or not yet [O] do not or not yet [P] do not or do not yet [R] readability offer IPv6 service, or, in perspective, will have ceased IPv4 service. If the resolver did not announce a reassembly size larger than 512 octets, this assumption is invalid. Simple re-issuing of the priming query does not help with those root name servers that respond with a fixed order of addresses in the additional section. Instead the [O] additional section [P] Additional section [R] consistency resolver ought to issue direct queries for A and AAAA RRSets for the remaining names. In today's environment these RRSets would be authoritatively available from the root name servers. 4. Requirements for Root Name Servers and the Root Zone The operational requirements for root name servers are described in [RFC2870]. This section specifies additional guidance for the configuration of and software deployed at the root name servers. All DNS root name servers need to be able to provide for all addresses of all root name servers. This can easily achieved by keeping all root name server names in a single zone and by making all root name servers authoritative for that zone. If the response packet does not provide for more than 512 octets due to lack of EDNS0 support, A RRSets SHOULD be given preference over AAAA RRSets when filling the additional section. [[Issue 1: EDNS0 is used as an indication of AAAA understanding on the side of the client. What to do with payload sizes indicated by EDNS0 that are smaller than 1024, is open to discussion. At the time of writing, some root name servers will fill the additional section with all available A RRSets, only adding some AAAA RRSets, when queried over IPv4 without EDNS0. Other servers will deliver more AAAA RRSets, therefore withholding some A RRSets completely [RFC4472].]] [R] IMO this needs more discussion in DNSOP and / or RSSAC and / or over beers. Personally I think that simply noting this behavior and then moving on with life is perfectly fine, but I'm somewhat of the "if it ain't (obviously) broke don't touch it" school. To ensure equal availability the A and AAAA RRSets for the root name servers' names SHOULD have identical TTL values at the authoritative source. Koch & Larson Expires August 18, 2014 [Page 5] =0C Internet-Draft DNS Priming Queries February 2014 [[Issue 2: Do the TTLs for the root NS RRSet and address RRSets in the root and the ROOT-SERVERS.NET. zones need to be aligned? In real life responses, the address RRSet's TTL values vary by name server implementation. Is this diversity we can live with? Should the authoritative source prevail? Is it therefore a protocol issue rather than an operational choice of parameters?]] [R] I think this is also a "don't poke at it" issue. Aligning these would require changing the TTL in either (or, gulp, both) . or ROOT-SERVERS.NET - neither sounds like the solution is worth opening this can of worms over. I think that this document should simply explain what a priming query is, and what whey look like. I don't think that changing the TTLs (on . or root-servers.net) should happen in this document, at least not without a much longer (and stronger) argument as to what we are solving... 5. Security Considerations This document deals with priming a DNS resolver's cache. The usual DNS caveats apply. Use of DNSSEC with priming queries is discussed in section 2.4. Spoofing a response to a priming query can be used to redirect all queries originating from a victim resolver, therefore any difference [O] resolver, therefore [P] resolver; therefore, [R] grammar/run on sentence between the inital SBELT list and the priming response SHOULD be brought to the operators' attention. There is also a chance that the random target selection chooses the address of a retired root name server. Operational measures to prevent reuse of these addresses are out of the scope of this document. 6. IANA Considerations This document does not propose any new IANA registry nor does it ask for any allocation from an existing IANA registry. However, this document deals with requirements for the root zone and root server operations. [[Issue3: related to issue 2 - any recommendation on the "." NS RRSet TTL or the TTLs of the respective A and/or AAAA RRSets might go here.]] [R] Ok, y'all have fun with that... More seriously, what problem exactly are we trying to solve here? I may just be a little ornery today[0]... W [0]: Actually, let's instead say that I'm trying to spark conversation, it sounds better... :-) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop