draft-ietf-dnsop-7706bis-01.txt   draft-ietf-dnsop-7706bis-02.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: April 25, 2019 October 22, 2018 Expires: July 29, 2019 January 25, 2019
Decreasing Access Time to Root Servers by Running One On The Same Server Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-01 draft-ietf-dnsop-7706bis-02
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 the same server, such as on a loopback of the full root zone on the same server, such as on a loopback
address. This document shows how to start and maintain such a copy address. This document shows how to start and maintain such a copy
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 April 25, 2019. This Internet-Draft will expire on July 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3. Operation of the Root Zone on the Local Server . . . . . . . 5 3. Operation of the Root Zone on the Local Server . . . . . . . 5
4. Using the Root Zone Server on the Same Host . . . . . . . . . 7 4. Using the Root Zone Server on the Same Host . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
Appendix B. Example Configurations of Common Implementations . . 9 Appendix B. Example Configurations of Common Implementations . . 9
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 10
B.3. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10 B.3. Example Configuration: Unbound . . . . . . . . . . . . . 11
B.4. Example Configuration: Microsoft Windows Server 2012 . . 11 B.4. Example Configuration: Knot Resolver . . . . . . . . . . 11
B.5. Example Configuration: Microsoft Windows Server 2012 . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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. Research shows that the vast majority of the TLD does not exist. Research shows that the vast majority of
queries going to the root are for names that do not exist in the root queries going to the root are for names that do not exist in the root
zone, partially because the negative answers are cached for a much zone because negative answers are sometimes cached for a much shorter
shorter period of time. A slow path between the recursive resolver period of time.
and the closest root server has a negative effect on the resolver's
customers.
Many of the queries from recursive resolvers to root servers get Many of the queries from recursive resolvers to root servers get
answers that are referrals to other servers. Malicious third parties answers that are referrals to other servers. Malicious third parties
might be able to observe that traffic on the network between the might be able to observe that traffic on the network between the
recursive resolver and root servers. recursive resolver and root servers.
This document describes a method for the operator of a recursive The primary goals of this design are to provide more reliable answers
resolver to greatly speed these queries and to hide them from for queries to the root zone during network attacks, and to prevent
outsiders. The basic idea is to create an up-to-date root zone queries and responses from being visible on the network. This design
server on the same host as the recursive server, and use that server will probably have little effect on getting faster responses to stub
when the recursive resolver looks up root information. The recursive resolver for good queries on TLDs, because the TTL for most TLDs is
resolver validates all responses from the root server on the same usually long-lived (on the order of a day or two) and is thus usually
host, just as it would all responses from a remote root server. already in the cache of the recursive resolver; the same is true for
the TTL for negative answers from the root servers.
The primary goals of this design are to provide faster negative This document describes a method for the operator of a recursive
responses to stub resolver queries that contain queries that result resolver to have a complete root zone locally, and to hide these
in NXDOMAIN responses, and to prevent queries and responses from queries from outsiders. The basic idea is to create an up-to-date
being visible on the network. This design will probably have little root zone server on the same host as the recursive server, and use
effect on getting faster positive responses to stub resolver for good that server when the recursive resolver looks up root information.
queries on TLDs, because the TTL for most TLDs is usually long-lived The recursive resolver validates all responses from the root server
(on the order of a day or two) and is thus usually already in the on the same host, just as it would all responses from a remote root
cache of the recursive resolver. server.
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 the same server as the recursive resolver, in order to prevent the on the same server as the recursive resolver, in order to prevent the
server from serving authoritative answers to any other system. server from serving authoritative answers to any other system.
Specifically, the root server on the local system MUST be configured Specifically, the root server on the local system MUST be configured
to only answer queries from the resolvers on the same host, and MUST to only answer queries from the resolvers on the same host, and MUST
NOT answer queries from any other resolver. NOT answer queries from any other resolver.
It is important to note that the design described in this document is At the time that RFC 7706 was published, it was considered
controversial. There is not consensus on whether this is a "best controversial: there was not consensus on whether this was a "best
practice". In fact, many people feel that it is an excessively risky practice". In fact, many people felt that it is an excessively risky
practice because it introduces a new operational piece to local DNS practice because it introduced a new operational piece to local DNS
operations where there was not one before. The advantages listed operations where there was not one before. Since then, the DNS
above do not come free: if this new system does not work correctly, operational community has largely shifted to believing that local
users can get bad data, or the entire recursive resolution system serving of the root zone for an individual resolver is a reasonable
might fail in ways that are hard to diagnose. practice. The advantages listed above do not come free: if this new
system does not work correctly, 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 uses authoritative name server software running on the
software running on the same machine as the recursive resolver. same machine as the recursive resolver. Thus, recursive resolver
Thus, recursive resolver software such as BIND or modern versions of software such as BIND or modern versions of common open source
Unbound do not need to add new functionality, but other recursive recursive resolver software do not need to add new functionality, but
resolver software might need to be able to talk to an authoritative other recursive resolver software might need to be able to talk to an
server running on the same host. More recursive resolver software authoritative server running on the same host.
are expected add the capabilities described in this document in th
future.
A different approach to solving the problems discussed in this A different approach to solving some of the problems discussed in
document is described in [RFC8198]. this document is described in [RFC8198].
1.1. Updates from RFC 7706 1.1. Updates from RFC 7706
RFC 7706 explicitly required that the root server instance be run on RFC 7706 explicitly required that the root server instance be run on
the loopback interface of the host running the validating resolver. the loopback interface of the host running the validating resolver.
However, RFC 7706 also had examples of how to set up common software However, RFC 7706 also had examples of how to set up common software
that did not use the loopback interface. Thus, this document loosens that did not use the loopback interface. Thus, this document loosens
the restriction on the interface but keeps the requirement that only the restriction on the interface but keeps the requirement that only
systems running on that single host be able to query that root server systems running on that single host be able to query that root server
instance. instance.
skipping to change at page 4, line 42 skipping to change at page 4, line 44
draft, it is also the list of changes that we will make in future draft, it is also the list of changes that we will make in future
versions of the daft. ] 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 or modern Unbound) versus resolver zone in the software (such as BIND or modern Unbound) versus resolver
software that requires a local slaved root zone (older Unbound). ] software that requires a local slaved root zone (older Unbound). ]
[ Add a description of Knot's cache-prefilling as way to get the data [ Add a description of Knot's cache-prefilling as way to get the data
without having a local authoritative. ] without having a local authoritative. ]
[ Add examples of other resolvers such as Knot Resolver and PowerDNS [ Add examples of other resolvers such as PowerDNS Recusor. ]
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. ]
[ Make the use cases explicit. Be clearer that a real use case is [ Make the use cases explicit. Be clearer that a real use case is
folks who are worried that root server unavailabilty due to DDoS folks who are worried that root server unavailabilty due to DDoS
against them is a reason some people would use the mechanisms here. against them is a reason some people would use the mechanisms here.
] ]
[ Describe how slaving the root zone from root zone servers does not [ Describe how slaving the root zone from root zone servers does not
skipping to change at page 5, line 34 skipping to change at page 5, line 34
o The system MUST have an up-to-date copy of the key used to sign o The system MUST have an up-to-date copy of the key used to sign
the DNS root. 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 for the o The system MUST be able to run an authoritative server for the
root zone on the same host. The root server instance MUST only root zone on the same host. The root server instance MUST only
respond to queries from the same host. One way to assure not respond to queries from the same host. One way to assure not
responding to queries from other hosts is to make the address of responding to queries from other hosts is to make the address of
the authoritative server one of the IPv4 loopback addresses (that the authoritative server one of the loopback addresses (that is,
is, an address in the range 127/8 for IPv4 or ::1 in IPv6). 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 Local Server 3. Operation of the Root Zone on the Local Server
skipping to change at page 8, line 34 skipping to change at page 8, line 34
the root zone from ICANN by zone transfer (AXFR) over TCP from DNS the root zone from ICANN by zone transfer (AXFR) over TCP from DNS
servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
Currently, the root can also be retrieved by AXFR over TCP from the Currently, the root can also be retrieved by AXFR over TCP from the
following root server operators: following root server operators:
o b.root-servers.net o b.root-servers.net
o c.root-servers.net o c.root-servers.net
o d.root-servers.net
o f.root-servers.net o f.root-servers.net
o g.root-servers.net o g.root-servers.net
o k.root-servers.net o k.root-servers.net
It is crucial to note that none of the above services are guaranteed It is crucial to note that none of the above services are guaranteed
to be available. It is possible that ICANN or some of the root to be available. It is possible that ICANN or some of the root
server operators will turn off the AXFR capability on the servers server operators will turn off the AXFR capability on the servers
listed above. Using AXFR over TCP to addresses that are likely to be listed above. Using AXFR over TCP to addresses that are likely to be
skipping to change at page 9, line 15 skipping to change at page 9, line 17
Appendix B. Example Configurations of Common Implementations Appendix B. Example Configurations of Common Implementations
This section shows fragments of configurations for some popular This section shows fragments of configurations for some popular
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
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
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 10, line 12 skipping to change at page 10, line 12
all zone data in the recursive server will be updated as soon as all zone data in the recursive server will be updated as soon as
it receives its copy of the zone. it receives its copy of the zone.
view root { view root {
match-destinations { 127.12.12.12; }; match-destinations { 127.12.12.12; };
zone "." { zone "." {
type slave; type slave;
file "rootzone.db"; file "rootzone.db";
notify no; notify no;
masters { masters {
192.228.79.201; # b.root-servers.net 192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net 192.33.4.12; # c.root-servers.net
192.5.5.241; # f.root-servers.net 199.7.91.13; # d.root-servers.net
192.112.36.4; # g.root-servers.net 192.5.5.241; # f.root-servers.net
193.0.14.129; # k.root-servers.net 192.112.36.4; # g.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org 193.0.14.129; # k.root-servers.net
192.0.32.132; # xfr.lax.dns.icann.org 192.0.47.132; # xfr.cjr.dns.icann.org
2001:500:84::b; # b.root-servers.net 192.0.32.132; # xfr.lax.dns.icann.org
2001:500:2f::f; # f.root-servers.net 2001:500:84::b; # b.root-servers.net
2001:7fd::1; # k.root-servers.net 2001:500:2::c; # c.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org 2001:500:2d::d; # d.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:500:12::d0d; # g.root-servers.net
2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org 2620:0:2d0:202::132; # xfr.lax.dns.icann.org
}; };
}; };
}; };
view recursive { view recursive {
dnssec-validation auto; dnssec-validation auto;
allow-recursion { any; }; allow-recursion { any; };
recursion yes; recursion yes;
zone "." { zone "." {
type static-stub; type static-stub;
server-addresses { 127.12.12.12; }; server-addresses { 127.12.12.12; };
}; };
}; };
B.2. Example Configuration: Unbound 1.8 B.2. Example Configuration: Unbound 1.8
[ Add a description of Unbound 1.8's "auth-zone" configuration ] Similar to BIND, Unbound starting with version 1.8 can act both as a
recursive resolver and an authoritative server.
B.3. Example Configuration: Unbound 1.4 and NSD 4
[ Do we still want this section? If so, maybe use Know without auth-zone:
cache-prefilling. ]] name: "."
master: 192.228.79.201 # b.root-servers.net
master: 192.33.4.12 # c.root-servers.net
master: 199.7.91.13 # d.root-servers.net
master: 192.5.5.241 # f.root-servers.net
master: 192.112.36.4 # g.root-servers.net
master: 193.0.14.129 # k.root-servers.net
master: 192.0.47.132 # xfr.cjr.dns.icann.org
master: 192.0.32.132 # xfr.lax.dns.icann.org
master: 2001:500:84::b # b.root-servers.net
master: 2001:500:2::c # c.root-servers.net
master: 2001:500:2d::d # d.root-servers.net
master: 2001:500:2f::f # f.root-servers.net
master: 2001:500:12::d0d # g.root-servers.net
master: 2001:7fd::1 # k.root-servers.net
master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org
master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org
fallback-enabled: yes
for-downstream: no
for-upstream: yes
Unbound and NSD are separate software packages. Because of this, B.3. Example Configuration: Unbound
there is no "fate-sharing" between the two servers in the following
configurations. That is, if the root server instance (NSD) dies, the
recursive resolver instance (Unbound) will probably keep running but
will not be able to resolve any queries for the root zone.
Therefore, the administrator of this configuration might want to
carefully monitor the NSD instance and restart it immediately if it
dies.
Using this configuration, queries for information in the root zone [ Add an example of modern Unbound, or point to the Unbound
are returned with the AA bit not set. documentation where it exists ]
# Configuration for Unbound B.4. Example Configuration: Knot Resolver
server:
do-not-query-localhost: no
stub-zone:
name: "."
stub-prime: no
stub-addr: 127.12.12.12
# Configuration for NSD Knot Resolver uses its "prefill" module to load the root zone
server: information. This is described at <https://knot-
ip-address: 127.12.12.12 resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
zone: 7706>.
name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
B.4. Example Configuration: Microsoft Windows Server 2012 B.5. Example Configuration: Microsoft Windows Server 2012
Windows Server 2012 contains a DNS server in the "DNS Manager" Windows Server 2012 contains a DNS server in the "DNS Manager"
component. When activated, that component acts as a recursive component. When activated, that component acts as a recursive
server. DNS Manager can also act as an authoritative server. server. DNS Manager can also act as an authoritative server.
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 set. are returned with the AA bit set.
The steps to configure DNS Manager to implement the requirements in The steps to configure DNS Manager to implement the requirements in
this document are: this document are:
skipping to change at page 12, line 33 skipping to change at page 12, line 37
Right-click on the server name in the hierarchy, choosing the Right-click on the server name in the hierarchy, choosing the
"Advanced" tab in the dialog box. See that "Disable recursion "Advanced" tab in the dialog box. See that "Disable recursion
(also disables forwarders)" is not selected, and that "Enable (also disables forwarders)" is not selected, and that "Enable
DNSSEC validation for remote responses" is selected. DNSSEC validation for remote responses" is selected.
Acknowledgements Acknowledgements
The authors fully acknowledge that running a copy of the root zone on The authors fully acknowledge that running a copy of the root zone on
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 to the problems in his doctoral
(intermittent connectivity, instead of constant but slow 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 the same host, just a description of a way to operate a root zone on the same host,
and not a recommendation to do so. and not a recommendation to do so.
People who contributed to this update to RFC 7706 include: Florian
Obser, nusenu, [[ others go here ]].
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
Email: Warren@kumari.net Email: Warren@kumari.net
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
 End of changes. 27 change blocks. 
109 lines changed or deleted 104 lines changed or added

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