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

[Paul Hoffman <[e-mail]>]

On Jan 10, 2024, at 14:05, Roy Arends <[e-mail]> wrote:
> I support this documents.

Thanks!

> 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.

Good idea; fixed.

> “published”

Already caught in all places, thanks.

>        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.

Excellent catch: fixed. (Background: more than a few ccTLDs are not signed.)


>        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.

We could replace "normal" with "ordinary", but they sound similar to me.

> 
>        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.

Already fixed from earlier comments.

>        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.

Ack.

>        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”

Ack.

Thanks!

--Paul Hoffman