Internet DRAFT - draft-wkumari-dnsop-dist-root
draft-wkumari-dnsop-dist-root
Network Working Group W. Kumari, Ed.
Internet-Draft Google
Intended status: Informational P. Hoffman, Ed.
Expires: January 4, 2015 VPN Consortium
July 3, 2014
Securely Distributing the DNS Root
draft-wkumari-dnsop-dist-root-01
Abstract
This document recommends that recursive DNS resolvers get copies of
the root zone, validate it using DNSSEC, populate their caches with
the information, and also give negative responses from the validated
zone.
[[ Note: This document is largely a discussion starting point. ]]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Kumari & Hoffman Expires January 4, 2015 [Page 1]
Internet-Draft Securely Distributing the DNS Root July 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Open Question: How Should the Root Zone Be Distributed? . . . 5
4. Open Question: Should Responses Have the AA Bit Set? . . . . 5
5. Pros and Cons of this Technique . . . . . . . . . . . . . . . 6
5.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
One of the main advantages of a DNSSEC-signed root zone is that it
doesn't matter where you get the data from, as long as you validate
the contents of the zone using DNSSEC information. From that point
on, you know all of the contents of the root zone at the time that
you retrieve and validated the zone.
When a typical recursive resolver starts up, it has an empty cache,
the addresses of the root servers. As it begins answering queries,
it populates its cache by making a number of queries to the set of
root servers, and caching the results. All queries for root zone
names that come to the recursive resolver that are not in either its
positive or negative cache are sent to one of the root servers. This
process cause a large number of the queries that hit the root are so
called "junk" queries, such as queries for second-level domains in
non-existent TLDs.
This document is describes a mechanism to populate caches in
recursive resolvers with the verified contents of the full root zone
so that the recursive resolvers have the all of root zone content
cached. This technique can be viewed as pre-populating a resolver's
cache with the root zone information by retrieving a signed copy of
the root zone and verifying the contents.
The two goals of this mechanism are to provide faster negative
responses to stub resolver queries that contain junk queries, and to
reduce the number of junk queries sent to the root servers. The
Kumari & Hoffman Expires January 4, 2015 [Page 2]
Internet-Draft Securely Distributing the DNS Root July 2014
mechanism has other minor advantages, but those two are the focus of
this document.
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Requirements
In the discussion below, the term "legacy operation" means the way
that a recursive resolver acts when it is not using the mechanism
describe in this document, namely as a normal validating recursive
resolver with no other special features.
In order to implement the mechanism described in this document, a
recursive resolver MUST support DNSSEC, and MUST have an up-to-date
copy of the DNS root key.
A recursive resolver using this mechanism MUST follow these steps at
startup or after clearing its cache:
1. The resolver determines the list of root zone delivery servers.
The delivery mechanism is not yet defined in this document, and
some possible options for it are described in Section 3.
2. The resolver SHOULD randomly sort the list of zone delivery
servers so that all the servers get a fairly even distribution of
queries.
3. The resolver SHOULD attempt to transfer the signed root zone
using the transfer protocol from each one of the servers until
either success is achieved or the list has been exhausted. The
resolver MAY attempt to transfer in parallel to minimize startup
latency. If the root zone cannot be transferred, the resolver
logs this as an error, and MUST fall back to legacy operation.
4. The resolver MUST validate the records in the zone using DNSSEC.
If any of the records do not validate, the resolver MUST discard
all records received, MUST log an error, and SHOULD try the next
server in the list. If no transferred copy of the root zone can
be validated, the resolver logs this as an error, and falls back
to legacy operation. Note that the resolver MUST validate all of
the zone contents, and MUST NOT start using the new contents
until all have been validated; the resolver MUST NOT use "lazy
validation". This means that the addition of the zone data MUST
be an atomic operation.
Kumari & Hoffman Expires January 4, 2015 [Page 3]
Internet-Draft Securely Distributing the DNS Root July 2014
The resolver MAY store the contents of the validated root zone to
disk. If the resolver has a stored copy of the root zone, and the
data in the zone is not expired, and that copy was written within the
refresh time listed in the zone, the resolver MAY load that zone
instead of transferring.
Once the resolver has transferred and validated the zone, it MUST
attempt to keep its copy of the root zone up to date. This includes
following the refresh, retry, expire logic, with certain
modifications:
o If the zone expires (for example, because it cannot retransfer
because of blocked TCP connections), the resolver MUST fall back
to legacy operation and MUST log an error. It MUST NOT return
SERVFAIL to queries only due to its copy of the root zone being
expired.
o The resolver MUST validate the contents of the records in the zone
using DNSSEC for every transfer. The resolver SHOULD try
alternate servers if the validation fails. If the resolver is
unable to transfer a copy of the zone that validates, it MUST
treat this as an error, MUST discard the received records, and
MUST fail back to legacy operation. Note that the resolver MUST
validate all of the zone contents, and MUST NOT start using the
new contents until all have been validated; the resolver MUST NOT
use "lazy validation". This means that the replacement of the
current zone data MUST be an atomic operation.
o The resolver SHOULD attempt to restart this process at every retry
interval for the root zone.
o The resolver MUST set the AD bit on responses to queries for
records in the root zone. This action is the same as if it had
inserted the entry into its cache through a "normal" query that
received a DNSSEC-validated answer.
o The resolver MUST set the TTL on responses in the same fashion as
it would in legacy operation. The difference here is that, when
the TTL times out, instead of fetching the new answer from the
root, the resolver simply starts the TTL at the maximum listed in
the root zone.
Compliant nameservers software MUST include an option to securely
cache the root zone (an example name for this option could be
"transfer-and-validate-root [yes|no]"). That is, the mechanism
described in this document MUST be optional, and the cache operator
MUST be able to turn it off and on.
Kumari & Hoffman Expires January 4, 2015 [Page 4]
Internet-Draft Securely Distributing the DNS Root July 2014
3. Open Question: How Should the Root Zone Be Distributed?
The signed root zone can be distributed over almost any protocol.
Because the zone is signed, the distribution protocol does not need
to be authenticated. Suggestions for the distribution mechanism
include:
AXFR zone transfer within the DNS
HTTP, most likely with appropriately-tuned caching
FTP
[[ Others... ]]
Note that with any of these methods, the zone does not need to be
transferred from the root servers themselves. Instead, a simple
discovery mechanism can be built into the protocol that lets a
recursive resolver discover where there are servers that will let it
transfer the root zone.
4. Open Question: Should Responses Have the AA Bit Set?
A recursive resolver that has a securely validated copy of the root
can be thought of in at least two ways: as a smarter cache, or as a
pseudo-slave server for the root. This section discusses the
ramifications of those two choices. In both scenarios, the resolver
will send back NXDOMAIN responses for junk queries without sending
queries to the root and the resolver will set the AD bit on the
responses. However, the two scenarios differ in whether or not the
responses have the AA bit set.
A smarter cache does not set the AA bit. The responses for any query
for a name in the root or an NXDOMAIN that is being sent because the
TLD is junk come back with the AD bit set but the AA bit not set,
just as it would in legacy operation.
A pseudo-slave to the root sets the AA bit in response to any query
for a name in the root or an NXDOMAIN that is being sent because the
TLD is junk. The reason that this is called a pseudo-slave instead
of a slave is that there is a general expectation that a slave has a
relationship with the master that would cause the slave to be
notified of changes in the master with a NOTIFY announcement; that is
not the case here. It acts a slave because it knows exactly how the
master would reply at the time that it retrieve the signed zone, but
it is a pseudo-slave because the master has no way of alerting it of
changes.
Kumari & Hoffman Expires January 4, 2015 [Page 5]
Internet-Draft Securely Distributing the DNS Root July 2014
The advantage of a recursive resolver acting as a pseudo-slave is
that other resolvers that demand authoritative answers can ask if for
those. However, there are few scenarios in which those demanding
resolvers exist. The disadvantage of a recursive resolver acting as
a pseudo-slave is that there is no way to signal that it is a pseudo-
slave and not a real slave. Thus, someone seeing the AA bit set
might thing that the resolver is a real slave. This opens the can of
worms about trusting the settings of the AA and AD bits in responses.
5. Pros and Cons of this Technique
This is primarily a tracking / discussion section, and the text is
kept even looser than in the rest of this doc. These are not
ordered.
5.1. Pros
o Junk queries / negative caching - Currently, a significant number
of queries to the root servers are "junk" queries. Many of these
queries are TLDs that do not (and may never) exist in the root
Another significant source of junk is queries where the negative
TLD answer did not get cached because the queries are for second-
level domains (a negative cache entry for "foo.example" will not
cover a subsequent query for "bar.example").
o DoS against the root service - By distributing the contents of the
root to many recursive resolvers, the DoS protection for customers
of the root servers is significantly increased. A DDoS may still
be able to take down some recursive servers, but there is much
more root service infrastructure to attack in order to be
effective. Of course, there is still a zone distribution system
that could be attacked (but it would need to be kept down for a
much longer time to cause significant damage, and so far the root
has stood up just fine to DDoS.
o Small increase to privacy of requests - This also removes a place
where attackers could collect information. Although query name
minimization also achieves some of this, it does still leak the
TLDs that people behind a resolver are querying for, which may in
itself be a concern (for example someone in a homophobic country
who is querying for a name in .gay).
5.2. Cons
o Loss of agility in making root zone changes - Currently, if there
is an error in the root zone (or someone needs to make an
emergency change), a new root zone can be created, and the root
server operators can be notified and start serving the new zone
Kumari & Hoffman Expires January 4, 2015 [Page 6]
Internet-Draft Securely Distributing the DNS Root July 2014
quickly. Of course, this does not invalidate the bad information
in (long TTL) cached answers. Notifying every recursive resolver
is not feasible. Currently, an "oops" in the root zone will be
cached for the TTL of the record by some percentage of servers.
Using the technique described above, the information may be cached
(by the same percentage of servers) for the refresh time + the TTL
of the record
o No central monitoring point - DNS operators lose the ability to
monitor the root system. While there is work underway to
implement better instrumentation of the root server system, this
(potentially) removes the thing to monitor.
o Increased complexity in nameserver software and their operations -
Any proposal for recursive servers to copy and serve the root
inherently means more code to write and execute. Note that many
recursive resolvers are on inexpensive home routers that are
rarely (if ever) updated.
o Changes the nature and distribution of traffic hitting the root
servers - If all the "good" recursive resolvers deploy root
copying, then root servers end up servicing only "bad" recursive
resolvers and attack traffic. The roots (could) become what AS112
is for RFC1918.
6. IANA Considerations
This document requires no action from the IANA.
7. Security Considerations
A resolver that uses this mechanism but does not do full DNSSEC
validation on the data it uses can obviously cause serious security
issues because it can be fooled into giving wrong answers.
[[ More? ]]
8. Acknowledgements
The editors fully acknowledge that this is not a new concept, and
that we have chatted with many people about this. If we have spoken
to you and your name is not listed below, let us know.
9. Contributors
The general concept in this document is not new; there have been
discussions regarding recursive resolvers copying the root zone for
Kumari & Hoffman Expires January 4, 2015 [Page 7]
Internet-Draft Securely Distributing the DNS Root July 2014
many years. The fact that the root zone is now signed with DNSSEC
makes implementing some of these techniques more feasible.
The following is an unordered list of individuals have contributed
text and / or significant discussions to this document.
Steve Crocker - Shinkuro
Jaap Akkerhuis - NLnet Labs
David Conrad - Virtualized, LLC.
Lars-Johan Liman - Netnod
Suzanne Woolf - Individual
Roy Arends - Nominet
Olaf Kolkman - NLnet Labs
Danny McPherson - Verisign
Joe Abley - Dyn
Jim Martin - ISC
Jared Mauch - NTT America
Rob Austien - Dragon Research Labs
Sam Weiler - Parsons
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Warren Kumari (editor)
Google
1600 Amphitheatre Parkway
Mountain View, Ca 94043
US
Email: Warren@kumari.net
Kumari & Hoffman Expires January 4, 2015 [Page 8]
Internet-Draft Securely Distributing the DNS Root July 2014
Paul Hoffman (editor)
VPN Consortium
Email: paul.hoffman@vpnc.org
Kumari & Hoffman Expires January 4, 2015 [Page 9]
