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

Reply via email to