draft-ietf-dnsop-as112-ops-04.txt   draft-ietf-dnsop-as112-ops-05.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: January 30, 2011 NRC-CNRC Expires: May 14, 2011 NRC-CNRC
July 29, 2010 November 10, 2010
AS112 Nameserver Operations AS112 Nameserver Operations
draft-ietf-dnsop-as112-ops-04 draft-ietf-dnsop-as112-ops-05
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 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 reverse DNS Devices in such environments may occasionally originate Domain Name
queries corresponding to those private-use addresses. Since the System (DNS) queries (so-called "reverse lookups") corresponding to
addresses concerned have only local significance, it is good practice those private-use addresses. Since the addresses concerned have only
for site administrators to ensure that they are answered locally. local significance, it is good practice for site administrators to
However, it is not uncommon for such queries to follow the normal ensure that such queries are answered locally. However, it is not
delegation path in the public DNS instead of being answered within uncommon for such queries to follow the normal delegation path in the
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 authority servers. the root and IN-ADDR.ARPA authoritative servers.
The AS112 project is named after the Autonomous System Number (ASN)
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 January 30, 2011.
This Internet-Draft will expire on May 14, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 5 2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 5
3. Installation of a New Node . . . . . . . . . . . . . . . . . . 6 3. Installation of a New Node . . . . . . . . . . . . . . . . . . 6
3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 6 3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 6
3.2. Topological Location . . . . . . . . . . . . . . . . . . . 6 3.2. Topological Location . . . . . . . . . . . . . . . . . . . 6
3.3. Operating System and Host Considerations . . . . . . . . . 6 3.3. Operating System and Host Considerations . . . . . . . . . 6
3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 7 3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 7
3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 11 3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 12
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 12 4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 13
5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 14
6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 14 6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 21 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 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 reverse DNS Devices in such environments may occasionally originate Domain Name
queries [RFC1034] corresponding to those private-use addresses. System (DNS) [RFC1034] queries (so-called "reverse lookups")
Since the addresses concerned have only local significance, it is corresponding to those private-use addresses. Since the addresses
good practice for site administrators to ensure that they are concerned have only local significance, it is good practice for site
answered locally [I-D.ietf-dnsop-default-local-zones]. However, it administrators to ensure that such queries are answered locally
is not uncommon for such queries to follow the normal delegation path [I-D.ietf-dnsop-default-local-zones]. However, it is not uncommon
in the public DNS instead of being answered within the site. for such queries to follow the normal delegation path in the 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 authority 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)
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 [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
the recomended contents of that zone. the recommended contents of that zone.
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
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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 authority server operations; o DNS authoritative 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
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.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
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.
Wrapper scripts or other arrangements should be employed to ensure Wrapper scripts or other arrangements should be employed to ensure
that the anycast service prefix for AS112 is not advertised while that the anycast service prefix for AS112 is not advertised while
either the anycast addresses are unconfigured, or while the DNS either the anycast addresses are not configured, or while the DNS
software is not running. software is not running.
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
skipping to change at page 7, line 40 skipping to change at page 7, line 40
o OpenBGPD [2] o OpenBGPD [2]
o The Quagga Routing Suite [3] o The Quagga Routing Suite [3]
o GNU Zebra [4] 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 example is 203.0.113.1;
the AS112 node peers with external peers 198.32.149.1 and the AS112 node peers with external peers 192.0.2.1 and 192.0.2.2.
198.32.149.2, which are route servers at an exchange point. Note the 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.
! bgpd.conf ! bgpd.conf
! !
hostname as112-bgpd hostname as112-bgpd
password <something> password <something>
enable password <supersomething> enable password <supersomething>
! !
! Note that all AS112 nodes use the local Autonomous System
! Number 112, and originate the IPv4 prefix 192.175.48.0/24.
! All other addresses shown below are illustrative, and
! actual numbers will depend on local circumstances.
!
router bgp 112 router bgp 112
bgp router-id 198.32.149.123 bgp router-id 203.0.113.1
network 192.175.48.0 network 192.175.48.0
neighbor 198.32.149.1 remote-as 2884 neighbor 192.0.2.1 remote-as 64496
neighbor 198.32.149.1 next-hop-self neighbor 192.0.2.1 next-hop-self
neighbor 198.32.149.2 remote-as 2884 neighbor 192.0.2.2 remote-as 64497
neighbor 198.32.149.2 next-hop-self neighbor 192.0.2.2 next-hop-self
The "zebra.conf" file is required to provide integration between The "zebra.conf" file is required to provide integration between
protocol daemons (bgpd, in this case) and the kernel. protocol daemons (bgpd, in this case) and the kernel.
! zebra.conf ! zebra.conf
! !
hostname as112 hostname as112
password <something> password <something>
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 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 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 [5]
o NLnet Labs' NSD [6] 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 authoritative-only server (i.e. recursion is disabled). The
is also configured to listen on the various AS112 anycast nameserver nameserver is also configured to listen on the various AS112 anycast
addresses, as well as its local addresses. nameserver addresses, as well as its local addresses.
// named.conf // named.conf
// global options // global options
options { options {
listen-on { listen-on {
127.0.0.1; // localhost 127.0.0.1; // localhost
198.32.149.252; // local address (globally-unique, unicast)
// the following address is node-dependent, and should be set to
// something appropriate for the new AS112 node
203.0.113.1; // local address (globally-unique, unicast)
// the following addresses correspond to AS112 addresses, and
// 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; // authority-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
skipping to change at page 10, line 19 skipping to change at page 10, line 31
zone "254.169.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"; };
// 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" { type master;
file "db.hostname.as112.net"; }; 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. populate all the zones listed in Section 2.1. Note that the RNAME
specified in the SOA record corresponds to
hostmaster@root-servers.org, a suitable e-mail address for receiving
technical queries about this zone.
; 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
skipping to change at page 10, line 50 skipping to change at page 11, line 34
; 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 which 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 LOC record [RFC1876] included in the zone apex provides The optional LOC record [RFC1876] included in the zone apex provides
information about the geospacial location of the node. information about the geospatial location of the node.
; db.hostname.as112.net ; db.hostname.as112.net
; ;
$TTL 1W $TTL 1W
@ SOA flo.gigafed.net. dns.ryouko.imsb.nrc.ca. ( @ SOA server.example.net. admin.example.net. (
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-2.iana.org. NS blackhole-2.iana.org.
NS blackhole-1.iana.org. NS blackhole-1.iana.org.
; ;
TXT "Federal GigaPOP" "Ottawa, Canada" TXT "Name of Facility or similar" "City, Country"
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 which 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
"Federal GigaPOP" "Ottawa, Canada" "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
response received at all, there might be host or nameserver problem. response received at all, there might be host or nameserver problem.
Judicious use of tools such as traceroute, and consultation of BGP Judicious use of tools such as traceroute, and consultation of BGP
looking glasses might be useful in troubleshooting. looking glasses might be useful in troubleshooting.
Note that an appropriate set of tests for a new server will include Note that an appropriate set of tests for a new server will include
skipping to change at page 15, line 8 skipping to change at page 16, line 8
netblock for use as an anycast service prefix. netblock for use as an anycast service prefix.
There may be a requirement in the future for AS112 nodes to serve There may be a requirement in the future for AS112 nodes to serve
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). However, the anycast infrastructure itself is operated
coordination of many technical aspects of the Internet's basic by a loosely-coordinated, diverse mix of organisations across the
infrastructure. The AS112 project nameservers provide a public Internet, and is not an IANA function.
service to the Internet which is sanctioned by and operated in loose
coordination with the IANA. The autonomous system number 112 and the IPv4 prefix 192.175.48.0/24
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 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 authoritative servers for these zones in
public DNS infrastructure, however. the public DNS infrastructure, however.
Queries 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. 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]. [draft-ietf-dnsop-as112-under-attack-help-help].
The deployment of AS112 nodes are very loosely coordinated compared The deployment of AS112 nodes is very loosely coordinated compared to
to other services distributed using anycast. The malicious other services distributed using anycast. The malicious compromise
compromise of an AS112 node and subversion of the data served by the of an AS112 node and subversion of the data served by the node is
node is hence more difficult to detect due to the lack of central hence more difficult to detect due to the lack of central management.
management. Since it is conceivable that changing the responses to Since it is conceivable that changing the responses to queries
queries received by AS112 nodes might influence the behaviour of the received by AS112 nodes might influence the behaviour of the hosts
hosts sending the queries, such a compromise might be used as an sending the queries, such a compromise might be used as an attack
attack vector against private infrastructure. 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.
The zones hosted by AS112 servers are not signed with DNSSEC
[RFC4033]. Given the distributed and loosely-coordinated structure
of the AS112 service, the zones concerned could only be signed if the
private key material used was effectively public, obviating any
security benefit resulting from the use of those keys.
9. References 9. References
9.1. Normative References 9.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,
June 2000. June 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
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 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",
skipping to change at page 20, line 9 skipping to change at page 21, line 9
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 authority servers
in subsequent years (e.g. various root servers). in subsequent years (e.g. various root servers).
Appendix B. Acknowledgements Appendix B. Acknowledgements
The authors wish to acknowledge the assistance of Bill Manning, John The authors wish to acknowledge the assistance of Bill Manning, John
Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank
Habicht, Chris Thompson and Peter Losher in the preparation of this Habicht, Chris Thompson, Peter Losher and Peter Koch in the
document. preparation of this document.
Appendix C. Change History Appendix C. 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.
skipping to change at page 22, line 5 skipping to change at page 22, line 26
02 Version bump as request by DNSOP chairs. Added missing IANA 02 Version bump as request by DNSOP chairs. Added missing IANA
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.
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. 35 change blocks. 
80 lines changed or deleted 127 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/