> On 9 Jan 2024, at 01:54, Tim Wicinski <tjw.i...@gmail.com> 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 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
