draft-ietf-dnsop-resolver-priming-01.txt   draft-ietf-dnsop-resolver-priming-02.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: BCP M. Larson
Expires: January 15, 2009 VeriSign, Inc. Expires: April 29, 2010 VeriSign, Inc.
July 14, 2008 October 26, 2009
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-01 draft-ietf-dnsop-resolver-priming-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes the initial queries a DNS resolver is This document describes the initial queries a DNS resolver is
supposed to emit to initialize its cache with a current NS RRSet for supposed to emit to initialize its cache with a current NS RRSet for
the root zone as well as the necessary address information. 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
skipping to change at page 3, line 5 skipping to change at page 3, line 12
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
the response to be sent by a root name server. the response to be sent by a root name server.
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].
2. Parameters of a Priming Query 2. Priming Queries
This document only deals with QCLASS IN. A priming query SHOULD use This document only deals with recursive name servers (recursive
a QNAME of "." and a QTYPE of NS. It SHOULD also use EDNS0 [RFC2671] resolvers, resolvers) for the IN CLASS.
2.1. Parameters of a Priming Query
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]).
The UDP source port SHOULD be randomly selected [RFC5452]. The RD
bit MUST NOT be set. The resolver SHOULD also use EDNS0 [RFC2671]
and announce and handle a reassembly size of at least 1024 octets and announce and handle a reassembly size of at least 1024 octets
[RFC3226]. [RFC3226].
A priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]). [[Do we need a fallback strategy for EDNS unfriendly environments?]]
The RD bit MUST NOT be set in the query.
2.1. Target Selection 2.2. Repeating Priming Queries
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
given in the priming response. To avoid amnesia, the resolver MAY
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
RRSets' TTL, whichever is lower) have passed.
Should the priming query time out, the resolver should try another
target address.
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 available in its SBELT structure and it MUST the list of addresses (IPv4 and IPv6) available in its SBELT
ensure that all targets are selected with equal probability even upon structure and it MUST ensure that all targets are selected with equal
startup. For resending the priming query to a different server the probability even upon startup. For resending the priming query to a
random selection SHOULD also be used. different server the random selection SHOULD also be used.
2.2. DNSSEC with Priming Queries [[Is it OK to send multiple priming queries to multiple targets in
parallel?]]
The resolver MAY choose to use DNSSEC OK [RFC4033], in which case it 2.4. DNSSEC with Priming Queries
MUST announce and handle a message size of at least 1220 octets.
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
following this model there would be no need to require a signed root consequently the priming response is not validated, either. For that
NS RRSet and, equally important, signed A and AAAA RRSet for the root to work, the priming response would also have to be self-contained in
name servers' names. On the other hand, a poisoned priming response that it would allow the resolver to not only validate the NS RRSet
could drastically influence the resolver's operations. If the (with the root DNSKEY RRSet and the root NS RRSet's signature), but
priming response should be secured by DNSSEC, then it should also be also the A and AAAA RRSets. All this information cannot be
self contained, i.e., the whole validation chain should be present in guaranteed to be either present at the root name servers or fit into
the priming response. This might call for a different naming scheme the priming reponse even with the largest feasible EDNS0 buffer size.
(see section 6.1 of [I-D.koch-dns-glue-clarifications]). In fact, in today's Internet, with the root name servers' names under
"ROOT-SERVERS.NET.", this isn't even true for the top level domain
involved. So, even though a poisoned priming response could
drastically influence the resolver's operations, there is little a
DNSSEC enhanced priming response could achieve without the whole
validation chain. This would probably call for a different naming
scheme (see section 6.1 of [I-D.koch-dns-glue-clarifications]).
2.3. Repeating Priming Queries 3. Priming Responses
A resolver SHOULD NOT originate a priming query more often than once A root name server cannot distinguish a priming query from any other
per day (or whenever it starts). It SHOULD adhere to the TTL values query for the root NS RRSet, except that QTYPE NS would not usually
given in the priming response. To avoid amnesia, the resolver MAY be part of the DNS resolution process.
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
RRSets' TTL, whichever is lower) have passed.
3. Expected Properties of a Priming Response 3.1. Expected Properties of the Priming Response
The response can be expected to have an RCODE of NOERROR and the AA The priming response can be expected to have an RCODE of NOERROR and
bit set. Also, there should be an NS RRSet in the answer section the AA bit set. Also, there should be an NS RRSet in the answer
(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 lower number of server setups in split DNS configurations might use a different
servers. Resolver software SHOULD warn the operator about any change number of servers. Resolver software SHOULD warn the operator about
in the number or names of name servers compared to the SBELT any change in the number or names of name servers compared to the
information. SBELT information.
3.1. 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.
3.2. Completeness of the Response [[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
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. To ensure equal
availability the A and AAAA RRSets should have identical TTL values availability the A and AAAA RRSets should have identical TTL values
at the authoritative source. [[There might still be some degenerate at the authoritative source. [[There might still be some degenerate
cases of response sizes between 512 and 1024.]] cases of response sizes between 512 and 1024.]]
[[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. How to acquire the remaining
address RRSets is TBD. Simple re-issueing of the priming query does address RRSets is TBD. Simple re-issueing 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.]] of addresses in the additional section.]]
4. Root Name Server Requirements 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]. [RFC2870]. This section specifies additional guidance for the
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 [[At the time of writing, all but one root name server were
authoritative for ROOT-SERVERS.NET., even though only a subset authoritative for ROOT-SERVERS.NET., even though only a subset
received an official delegation.]] received an official delegation.]]
skipping to change at page 5, line 23 skipping to change at page 6, line 13
some A RRSets completely [RFC4472].]] some A RRSets completely [RFC4472].]]
[[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 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.2. 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
brought to the operators' attention. There is also a chance that the brought to the operators' attention. There is also a chance that the
random target selection chooses the address of a retired root name random target selection chooses the address of a retired root name
server. Operational measures to prevent reuse of these addresses are server. Operational measures to prevent reuse of these addresses are
out of the scope of this document. out of the scope of this document.
[[This section needs more work.]]
6. IANA Considerations 6. IANA Considerations
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.]]
skipping to change at page 6, line 25 skipping to change at page 7, line 13
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999. RFC 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 4033, March 2005. RFC 4033, March 2005.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
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-trust-anchor-01 (work in draft-ietf-dnsop-dnssec-trust-anchor-03 (work in
progress), February 2008. 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-03
(work in progress), November 2007. (work in progress), November 2007.
[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.
skipping to change at page 7, line 18 skipping to change at page 8, line 9
January 2007. January 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 017, February 2007. SSAC 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.
A.1. -01 WG Document $Id: draft-ietf-dnsop-resolver-priming.xml,v 1.4 2009/10/26 20:18:33
pk Exp $
A.1. -02 WG Document
Revived. Changed use of DNSSEC OK in the priming query as per the WG
discussion.
A.2. -01 WG Document
Revived with minor edits. Open issues marked [[]]. Revived with minor edits. Open issues marked [[]].
A.2. -00 WG Document A.3. -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.3. Initial Document A.4. 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
skipping to change at page 8, line 4 skipping to change at page 8, line 41
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. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
USA USA
Email: mlarson@verisign.com Email: mlarson@verisign.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 30 change blocks. 
56 lines changed or deleted 103 lines changed or added

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