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
