draft-ietf-dnsop-root-loopback-04.txt   draft-ietf-dnsop-root-loopback-05.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational P. Hoffman Intended status: Informational P. Hoffman
Expires: March 17, 2016 ICANN Expires: April 3, 2016 ICANN
September 14, 2015 October 1, 2015
Decreasing Access Time to Root Servers by Running One on Loopback Decreasing Access Time to Root Servers by Running One on Loopback
draft-ietf-dnsop-root-loopback-04 draft-ietf-dnsop-root-loopback-05
Abstract Abstract
Some DNS recursive resolvers have longer-than-desired round trip Some DNS recursive resolvers have longer-than-desired round trip
times to the closest DNS root server. Some DNS recursive resolver times to the closest DNS root server. Some DNS recursive resolver
operators want to prevent snooping of requests sent to DNS root operators want to prevent snooping of requests sent to DNS root
servers by third parties. Such resolvers can greatly decrease the servers by third parties. Such resolvers can greatly decrease the
round trip time and prevent observation of requests by running a copy round trip time and prevent observation of requests by running a copy
of the full root zone on a loopback address (such as 127.0.0.1). of the full root zone on a loopback address (such as 127.0.0.1).
This document shows how to start and maintain such a copy of the root This document shows how to start and maintain such a copy of the root
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 March 17, 2016. This Internet-Draft will expire on April 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 4, line 24 skipping to change at page 4, line 24
o The system MUST be able to validate a zone with DNSSEC [RFC4033]. o The system MUST be able to validate a zone with DNSSEC [RFC4033].
o The system MUST have an up-to-date copy of the DNS root key. o The system MUST have an up-to-date copy of the DNS root key.
o The system MUST be able to retrieve a copy of the entire root zone o The system MUST be able to retrieve a copy of the entire root zone
(including all DNSSEC-related records). (including all DNSSEC-related records).
o The system MUST be able to run an authoritative server on one of o The system MUST be able to run an authoritative server on one of
the IPv4 loopback addresses (that is, an address in the range the IPv4 loopback addresses (that is, an address in the range
127/8). 127/8 for IPv4 or ::1 in IPv6).
A corollary of the above list is that authoritative data in the root A corollary of the above list is that authoritative data in the root
zone used on the local authoritative server MUST be identical to the zone used on the local authoritative server MUST be identical to the
same data in the root zone for the DNS. It is possible to change the same data in the root zone for the DNS. It is possible to change the
unsigned data (the glue records) in the copy of the root zone, but unsigned data (the glue records) in the copy of the root zone, but
such changes could cause problems for the recursive server that such changes could cause problems for the recursive server that
accesses the local root zone, and therefore any changes to the glue accesses the local root zone, and therefore any changes to the glue
records SHOULD NOT be made. records SHOULD NOT be made.
3. Operation of the Root Zone on the Loopback Address 3. Operation of the Root Zone on the Loopback Address
skipping to change at page 4, line 46 skipping to change at page 4, line 46
The operation of an authoritative server for the root in the system The operation of an authoritative server for the root in the system
described here can be done separately from the operation of the described here can be done separately from the operation of the
recursive resolver. recursive resolver.
The steps to set up the root zone are: The steps to set up the root zone are:
1. Retrieve a copy of the root zone. (See Appendix A for some 1. Retrieve a copy of the root zone. (See Appendix A for some
current locations of sources.) current locations of sources.)
2. Start the authoritative server with the root zone on a loopback 2. Start the authoritative server with the root zone on a loopback
address that is not in use. This would typically be 127.0.0.1, address that is not in use. For IPv4, this would typically be
but if that address is in use, any address in 127/8 is 127.0.0.1, but if that address is in use, any address in 127/8 is
acceptable. acceptable. For IPv6, this would be ::1.
The contents of the root zone MUST be refreshed using the timers from The contents of the root zone MUST be refreshed using the timers from
the SOA record in root zone, as described in [RFC1035]. This the SOA record in root zone, as described in [RFC1035]. This
inherently means that the conents of the local root zone will likely inherently means that the conents of the local root zone will likely
be a little behind those of the global root servers because those be a little behind those of the global root servers because those
servers are updated triggered by NOTIFY messages. If the contents of servers are updated triggered by NOTIFY messages. If the contents of
the zone cannot be refreshed before the expire time, the server MUST the zone cannot be refreshed before the expire time, the server MUST
return a SERVFAIL error response for all queries until the zone can return a SERVFAIL error response for all queries until the zone can
be successfully be set up again. be successfully be set up again.
 End of changes. 5 change blocks. 
8 lines changed or deleted 8 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/