draft-ietf-dnsop-as112-ops-05.txt   draft-ietf-dnsop-as112-ops-06.txt 
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Informational W. Maton Intended status: Informational W. Maton
Expires: May 14, 2011 NRC-CNRC Expires: May 16, 2011 NRC-CNRC
November 10, 2010 November 12, 2010
AS112 Nameserver Operations AS112 Nameserver Operations
draft-ietf-dnsop-as112-ops-05 draft-ietf-dnsop-as112-ops-06
Abstract Abstract
Many sites connected to the Internet make use of IPv4 addresses that Many sites connected to the Internet make use of IPv4 addresses that
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. RFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain Name Devices in such environments may occasionally originate Domain Name
System (DNS) queries (so-called "reverse lookups") corresponding to System (DNS) queries (so-called "reverse lookups") corresponding to
those private-use addresses. Since the addresses concerned have only those private-use addresses. Since the addresses concerned have only
local significance, it is good practice for site administrators to local significance, it is good practice for site administrators to
ensure that such queries are answered locally. However, it is not ensure that such queries are answered locally. However, it is not
uncommon for such queries to follow the normal delegation path in the uncommon for such queries to follow the normal delegation path in the
public DNS instead of being answered within the site. public DNS instead of being answered within the site.
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 authoritative servers. the root and IN-ADDR.ARPA authoritative servers. The AS112 project
is named after the Autonomous System Number (ASN) that was assigned
The AS112 project is named after the Autonomous System Number (ASN) to it.
that was assigned to it.
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 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2011. This Internet-Draft will expire on May 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 26 skipping to change at page 3, line 26
3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 12 3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 12
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 13 4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 13
5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 14
6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 15 6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 22 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Many sites connected to the Internet make use of IPv4 addresses that Many sites connected to the Internet make use of IPv4 addresses that
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 Domain Name Devices in such environments may occasionally originate Domain Name
System (DNS) [RFC1034] queries (so-called "reverse lookups") System (DNS) [RFC1034] queries (so-called "reverse lookups")
skipping to change at page 4, line 27 skipping to change at page 4, line 27
for such queries to follow the normal delegation path in the public for such queries to follow the normal delegation path in the public
DNS instead of being answered within the site. DNS instead of being answered within the site.
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 authoritative servers. the root and IN-ADDR.ARPA authoritative servers.
The AS112 project encompasses a loosely-coordinated collection of The AS112 project encompasses a loosely coordinated collection of
independently-operated nameservers. Each nameserver functions as a independently operated nameservers. Each nameserver functions as a
single node in an AS112 anycast cloud [RFC4786], and is configured to single node in an AS112 anycast cloud [RFC4786], and is configured to
answer authoritatively for a particular set of nominated zones. answer authoritatively for a particular set of nominated zones.
The AS112 project is named after the Autonomous System Number (ASN) The AS112 project is named after the Autonomous System Number (ASN)
that was assigned to it. that was assigned to it.
2. AS112 DNS Service 2. AS112 DNS Service
2.1. Zones 2.1. Zones
AS112 nameservers answer authoritatively for the following zones, AS112 nameservers answer authoritatively for the following zones,
corresponding to [RFC1918] private-use netblocks: corresponding to [RFC1918] private-use netblocks:
o 10.IN-ADDR.ARPA o 10.IN-ADDR.ARPA
o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA
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 [RFC5735]:
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.
the recommended contents of that zone.
See Section 3.5 for the recommended contents of all these zones.
It is possible that other zones corresponding to private-use It is possible that other zones corresponding to private-use
infrastructure will be delegated to AS112 servers in the future. A infrastructure will be delegated to AS112 servers in the future. A
list of zones for which AS112 servers answer authoritatively is list of zones for which AS112 servers answer authoritatively is
maintained 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 MNAME field of the SOA records of zones served by AS112 in the MNAME field of the SOA records of the IN-ADDR.ARPA zones
nameservers, and receives mainly dynamic update queries. served by AS112 nameservers. PRISONER.IANA.ORG receives mainly
dynamic update queries.
The addresses of all these nameservers are covered by the single IPv4 The addresses of all these nameservers are covered by the single IPv4
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, experience in the following general areas may prove useful: However, experience in the following general areas may prove useful:
o Inter-domain routing with BGP [RFC4271]; o inter-domain routing with BGP [RFC4271];
o DNS authoritative server operations; o DNS authoritative server operations;
o Anycast distribution of DNS services ([ISC-TN-2003-1], [RFC4786]). o anycast [RFC4786] distribution of DNS services.
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 that
are intended to provide a public service to the Internet community are intended to provide a public service to the Internet community
(as opposed to private use), it may well be advantageous to choose a (as opposed to private use), it may well be advantageous to choose a
location that is easily (and cheaply) reachable by multiple location that is easily (and cheaply) reachable by multiple
providers, such as an Internet exchange point. providers, such as an Internet exchange point.
AS112 nodes may advertise their service prefix to BGP peers for local AS112 nodes may advertise their service prefix to BGP peers for local
use (analogous to a conventional peering relationship between two use (analogous to a conventional peering relationship between two
providers) or for global use (analogous to a customer relationship providers) or for global use (analogous to a customer relationship
with one or more providers). with one or more providers).
It is good operational practice to notify the community of users It is good operational practice to notify the community of users that
which may fall within the reach of a new AS112 node before it is may fall within the reach of a new AS112 node before it is installed.
installed. At an Internet Exchange, local mailing lists usually At an Internet Exchange, local mailing lists usually exist to
exist to facilitate such announcements. For nodes which are intended facilitate such announcements. For nodes that are intended to be
to be globally reachable, coordination with other AS112 operators is globally reachable, coordination with other AS112 operators is highly
highly recommended. See also Section 5. 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, The use of a UNIX or UNIX-like operating system (e.g. FreeBSD [1],
Linux) is recommended for the construction of AS112 nodes, primarily OpenBSD [2], Linux [3]) is recommended for the construction of AS112
due to the cumulative experience of using such platforms for this nodes, primarily due to the cumulative experience of using such
purpose. Examples in this document will assume use of such an platforms for this purpose. Examples in this document will assume
operating system. use of such an 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.
A host which is configured to act as an AS112 anycast node should be A host that is configured to act as an AS112 anycast node should be
dedicated to that purpose, and should not be used to simultaneously dedicated to that purpose, and should not be used to simultaneously
provide other services. provide other services.
System startup scripts should be arranged such that the various System startup scripts should be arranged such that the various
AS112-related components start automatically following a system AS112-related components start automatically following a system
reboot. The order in which interfaces are configured and software reboot. The order in which interfaces are configured and software
components started should be arranged such that routing software components started should be arranged such that routing software
startup follows DNS software startup, and DNS software startup startup follows DNS software startup, and DNS software startup
follows loopback interface configuration. follows loopback interface configuration.
skipping to change at page 7, line 29 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 BIRD Internet Routing Daemon [1] o BIRD Internet Routing Daemon [4]
o OpenBGPD [2] o OpenBGPD [5]
o The Quagga Routing Suite [3] o The Quagga Routing Suite [6]
o GNU Zebra [4] o GNU Zebra [7]
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 example is 203.0.113.1; BGP protocol support. The router id in this example is 203.0.113.1;
the AS112 node peers with external peers 192.0.2.1 and 192.0.2.2. the AS112 node peers with external peers 192.0.2.1 and 192.0.2.2.
Note the local AS number 112, and the origination of the prefix Note the local AS number 112, and the origination of the prefix
192.175.48.0/24. 192.175.48.0/24.
! bgpd.conf ! bgpd.conf
skipping to change at page 8, line 41 skipping to change at page 8, line 41
enable password <supersomething> enable password <supersomething>
! !
interface lo interface lo
! !
interface eth0 interface eth0
! !
3.5. DNS Software 3.5. DNS Software
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 that
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 authoritative servers fully-functional and standards-compliant DNS authoritative 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 [5] o ISC BIND9 [8]
o NLnet Labs' NSD [6] o NLnet Labs' NSD [9]
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
authoritative-only server (i.e. recursion is disabled). The authoritative-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. nameserver addresses, as well as its local addresses.
// named.conf // named.conf
skipping to change at page 9, line 33 skipping to change at page 9, line 33
203.0.113.1; // local address (globally-unique, unicast) 203.0.113.1; // local address (globally-unique, unicast)
// the following addresses correspond to AS112 addresses, and // the following addresses correspond to AS112 addresses, and
// are the same for all AS112 nodes // are the same for all AS112 nodes
192.175.48.1; // prisoner.iana.org (anycast) 192.175.48.1; // prisoner.iana.org (anycast)
192.175.48.6; // blackhole-1.iana.org (anycast) 192.175.48.6; // blackhole-1.iana.org (anycast)
192.175.48.42; // blackhole-2.iana.org (anycast) 192.175.48.42; // blackhole-2.iana.org (anycast)
}; };
directory "/var/named"; directory "/var/named";
recursion no; // authority-only server recursion no; // authoritative-only server
query-source address *; query-source address *;
}; };
// log queries, so that when people call us about unexpected // log queries, so that when people call us about unexpected
// answers to queries they didn't realise they had sent, we // answers to queries they didn't realise they had sent, we
// have something to talk about. Note that activating this // have something to talk about. Note that activating this
// has the potential to create high CPU and take enormous // has the potential to create high CPU load and consume
// amounts of disk space. // enormous amounts of disk space.
logging { logging {
channel "querylog" { channel "querylog" {
file "/var/log/query.log" versions 2 size 500m; file "/var/log/query.log" versions 2 size 500m;
print-time yes; print-time yes;
}; };
category queries { querylog; }; category queries { querylog; };
}; };
// RFC 1918 // RFC 1918
skipping to change at page 10, line 21 skipping to change at page 10, line 21
zone "22.172.in-addr.arpa" { type master; file "db.empty"; }; zone "22.172.in-addr.arpa" { type master; file "db.empty"; };
zone "23.172.in-addr.arpa" { type master; file "db.empty"; }; zone "23.172.in-addr.arpa" { type master; file "db.empty"; };
zone "24.172.in-addr.arpa" { type master; file "db.empty"; }; zone "24.172.in-addr.arpa" { type master; file "db.empty"; };
zone "25.172.in-addr.arpa" { type master; file "db.empty"; }; zone "25.172.in-addr.arpa" { type master; file "db.empty"; };
zone "26.172.in-addr.arpa" { type master; file "db.empty"; }; zone "26.172.in-addr.arpa" { type master; file "db.empty"; };
zone "27.172.in-addr.arpa" { type master; file "db.empty"; }; zone "27.172.in-addr.arpa" { type master; file "db.empty"; };
zone "28.172.in-addr.arpa" { type master; file "db.empty"; }; zone "28.172.in-addr.arpa" { type master; file "db.empty"; };
zone "29.172.in-addr.arpa" { type master; file "db.empty"; }; zone "29.172.in-addr.arpa" { type master; file "db.empty"; };
zone "30.172.in-addr.arpa" { type master; file "db.empty"; }; zone "30.172.in-addr.arpa" { type master; file "db.empty"; };
zone "31.172.in-addr.arpa" { type master; file "db.empty"; }; zone "31.172.in-addr.arpa" { type master; file "db.empty"; };
zone "254.169.in-addr.arpa" { type master; file "db.empty"; };
zone "168.192.in-addr.arpa" { type master; file "db.empty"; }; zone "168.192.in-addr.arpa" { type master; file "db.empty"; };
// RFC 5735
zone "254.169.in-addr.arpa" { type master; file "db.empty"; };
// also answer authoritatively for the HOSTNAME.AS112.NET zone, // also answer authoritatively for the HOSTNAME.AS112.NET zone,
// which contains data of operational relevance // which contains data of operational relevance
zone "hostname.as112.net" { type master; zone "hostname.as112.net" {
file "db.hostname.as112.net"; }; type master;
file "db.hostname.as112.net";
};
The "db.empty" file follows, below. This is the source data used to The "db.empty" file follows, below. This is the source data used to
populate all the zones listed in Section 2.1. Note that the RNAME populate all the IN-ADDR.ARPA zones listed in Section 2.1. Note that
specified in the SOA record corresponds to the RNAME specified in the SOA record corresponds to
hostmaster@root-servers.org, a suitable e-mail address for receiving hostmaster@root-servers.org, a suitable e-mail address for receiving
technical queries about this zone. technical queries about these zones.
; db.empty ; db.empty
; ;
; Empty zone for AS112 server. ; Empty zone for AS112 server.
; ;
$TTL 1W $TTL 1W
@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. ( @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (
1 ; serial number 1 ; serial number
1W ; refresh 1W ; refresh
1M ; retry 1M ; retry
1W ; expire 1W ; expire
1W ) ; negative caching TTL 1W ) ; negative caching TTL
; ;
NS blackhole-1.iana.org. NS blackhole-1.iana.org.
NS blackhole-2.iana.org. NS blackhole-2.iana.org.
; ;
; There should be no other resource records included in this zone. ; There should be no other resource records included in this zone.
; ;
; Records which relate to RFC1918-numbered resources within the ; Records that relate to RFC 1918-numbered resources within the
; site hosting this AS112 node should not be hosted on this ; site hosting this AS112 node should not be hosted on this
; nameserver. ; nameserver.
The "db.hostname.as112.net" file follows, below. This zone contains The "db.hostname.as112.net" file follows, below. This zone contains
various resource records which provide operational data to users for various resource records that provide operational data to users for
troubleshooting or measurement purposes, and should be edited to suit troubleshooting or measurement purposes, and should be edited to suit
local circumstances. Note that the response to the query local circumstances. Note that the response to the query
"HOSTNAME.AS112.NET IN TXT" should fit within a 512 octet DNS/UDP "HOSTNAME.AS112.NET IN TXT" should fit within a 512 octet DNS/UDP
datagram: i.e. it should be available over UDP transport without datagram: i.e. it should be available over UDP transport without
requiring EDNS0 support. requiring EDNS0 support.
The optional LOC record [RFC1876] included in the zone apex provides The optional LOC record [RFC1876] included in the zone apex provides
information about the geospatial location of the node. information about the geospatial location of the node.
; db.hostname.as112.net ; db.hostname.as112.net
skipping to change at page 12, line 12 skipping to change at page 12, line 12
TXT "See http://www.as112.net/ for more information." TXT "See http://www.as112.net/ for more information."
; ;
LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m
3.6. Testing a Newly-Installed Node 3.6. Testing a Newly-Installed Node
The BIND9 tool "dig" can be used to retrieve the TXT resource records The BIND9 tool "dig" can be used to retrieve the TXT resource records
associated with the domain "HOSTNAME.AS112.NET", directed at one of associated with the domain "HOSTNAME.AS112.NET", directed at one of
the AS112 anycast nameserver addresses. Continuing the example from the AS112 anycast nameserver addresses. Continuing the example from
above, the response received should indicate the identity of the above, the response received should indicate the identity of the
AS112 node which responded to the query. See Section 3.5 for more AS112 node that responded to the query. See Section 3.5 for more
details about the resource records associated with details about the resource records associated with
"HOSTNAME.AS112.NET". "HOSTNAME.AS112.NET".
% dig @prisoner.iana.org hostname.as112.net txt +short +norec % dig @prisoner.iana.org hostname.as112.net txt +short +norec
"Name of Facility or similar" "City, Country" "Name of Facility or similar" "City, Country"
"See http://www.as112.net/ for more information." "See http://www.as112.net/ for more information."
% %
If the response received indicates a different node is being used, If the response received indicates a different node is being used,
then there is probably a routing problem to solve. If there is no then there is probably a routing problem to solve. If there is no
skipping to change at page 13, line 11 skipping to change at page 13, line 11
queries sent from many different places within the expected service queries sent from many different places within the expected service
area of the node, using both UDP and TCP transport, and exercising area of the node, using both UDP and TCP transport, and exercising
all three AS112 anycast nameserver addresses. all three AS112 anycast nameserver addresses.
4. Operations 4. Operations
4.1. Monitoring 4.1. Monitoring
AS112 nodes should be monitored to ensure they are functioning AS112 nodes should be monitored to ensure they are functioning
correctly, just as with any other production service. An AS112 node correctly, just as with any other production service. An AS112 node
which stops answering queries correctly can cause failures and that stops answering queries correctly can cause failures and
timeouts in unexpected places, and can lead to failures in dependent timeouts in unexpected places and can lead to failures in dependent
systems which can be difficult to troubleshoot. systems that can be difficult to troubleshoot.
4.2. Downtime 4.2. Downtime
An AS112 node which needs to go off-line (e.g. for planned An AS112 node that needs to go off-line (e.g. for planned maintenance
maintenance, or as part of the diagnosis of some problem) should stop or as part of the diagnosis of some problem) should stop advertising
advertising the AS112 service prefix to its BGP peers. This can be the AS112 service prefix to its BGP peers. This can be done by
done by shutting down the routing software on the node altogether, or shutting down the routing software on the node altogether or by
by causing the routing system to withdraw the route. causing the routing system to withdraw the route.
Withdrawing the service prefix is important in order to avoid Withdrawing the service prefix is important in order to avoid
blackholing query traffic in the event that the DNS software on the blackholing query traffic in the event that the DNS software on the
node is not functioning normally. node is not functioning normally.
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 that 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 [7] o bindgraph [10]
o dnstop [8] o dnstop [11]
o DSC [9] o DSC [12]
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 that
which may fall within the reach of a new AS112 node before it is may fall within the reach of a new AS112 node before it is installed.
installed. At Internet Exchanges, local mailing lists usually exist At Internet Exchanges, local mailing lists usually exist to
to facilitate such announcements. facilitate such announcements.
For nodes which are intended to be globally reachable, coordination For nodes that are intended to be globally reachable, coordination
with other AS112 operators is especially recommended. The mailing with other AS112 operators is especially recommended. The mailing
list <mailto:as112-ops@lists.dns-oarc.net> is operated for this list <mailto:as112-ops@lists.dns-oarc.net> is operated for this
purpose. purpose.
Information pertinent to AS112 operations is maintained at Information pertinent to AS112 operations is maintained at
<http://www.as112.net/>. <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.
skipping to change at page 15, line 15 skipping to change at page 15, line 15
6. On the Future 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 that will implement measures such as those described in
in [I-D.ietf-dnsop-default-local-zones]. If such software is widely [I-D.ietf-dnsop-default-local-zones]. If such software is widely
deployed, it is reasonable to assume that the query load received by deployed, it is reasonable to assume that the query load received by
AS112 nodes will decrease; however, it is safe to assume that the AS112 nodes will decrease; however, it is safe to assume that the
query load will not decrease to zero, and consequently that AS112 query load will not decrease to zero, and consequently that AS112
nodes will continue to provide a useful service for the foreseeable nodes will continue to provide a useful service for the foreseeable
future. future.
There may be a requirement in the future for AS112 nodes to answer There may be a requirement in the future for AS112 nodes to answer
for their current set of zones over IPv6 transport. Such a for their current set of zones over IPv6 transport. Such a
requirement would necessitate the assignment of a corresponding IPv6 requirement would necessitate the assignment of a corresponding IPv6
netblock for use as an anycast service prefix. netblock for use as an anycast service prefix.
skipping to change at page 17, line 9 skipping to change at page 17, line 9
The autonomous system number 112 and the IPv4 prefix 192.175.48.0/24 The autonomous system number 112 and the IPv4 prefix 192.175.48.0/24
were assigned by ARIN. were assigned by ARIN.
This document makes no request of the IANA. 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 that 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 and this could present a security risk. This risk is orthogonal to
the presence or absence of authoritative servers for these zones in the presence or absence of authoritative servers for these zones in
the public DNS infrastructure, however. the public DNS infrastructure, however.
Queries which are answered by AS112 servers are usually Queries that are answered by AS112 servers are usually unintentional;
unintentional; it follows that the responses from AS112 servers are it follows that the responses from AS112 servers are usually
usually unexpected. Unexpected inbound traffic can trigger intrusion 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. Advice infrastructure who believe their security has been violated. Advice
to those who mistakenly believe that responses from AS112 nodes to those who mistakenly believe that responses from AS112 nodes
constitutes an attack on their infrastructure can be found in constitutes an attack on their infrastructure can be found in
[draft-ietf-dnsop-as112-under-attack-help-help]. [I-D.ietf-dnsop-as112-under-attack-help-help].
The deployment of AS112 nodes is very loosely coordinated compared to The deployment of AS112 nodes is very loosely coordinated compared to
other services distributed using anycast. The malicious compromise other services distributed using anycast. The malicious compromise
of an AS112 node and subversion of the data served by the node is of an AS112 node and subversion of the data served by the node is
hence more difficult to detect due to the lack of central management. hence more difficult to detect due to the lack of central management.
Since it is conceivable that changing the responses to queries Since it is conceivable that changing the responses to queries
received by AS112 nodes might influence the behaviour of the hosts received by AS112 nodes might influence the behaviour of the hosts
sending the queries, such a compromise might be used as an attack sending the queries, such a compromise might be used as an attack
vector against private infrastructure. vector against private infrastructure.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
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.
The zones hosted by AS112 servers are not signed with DNSSEC The zones hosted by AS112 servers are not signed with DNSSEC
[RFC4033]. Given the distributed and loosely-coordinated structure [RFC4033]. Given the distributed and loosely-coordinated structure
of the AS112 service, the zones concerned could only be signed if the of the AS112 service, the zones concerned could only be signed if the
private key material used was effectively public, obviating any private key material used was effectively public, obviating any
security benefit resulting from the use of those keys. security benefit resulting from the use of those keys.
9. References 9. Acknowledgements
9.1. Normative References The authors wish to acknowledge the assistance of Bill Manning, John
Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank
Habicht, Chris Thompson, Peter Losher, Peter Koch and Alfred Hoenes
in the preparation of this document.
10. References
10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
Name Server Operational Requirements", BCP 40, RFC 2870, Name Server Operational Requirements", BCP 40, RFC 2870,
skipping to change at page 18, line 30 skipping to change at page 19, line 30
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[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 10.2. Informative References
[I-D.ietf-dnsop-as112-under-attack-help-help]
Abley, J. and W. Maton, "I'm Being Attacked by
PRISONER.IANA.ORG!",
draft-ietf-dnsop-as112-under-attack-help-help-04 (work in
progress), July 2010.
[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-13 (work in draft-ietf-dnsop-default-local-zones-14 (work in
progress), April 2010. progress), September 2010.
[ISC-TN-2003-1]
Abley, J., "Hierarchical Anycast for Global Service
Distribution",
<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, [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
September 2002. BCP 153, RFC 5735, January 2010.
[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://bird.network.cz/> [1] <http://www.freebsd.org/>
[2] <http://www.openbgpd.org/> [2] <http://www.openbsd.org/>
[3] <http://www.quagga.net/> [3] <http://www.linuxfoundation.org/>
[4] <http://www.zebra.org/> [4] <http://bird.network.cz/>
[5] <http://www.isc.org/software/BIND/> [5] <http://www.openbgpd.org/>
[6] <http://www.nlnetlabs.nl/nsd/> [6] <http://www.quagga.net/>
[7] <http://www.linux.it/~md/software/> [7] <http://www.zebra.org/>
[8] <http://dns.measurement-factory.com/tools/dnstop/> [8] <http://www.isc.org/software/BIND/>
[9] <http://dns.measurement-factory.com/tools/dsc/> [9] <http://www.nlnetlabs.nl/nsd/>
[10] <http://www.linux.it/~md/software/>
[11] <http://dns.measurement-factory.com/tools/dnstop/>
[12] <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.
The use of anycast for distributing authority service for [RFC1918] The use of anycast for distributing authoritative DNS service for
IN-ADDR.ARPA zones was subsequently proposed at a private meeting of [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private
root server operators. meeting of root server operators.
ARIN provided an IPv4 prefix for the anycast service, and also the ARIN provided an IPv4 prefix for the anycast service, and also the
autonomous system number 112 for use in originating that prefix. autonomous system number 112 for use in originating that prefix.
This assignment gave the project its name. This assignment gave the project its name.
In 2002, the first AS112 anycast nodes were deployed. In 2002, the first AS112 anycast nodes were deployed.
The use of anycast nameservers in the AS112 project contributed to The use of anycast nameservers in the AS112 project contributed to
the operational experience of anycast DNS services, and can be seen the operational experience of anycast DNS services, and can be seen
as a precursor to the anycast distribution of other authority servers as a precursor to the anycast distribution of other authoritative DNS
in subsequent years (e.g. various root servers). servers in subsequent years (e.g. various root servers).
Appendix B. Acknowledgements
The authors wish to acknowledge the assistance of Bill Manning, John
Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank
Habicht, Chris Thompson, Peter Losher and Peter Koch in the
preparation of this document.
Appendix C. Change History Appendix B. Change History
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.
skipping to change at page 23, line 5 skipping to change at page 22, line 28
Considerations section. Updated author's addresses. Make Considerations section. Updated author's addresses. Make
http://www.as112.net/ URL consistent. 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. 04 Bump version number. Refresh references. Add reference to BIRD.
Minor wordsmithing. Minor wordsmithing.
05 Updated following review from Peter Koch. 05 Updated following review from Peter Koch.
06 Updated following review from Alfred Hoenes.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
ICANN ICANN
4676 Admiralty Way, Suite 330 4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292 Marina del Rey, CA 90292
US US
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: joe.abley@icann.org Email: joe.abley@icann.org
 End of changes. 65 change blocks. 
120 lines changed or deleted 131 lines changed or added

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