< draft-kh-dnsop-7706bis-00.txt   draft-kh-dnsop-7706bis-01.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Updates: 7706 (if approved) P. Hoffman Updates: 7706 (if approved) P. Hoffman
Intended status: Informational ICANN Intended status: Informational ICANN
Expires: September 3, 2018 March 2, 2018 Expires: December 26, 2018 June 24, 2018
Decreasing Access Time to Root Servers by Running One on Loopback Decreasing Access Time to Root Servers by Running One On The Same Server
draft-kh-dnsop-7706bis-00 draft-kh-dnsop-7706bis-01
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 the same server, such as on a loopback
This document shows how to start and maintain such a copy of the root address. This document shows how to start and maintain such a copy
zone that does not pose a threat to other users of the DNS, at the of the root zone that does not pose a threat to other users of the
cost of adding some operational fragility for the operator. DNS, at the cost of adding some operational fragility for the
operator.
This draft will update RFC 7706. See Section 1.1 for a list of This draft will update RFC 7706. See Section 1.1 for a list of
topics that will be added in the update. topics that will be added in the update.
[ Ed note: Text inside square brackets ([]) is additional background [ Ed note: Text inside square brackets ([]) is additional background
information, answers to freqently asked questions, general musings, information, answers to freqently asked questions, general musings,
etc. They will be removed before publication.] etc. They will be removed before publication.]
[ This document is being collaborated on in Github at: [ This document is being collaborated on in Github at:
https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent
version of the document, open issues, etc should all be available version of the document, open issues, and so on should all be
here. The authors (gratefully) accept pull requests ] available there. The authors gratefully accept pull requests. ]
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 3, 2018.
This Internet-Draft will expire on December 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operation of the Root Zone on the Loopback Address . . . . . 5 3. Operation of the Root Zone on the Local Server . . . . . . . 5
4. Using the Root Zone Server on the Loopback Address . . . . . 6 4. Using the Root Zone Server on the Same Host . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 7 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
Appendix B. Example Configurations of Common Implementations . . 8 Appendix B. Example Configurations of Common Implementations . . 9
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 8 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
B.3. Example Configuration: Microsoft Windows Server 2012 . . 10 B.3. Example Configuration: Microsoft Windows Server 2012 . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
DNS recursive resolvers have to provide answers to all queries from DNS recursive resolvers have to provide answers to all queries from
their customers, even those for domain names that do not exist. For their customers, even those for domain names that do not exist. For
each queried name that has a top-level domain (TLD) that is not in each queried name that has a top-level domain (TLD) that is not in
the recursive resolver's cache, the resolver must send a query to a the recursive resolver's cache, the resolver must send a query to a
root server to get the information for that TLD, or to find out that root server to get the information for that TLD, or to find out that
the TLD does not exist. Typically, the vast majority of queries the TLD does not exist. Research shows that the vast majority of
going to the root are for names that do not exist in the root zone, queries going to the root are for names that do not exist in the root
and the negative answers are cached for a much shorter period of zone, partially because the negative answers are cached for a much
time. A slow path between the recursive resolver and the closest shorter period of time. A slow path between the recursive resolver
root server has a negative effect on the resolver's customers. and the closest root server has a negative effect on the resolver's
customers.
Recursive resolvers currently send queries for all TLDs that are not Many of the queries from recursive resolvers to root servers get
in their caches to root servers, even though most of those queries answers that are referrals to other servers. Malicious third parties
get answers that are referrals to other servers. Malicious third might be able to observe that traffic on the network between the
parties might be able to observe that traffic on the network between recursive resolver and root servers.
the recursive resolver and one or more of the DNS roots.
This document describes a method for the operator of a recursive This document describes a method for the operator of a recursive
resolver to greatly speed these queries and to hide them from resolver to greatly speed these queries and to hide them from
outsiders. The basic idea is to create an up-to-date root zone outsiders. The basic idea is to create an up-to-date root zone
server on a loopback address on the same host as the recursive server on the same host as the recursive server, and use that server
server, and use that server when the recursive resolver looks up root when the recursive resolver looks up root information. The recursive
information. The recursive resolver validates all responses from the resolver validates all responses from the root server on the same
root server on the loopback address, just as it would all responses host, just as it would all responses from a remote root server.
from a remote root server.
The primary goals of this design are to provide faster negative The primary goals of this design are to provide faster negative
responses to stub resolver queries that contain junk queries, and to responses to stub resolver queries that contain queries that result
prevent queries and responses from being visible on the network. in NXDOMAIN responses, and to prevent queries and responses from
This design will probably have little effect on getting faster being visible on the network. This design will probably have little
positive responses to stub resolver for good queries on TLDs, because effect on getting faster positive responses to stub resolver for good
the data for those zones is usually long-lived and already in the queries on TLDs, because the TTL for most TLDs is usually long-lived
cache of the recursive resolver; thus, getting faster positive (on the order of a day or two) and is thus usually already in the
responses is a non-goal of this design. cache of the recursive resolver.
This design explicitly only allows the new root zone server to be run This design explicitly only allows the new root zone server to be run
on a loopback address, in order to prevent the server from serving on the same server as the recursive resolver, in order to prevent the
authoritative answers to any system other than the recursive server from serving authoritative answers to any other system.
resolver. Specifically, the root server on the local system MUST be configured
to only answer queries from the resolvers on the same host, and MUST
NOT answer queries from any other resolver.
It is important to note that the design being described here is not It is important to note that the design described in this document is
considered a "best practice". In fact, many people feel that it is controversial. There is not consensus on whether this is a "best
an excessively risky practice because it introduces a new operational practice". In fact, many people feel that it is an excessively risky
piece to local DNS operations where there was not one before. The practice because it introduces a new operational piece to local DNS
advantages listed above do not come free: if this new system does not operations where there was not one before. The advantages listed
work correctly, users can get bad data, or the entire recursive above do not come free: if this new system does not work correctly,
resolution system might fail in ways that are hard to diagnose. users can get bad data, or the entire recursive resolution system
might fail in ways that are hard to diagnose.
This design requires the addition of authoritative name server This design requires the addition of authoritative name server
software running on the same machine as the recursive resolver. software running on the same machine as the recursive resolver.
Thus, recursive resolver software such as BIND will not need to add Thus, recursive resolver software such as BIND will not need to add
much new functionality, but recursive resolver software such as much new functionality, but recursive resolver software such as
Unbound will need to be able to talk to an authoritative server (such Unbound will need to be able to talk to an authoritative server (such
as NSD) running on the same host. as NSD) running on the same host. However, more recursive resolver
software might add the capabilities described in this document in th
Because of the significant operational risks described in this future.
document, distributions of recursive DNS servers MUST NOT include
configuration for the design described here. It is acceptable to
point to this document, but not to indicate that this configuration
is something that should be considered without reading the entire
document.
A different approach to solving the problems discussed in this A different approach to solving the problems discussed in this
document is described in [RFC8198]. document is described in [RFC8198].
1.1. Updates from RFC 7706 1.1. Updates from RFC 7706
[ This section will list all the changes from RFC 7706. For this -00 RFC 7706 explicitly required that the root server instance be run on
draft, it is the list of changes that we will make in future versions the loopback interface of the host running the validating resolver.
of the daft. ] However, RFC 7706 also had examples of how to set up common software
that did not use the loopback interface. Thus, this document loosens
the restriction on the interface but keeps the requirement that only
systems running on that single host be able to query that root server
instance.
Removed the prohibition on distribution of recursive DNS servers
including configurations for this design because some already do, and
others have expressed an interest in doing so.
Added the idea that a recursive resolver using this design might
switch to using the normal (remote) root servers if the local root
server fails.
[ This section will list all the changes from RFC 7706. For this
draft, it is also the list of changes that we will make in future
versions of the daft. ]
[ Give a clearer comparison of software that allows slaving the root [ Give a clearer comparison of software that allows slaving the root
zone in the software (such as BIND) versus resolver software that zone in the software (such as BIND) versus resolver software that
requires a local slaved root zone (Unbound). ] requires a local slaved root zone (Unbound). ]
[ Add examples of other resolvers such as Knot Resolver and PowerDNS [ Add examples of other resolvers such as Knot Resolver and PowerDNS
Recusor, and maybe Windows Server. ] Recusor, and maybe Windows Server. ]
[ Add discussion of BIND slaving the root zone in the same view [ Add discussion of BIND slaving the root zone in the same view
instead of using different views. ] instead of using different views. ]
skipping to change at page 5, line 11 skipping to change at page 5, line 21
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. Requirements 2. Requirements
In order to implement the mechanism described in this document: In order to implement the mechanism described in this document:
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 key used to sign
the DNS root.
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 for the
the IPv4 loopback addresses (that is, an address in the range root zone on the same host. The root server instance MUST only
127/8 for IPv4 or ::1 in IPv6). respond to queries from the same host. One way to assure not
responding to queries from other hosts is to make the address of
the authoritative server one of the IPv4 loopback addresses (that
is, an address in the range 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 Local Server
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, or it might be part of the configuration of the
recursive resolver system.
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 an address
address that is not in use. For IPv4, this would typically be on the host that is not in use. For IPv4, this could be
127.0.0.1, 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. For IPv6, this would be ::1. acceptable. For IPv6, this would be ::1. It can also be a
publicly-visible address on the host, but only if the
authoritative server software allows restricting the addresses
that can access the authoritative server, and the software is
configured to only allow access from addresses on this single
host.
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 the root zone, as described in [RFC1035]. This the SOA record in the root zone, as described in [RFC1035]. This
inherently means that the contents of the local root zone will likely inherently means that the contents 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 when triggered by NOTIFY messages. If the servers are updated when triggered by NOTIFY messages.
contents of the zone cannot be refreshed before the expire time, the
server MUST return a SERVFAIL error response for all queries until If the contents of the root zone cannot be refreshed before the
the zone can be successfully be set up again. expire time in the SOA, the local root server MUST return a SERVFAIL
error response for all queries sent to it until the zone can be
successfully be set up again. Because this would cause a recursive
resolver on the same host that is relying on this root server to also
fail, a resolver might be configured to immediatly switch to using
other (non-local) root servers if the resolver receives a SERVFAIL
response from a local root server.
In the event that refreshing the contents of the root zone fails, the In the event that refreshing the contents of the root zone fails, the
results can be disastrous. For example, sometimes all the NS records results can be disastrous. For example, sometimes all the NS records
for a TLD are changed in a short period of time (such as 2 days); if for a TLD are changed in a short period of time (such as 2 days); if
the refreshing of the local root zone is broken during that time, the the refreshing of the local root zone is broken during that time, the
recursive resolver will have bad data for the entire TLD zone. recursive resolver will have bad data for the entire TLD zone.
An administrator using the procedure in this document SHOULD have an An administrator using the procedure in this document SHOULD have an
automated method to check that the contents of the local root zone automated method to check that the contents of the local root zone
are being refreshed. One way to do this is to have a separate are being refreshed; this might be part of the resolver software.
process that periodically checks the SOA of the root zone from the One way to do this is to have a separate process that periodically
local root zone and makes sure that it is changing. At the time that checks the SOA of the root zone from the local root zone and makes
this document is published, the SOA for the root zone is the digital sure that it is changing. At the time that this document is
representation of the current date with a two-digit counter appended, published, the SOA for the root zone is the digital representation of
and the SOA is changed every day even if the contents of the root the current date with a two-digit counter appended, and the SOA is
zone are unchanged. For example, the SOA of the root zone on January changed every day even if the contents of the root zone are
2, 2015 was 2015010201. A process can use this fact to create a unchanged. For example, the SOA of the root zone on January 2, 2018
check for the contents of the local root zone (using a program not was 2018010201. A process can use this fact to create a check for
specified in this document). the contents of the local root zone (using a program not specified in
this document).
4. Using the Root Zone Server on the Loopback Address 4. Using the Root Zone Server on the Same Host
A recursive resolver that wants to use a root zone server operating A recursive resolver that wants to use a root zone server operating
as described in Section 3 simply specifies the local address as the as described in Section 3 simply specifies the local address as the
place to look when it is looking for information from the root. All place to look when it is looking for information from the root. All
responses from the root server must be validated using DNSSEC. responses from the root server MUST be validated using DNSSEC.
Note that using this configuration will cause the recursive resolver Note that using this simplistic configuration will cause the
to fail if the local root zone server fails. See Appendix B for more recursive resolver to fail if the local root zone server fails. A
discussion of this for specific software. more robust configuration would cause the resolver to start using the
normal remote root servers when the local root server fails (such as
if it does not respond or gives SERVFAIL responses).
See Appendix B for more discussion of this for specific software.
To test the proper operation of the recursive resolver with the local To test the proper operation of the recursive resolver with the local
root server, use a DNS client to send a query for the SOA of the root root server, use a DNS client to send a query for the SOA of the root
to the recursive server. Make sure the response that comes back has to the recursive server. Make sure the response that comes back has
the AA bit in the message header set to 0. the AA bit in the message header set to 0.
5. Security Considerations 5. Security Considerations
A system that does not follow the DNSSEC-related requirements given A system that does not follow the DNSSEC-related requirements given
in Section 2 can be fooled into giving bad responses in the same way in Section 2 can be fooled into giving bad responses in the same way
as any recursive resolver that does not do DNSSEC validation on as any recursive resolver that does not do DNSSEC validation on
responses from a remote root server. Anyone deploying the method responses from a remote root server. Anyone deploying the method
described in this document should be familiar with the operational described in this document should be familiar with the operational
benefits and costs of deploying DNSSEC [RFC4033]. benefits and costs of deploying DNSSEC [RFC4033].
As stated in Section 1, this design explicitly only allows the new As stated in Section 1, this design explicitly only allows the new
root zone server to be run on a loopback address, in order to prevent root zone server to be run on the same host, answering queries only
the server from serving authoritative answers to any system other from resolvers on that host, in order to prevent the server from
than the recursive resolver. This has the security property of serving authoritative answers to any system other than the recursive
limiting damage to any other system that might try to rely on an resolver. This has the security property of limiting damage to any
altered copy of the root. other system that might try to rely on an altered copy of the root.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 8, line 32 skipping to change at page 9, line 18
recursive server software that is believed to correctly implement the recursive server software that is believed to correctly implement the
requirements given in this document. requirements given in this document.
The IPv4 and IPv6 addresses in this section were checked recently by The IPv4 and IPv6 addresses in this section were checked recently by
testing for AXFR over TCP from each address for the known single- testing for AXFR over TCP from each address for the known single-
letter names in the root-servers.net zone. letter names in the root-servers.net zone.
The examples here use a loopback address of 127.12.12.12, but typical The examples here use a loopback address of 127.12.12.12, but typical
installations will use 127.0.0.1. The different address is used in installations will use 127.0.0.1. The different address is used in
order to emphasize that the root server does not need to be on the order to emphasize that the root server does not need to be on the
device at "localhost". device at the name "localhost" which is often locally served as
127.0.0.1.
B.1. Example Configuration: BIND 9.9 B.1. Example Configuration: BIND 9.9
BIND acts both as a recursive resolver and an authoritative server. BIND acts both as a recursive resolver and an authoritative server.
Because of this, there is "fate-sharing" between the two servers in Because of this, there is "fate-sharing" between the two servers in
the following configuration. That is, if the root server dies, it is the following configuration. That is, if the root server dies, it is
likely that all of BIND is dead. likely that all of BIND is dead.
Using this configuration, queries for information in the root zone Using this configuration, queries for information in the root zone
are returned with the AA bit not set. are returned with the AA bit not set.
skipping to change at page 11, line 48 skipping to change at page 12, line 35
the loopback address is not a new concept, and that we have chatted the loopback address is not a new concept, and that we have chatted
with many people about that idea over time. For example, Bill with many people about that idea over time. For example, Bill
Manning described a similar solution but to a very different problem Manning described a similar solution but to a very different problem
(intermittent connectivity, instead of constant but slow (intermittent connectivity, instead of constant but slow
connectivity) in his doctoral dissertation in 2013 [Manning2013]. connectivity) in his doctoral dissertation in 2013 [Manning2013].
Evan Hunt contributed greatly to the logic in the requirements. Evan Hunt contributed greatly to the logic in the requirements.
Other significant contributors include Wouter Wijngaards, Tony Hain, Other significant contributors include Wouter Wijngaards, Tony Hain,
Doug Barton, Greg Lindsay, and Akira Kato. The authors also received Doug Barton, Greg Lindsay, and Akira Kato. The authors also received
many offline comments about making the document clear that this is many offline comments about making the document clear that this is
just a description of a way to operate a root zone on localhost, and just a description of a way to operate a root zone on the same host,
not a recommendation to do so. and not a recommendation to do so.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
Email: Warren@kumari.net Email: Warren@kumari.net
Paul Hoffman Paul Hoffman
ICANN ICANN
 End of changes. 31 change blocks. 
99 lines changed or deleted 136 lines changed or added

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