rfc9609v5.txt   rfc9609.txt 
Internet Engineering Task Force (IETF) P. Koch Internet Engineering Task Force (IETF) P. Koch
Request for Comments: 9609 DENIC eG Request for Comments: 9609 DENIC eG
BCP: 209 M. Larson BCP: 209 M. Larson
Obsoletes: 8109 P. Hoffman Obsoletes: 8109 P. Hoffman
Category: Best Current Practice ICANN Category: Best Current Practice ICANN
ISSN: 2070-1721 January 2025 ISSN: 2070-1721 February 2025
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
Abstract Abstract
This document describes the queries that a DNS resolver should emit This document describes the queries that a DNS resolver should emit
to initialize its cache. The result is that the resolver gets both a to initialize its cache. The result is that the resolver gets both a
current NS resource record set (RRset) for the root zone and the current NS resource record set (RRset) for the root zone and the
necessary address information for reaching the root servers. necessary address information for reaching the root servers.
skipping to change at line 230 skipping to change at line 230
Note that this recommended method is not the only way to choose from Note that this recommended method is not the only way to choose from
the list in a recursive resolver's configuration. Two other common the list in a recursive resolver's configuration. Two other common
methods include picking the first from the list, and remembering methods include picking the first from the list, and remembering
which address in the list gave the fastest response earlier and using which address in the list gave the fastest response earlier and using
that one. There are probably other methods in use today. However, that one. There are probably other methods in use today. However,
the random method SHOULD be used for priming. the random method SHOULD be used for priming.
3.3. DNSSEC with Priming Queries 3.3. DNSSEC with Priming Queries
The root NS RRset is signed and can be validated by a DNSSEC The root NS RRset is signed and can be validated by a DNSSEC
validating resolver. At the time this document was published, the validating resolver. At the time this document is published, the
addresses for the names in the root NS RRset are in the "root- addresses for the names in the root NS RRset are in the "root-
servers.net" zone. All root servers are also authoritative for the servers.net" zone. All root servers are also authoritative for the
"root-servers.net" zone, which allows priming responses to include "root-servers.net" zone, which allows priming responses to include
the appropriate root name server A and AAAA RRsets. However, because the appropriate root name server A and AAAA RRsets. However, because
at the time this document was published the "root-servers.net" zone at the time this document is published the "root-servers.net" zone is
is not signed, the root name server A and AAAA RRsets cannot be not signed, the root name server A and AAAA RRsets cannot be
validated. An attacker that is able to provide a spoofed priming validated. An attacker that is able to provide a spoofed priming
response can provide alternative A and AAAA RRsets and thus fool a response can provide alternative A and AAAA RRsets and thus fool a
resolver into considering addresses under the control of the attacker resolver into considering addresses under the control of the attacker
to be authoritative for the root zone. to be authoritative for the root zone.
A rogue root name server can view all queries from the resolver to A rogue root name server can view all queries from the resolver to
the root and alter all unsigned parts of responses, such as the the root and alter all unsigned parts of responses, such as the
parent-side NS RRsets and glue in referral responses. A resolver can parent-side NS RRsets and glue in referral responses. A resolver can
be fooled into trusting child (Top-Level Domain (TLD)) NS addresses be fooled into trusting child (Top-Level Domain (TLD)) NS addresses
that are under the control of the attacker as being authoritative if that are under the control of the attacker as being authoritative if
skipping to change at line 296 skipping to change at line 296
section with A and/or AAAA RRsets for the root servers pointed at by section with A and/or AAAA RRsets for the root servers pointed at by
the NS RRset. the NS RRset.
Resolver software SHOULD treat the response to the priming query as a Resolver software SHOULD treat the response to the priming query as a
normal DNS response, just as it would use any other data fed to its normal DNS response, just as it would use any other data fed to its
cache. Resolver software SHOULD NOT expect 13 NS RRs because, cache. Resolver software SHOULD NOT expect 13 NS RRs because,
historically, some root servers have returned fewer. historically, some root servers have returned fewer.
4.2. Completeness of the Response 4.2. Completeness of the Response
At the time this document was published, there are 13 root server At the time this document is published, there are 13 root server
operators operating a total of more than 1500 root server instances. operators operating a total of more than 1500 root server instances.
Each instance has one IPv4 address and one IPv6 address. The Each instance has one IPv4 address and one IPv6 address. The
combined size of all the A and AAAA RRsets exceeds the original combined size of all the A and AAAA RRsets exceeds the original
512-octet payload limit specified in [RFC1035]. 512-octet payload limit specified in [RFC1035].
In the event of a response where the Additional section omits certain In the event of a response where the Additional section omits certain
root server address information, reissuing of the priming query does root server address information, reissuing of the priming query does
not help with those root name servers that respond with a fixed order not help with those root name servers that respond with a fixed order
of addresses in the Additional section. Instead, the recursive of addresses in the Additional section. Instead, the recursive
resolver needs to issue direct queries for A and AAAA RRsets for the resolver needs to issue direct queries for A and AAAA RRsets for the
remaining names. At the time this document was published, these remaining names. At the time this document is published, these
RRsets would be authoritatively available from the root name servers. RRsets would be authoritatively available from the root name servers.
If some root server addresses are omitted from the Additional If some root server addresses are omitted from the Additional
section, there is no expectation that the TC bit in the response will section, there is no expectation that the TC bit in the response will
be set to 1. At the time this document was published, many of the be set to 1. At the time this document is written, many of the root
root servers are not setting the TC bit when omitting addresses from servers are not setting the TC bit when omitting addresses from the
the Additional section. Additional section.
Note that [RFC9471] updates [RFC1034] with respect to the use of the Note that [RFC9471] updates [RFC1034] with respect to the use of the
TC bit. It says TC bit. It says
| If message size constraints prevent the inclusion of all glue | If message size constraints prevent the inclusion of all glue
| records for in-domain name servers over the chosen transport, the | records for in-domain name servers over the chosen transport, the
| server MUST set the TC (Truncated) flag to inform the client that | server MUST set the TC (Truncated) flag to inform the client that
| the response is incomplete and that the client SHOULD use another | the response is incomplete and that the client SHOULD use another
| transport to retrieve the full response. | transport to retrieve the full response.
skipping to change at line 491 skipping to change at line 491
* Clarified that machine-in-the-middle attacks could be successful * Clarified that machine-in-the-middle attacks could be successful
for non-signed TLDs. for non-signed TLDs.
* Added discussion of where resolvers that pre-fetch should get the * Added discussion of where resolvers that pre-fetch should get the
root NS addresses. root NS addresses.
* Elevated the expectations in Section 4.1 ("Expected Properties of * Elevated the expectations in Section 4.1 ("Expected Properties of
the Priming Response") to MUST-level. the Priming Response") to MUST-level.
* Clarified that "currently" means "at the time this document was * Clarified that "currently" means "at the time this document is
published". published".
* Added a note about priming and RFC 8806. * Added a note about priming and RFC 8806.
* Added a reference to research about discontinued root server * Added a reference to research about discontinued root server
addresses. addresses.
Acknowledgements Acknowledgements
RFC 8109 was the product of the DNSOP WG and benefited from the RFC 8109 was the product of the DNSOP WG and benefited from the
 End of changes. 7 change blocks. 
10 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.48.