On Jan 10, 2024, at 14:05, Roy Arends <[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
