draft-ietf-dnsop-as112-ops-03.txt   draft-ietf-dnsop-as112-ops-04.txt 
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft TekSavvy Internet-Draft ICANN
Intended status: Informational W. Maton Intended status: Informational W. Maton
Expires: April 8, 2010 NRC-CNRC Expires: January 30, 2011 NRC-CNRC
October 5, 2009 July 29, 2010
AS112 Nameserver Operations AS112 Nameserver Operations
draft-ietf-dnsop-as112-ops-03 draft-ietf-dnsop-as112-ops-04
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 8, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
Many sites connected to the Internet make use of IPv4 addresses which Many sites connected to the Internet make use of IPv4 addresses which
are not globally unique. Examples are the addresses designated in are not globally unique. Examples are the addresses designated in
RFC1918 for private use within individual sites. RFC1918 for private use within individual sites.
Devices in such environments may occasionally originate reverse DNS Devices in such environments may occasionally originate reverse DNS
queries corresponding to those private-use addresses. Since the queries corresponding to those private-use addresses. Since the
addresses concerned have only local significance, it is good practice addresses concerned have only local significance, it is good practice
skipping to change at page 4, line 5 skipping to change at page 1, line 36
It is not possible for public DNS servers to give useful answers to It is not possible for public DNS servers to give useful answers to
such queries. In addition, due to the wide deployment of private-use such queries. In addition, due to the wide deployment of private-use
addresses and the continuing growth of the Internet, the volume of addresses and the continuing growth of the Internet, the volume of
such queries is large and growing. The AS112 project aims to provide such queries is large and growing. The AS112 project aims to provide
a distributed sink for such queries in order to reduce the load on a distributed sink for such queries in order to reduce the load on
the root and IN-ADDR.ARPA authority servers. the root and IN-ADDR.ARPA authority servers.
This document describes the steps required to install a new AS112 This document describes the steps required to install a new AS112
node, and offers advice relating to such a node's operation. node, and offers advice relating to such a node's operation.
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 30, 2011.
Copyright Notice
Copyright (c) 2010 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 6 2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 5
3. Installation of a New Node . . . . . . . . . . . . . . . . . . 7 3. Installation of a New Node . . . . . . . . . . . . . . . . . . 6
3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 7 3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 6
3.2. Topological Location . . . . . . . . . . . . . . . . . . . 7 3.2. Topological Location . . . . . . . . . . . . . . . . . . . 6
3.3. Operating System and Host Considerations . . . . . . . . . 7 3.3. Operating System and Host Considerations . . . . . . . . . 6
3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 8 3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 7
3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 12 3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 11
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 13 4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 12
5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Future Usefulness of AS112 Nodes . . . . . . . . . . . . . . . 15 6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 22 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Many sites connected to the Internet make use of IPv4 addresses which Many sites connected to the Internet make use of IPv4 addresses which
are not globally unique. Examples are the addresses designated in are not globally unique. Examples are the addresses designated in
[RFC1918] for private use within individual sites. [RFC1918] for private use within individual sites.
Devices in such environments may occasionally originate reverse DNS Devices in such environments may occasionally originate reverse DNS
queries [RFC1034] corresponding to those private-use addresses. queries [RFC1034] corresponding to those private-use addresses.
Since the addresses concerned have only local significance, it is Since the addresses concerned have only local significance, it is
skipping to change at page 6, line 25 skipping to change at page 5, line 25
o 168.192.IN-ADDR.ARPA o 168.192.IN-ADDR.ARPA
and the following zone, corresponding to the "link local" netblock and the following zone, corresponding to the "link local" netblock
169.254.0.0/16 listed in [RFC3330]: 169.254.0.0/16 listed in [RFC3330]:
o 254.169.IN-ADDR.ARPA o 254.169.IN-ADDR.ARPA
To aid identification of AS112 anycast nodes, each node also answers To aid identification of AS112 anycast nodes, each node also answers
authoritatively for the zone HOSTNAME.AS112.NET. See Section 3.5 for authoritatively for the zone HOSTNAME.AS112.NET. See Section 3.5 for
more details on the resource records contained within that zone. the recomended contents of that zone.
It is possible that the IANA might delegate other zones corresponding It is possible that other zones corresponding to private-use
to private-use infrastructure to AS112 servers in the future. A infrastructure will be delegated to AS112 servers in the future. A
current list of zones for which AS112 servers answer authoritatively list of zones for which AS112 servers answer authoritatively is
can be found at <http://www.as112.net/>. maintained at <http://www.as112.net/>.
2.2. Nameservers 2.2. Nameservers
The zones listed in Section 2.1 are delegated to the two nameservers The zones listed in Section 2.1 are delegated to the two nameservers
BLACKHOLE-1.IANA.ORG (192.175.48.6) and BLACKHOLE-2.IANA.ORG BLACKHOLE-1.IANA.ORG (192.175.48.6) and BLACKHOLE-2.IANA.ORG
(192.175.48.42). (192.175.48.42).
Additionally, the server PRISONER.IANA.ORG (192.175.48.1) is listed Additionally, the server PRISONER.IANA.ORG (192.175.48.1) is listed
in the SOA RDATA of zones served by AS112 nameservers, and receives in MNAME field of the SOA records of zones served by AS112
mainly dynamic update queries. nameservers, and receives mainly dynamic update queries.
It should be noted that the addresses of all these nameservers are The addresses of all these nameservers are covered by the single IPv4
covered by the single prefix 192.175.48.0/24. prefix 192.175.48.0/24.
3. Installation of a New Node 3. Installation of a New Node
3.1. Useful Background Knowledge 3.1. Useful Background Knowledge
Installation of an AS112 node is relatively straightforward. Installation of an AS112 node is relatively straightforward.
However, prior knowledge of or experience in the following general However, experience in the following general areas may prove useful:
areas may prove useful:
o Inter-domain routing with BGP [RFC4271]; o Inter-domain routing with BGP [RFC4271];
o DNS authority server operations; o DNS authority server operations;
o Anycast distribution of DNS services ([ISC-TN-2003-1], [RFC4786]). o Anycast distribution of DNS services ([ISC-TN-2003-1], [RFC4786]).
3.2. Topological Location 3.2. Topological Location
AS112 nodes may be located anywhere on the Internet. For nodes which AS112 nodes may be located anywhere on the Internet. For nodes which
skipping to change at page 7, line 41 skipping to change at page 6, line 40
It is good operational practice to notify the community of users It is good operational practice to notify the community of users
which may fall within the reach of a new AS112 node before it is which may fall within the reach of a new AS112 node before it is
installed. At an Internet Exchange, local mailing lists usually installed. At an Internet Exchange, local mailing lists usually
exist to facilitate such announcements. For nodes which are intended exist to facilitate such announcements. For nodes which are intended
to be globally reachable, coordination with other AS112 operators is to be globally reachable, coordination with other AS112 operators is
highly recommended. See also Section 5. highly recommended. See also Section 5.
3.3. Operating System and Host Considerations 3.3. Operating System and Host Considerations
The use of a UNIX or UNIX-like operating system (e.g. FreeBSD, GNU The use of a UNIX or UNIX-like operating system (e.g. FreeBSD,
Linux) is recommended for the construction of AS112 nodes, primarily Linux) is recommended for the construction of AS112 nodes, primarily
due to the cumulative experience of using such platforms for this due to the cumulative experience of using such platforms for this
purpose. Examples in this document will assume use of such an purpose. Examples in this document will assume use of such an
operating system. operating system.
The chosen platform should include support for either cloned loopback The chosen platform should include support for either cloned loopback
interfaces, or the capability to bind multiple addresses to a single interfaces, or the capability to bind multiple addresses to a single
loopback interface. The addresses of the nameservers listed in loopback interface. The addresses of the nameservers listed in
Section 2.2 will be configured on these interfaces in order that the Section 2.2 will be configured on these interfaces in order that the
DNS software can respond to queries properly. DNS software can respond to queries properly.
skipping to change at page 8, line 31 skipping to change at page 7, line 29
3.4. Routing Software 3.4. Routing Software
AS112 nodes signal the availability of AS112 nameservers to the AS112 nodes signal the availability of AS112 nameservers to the
Internet using BGP [RFC4271]: each AS112 node is a BGP speaker, and Internet using BGP [RFC4271]: each AS112 node is a BGP speaker, and
announces the prefix 192.175.48.0/24 to the Internet with origin AS announces the prefix 192.175.48.0/24 to the Internet with origin AS
112 (see also Section 2.2). 112 (see also Section 2.2).
Suitable choices of free software to allow hosts to act as BGP Suitable choices of free software to allow hosts to act as BGP
speakers include, but are not limited to: speakers include, but are not limited to:
o OpenBGPD [1] o BIRD Internet Routing Daemon [1]
o The Quagga Routing Suite [2] o OpenBGPD [2]
o GNU Zebra [3] o The Quagga Routing Suite [3]
o GNU Zebra [4]
The examples in this document are based on Quagga. The examples in this document are based on Quagga.
The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides
BGP protocol support. The router id in this case is 198.32.149.123; BGP protocol support. The router id in this case is 198.32.149.123;
the AS112 node peers with external peers 198.32.149.1 and the AS112 node peers with external peers 198.32.149.1 and
198.32.149.2, which are route servers at an exchange point. Note the 198.32.149.2, which are route servers at an exchange point. Note the
local AS number 112, and the origination of the prefix local AS number 112, and the origination of the prefix
192.175.48.0/24. 192.175.48.0/24.
skipping to change at page 9, line 44 skipping to change at page 8, line 44
Although the queries received by AS112 nodes are definitively Although the queries received by AS112 nodes are definitively
misdirected, it is important that they be answered in a manner which misdirected, it is important that they be answered in a manner which
is accurate and consistent. For this reason AS112 nodes operate as is accurate and consistent. For this reason AS112 nodes operate as
fully-functional and standards-compliant DNS authority servers fully-functional and standards-compliant DNS authority servers
[RFC1034], and hence require DNS software. [RFC1034], and hence require DNS software.
Suitable choices of free DNS software for AS112 nodes include, but Suitable choices of free DNS software for AS112 nodes include, but
are not limited to: are not limited to:
o ISC BIND9 [4] o ISC BIND9 [5]
o NLnet Labs' NSD [5] o NLnet Labs' NSD [6]
Examples in this document are based on ISC BIND9. Examples in this document are based on ISC BIND9.
The following is a sample BIND9 "named.conf" file for a dedicated The following is a sample BIND9 "named.conf" file for a dedicated
AS112 server. Note that the nameserver is configured to act as an AS112 server. Note that the nameserver is configured to act as an
authority-only server (i.e. recursion is disabled). The nameserver authority-only server (i.e. recursion is disabled). The nameserver
is also configured to listen on the various AS112 anycast nameserver is also configured to listen on the various AS112 anycast nameserver
addresses, as well as its local addresses. addresses, as well as its local addresses.
// named.conf // named.conf
skipping to change at page 13, line 37 skipping to change at page 12, line 37
4.3. Statistics and Measurement 4.3. Statistics and Measurement
Use of the AS112 node should be measured in order to track long-term Use of the AS112 node should be measured in order to track long-term
trends, identify anomalous conditions and to ensure that the trends, identify anomalous conditions and to ensure that the
configuration of the AS112 node is sufficient to handle the query configuration of the AS112 node is sufficient to handle the query
load. load.
Examples of free monitoring tools which might be useful to operators Examples of free monitoring tools which might be useful to operators
of AS112 nodes include, but are not limited to: of AS112 nodes include, but are not limited to:
o bindgraph [6] o bindgraph [7]
o dnstop [7] o dnstop [8]
o DSC [8] o DSC [9]
5. Communications 5. Communications
It is good operational practice to notify the community of users It is good operational practice to notify the community of users
which may fall within the reach of a new AS112 node before it is which may fall within the reach of a new AS112 node before it is
installed. At Internet Exchanges, local mailing lists usually exist installed. At Internet Exchanges, local mailing lists usually exist
to facilitate such announcements. to facilitate such announcements.
For nodes which are intended to be globally reachable, coordination For nodes which are intended to be globally reachable, coordination
with other AS112 operators is especially recommended. with other AS112 operators is especially recommended. The mailing
list <mailto:as112-ops@lists.dns-oarc.net> is operated for this
purpose.
Operational notices relating to all AS112 nodes may be sent to Information pertinent to AS112 operations is maintained at
<mailto:112@root-servers.org>. Information pertinent to AS112 <http://www.as112.net/>.
operations is maintained at <http://www.as112.net/>.
Information about an AS112 node should also be published within the Information about an AS112 node should also be published within the
DNS, within the "HOSTNAME.AS112.NET" zone. See Section 3.5 for more DNS, within the "HOSTNAME.AS112.NET" zone. See Section 3.5 for more
details. details.
6. Future Usefulness of AS112 Nodes 6. On the Future of AS112 Nodes
It is recommended practice for the operators of recursive nameservers It is recommended practice for the operators of recursive nameservers
to answer queries for zones served by AS112 nodes locally, such that to answer queries for zones served by AS112 nodes locally, such that
queries never have an opportunity to reach AS112 servers queries never have an opportunity to reach AS112 servers
[I-D.ietf-dnsop-default-local-zones]. Operational experience with [I-D.ietf-dnsop-default-local-zones]. Operational experience with
AS112 nodes does not currently indicate an observable trend towards AS112 nodes does not currently indicate an observable trend towards
compliance with those recommendations, however. compliance with those recommendations, however.
It is expected that some DNS software vendors will include default It is expected that some DNS software vendors will include default
configuration which will implement measures such as those described configuration which will implement measures such as those described
skipping to change at page 16, line 11 skipping to change at page 15, line 11
additional zones, or to stop serving particular zones that are additional zones, or to stop serving particular zones that are
currently served. Such changes would be widely announced in currently served. Such changes would be widely announced in
operational forums, and published at <http://www.as112.net/>. operational forums, and published at <http://www.as112.net/>.
7. IANA Considerations 7. IANA Considerations
The AS112 nameservers are all named under the domain IANA.ORG (see The AS112 nameservers are all named under the domain IANA.ORG (see
Section 2.2). The IANA is the organisation responsible for the Section 2.2). The IANA is the organisation responsible for the
coordination of many technical aspects of the Internet's basic coordination of many technical aspects of the Internet's basic
infrastructure. The AS112 project nameservers provide a public infrastructure. The AS112 project nameservers provide a public
service to the Internet which is sanctioned by and operated in service to the Internet which is sanctioned by and operated in loose
coordination with the IANA. coordination with the IANA.
This document does not require any IANA actions. This document makes no request of the IANA.
8. Security Considerations 8. Security Considerations
Hosts should never normally send queries to AS112 servers; queries Hosts should never normally send queries to AS112 servers; queries
relating to private-use addresses should be answered locally within a relating to private-use addresses should be answered locally within a
site. Hosts which send queries to AS112 servers may well leak site. Hosts which send queries to AS112 servers may well leak
information relating to private infrastructure to the public network, information relating to private infrastructure to the public network,
which could represent a security risk. This risk is orthogonal to which could represent a security risk. This risk is orthogonal to
the presence or absence of authority servers for these zones in the the presence or absence of authority servers for these zones in the
public DNS infrastructure, however. public DNS infrastructure, however.
Requests which are answered by AS112 servers are usually Queries which are answered by AS112 servers are usually
unintentional; it follows that the responses from AS112 servers are unintentional; it follows that the responses from AS112 servers are
usually unexpected. Unexpected inbound traffic can trigger intrusion usually unexpected. Unexpected inbound traffic can trigger intrusion
detection systems or alerts by firewalls. Operators of AS112 servers detection systems or alerts by firewalls. Operators of AS112 servers
should be prepared to be contacted by operators of remote should be prepared to be contacted by operators of remote
infrastructure who believe their security has been violated. infrastructure who believe their security has been violated. Advice
to those who mistakenly believe that responses from AS112 nodes
constitutes an attack on their infrastructure can be found in
[draft-ietf-dnsop-as112-under-attack-help-help].
The deployment of AS112 nodes are very loosely coordinated, compared The deployment of AS112 nodes are very loosely coordinated compared
to other services distributed using anycast. The compromise of an to other services distributed using anycast. The malicious
AS112 node and subversion of the data served by the node is hence compromise of an AS112 node and subversion of the data served by the
more difficult to detect due to the lack of central management. node is hence more difficult to detect due to the lack of central
Since it is conceivable that changing the responses to queries management. Since it is conceivable that changing the responses to
received by AS112 nodes might influence the behaviour of the hosts queries received by AS112 nodes might influence the behaviour of the
sending the queries, such a compromise might be used as an attack hosts sending the queries, such a compromise might be used as an
vector against private infrastructure. attack vector against private infrastructure.
Operators of AS112 should take appropriate measures to ensure that Operators of AS112 should take appropriate measures to ensure that
AS112 nodes are appropriately protected from compromise, such as AS112 nodes are appropriately protected from compromise, such as
would normally be employed for production nameserver or network would normally be employed for production nameserver or network
infrastructure. The guidance provided for root nameservers in infrastructure. The guidance provided for root nameservers in
[RFC2870] may be instructive. [RFC2870] may be instructive.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 18, line 30 skipping to change at page 17, line 30
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, December 2006.
9.2. Informative References 9.2. Informative References
[I-D.ietf-dnsop-default-local-zones] [I-D.ietf-dnsop-default-local-zones]
Andrews, M., "Locally-served DNS Zones", Andrews, M., "Locally-served DNS Zones",
draft-ietf-dnsop-default-local-zones-08 (work in draft-ietf-dnsop-default-local-zones-13 (work in
progress), February 2009. progress), April 2010.
[ISC-TN-2003-1] [ISC-TN-2003-1]
Abley, J., "Hierarchical Anycast for Global Service Abley, J., "Hierarchical Anycast for Global Service
Distribution", Distribution",
<http://www.isc.org/pubs/tn/isc-tn-2003-1.html>. <http://www.isc.org/pubs/tn/isc-tn-2003-1.html>.
[RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
Means for Expressing Location Information in the Domain Means for Expressing Location Information in the Domain
Name System", RFC 1876, January 1996. Name System", RFC 1876, January 1996.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002. September 2002.
[draft-ietf-dnsop-as112-under-attack-help-help]
Abley, J. and W. Maton, "I'm Being Attacked by
PRISONER.IANA.ORG!", July 2010.
URIs URIs
[1] <http://www.openbgpd.org/> [1] <http://bird.network.cz/>
[2] <http://www.quagga.net/> [2] <http://www.openbgpd.org/>
[3] <http://www.zebra.org/> [3] <http://www.quagga.net/>
[4] <http://www.isc.org/products/BIND/> [4] <http://www.zebra.org/>
[5] <http://www.nlnetlabs.nl/nsd/> [5] <http://www.isc.org/software/BIND/>
[6] <http://www.linux.it/~md/software/> [6] <http://www.nlnetlabs.nl/nsd/>
[7] <http://dns.measurement-factory.com/tools/dnstop/> [7] <http://www.linux.it/~md/software/>
[8] <http://dns.measurement-factory.com/tools/dsc/> [8] <http://dns.measurement-factory.com/tools/dnstop/>
[9] <http://dns.measurement-factory.com/tools/dsc/>
Appendix A. History Appendix A. History
Widespread use of the private address blocks listed in [RFC1918] Widespread use of the private address blocks listed in [RFC1918]
followed that document's publication in 1996. followed that document's publication in 1996.
The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918] The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918]
addresses from the root nameservers was first proposed by Bill addresses from the root nameservers was first proposed by Bill
Manning and John Brown. Manning and John Brown.
skipping to change at page 22, line 17 skipping to change at page 21, line 17
This section to be removed prior to publication. This section to be removed prior to publication.
00 Initial draft, circulated as draft-jabley-as112-ops-00 and 00 Initial draft, circulated as draft-jabley-as112-ops-00 and
reviewed at the DNSOP working group meeting at IETF 66. reviewed at the DNSOP working group meeting at IETF 66.
00 Document adoped by the DNSOP working group and renamed 00 Document adoped by the DNSOP working group and renamed
accordingly. accordingly.
01 Input from reviewers of DNSOP and others, some cosmetic tweaks. 01 Input from reviewers of DNSOP and others, some cosmetic tweaks.
02 Version bump as request by working group chairs. 02 Version bump as request by DNSOP chairs. Added missing IANA
Considerations section. Updated author's addresses. Make
02 Added missing IANA Considerations section. http://www.as112.net/ URL consistent.
02 Updated author's addresses.
03 Make http://www.as112.net/ URL consistent.
03 Fix BLACKHOLE-2.IANA.ORG IP address. 03 Fix BLACKHOLE-2.IANA.ORG IP address.
04 Bump version number. Refresh references. Add reference to BIRD.
Minor wordsmithing.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
TekSavvy Solutions, Inc. ICANN
330 Richmond Street, Suite 205 4676 Admiralty Way, Suite 330
Chatham, ON N7M 1P7 Marina del Rey, CA 90292
Canada US
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: jabley@teksavvy.com Email: joe.abley@icann.org
William F. Maton Sotomayor William F. Maton Sotomayor
National Research Council of Canada National Research Council of Canada
1200 Montreal Road 1200 Montreal Road
Ottawa, ON K1A 0R6 Ottawa, ON K1A 0R6
Canada Canada
Phone: +1 613 993 0880 Phone: +1 613 993 0880
Email: wmaton@ryouko.imsb.nrc.ca Email: wmaton@ryouko.imsb.nrc.ca
 End of changes. 41 change blocks. 
133 lines changed or deleted 130 lines changed or added

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