draft-ietf-dnsop-resolver-priming-06.txt   draft-ietf-dnsop-resolver-priming-07.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: July 16, 2016 Dyn, Inc. Expires: September 20, 2016 Dyn, Inc.
P. Hoffman P. Hoffman
ICANN ICANN
January 13, 2016 March 19, 2016
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-06 draft-ietf-dnsop-resolver-priming-07
Abstract Abstract
This document describes the queries a DNS resolver can emit to This document describes the queries that a DNS resolver should emit
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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 16, 2016. This Internet-Draft will expire on September 20, 2016.
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 13 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 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. (sometimes disastrously) under different conditions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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.
2. Description of Priming 2. Description of Priming
As described in this document, priming is the act of finding the list Priming is the act of finding the list of root servers from a
of root servers from a configuration that lists some or all of the configuration that lists some or all of the purported IP addresses of
purported IP addresses of some or all of those root servers. A some or all of those root servers. A recursive resolver starts with
recursive resolver starts with no information about the root servers, no information about the root servers, and ends up with a list of
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.
Currently, it is quite common for the configured list of IP addresses The configured list of IP address for the root servers usually comes
for the root server to be mostly complete and correct. Note that from the vendor or distributor of the recursive server software.
this list (at least initially) comes from the vendor or distributor This list is usually correct and complete when shipped, but may
of the recursive server software. 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 NS records for those root server operators, both for
IPv4 and IPv6 addresses. However, research shows that after those IPv4 and IPv6 addresses. However, research shows that after those
addresses change, some resolvers never get the new addresses. addresses change, some resolvers never get the new addresses.
Therefore, it is important that resolvers be able to cope with Therefore, it is important that resolvers be 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. This is the main reason that one needs to do by their operator. This is the main reason that one needs 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 that has a QNAME of "." and a QTYPE of A priming query is a DNS query used to get the root server
NS, and is sent to one of the addresses in the configuration for the 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
recursive resolver. The priming query MAY be sent over UDP or TCP. recursive resolver. The priming query MAY be sent over UDP or TCP.
If the query is sent over UDP, the source port SHOULD be randomly If the query is sent over UDP, the source port SHOULD be randomly
selected (see [RFC5452]). The RD bit MAY be set to 0 or 1, although selected (see [RFC5452]). The RD bit MAY be set to 0 or 1, although
the meaning of it being set to 1 is undefined for priming queries. 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). full priming response (see Section 4.2) for the current set of root
servers.
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. This would be when the resolver starts with an empty cache,
and when one or more of the NS records for the root servers has and when the NS RRset for the root zone has expired. The recursive
expired. The recursive resolver SHOULD expire the NS records of the resolver SHOULD expire the NS records of the root servers according
root servers according to the TTL values given in the priming to the TTL values given in the priming response. (Note that a
response. recursive 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 within 2 seconds, the
recursive resolver SHOULD retry with a different target address from recursive resolver SHOULD retry with a different target address from
the configuration. the 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 operators, the
recursive resolver SHOULD select the target for a priming query 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 server on which it is running has adequate transit on
either type of address. 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 other the list in a recursive resolver's configuration. Two other common
common methods include picking the first from the list, and methods include picking the first from the list, and remembering
remembering which address in the list gave the fastest response which address in the list gave the fastest response earlier and using
earlier and using that one. There are probably other methods in use that one. There are probably other methods in use today. However,
today. However, the random method listed above is the one that is the random method listed above is the one that is recommended for
recommended 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 [RFC4033] 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 server
operators choose a different zone to identify themselves and that operators choose a different zone to identify themselves and that
skipping to change at page 4, line 30 skipping to change at page 4, line 32
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, there should be an NS RRSet in the Answer have the AA bit set. Also, it is expected to have an NS RRSet in the
section (because the NS RRSet originates from the root zone), an Answer section (because the NS RRSet originates from the root zone),
empty Authority section (because the NS RRSet already appears in the and an empty Authority section (because the NS RRSet already appears
answer section) and an Additional section with A and/or AAAA RRSets in the answer section). There may be an Additional section with A
for the root name servers pointed at by the NS RRSet. and/or AAAA RRSets for the root name servers pointed at by 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 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 11 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 (13 * 16) + (11 * 32), or 560 bytes. Not even
skipping to change at page 5, line 11 skipping to change at page 5, line 15
For an EDNS response, a resolver SHOULD consider the address For an EDNS response, 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 SHOULD assume that no AAAA RRSet exists.
It is important to note that if the recursive resolver did not It is important to note that if the recursive resolver did not
announce a reassembly size larger than 512 octets, this assumption is announce a reassembly size larger than 512 octets, this assumption is
invalid. Re-issuing of the priming query does not help with those invalid. Re-issuing of the priming query does not help with those
root name servers that respond with a fixed order of addresses in the root name servers that respond with a fixed order of addresses in the
additional section. Instead, the recursive resolver needs to to additional section. Instead, the recursive resolver needs to issue
issue direct queries for A and AAAA RRSets for the remaining names. direct queries for A and AAAA RRSets for the remaining names.
Currently, these RRSets would be authoritatively available from the Currently, these RRSets would be authoritatively 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.
skipping to change at page 5, line 39 skipping to change at page 5, line 43
[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>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, DOI 10.17487/ message size requirements", RFC 3226,
RFC3226, December 2001, DOI 10.17487/RFC3226, December 2001,
<http://www.rfc-editor.org/info/rfc3226>. <http://www.rfc-editor.org/info/rfc3226>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, DOI 10.17487/ Resilient against Forged Answers", RFC 5452,
RFC5452, January 2009, DOI 10.17487/RFC5452, January 2009,
<http://www.rfc-editor.org/info/rfc5452>. <http://www.rfc-editor.org/info/rfc5452>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ for DNS (EDNS(0))", STD 75, RFC 6891,
RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This document is the product of the DNSOP WG and benefitted from the This document is the product of the DNSOP WG and benefitted from the
reviews done there. reviews done there.
Authors' Addresses Authors' Addresses
Peter Koch Peter Koch
 End of changes. 19 change blocks. 
46 lines changed or deleted 49 lines changed or added

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