Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Roy Arends <[e-mail]>]

Let me try that again with proper indentation.

> On 9 Jan 2024, at 01:54, Tim Wicinski <[e-mail]> wrote:
> 
> All
> 
> 
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
> 
> The Current Intended Status of this document is: Best Current Practice
> 
> Please review the draft and offer relevant comments.
> 
> For WGLC, we need *positive support and constructive comments*; lack of objection is not enough.
> So if you think this draft should be published as an RFC, please say so.
> 
> If you feel the document is *not* ready for publication, please speak out with your reasons.
> 
> 
> This starts a two week Working Group Last Call process, and ends on: January 22, 2024
> 
> thanks

Thanks Tim,

I support this documents. Furthermore, here are some comments:

        2. Description of Priming
        
        Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The
        scenario used in that description, that of a recursive server that is
        also authoritative, is no longer as common.

The term “Priming” is not used in RFC1034. What is used in RFC1034 is the term SBELT ("safety belt” structure), defined in 5.3.2. The reference is more useful when the term SBELT is included.

        3.3. DNSSEC with Priming Queries

        The resolver MAY set the DNSSEC OK (DO) bit. At the time of
        publication, there is little use to performing DNSSEC validation on
        the priming query. At the time this document is pulished, all root

“published”

        server names end in "root-servers.net" and the AAAA and A RRsets for
        the root server names reside in the "root-servers.net" zone. All
        root servers are also authoritative for this zone, allowing priming
        responses to include the appropriate root name server A and AAAA
        RRsets. But, because the "root-servers.net" zone is not signed at
        the time this document is pulished, these RRsets cannot be validated.

“published"

        A machine-in-the-middle attack on the priming query could direct a
        resolver to a rogue root name server. Note, however, that a
        validating resolver will not accept responses from rogue root servers
        if they are different from the real responses because the resolver
        has a trust anchor for the root and the answers from the root are
        signed.  Thus, if there is a machine-in-the-middle attack on the
        priming query, the results for a validating resolver could be a
        denial of service, or the attacker seeing queries while returning
        good answers, but not the resolver's accepting the bad responses.

This is misleading. Not all answers from the root are signed. Some content in the root zone is signed, delegation point NS records are not. This attack will be successful when rogue root-servers change delegation information to unsigned zones. This needs to be more precise.

        If the "root-servers.net" zone is later signed, or if the root
        servers are named in a different zone and that zone is signed, having
        DNSSEC validation for the priming queries might be valuable. The
        benefits and costs of resolvers validating the responses will depend
        heavily on the naming scheme used.

Not necessarily. This attack will be successful when rogue root-servers change delegation information to unsigned zones (see above) and is not dependent on a naming scheme.

        4. Priming Responses

        A priming query is a normal DNS query. Thus, a root server cannot
        distinguish a priming query from any other query for the root NS
        RRset. Thus, the root server's response will also be a normal DNS
        response.

Apologies for sounding pedantic, but what is “a normal DNS query” or a “normal DNS response” ? 

If there is no definition, maybe the following works for you:

The term “Priming” reflects the intent of the resolver. A root server cannot distinguish a priming query from any other root type NS query. The root server's response will therefore be an ordinary DNS response.

        4.2. Completeness of the Response

        At the time this document is pulished, there are 13 root servers.

“published"

There are 13 hostnames, or root server identifiers. "13 root servers" implies that there are 13 physical boxes.

        Each has one IPv4 address and one IPv6 address. Not even counting
        the NS RRset, the combined size of all the A and AAAA RRsets exceeds
        the original 512-octet payload limit from [RFC1035].

Remove “Not even counting the NS RRset, ”. The remainder of the sentence says enough.

        In the event of a response where the Additional section omits certain
        root server address information, 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 recursive
        resolver needs to issue direct queries for A and AAAA RRsets for the
        remaining names. At the time this document is pulished, these RRsets

“published”

        would be authoritatively available from the root name servers.

        5. Post-Priming Strategies

        When a resolver has a zone's NS RRset in cache, and it gets a query
        for a domain in that zone that cannot be answered from its cache, the
        resolver has to choose which NS to send queries to. (This statement
        is as true for the root zone as for any other zone in the DNS.) Two
        common strategies for choosing are "determine the fastest nameserver

“name server”

Hope this helps,

Warmly,

Roy