draft-ietf-dnsop-resolver-priming-02.txt   draft-ietf-dnsop-resolver-priming-03.txt 
Network Working Group P. Koch Network Working Group P. Koch
Internet-Draft DENIC eG Internet-Draft DENIC eG
Intended status: BCP M. Larson Intended status: Best Current Practice M. Larson
Expires: April 29, 2010 VeriSign, Inc. Expires: January 16, 2014 Dyn, Inc.
October 26, 2009 July 15, 2013
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-02 draft-ietf-dnsop-resolver-priming-03
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the This document describes the initial queries a DNS resolver is
supposed to emit to initialize its cache with a current NS RRSet for
the root zone as well as the necessary address information.
Status of This Memo
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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 16, 2014.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2013 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://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. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes the initial queries a DNS resolver is described in the Simplified BSD License.
supposed to emit to initialize its cache with a current NS RRSet for
the root zone as well as the necessary address information.
1. Introduction 1. Introduction
Domain Name System (DNS) resolvers need a starting point to resolve Domain Name System (DNS) resolvers need a starting point to resolve
queries. [RFC1034], section 5.3.2, defines the SBELT structure in a queries. [RFC1034], section 5.3.2, defines the SBELT structure in a
full resolver as: full resolver as:
``a "safety belt" structure of the same form as SLIST, which is ``a "safety belt" structure of the same form as SLIST, which is
initialized from a configuration file, and lists servers which initialized from a configuration file, and lists servers which
should be used when the resolver doesn't have any local should be used when the resolver doesn't have any local
skipping to change at page 2, line 34 skipping to change at page 2, line 33
functionality, so the servers ``for the host's domain'' might no functionality, so the servers ``for the host's domain'' might no
longer be an appropriate choice, even if they were only intended to longer be an appropriate choice, even if they were only intended to
resolve ``local'' names, especially since the SBELT structure does resolve ``local'' names, especially since the SBELT structure does
not distinguish between local and global information. In addition, not distinguish between local and global information. In addition,
DNS server implementations have for a long time been seeded with not DNS server implementations have for a long time been seeded with not
only two but an exhaustive list of the root servers' addresses. This only two but an exhaustive list of the root servers' addresses. This
list is either supplied as a configuration file (root "hints", an list is either supplied as a configuration file (root "hints", an
excerpt of the DNS root zone) or even compiled into the software. excerpt of the DNS root zone) or even compiled into the software.
The list of root name servers has been rather stable over the last The list of root name servers has been rather stable over the last
ten years. After the last four servers had been added and moved to fifteen years. After the last four servers had been added and moved
their final (network) destinations in 1997, there have been only four to their final (network) destinations in 1997, there have been only
address changes affecting the L (twice), J, and B servers. Research five address changes affecting the L (twice), J, B, and D servers.
is available for B [Mann2006] and J [BLKT2004], which shows that Research is available for B [Mann2006] and J [BLKT2004], which shows
several months or even years after the change had become effective, that several months or even years after the change had become
traffic is still received on the old addresses. Therefore, it is effective, traffic is still received on the old addresses.
important that resolvers be able to cope with change, even without Therefore, it is important that resolvers be able to cope with
relying upon configuration updates to be applied by their operator. change, even without relying upon configuration updates to be applied
by their operator.
Work by the ICANN SSAC and RSSAC committees, [SSAC016] and [SSAC017], Work by the ICANN SSAC and RSSAC committees, [SSAC016] and [SSAC017],
aiming at adding AAAA RRs for the root name servers' names, deals aiming at adding AAAA RRs for the root name servers' names, deals
with priming queries and so does a draft on DNSSEC Trust Anchor with priming queries and so does a draft on DNSSEC Trust Anchor
maintenance [I-D.ietf-dnsop-dnssec-trust-anchor]. However, it turned maintenance [I-D.ietf-dnsop-dnssec-trust-anchor]. However, it turned
out that despite having been practiced for a long time, priming out that despite having been practiced for a long time, priming
queries have not yet been documented as an important resolver queries have not yet been documented as an important resolver
feature. feature.
The following sections cover parameters of both the priming query and The following sections cover parameters of both the priming query and
skipping to change at page 3, line 22 skipping to change at page 3, line 19
2. Priming Queries 2. Priming Queries
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.1. Parameters of a Priming Query 2.1. Parameters of a Priming Query
A priming query SHOULD use a QNAME of "." and a QTYPE of NS. The A priming query SHOULD use a QNAME of "." and a QTYPE of NS. The
priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]). priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]).
The UDP source port SHOULD be randomly selected [RFC5452]. The RD The UDP source port SHOULD be randomly selected [RFC5452]. The RD
bit MUST NOT be set. The resolver SHOULD also use EDNS0 [RFC2671] bit MUST NOT be set.
and announce and handle a reassembly size of at least 1024 octets
[RFC3226].
[[Do we need a fallback strategy for EDNS unfriendly environments?]] The resolver SHOULD also use EDNS0 [RFC2671] and announce and handle
a reassembly size of at least 1024 octets [RFC3226]. This is to
cover the size of a full priming response (see Section 3.3).
2.2. Repeating Priming Queries 2.2. Repeating Priming Queries
A resolver SHOULD NOT originate a priming query more often than once A resolver SHOULD NOT originate a priming query more often than once
per day (or whenever it starts). It SHOULD adhere to the TTL values per day (or whenever it starts). It SHOULD adhere to the TTL values
given in the priming response. To avoid amnesia, the resolver MAY given in the priming response. To avoid amnesia, the resolver MAY
proactively re-prime before the old root NS RRSet expires from the proactively re-prime before the old root NS RRSet expires from the
cache, but only after 75 percent of the NS RRSet's TTL (or the A/AAAA cache, but only after 75 percent of the NS RRSet's TTL (or of the A/
RRSets' TTL, whichever is lower) have passed. AAAA RRSets' TTL, whichever is lower) have passed.
Should the priming query time out, the resolver should try another Should the priming query time out, the resolver SHOULD retry with a
target address. different target address.
2.3. Target Selection 2.3. Target Selection
A resolver MUST select the target for a priming query randomly from A resolver MUST select the target for a priming query randomly from
the list of addresses (IPv4 and IPv6) available in its SBELT the list of addresses (IPv4 and IPv6) available in its SBELT
structure and it MUST ensure that all targets are selected with equal structure and it MUST ensure that all targets are selected with equal
probability even upon startup. For resending the priming query to a probability even upon startup. For resending the priming query to a
different server the random selection SHOULD also be used. different server the random selection SHOULD also be used.
[[Is it OK to send multiple priming queries to multiple targets in
parallel?]]
2.4. DNSSEC with Priming Queries 2.4. DNSSEC with Priming Queries
The resolver SHOULD NOT set the DNSSEC OK [RFC4033] bit. The resolver SHOULD NOT set the DNSSEC OK [RFC4033] bit.
Discussion: Delegations in referral responses are not signed, so Discussion: Delegations in referral responses are not signed, so
consequently the priming response is not validated, either. For that consequently the priming response is not validated, either. For that
to work, the priming response would also have to be self-contained in to work, the priming response would also have to be self-contained in
that it would allow the resolver to not only validate the NS RRSet that it would allow the resolver to not only validate the NS RRSet
(with the root DNSKEY RRSet and the root NS RRSet's signature), but (with the root DNSKEY RRSet and the root NS RRSet's signature), but
also the A and AAAA RRSets. All this information cannot be also the A and AAAA RRSets. All this information cannot be
skipping to change at page 4, line 42 skipping to change at page 4, line 33
The priming response can be expected to have an RCODE of NOERROR and The priming response can be expected to have an RCODE of NOERROR and
the AA bit set. Also, there should be an NS RRSet in the answer the AA bit set. Also, there should be an NS RRSet in the answer
section (since the NS RRSet originates from the root zone), an empty section (since the NS RRSet originates from the root zone), an empty
authority section (since the NS RRSet already appears in the answer authority section (since the NS RRSet already appears in the answer
section) and an additional section with A and AAAA RRSets for the section) and an additional section with A and AAAA RRSets for the
root name servers pointed at by the NS RRSet. Resolver software root name servers pointed at by the NS RRSet. Resolver software
SHOULD NOT expect a fixed number of 13 NS RRs, since "internal" root SHOULD NOT expect a fixed number of 13 NS RRs, since "internal" root
server setups in split DNS configurations might use a different server setups in split DNS configurations might use a different
number of servers. Resolver software SHOULD warn the operator about number of servers. Resolver software SHOULD warn the operator about
any change in the number or names of name servers compared to the any change in the number or names of name servers or their addresses
SBELT information. compared to the SBELT information.
3.2. Use of the Priming Response 3.2. Use of the Priming Response
A resolver MAY use the priming response as it would use any other A resolver MAY use the priming response as it would use any other
data fed to its cache. However, it SHOULD NOT use the SBELT data fed to its cache. However, it SHOULD NOT use the SBELT
information directly in any responses it hands out. information directly in any responses it hands out.
[[Is there any special consideration needed for those cases where
someone managed to cause a signed root NS RRSet being fed into the
cache?]]
3.3. Completeness of the Response 3.3. Completeness of the Response
Assuming an upper bound of thirteen root name servers and one address
each for IPv4 and IPv6, the combined size of all the A and AAAA
RRSets is 13 * (16 + 28) == 572, independent of the naming scheme.
Not even counting the NS RRSet, this value exceeds the original 512
octet payload limit.
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. In other words: if the particular server that appears at all. In other words: if the
additional section only has an A RRSet for a server, the resolver additional section only has an A RRSet for a server, the resolver
SHOULD assume that no AAAA RRSet exists. To ensure equal SHOULD assume that no AAAA RRSet exists. This is to avoid repeated
availability the A and AAAA RRSets should have identical TTL values unnecessary queries for names of name servers that do not or not yet
at the authoritative source. [[There might still be some degenerate offer IPv6 service, or, in perspective, will have ceased IPv4
cases of response sizes between 512 and 1024.]] service.
[[If the resolver did not announce a reassembly size larger than 512 If the resolver did not announce a reassembly size larger than 512
octets, this assumption is invalid. How to acquire the remaining octets, this assumption is invalid. Simple re-issueing of the
address RRSets is TBD. Simple re-issueing of the priming query does priming query does not help with those root name servers that respond
not help with those root name servers that respond with a fixed order with a fixed order of addresses in the additional section. Instead
of addresses in the additional section.]] the resolver ought to issue direct queries for A and AAAA RRSets for
the remaining names. In today's environment these RRSets would be
authoritatively available from the root name servers.
4. Requirements for Root Name Servers and the Root Zone 4. Requirements for Root Name Servers and the Root Zone
The operational requirements for root name servers are described in The operational requirements for root name servers are described in
[RFC2870]. This section specifies additional guidance for the [RFC2870]. This section specifies additional guidance for the
configuration of and software deployed at the root name servers. configuration of and software deployed at the root name servers.
All DNS root name servers need to be able to provide for all All DNS root name servers need to be able to provide for all
addresses of all root name servers. This can easily achieved by addresses of all root name servers. This can easily achieved by
making all root name servers authoritative for the zone containing making all root name servers authoritative for the zone containing
the servers' names. the servers' names.
[[At the time of writing, all but one root name server were
authoritative for ROOT-SERVERS.NET., even though only a subset
received an official delegation.]]
If the response packet does not provide for more than 512 octets due If the response packet does not provide for more than 512 octets due
to lack of EDNS0 support, A RRSets SHOULD be given preference over to lack of EDNS0 support, A RRSets SHOULD be given preference over
AAAA RRSets when filling the additional section. AAAA RRSets when filling the additional section.
[[EDNS0 is used as an indication of AAAA understanding on the side of [[EDNS0 is used as an indication of AAAA understanding on the side of
the client. What to do with small payload sizes indicated by EDNS0 the client. What to do with small payload sizes indicated by EDNS0
is open to discussion. At the time of writing, some root name is open to discussion. At the time of writing, some root name
servers will fill the additional section with all available A RRSets, servers will fill the additional section with all available A RRSets,
only adding some AAAA RRSets, when queried over IPv4 without EDNS0. only adding some AAAA RRSets, when queried over IPv4 without EDNS0.
Other servers will deliver more AAAA RRSets, therefore withholding Other servers will deliver more AAAA RRSets, therefore withholding
some A RRSets completely [RFC4472].]] some A RRSets completely [RFC4472].]]
To ensure equal availability the A and AAAA RRSets for the rot name
servers' names SHOULD have identical TTL values at the authoritative
source.
[[Do the TTLs for the root NS RRSet and address RRSets in the root [[Do the TTLs for the root NS RRSet and address RRSets in the root
and the ROOT-SERVERS.NET. zones need to be aligned? In real life and the ROOT-SERVERS.NET. zones need to be aligned? In real life
responses, the address RRSet's TTL values vary by implementation.]] responses, the address RRSet's TTL values vary by name server
implementation.]]
5. Security Considerations 5. Security Considerations
This document deals with priming a DNS resolver's cache. The usual This document deals with priming a DNS resolver's cache. The usual
DNS caveats apply. Use of DNSSEC with priming queries is discussed DNS caveats apply. Use of DNSSEC with priming queries is discussed
in section 2.4. in section 2.4.
Spoofing a response to a priming query can be used to redirect all Spoofing a response to a priming query can be used to redirect all
queries originating from a victim resolver, therefore any difference queries originating from a victim resolver, therefore any difference
between the inital SBELT list and the priming response SHOULD be between the inital SBELT list and the priming response SHOULD be
skipping to change at page 6, line 34 skipping to change at page 6, line 30
This document does not propose any new IANA registry nor does it ask This document does not propose any new IANA registry nor does it ask
for any allocation from an existing IANA registry. for any allocation from an existing IANA registry.
However, this document deals with requirements for the root zone and However, this document deals with requirements for the root zone and
root server operations. root server operations.
[[Any recommendation on the "." NS RRSet TTL or the TTLs of the [[Any recommendation on the "." NS RRSet TTL or the TTLs of the
respective A and/or AAAA RRSets would go here.]] respective A and/or AAAA RRSets would go here.]]
[[This section needs more work.]]
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
RFC 2671, August 1999. 2671, August 1999.
[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, December 2001. message size requirements", RFC 3226, December 2001.
[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", Rose, "DNS Security Introduction and Requirements", RFC
RFC 4033, March 2005. 4033, March 2005.
[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, January 2009. Resilient against Forged Answers", RFC 5452, January 2009.
7.2. Informative References 7.2. Informative References
[BLKT2004] [BLKT2004]
Barber, P., Larson, M., Kosters, M., and P. Toscano, "Life Barber, P., Larson, M., Kosters, M., and P. Toscano, "Life
and Times of J-Root", NANOG 32, October 2004. and Times of J-Root", NANOG 32, October 2004.
[I-D.ietf-dnsop-dnssec-trust-anchor] [I-D.ietf-dnsop-dnssec-trust-anchor]
Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor
Configuration and Maintenance", Configuration and Maintenance", draft-ietf-dnsop-dnssec-
draft-ietf-dnsop-dnssec-trust-anchor-03 (work in trust-anchor-04 (work in progress), October 2010.
progress), March 2009.
[I-D.koch-dns-glue-clarifications] [I-D.koch-dns-glue-clarifications]
Koch, P., "DNS Glue RR Survey and Terminology Koch, P., "DNS Glue RR Survey and Terminology
Clarification", draft-koch-dns-glue-clarifications-03 Clarification", draft-koch-dns-glue-clarifications-04
(work in progress), November 2007. (work in progress), July 2010.
[Mann2006] [Mann2006]
Manning, B., "persistent queries and phantom nameservers", Manning, B., "persistent queries and phantom nameservers",
WIDE/CAIDA Workshop , October 2006. WIDE/CAIDA Workshop , October 2006.
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
Name Server Operational Requirements", BCP 40, RFC 2870, Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000. June 2000.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472, Considerations and Issues with IPv6 DNS", RFC 4472, April
April 2006. 2006.
[SSAC016] ICANN Security and Stability Advisory Committee, "Testing [SSAC016] ICANN Security and Stability Advisory Committee, "Testing
Firewalls for IPv6 and EDNS0 Support", SSAC 016, Firewalls for IPv6 and EDNS0 Support", SSAC 016, January
January 2007. 2007.
[SSAC017] ICANN Security and Stability Advisory Committee, "Testing [SSAC017] ICANN Security and Stability Advisory Committee, "Testing
Recursive Name Servers for IPv6 and EDNS0 Support", Recursive Name Servers for IPv6 and EDNS0 Support", SSAC
SSAC 017, February 2007. 017, February 2007.
Appendix A. Document Revision History Appendix A. Document Revision History
This section is to be removed should the draft be published. This section is to be removed should the draft be published.
$Id: draft-ietf-dnsop-resolver-priming.xml,v 1.4 2009/10/26 20:18:33 $Id: draft-ietf-dnsop-resolver-priming.xml,v 1.6 2013/07/15 17:35:18
pk Exp $ pk Exp $
A.1. -02 WG Document A.1. -03 WG Document
Revived. Resolved most open issues [[]] as per previous WG
discussion. Minor edits on history and wording. All root servers
authoritative for ROOT-SERVERS.NET.
A.2. -02 WG Document
Revived. Changed use of DNSSEC OK in the priming query as per the WG Revived. Changed use of DNSSEC OK in the priming query as per the WG
discussion. discussion.
A.2. -01 WG Document A.3. -01 WG Document
Revived with minor edits. Open issues marked [[]]. Revived with minor edits. Open issues marked [[]].
A.3. -00 WG Document A.4. -00 WG Document
Reposted as WG document with minor edits. Reposted as WG document with minor edits.
Added re-primimg proposal and A/AAAA TTL considerations. Added re-primimg proposal and A/AAAA TTL considerations.
A.4. Initial Document A.5. Initial Document
First draft First draft
Authors' Addresses Authors' Addresses
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
VeriSign, Inc. Dyn, Inc.
21345 Ridgetop Circle 150 Dow St
Dulles, VA 20166-6503 Manchester, NH 03101
USA USA
Email: mlarson@verisign.com Email: mlarson@dyn.com
 End of changes. 37 change blocks. 
91 lines changed or deleted 94 lines changed or added

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