draft-ietf-dnsop-resolver-priming-07.txt   draft-ietf-dnsop-resolver-priming-08.txt 
Network Working Group P. Koch Network Working Group P. Koch
Internet-Draft DENIC eG Internet-Draft DENIC eG
Intended status: Best Current Practice M. Larson Intended status: Best Current Practice M. Larson
Expires: September 20, 2016 Dyn, Inc. Expires: February 27, 2017 P. Hoffman
P. Hoffman
ICANN ICANN
March 19, 2016 August 26, 2016
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-07 draft-ietf-dnsop-resolver-priming-08
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 RRSet for the root zone and the necessary address current NS RRSet for the root zone and the necessary address
information for reaching the root servers. information for reaching the root servers.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 20, 2016. This Internet-Draft will expire on February 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
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. A recursive resolver starts with some or all of those root servers. A recursive resolver starts with
no information about the root servers, and ends up with a list of no information about the root servers, and ends up with a list of
their names and their addresses. their names and their addresses.
Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The 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 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 address for the root servers usually comes The configured list of IP addresses for the root servers usually
from the vendor or distributor of the recursive server software. comes from the vendor or distributor of the recursive server
This list is usually correct and complete when shipped, but may software. This list is usually correct and complete when shipped,
become out of date over time. but may become out of date over time.
The list of root server operators and the domain name associated with The list of root server operators and the domain name associated with
each one has been stable since 1997. However, there are address each one has been stable since 1997. However, there are address
changes for the NS records for those root server operators, both for changes for the root server domain names, both for IPv4 and IPv6
IPv4 and IPv6 addresses. However, research shows that after those addresses. However, research shows that after those addresses
addresses change, some resolvers never get the new addresses. change, some resolvers never get the new addresses. Therefore, it is
Therefore, it is important that resolvers be able to cope with important that resolvers be able to cope with change, even without
change, even without relying upon configuration updates to be applied relying upon configuration updates to be applied by their operator.
by their operator. This is the main reason that one needs to do Root server change is the main reason that resolvers need to do
priming instead of just going from a configured list to get a full priming instead of just going from a configured list to get a full
and accurate list of root servers. and accurate list of root servers.
3. Priming Queries 3. Priming Queries
A priming query is a DNS query used to get the root server A priming query is a DNS query used to get the root server
information in a resolver. It has a QNAME of "." and a QTYPE of NS, information in a resolver. It has a QNAME of "." and a QTYPE of NS,
and is sent to one of the addresses in the configuration for the and is sent to one of the addresses in the configuration for the
recursive resolver. The priming query MAY be sent over UDP or TCP. recursive resolver. The priming query can be sent over either UDP or
If the query is sent over UDP, the source port SHOULD be randomly TCP. If the query is sent over UDP, the source port SHOULD be
selected (see [RFC5452]). The RD bit MAY be set to 0 or 1, although randomly selected (see [RFC5452]). The RD bit MAY be set to 0 or 1,
the meaning of it being set to 1 is undefined for priming queries. although the meaning of it being set to 1 is undefined for priming
queries.
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. servers. See Section 3.3 for discussion of setting the DNSSEC OK
(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. This would be when the resolver starts with an empty cache, needed, such as when the resolver starts with an empty cache and when
and when the NS RRset for the root zone has expired. The recursive the NS RRset for the root zone has expired. Because the NS records
resolver SHOULD expire the NS records of the root servers according for the root are not special, the recursive resolver expires those NS
to the TTL values given in the priming response. (Note that a records according to their TTL values. (Note that a recursive
recursive resolver MAY pre-fetch the NS RRset before it expires.) resolver MAY pre-fetch the NS RRset before it expires.)
If a priming query does not get a response within 2 seconds, the If a priming query does not get a response, the recursive resolver
recursive resolver SHOULD retry with a different target address from needs to retry the query with a different target address from the
the configuration. configuration.
3.2. Target Selection 3.2. Target Selection
In order to spread the load across all the root server operators, the In order to spread the load across all the root server domain names,
recursive resolver SHOULD select the target for a priming query the recursive resolver SHOULD select the target for a priming query
randomly from the list of addresses. The recursive resolver might randomly from the list of addresses. The recursive resolver might
choose either IPv4 and IPv6 addresses based on its knowledge of choose either IPv4 and IPv6 addresses based on its knowledge of
whether the server on which it is running has adequate transit on whether the system on which it is running has adequate connectivity
either type of address. on either type of address.
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 is the one that is recommended for the random method listed above SHOULD be used for priming.
priming.
3.3. DNSSEC with Priming Queries 3.3. DNSSEC with Priming Queries
The resolver MAY set the DNSSEC OK [RFC4033] bit. At the time this The resolver MAY set the DNSSEC OK (DO) bit. At the time this
document is being published, there is little use to performing DNSSEC document is being published, there is little use to performing DNSSEC
validation on the priming query because the "root-servers.net" zone validation on the priming query because the "root-servers.net" zone
is not signed, and so a man-in-the-middle attack on the priming query is not signed, and so a man-in-the-middle attack on the priming query
can result in malicious data in the responses. However, if the can result in malicious data in the responses. However, if the
"root-servers.net" zone is later signed, or if the root server "root-servers.net" zone is later signed, or if the root servers are
operators choose a different zone to identify themselves and that named in a different zone and that zone is signed, having DNSSEC
zone is signed, having DNSSEC validation for the priming queries validation for the priming queries might be valuable.
might be valuable.
4. Priming Responses 4. Priming Responses
A priming query is a normal DNS query. Thus, a root name server A priming query is a normal DNS query. Thus, a root name server
cannot distinguish a priming query from any other query for the root 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 NS 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 is expected to have an RCODE of NOERROR, and to The priming response is expected to have an RCODE of NOERROR, and to
have the AA bit set. Also, it is expected to have an NS RRSet in the have the AA bit set. Also, it is expected to have an NS RRSet in the
Answer section (because the NS RRSet originates from the root zone), Answer section (because the NS RRSet originates from the root zone),
and an empty Authority section (because the NS RRSet already appears and an empty Authority section (because the NS RRSet already appears
in the answer section). There may be an Additional section with A in the Answer section). There will also be an Additional section
and/or AAAA RRSets for the root name servers pointed at by the NS with A and/or AAAA RRSets for the root name servers pointed at by the
RRSet. 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 exactly 13 NS RRs. cache. Resolver software SHOULD NOT expect exactly 13 NS RRs.
4.2. Completeness of the Response 4.2. Completeness of the Response
There are currently 13 root servers. Of those 13, all have one IPv4 There are currently 13 root servers. Of those 13, all have one IPv4
address, and 11 have an IPv6 address. The combined size of all the A address, and 12 have an IPv6 address. The combined size of all the A
and AAAA RRSets is (13 * 16) + (11 * 32), or 560 bytes. Not even and AAAA RRSets is 544 bytes. Not even counting the NS RRSet, this
counting the NS RRSet, this value exceeds the original 512 octet value exceeds the original 512 octet payload limit from [RFC1035].
payload limit from [RFC1035].
For an EDNS response, a resolver SHOULD consider the address For an EDNS response when recursive resolver announced a reassembly
size larger than 512 octets, a resolver SHOULD consider the address
information found in the Additional section complete for any information found in the Additional section complete for any
particular server that appears at all. Said another way: in an EDNS particular server that appears at all. Said another way: in an EDNS
response, if the additional section only has an A RRSet for a server, response, if the Additional section only has an A RRSet for a server,
the resolver SHOULD assume that no AAAA RRSet exists. the resolver can assume that no AAAA RRSet exists for that server.
This assumption is invalid if the announced reassembly size in the
resolver's query was smaller than 512 octets.
It is important to note that if the recursive resolver did not In the event of a response where the Additional section omits certain
announce a reassembly size larger than 512 octets, this assumption is root server address information, re-issuing of the priming query does
invalid. Re-issuing of the priming query does not help with those not help with those root name servers that respond with a fixed order
root name servers that respond with a fixed order of addresses in the of addresses in the Additional section. Instead, the recursive
additional section. Instead, the recursive resolver needs to issue resolver needs to issue direct queries for A and AAAA RRSets for the
direct queries for A and AAAA RRSets for the remaining names. remaining names. Currently, these RRSets would be authoritatively
Currently, these RRSets would be authoritatively available from the available from the root name servers.
root name servers.
5. Security Considerations 5. 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
can inject false answers before a root server can give correct
answers. If the attacker's answers are accepted, this can set up the
ability to give further false answers for future queries to the
resolver. False answers for root servers are more dangerous than,
say, false answers for TLDs, because the root is the highest node of
the DNS.
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
signed, but not for those that are unsigned.
6. IANA Considerations 6. IANA Considerations
None. None.
7. Normative References 7. 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,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
skipping to change at page 6, line 37 skipping to change at page 6, line 47
Peter Koch Peter Koch
DENIC eG DENIC eG
Kaiserstrasse 75-77 Kaiserstrasse 75-77
Frankfurt 60329 Frankfurt 60329
DE DE
Phone: +49 69 27235 0 Phone: +49 69 27235 0
Email: pk@DENIC.DE Email: pk@DENIC.DE
Matt Larson Matt Larson
Dyn, Inc. ICANN
150 Dow St
Manchester, NH 03101
USA
Email: mlarson@dyn.com
Email: matt.larson@icann.org
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
 End of changes. 23 change blocks. 
63 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/