rfc9609.original   rfc9609.txt 
Network Working Group P. Koch Internet Engineering Task Force (IETF) P. Koch
Internet-Draft DENIC eG Request for Comments: 9609 DENIC eG
Obsoletes: 8109 (if approved) M. Larson BCP: 209 M. Larson
Intended status: Best Current Practice P. Hoffman Obsoletes: 8109 P. Hoffman
Expires: 28 February 2025 ICANN Category: Best Current Practice ICANN
27 August 2024 ISSN: 2070-1721 November 2024
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-rfc8109bis-07
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.
This document, when published, obsoletes RFC 8109. See Appendix A This document obsoletes RFC 8109.
for the list of changes from RFC 8109.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 28 February 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9609.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Description of Priming . . . . . . . . . . . . . . . . . . . 3 2. Description of Priming
2.1. Content of Priming Information . . . . . . . . . . . . . 4 2.1. Content of Priming Information
3. Priming Queries . . . . . . . . . . . . . . . . . . . . . . . 4 3. Priming Queries
3.1. Repeating Priming Queries . . . . . . . . . . . . . . . . 5 3.1. Repeating Priming Queries
3.2. Target Selection . . . . . . . . . . . . . . . . . . . . 5 3.2. Target Selection
3.3. DNSSEC with Priming Queries . . . . . . . . . . . . . . . 5 3.3. DNSSEC with Priming Queries
4. Priming Responses . . . . . . . . . . . . . . . . . . . . . . 6 4. Priming Responses
4.1. Expected Properties of the Priming Response . . . . . . . 6 4.1. Expected Properties of the Priming Response
4.2. Completeness of the Response . . . . . . . . . . . . . . 7 4.2. Completeness of the Response
5. Post-Priming Strategies . . . . . . . . . . . . . . . . . . . 8 5. Post-Priming Strategies
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References
Appendix A. Changes from RFC 8109 . . . . . . . . . . . . . . . 10 Appendix A. Changes from RFC 8109
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
Recursive DNS resolvers need a starting point to resolve queries. Recursive DNS resolvers need a starting point to resolve queries.
[RFC1034] describes a common scenario for recursive resolvers: they [RFC1034] describes a common scenario for recursive resolvers: They
begin with an empty cache and some configuration for finding the begin with an empty cache and some configuration for finding the
names and addresses of the DNS root servers. [RFC1034] describes names and addresses of the DNS root servers. [RFC1034] describes
that configuration as a list of servers that will give authoritative that configuration as a list of servers that will give authoritative
answers to queries about the root. This has become a common answers to queries about the root. This has become a common
implementation choice for recursive resolvers, and is the topic of implementation choice for recursive resolvers and is the topic of
this document. this document.
This document describes the steps needed for this common This document describes the steps needed for this common
implementation choice. Note that this is not the only way to start a implementation choice. Note that this is not the only way to start a
recursive name server with an empty cache, but it is the only one recursive name server with an empty cache, but it is the only one
described in [RFC1034]. Some implementers have chosen other described in [RFC1034]. Some implementers have chosen other
directions, some of which work well and others of which fail directions, some of which work well and others of which fail
(sometimes disastrously) under different conditions. For example, an (sometimes disastrously) under different conditions. For example, an
implementation that only gets the addresses of the root name servers implementation that only gets the addresses of the root name servers
from configuration, not from the DNS as described in this document, from configuration, not from the DNS as described in this document,
will have stale data that could cause slower resolution. will have stale data that could cause slower resolution.
This document only deals with recursive name servers (recursive This document only deals with recursive name servers (recursive
resolvers, resolvers) for the IN class. resolvers, resolvers) for the IN class.
See Appendix A for the list of changes from [RFC8109].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
See [RSSAC026v2] for terminology that relates to the root server See [RSSAC026v2] for terminology that relates to the root server
system. See [RFC9499] for terminology that relates to the DNS in system. See [RFC9499] for terminology that relates to the DNS in
general. general.
2. Description of Priming 2. Description of Priming
Priming is the act of finding the list of root servers from a Priming is the act of finding the list of root servers from a
configuration that lists some or all of the purported IP addresses of configuration that lists some or all of the purported IP addresses of
some or all of those root servers. In priming, a recursive resolver some or all of those root servers. In priming, a recursive resolver
starts with no cached information about the root servers, and starts with no cached information about the root servers, and it
finishes with a full list of their names and their addresses in its finishes with a full list of their names and addresses in its cache.
cache.
Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. (It Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. (It
is called "SBELT", a "safety belt" structure, in that document.) The is called "SBELT", a "safety belt" structure, in that document.) The
scenario used in that description, that of a recursive server that is scenario used in that description, that of a recursive server that is
also authoritative, is no longer as common. also authoritative, is no longer as common.
The configured list of IP addresses for the root servers usually The configured list of IP addresses for the root servers usually
comes from the vendor or distributor of the recursive server comes from the vendor or distributor of the recursive server
software. Although this list is generally accurate and complete at software. Although this list is generally accurate and complete at
the time of distribution, it may become outdated over time. the time of distribution, it may become outdated over time.
skipping to change at page 4, line 7 skipping to change at line 144
Therefore, it is important that resolvers are able to cope with Therefore, it is important that resolvers are able to cope with
change, even without relying upon configuration updates to be applied change, even without relying upon configuration updates to be applied
by their operator. Root server identifier and address changes are by their operator. Root server identifier and address changes are
the main reasons that resolvers need to use priming to get a full and the main reasons that resolvers need to use priming to get a full and
accurate list of root servers, instead of just using a statically accurate list of root servers, instead of just using a statically
configured list. configured list.
See [RSSAC023v2] for a history of the root server system. See [RSSAC023v2] for a history of the root server system.
Although this document is targeted at the global DNS, it also could Although this document is targeted at the global DNS, it could apply
apply to a private DNS as well. These terms are defined in to a private DNS as well. These terms are defined in [RFC9499].
[RFC9499].
Some systems serve a copy of the full root zone on the same server as Some systems serve a copy of the full root zone on the same server as
the resolver, such as is described in [RFC8806]. In such a setup, the resolver, e.g., as described in [RFC8806]. In such a setup, the
the resolver primes its cache using the same methods as described in resolver primes its cache using the same methods as those described
the rest of this document. in the rest of this document.
2.1. Content of Priming Information 2.1. Content of Priming Information
As described above, the configuration for priming is a list of IP As described above, the configuration for priming is a list of IP
addresses. The priming information in software may be in any format addresses. The priming information in software may be in any format
that gives the software the addresses associated with at least some that gives the software the addresses associated with at least some
of the root server identifiers. of the root server identifiers.
Some software has configuration that also contains the root server Some software has configuration that also contains the root server
identifiers (such as "L.ROOT-SERVERS.NET"), sometimes as comments and identifiers (such as "L.ROOT-SERVERS.NET"), sometimes as comments and
sometimes as data consumed by the software. For example, the "root sometimes as data consumed by the software. For example, the "root
hints file" published by IANA at <https://www.internic.net/domain/ hints file" published by IANA at <https://www.internic.net/domain/
named.root> is derived directly from the root zone and contains all named.root> is derived directly from the root zone and contains all
of the addresses of the root server identifiers found in the root of the addresses of the root server identifiers found in the root
zone. It is in DNS zone file presentation format, and includes the zone. It is in DNS zone file presentation format and includes the
root server identifiers. Although there is no harm to adding these root server identifiers. Although there is no harm in adding these
names, they are not useful in the priming process. names, they are not useful in the priming process.
3. Priming Queries 3. Priming Queries
A priming query is a DNS query whose response provides root server A priming query is a DNS query whose response provides root server
identifiers and addresses. It has a QNAME of ".", a QTYPE of NS, and identifiers and addresses. It has a QNAME of ".", a QTYPE of NS, and
a QCLASS of IN; it is sent to one of the addresses in the a QCLASS of IN; it is sent to one of the addresses in the
configuration for the recursive resolver. The priming query can be configuration for the recursive resolver. The priming query can be
sent over either UDP or TCP. If the query is sent over UDP, the sent over either UDP or TCP. If the query is sent over UDP, the
source port SHOULD be randomly selected (see [RFC5452]) to hamper on- source port SHOULD be randomly selected (see [RFC5452]) to hamper on-
path attacks. DNS cookies [RFC7873] can also be used to hamper on- path attacks. DNS Cookies [RFC7873] can also be used to hamper on-
path attacks. The Recursion Desired (RD) bit SHOULD be set to 0. path attacks. The Recursion Desired (RD) bit SHOULD be set to 0.
The meaning when RD is set to 1 is undefined for priming queries and The meaning when RD is set to 1 is undefined for priming queries and
outside the scope of this document. is outside the scope of this document.
The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries
and SHOULD announce and handle a reassembly size of at least 1024 and SHOULD announce and handle a reassembly size of at least 1024
octets [RFC3226]. Doing so allows responses that cover the size of a octets [RFC3226]. Doing so allows responses that cover the size of a
full priming response (see Section 4.2) for the current set of root full priming response (see Section 4.2) for the current set of root
servers. See Section 3.3 for discussion of setting the DNSSEC OK servers. See Section 3.3 for discussion of setting the DNSSEC OK
(DO) bit (defined in [RFC4033]). (DO) bit (defined in [RFC4033]).
3.1. Repeating Priming Queries 3.1. Repeating Priming Queries
The recursive resolver SHOULD send a priming query only when it is The recursive resolver SHOULD send a priming query only when it is
needed, such as when the resolver starts with an empty cache or when needed, such as when the resolver starts with an empty cache or when
the NS RRset for the root zone has expired. Because the NS records the NS resource record set (RRset) for the root zone has expired.
for the root zone are not special, the recursive resolver expires Because the NS records for the root zone are not special, the
those NS records according to their TTL values. (Note that a recursive resolver expires those NS records according to their TTL
recursive resolver MAY pre-fetch the NS RRset before it expires.) values. (Note that a recursive resolver MAY pre-fetch the NS RRset
before it expires.)
If a resolver chooses to pre-fetch the root NS RRset before that If a resolver chooses to pre-fetch the root NS RRset before that
RRset has expired in its cache, it needs to choose whether to use the RRset has expired in its cache, it needs to choose whether to use the
addresses for the root NS RRset that it already has in its cache or addresses for the root NS RRset that it already has in its cache or
to use the addresses it has in its configuration. Such a resolver to use the addresses it has in its configuration. Such a resolver
SHOULD send queries to the addresses in its cache in order to reduce SHOULD send queries to the addresses in its cache in order to reduce
the chance of delay due to out-of-date addresses in its the chance of delay due to out-of-date addresses in its
configuration. configuration.
If a priming query does not get a response, the recursive resolver If a priming query does not get a response, the recursive resolver
skipping to change at page 5, line 45 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 listed above SHOULD be used for priming. the random method listed above 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 is published, the validating resolver. At the time this document was 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 is published the "root-servers.net" zone is at the time this document was published the "root-servers.net" zone
not signed, the root name server A and AAAA RRsets cannot be is 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 (TLD) NS addresses that are under the be fooled into trusting child (Top-Level Domain (TLD)) NS addresses
control of the attacker as being authoritative if the resolver: that are under the control of the attacker as being authoritative if
the resolver:
* follows referrals from a rogue root server, * follows referrals from a rogue root server,
* and does not explicitly query the authoritative NS RRset at the * does not explicitly query the authoritative NS RRset at the apex
apex of the child (TLD) zone, of the child (TLD) zone, and
* and does not explicitly query for the authoritative A and AAAA * does not explicitly query for the authoritative A and AAAA RRsets
RRsets for the child (TLD) NS RRsets. for the child (TLD) NS RRsets.
With such resolvers, an attacker that controls a rogue root server With such resolvers, an attacker that controls a rogue root server
effectively controls the entire domain name space and can view all effectively controls the entire domain name space and can view all
queries and alter all unsigned data undetected unless other queries and alter all unsigned data undetected unless other
protections are configured at the resolver. protections are configured at the resolver.
An attacker controlling a rogue root name server also has complete An attacker controlling a rogue root name server also has complete
control over all unsigned delegations, and over the entire domain control over all unsigned delegations and over the entire domain name
name space in case of non DNSSEC validating resolvers. space in the case of non-DNSSEC validating resolvers.
If the "root-servers.net" zone is later signed, or if the root If the "root-servers.net" zone is later signed or if the root servers
servers are named in a different zone and that zone is signed, having are named in a different zone and that zone is signed, having DNSSEC
DNSSEC validation for the priming queries might be valuable. The validation for the priming queries might be valuable. The benefits
benefits and costs of resolvers validating the responses will depend and costs of resolvers validating the responses will depend heavily
heavily on the naming scheme used. on the naming scheme used.
4. Priming Responses 4. Priming Responses
A priming query is a normal DNS query. Thus, a root server cannot 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 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 RRset. Thus, the root server's response will also be a normal DNS
response. response.
4.1. Expected Properties of the Priming Response 4.1. Expected Properties of the Priming Response
The priming response MUST have an RCODE of NOERROR, and MUST have the The priming response MUST have an RCODE of NOERROR and MUST have the
Authoritative Answer (AA) bit set. Also, it MUST have an NS RRset in Authoritative Answer (AA) bit set. Also, it MUST have an NS RRset in
the Answer section (because the NS RRset originates from the root the Answer section (because the NS RRset originates from the root
zone), and an empty Authority section (because the NS RRset already zone) and an empty Authority section (because the NS RRset already
appears in the Answer section). There will also be an Additional appears in the Answer section). There will also be an Additional
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 is published, there are 13 root server At the time this document was published, there are 13 root server
operators operating a total of more than 1,500 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 from [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, re-issuing 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 is published, these remaining names. At the time this document was 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 (Truncated) bit in the
be set to 1. At the time that this document is written, many of the response will be set to 1. At the time this document was published,
root servers are not setting the TC bit when omitting addresses from many of the root servers are not setting the TC bit when omitting
the Additional section. addresses from the Additional section.
Note that [RFC9471] updates [RFC1035] with respect to the use of the Note that [RFC9471] updates [RFC1035] with respect to the use of the
TC bit. It says "If message size constraints prevent the inclusion TC bit. It says
of all glue records for in-domain name servers, the server must set
the TC (Truncated) flag to inform the client that the response is | If message size constraints prevent the inclusion of all glue
incomplete and that the client should use another transport to | records for in-domain name servers, the server must set the TC
retrieve the full response." Because the priming response is not a | (Truncated) flag to inform the client that the response is
referral, root server addresses in the priming response are not | incomplete and that the client should use another transport to
considered glue records. Thus, [RFC9471] does not apply to the | retrieve the full response.
priming response and root servers are not required to set the TC bit
if not all root server addresses fit within message size constraints. Because the priming response is not a referral, root server addresses
There are no requirements on the number of root server addresses that in the priming response are not considered glue records. Thus,
a root server must include in a priming response. [RFC9471] does not apply to the priming response and root servers are
not required to set the TC bit if not all root server addresses fit
within message size constraints. There are no requirements on the
number of root server addresses that a root server must include in a
priming response.
5. Post-Priming Strategies 5. Post-Priming Strategies
When a resolver has a zone's NS RRset in cache, and it receives a When a resolver has a zone's NS RRset in its cache and it receives a
query for a domain in that zone that cannot be answered from its 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 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 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 DNS.) Two common strategies for choosing are "determine the fastest
name server and always use it" and "create buckets of fastness and name server and always use it" and "create buckets of fastness and
pick randomly in the buckets". This document gives no preference to pick randomly in the buckets". This document does not specify a
any particular strategy other than to suggest that resolvers not preference for any particular strategy other than to suggest that
treat the root zone as special for this decision. resolvers not treat the root zone as special for this decision.
6. Security Considerations 6. Security Considerations
Spoofing a response to a priming query can be used to redirect all of Spoofing a response to a priming query can be used to redirect all of
the queries originating from a victim recursive resolver to one or the queries originating from a victim recursive resolver to one or
more servers for the attacker. Until the responses to priming more servers for the attacker. Until the responses to priming
queries are protected with DNSSEC, there is no definitive way to queries are protected with DNSSEC, there is no definitive way to
prevent such redirection. prevent such redirection.
An on-path attacker who sees a priming query coming from a resolver An on-path attacker who sees a priming query coming from a resolver
can inject false answers before a root server can give correct can inject false answers before a root server can give correct
answers. If the attacker's answers are accepted, this can set up the answers. If the attacker's answers are accepted, this can set up the
ability to give further false answers for future queries to the ability to give further false answers for future queries to the
resolver. False answers for root servers are more dangerous than, resolver. False answers for root servers are more dangerous than,
say, false answers for Top-Level Domains (TLDs), because the root is say, false answers for TLDs, because the root is the highest node of
the highest node of the DNS. See Section 3.3 for more discussion. the DNS. See Section 3.3 for more discussion.
In both of the scenarios above, a validating resolver will be able to In both of the scenarios above, a validating resolver will be able to
detect the attack if its chain of queries comes to a zone that is detect the attack if its chain of queries comes to a zone that is
signed, but not for those that are unsigned. signed, but not for those that are unsigned.
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA actions. This document has no IANA actions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 10, line 5 skipping to change at line 430
Glue Requirements in Referral Responses", RFC 9471, Glue Requirements in Referral Responses", RFC 9471,
DOI 10.17487/RFC9471, September 2023, DOI 10.17487/RFC9471, September 2023,
<https://www.rfc-editor.org/info/rfc9471>. <https://www.rfc-editor.org/info/rfc9471>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024, RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>. <https://www.rfc-editor.org/info/rfc9499>.
8.2. Informative References 8.2. Informative References
[OLD-J] Wessels, D., "Thirteen Years of 'Old J Root'", 2015, [OLD-J] Wessels, D., Castonguay, J., and P. Barber, "Thirteen
Years of 'Old J Root'", DNS-OARC Fall 2015 Workshop,
October 2015,
<https://indico.dns-oarc.net/event/24/contributions/378/>. <https://indico.dns-oarc.net/event/24/contributions/378/>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>. <https://www.rfc-editor.org/info/rfc8806>.
[RSSAC023v2] [RSSAC023v2]
"History of the Root Server System", 2016, "History of the Root Server System", A Report from the
ICANN Root Server System Advisory Committee (RSSAC),
RSSAC023v2, June 2020,
<https://www.icann.org/en/system/files/files/rssac- <https://www.icann.org/en/system/files/files/rssac-
023-17jun20-en.pdf>. 023-17jun20-en.pdf>.
[RSSAC026v2] [RSSAC026v2]
"RSSAC Lexicon", 2020, "RSSAC Lexicon", An Advisory from the ICANN Root Server
System Advisory Committee (RSSAC), RSSAC026v2, March 2020,
<https://www.icann.org/en/system/files/files/rssac-026- <https://www.icann.org/en/system/files/files/rssac-026-
lexicon-12mar20-en.pdf>. lexicon-12mar20-en.pdf>.
Appendix A. Changes from RFC 8109 Appendix A. Changes from RFC 8109
This document obsoletes [RFC8109]. The significant changes from RFC This document obsoletes [RFC8109]. The significant changes from RFC
8109 are: 8109 are as follows:
* Added section on the content of priming information. * Added section on the content of priming information.
* Added paragraph about no expectation that the TC bit in responses * Added paragraph about no expectation that the TC bit in responses
will be set. will be set.
* Added paragraph about RFC 9471 and requirements on authoritative * Added paragraph about RFC 9471 and requirements on authoritative
servers and the TC bit. This clarified the role of glue records servers and the TC bit. This clarified the role of glue records
and truncation for responses from the root zone. and truncation for responses from the root zone.
skipping to change at page 10, line 47 skipping to change at line 477
more inclusive and more technically accurate. more inclusive and more technically accurate.
* Clarified that there are other effects of machine-in-the-middle * Clarified that there are other effects of machine-in-the-middle
attacks. attacks.
* Clarified language for root server domain names as "root server * Clarified language for root server domain names as "root server
identifiers". identifiers".
* Added short discussion of post-priming strategies. * Added short discussion of post-priming strategies.
* Added informative references to RSSAC documents. * Added informative references to Root Server System Advisory
Committee (RSSAC) documents.
* Added short discussion about this document and private DNS. * Added short discussion about this document and private DNS.
* 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 "Expected Properties of the Priming * Elevated the expectations in Section 4.1 ("Expected Properties of
Response" to MUST-level. the Priming Response") to MUST-level.
* Clarified that "currently" means at the time that this document is * Clarified that "currently" means "at the time this document was
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.
Appendix B. Acknowledgements Acknowledgements
RFC 8109 was the product of the DNSOP WG and benefitted from the RFC 8109 was the product of the DNSOP WG and benefited from the
reviews done there. This document also benefitted from review by reviews done there. This document also benefited from review by
Duane Wessels. Duane Wessels.
Authors' Addresses Authors' Addresses
Peter Koch Peter Koch
DENIC eG DENIC eG
Kaiserstrasse 75-77 Kaiserstrasse 75-77
60329 Frankfurt 60329 Frankfurt
Germany Germany
Phone: +49 69 27235 0 Phone: +49 69 27235 0
 End of changes. 47 change blocks. 
127 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48.