draft-ietf-dnsop-resolver-priming-04.txt   draft-ietf-dnsop-resolver-priming-05.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: August 18, 2014 Dyn, Inc. Expires: September 10, 2015 Dyn, Inc.
February 14, 2014 March 9, 2015
Initializing a DNS Resolver with Priming Queries Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-04 draft-ietf-dnsop-resolver-priming-05
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 in order to initialize its cache with both a current
the root zone as well as the necessary address information. NS RRSet for the root zone and the necessary address information.
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 August 18, 2014. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
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
information to guide name server selection. The match count will information to guide name server selection. The match count will
be -1 to indicate that no labels are known to match.'' be -1 to indicate that no labels are known to match.
Section 5.3.3 of [RFC1034] adds Section 5.3.3 of [RFC1034] adds
``the usual choice is two of the root servers and two of the the usual choice is two of the root servers and two of the servers
servers for the host's domain'' for the host's domain
Today's practice generally seperates serving and resolving Today's practice generally seperates serving and resolving
functionality, so the servers ``for the host's domain'' might no functionalities, 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
not distinguish between local and global information. In addition, distinguish between local and global information. In addition, DNS
DNS server implementations have for a long time been seeded with not server implementations have for a long time been seeded with not only
only two but an exhaustive list of the root servers' addresses. This two but an exhaustive list of the root servers' addresses. This list
list is either supplied as a configuration file (root "hints", an is either supplied as a configuration file (root "hints", an excerpt
excerpt of the DNS root zone) or even compiled into the software. 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
fifteen years. After the last four servers had been added and moved fifteen years. After the last four servers had been added and moved
to their final (network) destinations in 1997, there have been only to their final (network) destinations in 1997, there have been only
five address changes affecting the L (twice), J, B, and D servers. five address changes affecting the L (twice), J, B, and D servers.
Research is available for B [Mann2006] and J [BLKT2004], which shows Research is available for B [Mann2006] and J [BLKT2004], which shows
that several months or even years after the change had become that several months or even years after the change had become
effective, traffic is still received on the old addresses. effective, traffic is still received on the old 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
each for IPv4 and IPv6, the combined size of all the A and AAAA 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. RRSets is 13 * (16 + 28) == 572, independent of the naming scheme.
Not even counting the NS RRSet, this value exceeds the original 512 Not even counting the NS RRSet, this value exceeds the original 512
octet payload limit. 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. This is to avoid repeated SHOULD assume that no AAAA RRSet exists. This is to avoid repeated
unnecessary queries for names of name servers that do not or not yet unnecessary queries for names of name servers that do not or do not
offer IPv6 service, or, in perspective, will have ceased IPv4 yet offer IPv6 service, or, in perspective, will have ceased IPv4
service. 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. Simple re-issuing of the priming octets, this assumption is invalid. Simple re-issuing of the priming
query does not help with those root name servers that respond with a query does not help with those root name servers that respond with a
fixed order of addresses in the additional section. Instead the fixed order of addresses in the additional section. Instead the
resolver ought to issue direct queries for A and AAAA RRSets for the resolver ought to issue direct queries for A and AAAA RRSets for the
remaining names. In today's environment these RRSets would be remaining names. In today's environment these RRSets would be
authoritatively available from the root name servers. authoritatively available from the root name servers.
skipping to change at page 6, line 19 skipping to change at page 6, line 14
authoritative source prevail? Is it therefore a protocol issue authoritative source prevail? Is it therefore a protocol issue
rather than an operational choice of parameters?]] rather than an operational choice of parameters?]]
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
between the inital SBELT list and the priming response SHOULD be difference between the inital SBELT list and the priming response
brought to the operators' attention. There is also a chance that the SHOULD be brought to the operators' attention. There is also a
random target selection chooses the address of a retired root name chance that the random target selection chooses the address of a
server. Operational measures to prevent reuse of these addresses are retired root name server. Operational measures to prevent reuse of
out of the scope of this document. these addresses are out of the scope of this document.
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.
[[Issue3: related to issue 2 - any recommendation on the "." NS [[Issue3: related to issue 2 - any recommendation on the "." NS
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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", SSAC Recursive Name Servers for IPv6 and EDNS0 Support", 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.7 2014/02/14 23:27:23 $Id: draft-ietf-dnsop-resolver-priming.xml,v 1.8 2015/03/09 20:22:52
pk Exp $ pk Exp $
A.1. -04 WG Document A.1. -05 WG Document
Revived. Minor edits for readability - Warren.
A.2. -04 WG Document
Revived. Updated EDNS0 reference. Minor edits for clarity. Revived. Updated EDNS0 reference. Minor edits for clarity.
A.2. -03 WG Document A.3. -03 WG Document
Revived. Resolved most open issues [[]] as per previous WG Revived. Resolved most open issues [[]] as per previous WG
discussion. Minor edits on history and wording. All root servers discussion. Minor edits on history and wording. All root servers
authoritative for ROOT-SERVERS.NET. authoritative for ROOT-SERVERS.NET.
A.3. -02 WG Document A.4. -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.4. -01 WG Document A.5. -01 WG Document
Revived with minor edits. Open issues marked [[]]. Revived with minor edits. Open issues marked [[]].
A.5. -00 WG Document A.6. -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.6. Initial Document A.7. 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
Dyn, Inc. Dyn, Inc.
150 Dow St 150 Dow St
Manchester, NH 03101 Manchester, NH 03101
USA USA
Email: mlarson@dyn.com Email: mlarson@dyn.com
 End of changes. 21 change blocks. 
34 lines changed or deleted 38 lines changed or added

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