draft-ietf-dnsop-resolver-priming-00.txt   draft-ietf-dnsop-resolver-priming-01.txt 
Network Working Group P. Koch Network Working Group P. Koch
Internet-Draft DENIC eG Internet-Draft DENIC eG
Intended status: Best Current M. Larson Intended status: BCP M. Larson
Practice VeriSign, Inc. Expires: January 15, 2009 VeriSign, Inc.
Expires: January 3, 2008 July 2, 2007 July 14, 2008
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-00 draft-ietf-dnsop-resolver-priming-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 3, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 2, line 34 skipping to change at page 2, line 28
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 ten years. After the last four servers had been added and moved to
their final (network) destinations in 1997, there have been only their final (network) destinations in 1997, there have been only four
three address changes affecting the L, J, and B servers. Research is address changes affecting the L (twice), J, and B servers. Research
available for B [Mann2006] and J [BLKT2004], which shows that several is available for B [Mann2006] and J [BLKT2004], which shows that
months or even years after the change had become effective, traffic several months or even years after the change had become effective,
is still received on the old addresses. Therefore, it is important traffic is still received on the old addresses. Therefore, it is
that resolvers be able to cope with change, even without relying upon important that resolvers be able to cope with change, even without
configuration updates to be applied by their operator. relying upon configuration updates to be applied by their operator.
The recent work by the ICANN SSAC and RSSAC committees, [SSAC016] and Work by the ICANN SSAC and RSSAC committees, [SSAC016] and [SSAC017],
[SSAC017], aiming at adding AAAA RRs for the root name servers' aiming at adding AAAA RRs for the root name servers' names, deals
names, deals with priming queries and so does a draft on DNSSEC Trust with priming queries and so does a draft on DNSSEC Trust Anchor
Anchor maintenance [I-D.larson-dnsop-trust-anchor]. However, it maintenance [I-D.ietf-dnsop-dnssec-trust-anchor]. However, it turned
turned out that despite having been practiced for a long time, out that despite having been practiced for a long time, priming
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
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. Parameters of a Priming Query
skipping to change at page 3, line 22 skipping to change at page 3, line 18
a QNAME of "." and a QTYPE of NS. It SHOULD also use EDNS0 [RFC2671] a QNAME of "." and a QTYPE of NS. It 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]). A priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]).
The RD bit MUST NOT be set in the query. The RD bit MUST NOT be set in the query.
2.1. Target Selection 2.1. 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
its list of available addresses and it MUST ensure that all targets the list of addresses available in its SBELT structure and it MUST
are selected with equal probability even upon startup. For resending ensure that all targets are selected with equal probability even upon
the priming query to a different server the random selection SHOULD startup. For resending the priming query to a different server the
also be used. random selection SHOULD also be used.
2.2. DNSSEC with Priming Queries 2.2. DNSSEC with Priming Queries
The resolver MAY choose to use DNSSEC OK [RFC4033], in which case it The resolver MAY choose to use DNSSEC OK [RFC4033], in which case it
MUST announce and handle a message size of at least 1220 octets. MUST announce and handle a message size of at least 1220 octets.
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 following this model there would be no need to require a signed root
NS RRSet and, equally important, signed A and AAAA RRSet for the root NS RRSet and, equally important, signed A and AAAA RRSet for the root
name servers' names. On the other hand, a poisoned priming response name servers' names. On the other hand, a poisoned priming response
could drastically influence the resolver's operations. If the could drastically influence the resolver's operations. If the
priming response should be secured by DNSSEC, then it should also be priming response should be secured by DNSSEC, then it should also be
self contained, i.e., the whole validation chain should be present in self contained, i.e., the whole validation chain should be present in
the priming response. This might call for a different naming scheme the priming response. This might call for a different naming scheme
(see section 5.1 of [I-D.koch-dns-glue-clarifications]). (see section 6.1 of [I-D.koch-dns-glue-clarifications]).
2.3. Repeating Priming Queries 2.3. 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 the A/AAAA
RRSets' TTL, whichever is lower) have passed. RRSets' TTL, whichever is lower) have passed.
3. Expected Properties of a Priming Response 3. Expected Properties of a Priming Response
The response can be expected to have an RCODE of NOERROR and the AA The 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 section bit set. Also, there should be an NS RRSet in the answer section
(since the NS RRSet originates from the root zone), an empty (since the NS RRSet originates from the root zone), an empty
authority section and an additional section with A and AAAA RRSets authority section (since the NS RRSet already appears in the answer
for the root name servers pointed at by the NS RRSet. {Note that the section) and an additional section with A and AAAA RRSets for the
number 13 does not appear here. It might be necessary to consider root name servers pointed at by the NS RRSet. Resolver software
"internal" root server setups in split DNS configurations.} 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
servers. Resolver software SHOULD warn the operator about any change
in the number or names of name servers compared to the SBELT
information.
3.1. Use of the Priming Response 3.1. 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 cachhe. 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 3.2. Completeness of the Response
A resolver SHOULD consider the address information found in the For an EDNS response, a resolver SHOULD consider the address
additional section complete for any particular server that appears at information found in the additional section complete for any
all. In other words: if the additional section only has an A RRSet particular server that appears at all. In other words: if the
for a server, the resolver SHOULD assume that no AAAA RRSet exists. additional section only has an A RRSet for a server, the resolver
To ensure equal availability the A and AAAA RRSets should have SHOULD assume that no AAAA RRSet exists. To ensure equal
identical TTL values at the authoritative source. availability the A and AAAA RRSets should have identical TTL values
at the authoritative source. [[There might still be some degenerate
cases of response sizes between 512 and 1024.]]
[[If the resolver did not announce a reassembly size larger than 512
octets, this assumption is invalid. How to acquire the remaining
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
of addresses in the additional section.]]
4. Root Name Server Requirements 4. Root Name Server Requirements
The operational requirements for root name servers are described in The operational requirements for root name servers are described in
[RFC2870]. [RFC2870].
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. {At the time of writing, all but one root name the servers' names.
server were authoritative for ROOT-SERVERS.NET., even though only a
subset received an official delegation.} [[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, AAAA RRSets should be omitted from the to lack of EDNS0 support, A RRSets SHOULD be given preference over
response. {EDNS0 is used as an indication of AAAA understanding. AAAA RRSets when filling the additional section.
What to do with small payload sizes indicated by EDNS0 is open to
discussion.} [[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
is open to discussion. At the time of writing, some root name
servers will fill the additional section with all available A RRSets,
only adding some AAAA RRSets, when queried over IPv4 without EDNS0.
Other servers will deliver more AAAA RRSets, therefore withholding
some A RRSets completely [RFC4472].]]
[[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
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.2.
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.} [[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.
{This section needs more work.} [[Any recommendation on the "." NS RRSet TTL or the TTLs of the
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.
skipping to change at page 6, line 11 skipping to change at page 6, line 32
[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.
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.koch-dns-glue-clarifications] [I-D.ietf-dnsop-dnssec-trust-anchor]
Koch, P., "DNS Glue RR Survey and Terminology
Clarification", draft-koch-dns-glue-clarifications-02
(work in progress), October 2006.
[I-D.larson-dnsop-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-larson-dnsop-trust-anchor-01 (work in progress), draft-ietf-dnsop-dnssec-trust-anchor-01 (work in
March 2007. progress), February 2008.
[I-D.koch-dns-glue-clarifications]
Koch, P., "DNS Glue RR Survey and Terminology
Clarification", draft-koch-dns-glue-clarifications-03
(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.
[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
skipping to change at page 6, line 46 skipping to change at page 7, line 18
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. -00 WG Document A.1. -01 WG Document
Revived with minor edits. Open issues marked [[]].
A.2. -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.2. Initial Document A.3. Initial Document
First draft First draft
Authors' Addresses Authors' Addresses
Peter Koch Peter Koch
DENIC eG DENIC eG
Wiesenhuettenplatz 26 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 Full Copyright Statement
skipping to change at page 8, line 7 skipping to change at page 9, line 7
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 Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 8, line 44 skipping to change at line 367
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 23 change blocks. 
61 lines changed or deleted 87 lines changed or added

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