doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc6304.txt b/doc/rfc/rfc6304.txt
new file mode 100644
index 0000000..a286e66
--- /dev/null
+++ b/doc/rfc/rfc6304.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Abley
+Request for Comments: 6304                                         ICANN
+Category: Informational                                         W. Maton
+ISSN: 2070-1721                                                 NRC-CNRC
+                                                               July 2011
+
+
+                      AS112 Nameserver Operations
+
+Abstract
+
+   Many sites connected to the Internet make use of IPv4 addresses that
+   are not globally unique.  Examples are the addresses designated in
+   RFC 1918 for private use within individual sites.
+
+   Devices in such environments may occasionally originate Domain Name
+   System (DNS) queries (so-called "reverse lookups") corresponding to
+   those private-use addresses.  Since the addresses concerned have only
+   local significance, it is good practice for site administrators to
+   ensure that such queries are answered locally.  However, it is not
+   uncommon 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
+   such queries.  In addition, due to the wide deployment of private-use
+   addresses and the continuing growth of the Internet, the volume of
+   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
+   the 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
+   node and offers advice relating to such a node's operation.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+
+
+
+
+
+Abley & Maton                 Informational                     [Page 1]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6304.
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                     [Page 2]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  AS112 DNS Service  . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Zones  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Nameservers  . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Installation of a New Node . . . . . . . . . . . . . . . . . .  5
+     3.1.  Useful Background Knowledge  . . . . . . . . . . . . . . .  5
+     3.2.  Topological Location . . . . . . . . . . . . . . . . . . .  5
+     3.3.  Operating System and Host Considerations . . . . . . . . .  5
+     3.4.  Routing Software . . . . . . . . . . . . . . . . . . . . .  6
+     3.5.  DNS Software . . . . . . . . . . . . . . . . . . . . . . .  8
+     3.6.  Testing a Newly Installed Node . . . . . . . . . . . . . . 11
+   4.  Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     4.1.  Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 12
+     4.2.  Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     4.3.  Statistics and Measurement . . . . . . . . . . . . . . . . 12
+   5.  Communications . . . . . . . . . . . . . . . . . . . . . . . . 12
+   6.  On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 13
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
+   Appendix A.  History . . . . . . . . . . . . . . . . . . . . . . . 17
+
+1.  Introduction
+
+   Many sites connected to the Internet make use of IPv4 addresses that
+   are not globally unique.  Examples are the addresses designated in
+   [RFC1918] for private use within individual sites.
+
+   Devices in such environments may occasionally originate Domain Name
+   System (DNS) [RFC1034] queries (so-called "reverse lookups")
+   corresponding to those private-use addresses.  Since the addresses
+   concerned have only local significance, it is good practice for site
+   administrators to ensure that such queries are answered locally
+   [RFC6303].  However, it is not uncommon 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
+   such queries.  In addition, due to the wide deployment of private-use
+   addresses and the continuing growth of the Internet, the volume of
+   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
+   the IN-ADDR.ARPA authoritative servers [RFC5855].
+
+
+
+Abley & Maton                 Informational                     [Page 3]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   The AS112 project encompasses a loosely coordinated collection of
+   independently operated nameservers.  Each nameserver functions as a
+   single node in an AS112 anycast cloud [RFC4786] and is configured to
+   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.1.  Zones
+
+   AS112 nameservers answer authoritatively for the following zones,
+   corresponding to [RFC1918] private-use netblocks:
+
+   o  10.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
+
+   and the following zone, corresponding to the "link local" netblock
+   169.254.0.0/16 listed in [RFC5735]:
+
+   o  254.169.IN-ADDR.ARPA
+
+   To aid identification of AS112 anycast nodes, each node also answers
+   authoritatively for the zone HOSTNAME.AS112.NET.
+
+   See Section 3.5 for the recommended contents of all these zones.
+
+   It is possible that other zones corresponding to private-use
+   infrastructure will be delegated to AS112 servers in the future.  A
+   list of zones for which AS112 servers answer authoritatively is
+   maintained at <http://www.as112.net/>.
+
+2.2.  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
+   (192.175.48.42).
+
+   Additionally, the server PRISONER.IANA.ORG (192.175.48.1) is listed
+   in the MNAME field of the SOA records of the IN-ADDR.ARPA zones
+   served by AS112 nameservers.  PRISONER.IANA.ORG receives mainly
+   dynamic update queries.
+
+
+
+
+
+Abley & Maton                 Informational                     [Page 4]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   The addresses of all these nameservers are covered by the single IPv4
+   prefix 192.175.48.0/24.
+
+3.  Installation of a New Node
+
+3.1.  Useful Background Knowledge
+
+   Installation of an AS112 node is relatively straightforward.
+   However, experience in the following general areas may prove useful:
+
+   o  inter-domain routing with BGP [RFC4271];
+
+   o  DNS authoritative server operations; and
+
+   o  anycast [RFC4786] distribution of DNS services.
+
+3.2.  Topological Location
+
+   AS112 nodes may be located anywhere on the Internet.  For nodes that
+   are intended to provide a public service to the Internet community
+   (as opposed to private use), it may well be advantageous to choose a
+   location that is easily (and cheaply) reachable by multiple
+   providers, such as an Internet Exchange Point.
+
+   AS112 nodes may advertise their service prefix to BGP peers for local
+   use (analogous to a conventional peering relationship between two
+   providers) or for global use (analogous to a customer relationship
+   with one or more providers).
+
+   It is good operational practice to notify the community of users that
+   may fall within the reach of a new AS112 node before it is installed.
+   At an Internet Exchange, local mailing lists usually exist to
+   facilitate such announcements.  For nodes that are intended to be
+   globally reachable, coordination with other AS112 operators is highly
+   recommended.  See also Section 5.
+
+3.3.  Operating System and Host Considerations
+
+   Examples in this document are based on UNIX and UNIX-like operating
+   systems, but other operating systems exist that are suitable for use
+   in construction of an AS112 node.
+
+   The chosen platform should include either support for cloned loopback
+   interfaces or the capability to bind multiple addresses to a single
+   loopback interface.  The addresses of the nameservers listed in
+   Section 2.2 will be configured on these interfaces in order that the
+   DNS software can respond to queries properly.
+
+
+
+
+Abley & Maton                 Informational                     [Page 5]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   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
+   provide other services.  This guidance is provided due to the
+   unpredictable (and occasionally high) traffic levels that AS112 nodes
+   have been seen to attract.
+
+   System startup scripts should be arranged such that the various
+   AS112-related components start automatically following a system
+   reboot.  The order in which interfaces are configured and software
+   components started should be arranged such that routing software
+   startup follows DNS software startup, and DNS software startup
+   follows loopback interface configuration.
+
+   Wrapper scripts or other arrangements should be employed to ensure
+   that the anycast service prefix for AS112 is not advertised while
+   either the anycast addresses are not configured or the DNS software
+   is not running.
+
+3.4.  Routing Software
+
+   AS112 nodes signal the availability of AS112 nameservers to the
+   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
+   112 (see also Section 2.2).
+
+   The examples in this document are based on the Quagga Routing Suite
+   [QUAGGA] running on Linux, but other software packages exist that
+   also provide suitable BGP support for AS112 nodes.
+
+   The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides
+   BGP 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.  Note the
+   local AS number is 112, and the service prefix originated from the
+   AS112 node is 192.175.48.0/24.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                     [Page 6]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   ! bgpd.conf
+   !
+   hostname as112-bgpd
+   password <something>
+   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
+    bgp router-id 203.0.113.1
+    network 192.175.48.0
+    neighbor 192.0.2.1 remote-as 64496
+    neighbor 192.0.2.1 next-hop-self
+    neighbor 192.0.2.1 prefix-list AS112 out
+    neighbor 192.0.2.1 filter-list 1 out
+    neighbor 192.0.2.2 remote-as 64497
+    neighbor 192.0.2.2 next-hop-self
+    neighbor 192.0.2.2 prefix-list AS112 out
+    neighbor 192.0.2.2 filter-list 1 out
+   !
+   ip prefix-list AS112 permit 192.175.48.0/24
+   !
+   ip as-path access-list 1 permit ^$
+
+   The configuration above includes a double-blinded restriction on what
+   the AS112 node shall advertise to the pair of BGP neighbors.
+   Firstly, that prefix-list "AS112" only containing the service prefix
+   192.175.48.0/24 shall be advertised.  Secondly, the "ip as-path
+   access-list 1" statement contains a one-line regular expression that
+   permits only the local AS number (112 in this case) and no other to
+   be advertised as well.  Both statements prevent the node from
+   becoming a transit router.  Equivalent restrictions using other BGP
+   implementations should be utilised.
+
+   The "zebra.conf" file is required to provide integration between
+   protocol daemons (bgpd, in this case) and the kernel.
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                     [Page 7]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   ! zebra.conf
+   !
+   hostname as112
+   password <something>
+   enable password <supersomething>
+   !
+   interface lo
+   !
+   interface eth0
+   !
+
+3.5.  DNS Software
+
+   Although the queries received by AS112 nodes are definitively
+   misdirected, it is important that they be answered in a manner that
+   is accurate and consistent.  For this reason, AS112 nodes operate as
+   fully functional and standards-compliant DNS authoritative servers
+   [RFC1034], and hence require DNS software.
+
+   Examples in this document are based on ISC BIND9 [BIND], but other
+   DNS software exists that is suitable for use in construction of an
+   AS112 node.
+
+   The following is a sample BIND9 "named.conf" file for a dedicated
+   AS112 server.  Note that the nameserver is configured to act as an
+   authoritative-only server (i.e., recursion is disabled).  The
+   nameserver is also configured to listen on the various AS112 anycast
+   nameserver addresses, as well as its local addresses.
+
+   // named.conf
+
+   // global options
+
+   options {
+     listen-on {
+       127.0.0.1;         // localhost
+
+     // 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.6;      // blackhole-1.iana.org (anycast)
+       192.175.48.42;     // blackhole-2.iana.org (anycast)
+
+
+
+Abley & Maton                 Informational                     [Page 8]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+     };
+     directory "/var/named";
+     recursion no;        // authoritative-only server
+     query-source address *;
+   };
+
+   // Log queries, so that when people call us about unexpected
+   // answers to queries they didn't realise they had sent, we
+   // have something to talk about.  Note that activating this
+   // has the potential to create high CPU load and consume
+   // enormous amounts of disk space.
+
+   logging {
+     channel "querylog" {
+       file "/var/log/query.log" versions 2 size 500m;
+       print-time yes;
+     };
+     category queries { querylog; };
+   };
+
+   // RFC 1918
+
+   zone "10.in-addr.arpa" { type master; file "db.empty"; };
+   zone "16.172.in-addr.arpa" { type master; file "db.empty"; };
+   zone "17.172.in-addr.arpa" { type master; file "db.empty"; };
+   zone "18.172.in-addr.arpa" { type master; file "db.empty"; };
+   zone "19.172.in-addr.arpa" { type master; file "db.empty"; };
+   zone "20.172.in-addr.arpa" { type master; file "db.empty"; };
+   zone "21.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 "24.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 "27.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 "30.172.in-addr.arpa" { type master; file "db.empty"; };
+   zone "31.172.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,
+   // which contains data of operational relevance.
+
+
+
+
+Abley & Maton                 Informational                     [Page 9]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   zone "hostname.as112.net" {
+     type master;
+     file "db.hostname.as112.net";
+   };
+
+   The "db.empty" file follows, below.  This is the source data used to
+   populate all the IN-ADDR.ARPA zones listed in Section 2.1.  Note that
+   the RNAME specified in the SOA record corresponds to
+   hostmaster@root-servers.org, a suitable email address for receiving
+   technical queries about these zones.
+
+   ; db.empty
+   ;
+   ; Empty zone for AS112 server.
+   ;
+   $TTL    1W
+   @  IN  SOA  prisoner.iana.org. hostmaster.root-servers.org. (
+                                  1       ; serial number
+                                  1W      ; refresh
+                                  1M      ; retry
+                                  1W      ; expire
+                                  1W )    ; negative caching TTL
+   ;
+          NS     blackhole-1.iana.org.
+          NS     blackhole-2.iana.org.
+   ;
+   ; There should be no other resource records included in this zone.
+   ;
+   ; Records that relate to RFC 1918-numbered resources within the
+   ; site hosting this AS112 node should not be hosted on this
+   ; nameserver.
+
+   The "db.hostname.as112.net" file follows, below.  This zone contains
+   various resource records that provide operational data to users for
+   troubleshooting or measurement purposes; the data should be edited to
+   suit local circumstances.  Note that the response to the query
+   "HOSTNAME.AS112.NET IN TXT" should fit within a 512-octet DNS/UDP
+   datagram: i.e., it should be available over UDP transport without
+   requiring EDNS0 support.
+
+   The optional LOC record [RFC1876] included in the zone apex provides
+   information about the geospatial location of the node.
+
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                    [Page 10]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   ; db.hostname.as112.net
+   ;
+   $TTL    1W
+   @       SOA     server.example.net. admin.example.net. (
+                           1               ; serial number
+                           1W              ; refresh
+                           1M              ; retry
+                           1W              ; expire
+                           1W )            ; negative caching TTL
+   ;
+           NS      blackhole-2.iana.org.
+           NS      blackhole-1.iana.org.
+   ;
+           TXT     "Name of Facility or similar" "City, Country"
+           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
+
+3.6.  Testing a Newly Installed Node
+
+   The BIND9 tool "dig" can be used to retrieve the TXT resource records
+   associated with the domain "HOSTNAME.AS112.NET", directed at one of
+   the AS112 anycast nameserver addresses.  Continuing the example from
+   above, the response received should indicate the identity of the
+   AS112 node that responded to the query.  See Section 3.5 for more
+   details about the resource records associated with
+   "HOSTNAME.AS112.NET".
+
+       % dig @prisoner.iana.org hostname.as112.net txt +short +norec
+       "Name of Facility or similar" "City, Country"
+       "See http://www.as112.net/ for more information."
+       %
+
+   If the response received indicates a different node is being used,
+   then there is probably a routing problem to solve.  If there is no
+   response received at all, there might be a host or nameserver
+   problem.  Judicious use of tools such as traceroute and consultation
+   of BGP looking glasses might be useful in troubleshooting.
+
+   Note that an appropriate set of tests for a new server will include
+   queries sent from many different places within the expected service
+   area of the node, using both UDP and TCP transport, and exercising
+   all three AS112 anycast nameserver addresses.
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                    [Page 11]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+4.  Operations
+
+4.1.  Monitoring
+
+   AS112 nodes should be monitored to ensure they are functioning
+   correctly, just as with any other production service.  An AS112 node
+   that stops answering queries correctly can cause failures and
+   timeouts in unexpected places and can lead to failures in dependent
+   systems that can be difficult to troubleshoot.
+
+4.2.  Downtime
+
+   An AS112 node that needs to go off-line (e.g., for planned
+   maintenance or as part of the diagnosis of some problem) should stop
+   advertising the AS112 service prefix to its BGP peers.  This can be
+   done by shutting down the routing software on the node altogether or
+   by causing the routing system to withdraw the route.
+
+   Withdrawing the service prefix is important in order to avoid
+   blackholing query traffic in the event that the DNS software on the
+   node is not functioning normally.
+
+4.3.  Statistics and Measurement
+
+   Use of the AS112 node should be measured in order to track long-term
+   trends, identify anomalous conditions, and ensure that the
+   configuration of the AS112 node is sufficient to handle the query
+   load.
+
+   Examples of free monitoring tools that might be useful to operators
+   of AS112 nodes include:
+
+   o  bindgraph [BINDGRAPH]
+
+   o  dnstop [DNSTOP]
+
+   o  DSC [DSC]
+
+5.  Communications
+
+   It is good operational practice to notify the community of users that
+   may fall within the reach of a new AS112 node before it is installed.
+   At Internet Exchanges, local mailing lists usually exist to
+   facilitate such announcements.
+
+   For nodes that are intended to be globally reachable, coordination
+   with other AS112 operators is especially recommended.  The mailing
+   list <as112-ops@lists.dns-oarc.net> is operated for this purpose.
+
+
+
+Abley & Maton                 Informational                    [Page 12]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   Information pertinent to AS112 operations is maintained at
+   <http://www.as112.net/>.
+
+   Information about an AS112 node should also be published within the
+   DNS, within the "HOSTNAME.AS112.NET" zone.  See Section 3.5 for more
+   details.
+
+6.  On the Future of AS112 Nodes
+
+   It is recommended practice for the operators of recursive nameservers
+   to answer queries for zones served by AS112 nodes locally, such that
+   queries never have an opportunity to reach AS112 servers [RFC6303].
+   Operational experience with AS112 nodes does not currently indicate
+   an observable trend towards compliance with those recommendations,
+   however.
+
+   It is expected that some DNS software vendors will include default
+   configuration that will implement measures such as those described in
+   [RFC6303].  If such software is widely deployed, it is reasonable to
+   assume that the query load received by AS112 nodes will decrease;
+   however, it is safe to assume that the query load will not decrease
+   to zero, and consequently that AS112 nodes will continue to provide a
+   useful service for the foreseeable future.
+
+   There may be a requirement in the future for AS112 nodes to answer
+   for their current set of zones over IPv6 transport.  Such a
+   requirement would necessitate the assignment of a corresponding IPv6
+   netblock for use as an anycast service prefix.
+
+   There may be a requirement in the future for AS112 nodes to serve
+   additional zones or to stop serving particular zones that are
+   currently served.  Such changes would be widely announced in
+   operational forums and published at <http://www.as112.net/>.
+
+7.  IANA Considerations
+
+   The AS112 nameservers are all named under the domain IANA.ORG (see
+   Section 2.2).  However, the anycast infrastructure itself is operated
+   by a loosely coordinated, diverse mix of organisations across the
+   Internet, and is not an IANA function.
+
+   The Autonomous System Number 112 and the IPv4 prefix 192.175.48.0/24
+   were assigned by ARIN.
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                    [Page 13]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+8.  Security Considerations
+
+   Hosts should never normally send queries to AS112 servers; queries
+   relating to private-use addresses should be answered locally within a
+   site.  Hosts that send queries to AS112 servers may well leak
+   information relating to private infrastructure to the public network,
+   and this could present a security risk.  This risk is orthogonal to
+   the presence or absence of authoritative servers for these zones in
+   the public DNS infrastructure, however.
+
+   Queries that are answered by AS112 servers are usually unintentional;
+   it follows that the responses from AS112 servers are usually
+   unexpected.  Unexpected inbound traffic can trigger intrusion
+   detection systems or alerts by firewalls.  Operators of AS112 servers
+   should be prepared to be contacted by operators of remote
+   infrastructure who believe their security has been violated.  Advice
+   to those who mistakenly believe that responses from AS112 nodes
+   constitute an attack on their infrastructure can be found in
+   [RFC6305].
+
+   The deployment of AS112 nodes is very loosely coordinated compared to
+   other services distributed using anycast.  The malicious compromise
+   of an AS112 node and subversion of the data served by the node are
+   hence more difficult to detect due to the lack of central management.
+   Since it is conceivable that changing the responses to queries
+   received by AS112 nodes might influence the behaviour of the hosts
+   sending the queries, such a compromise might be used as an attack
+   vector against private infrastructure.
+
+   Operators of AS112 should take appropriate measures to ensure that
+   AS112 nodes are appropriately protected from compromise, such as
+   would normally be employed for production nameserver or network
+   infrastructure.  The guidance provided for root nameservers in
+   [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.  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, Peter Koch, Alfred Hoenes, S.
+   Moonesamy, and Mehmet Akcin in the preparation of this document.
+
+
+
+
+Abley & Maton                 Informational                    [Page 14]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]    Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1918]    Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
+                and E. Lear, "Address Allocation for Private Internets",
+                BCP 5, RFC 1918, February 1996.
+
+   [RFC2870]    Bush, R., Karrenberg, D., Kosters, M., and R. Plzak,
+                "Root Name Server Operational Requirements", BCP 40,
+                RFC 2870, 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
+                Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC4786]    Abley, J. and K. Lindqvist, "Operation of Anycast
+                Services", BCP 126, RFC 4786, December 2006.
+
+10.2.  Informative References
+
+   [BIND]       Internet Systems Consortium, "BIND",
+                <http://www.isc.org/software/BIND/>.
+
+   [BINDGRAPH]  Delaurenti, M. and M. d'Itri, "bindgraph",
+                <http://www.linux.it/~md/software/>.
+
+   [DNSTOP]     The Measurement Factory, "Dnstop: Stay on Top of Your
+                DNS Traffic",
+                <http://dns.measurement-factory.com/tools/dnstop/>.
+
+   [DSC]        The Measurement Factory, "Dsc: A DNS Statistics
+                Collector",
+                <http://dns.measurement-factory.com/tools/dsc/>.
+
+   [QUAGGA]     "Quagga Software Routing Suite",
+                <http://www.quagga.net>.
+
+   [RFC1876]    Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
+                Means for Expressing Location Information in the Domain
+                Name System", RFC 1876, January 1996.
+
+
+
+
+Abley & Maton                 Informational                    [Page 15]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+   [RFC5735]    Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+                BCP 153, RFC 5735, January 2010.
+
+   [RFC5855]    Abley, J. and T. Manderson, "Nameservers for IPv4 and
+                IPv6 Reverse Zones", BCP 155, RFC 5855, May 2010.
+
+   [RFC6303]    Andrews, M., "Locally Served DNS Zones", BCP 163,
+                RFC 6303, July 2011.
+
+   [RFC6305]    Abley, J. and W. Maton, "I'm Being Attacked by
+                PRISONER.IANA.ORG!", RFC 6305, July 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                    [Page 16]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+Appendix A.  History
+
+   Widespread use of the private address blocks listed in [RFC1918]
+   followed that document's publication in 1996.  At that time the
+   IN-ADDR.ARPA zone was served by root servers.
+
+   The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918]
+   addresses from the root nameservers was first proposed by Bill
+   Manning and John Brown.
+
+   The use of anycast for distributing authoritative DNS service for
+   [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private
+   meeting of root server operators.
+
+   ARIN provided an IPv4 prefix for the anycast service and also the
+   autonomous system number 112 for use in originating that prefix.
+   This assignment gave the project its name.
+
+   In 2002, the first AS112 anycast nodes were deployed.
+
+   In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers
+   to a new set of servers operated independently by AfriNIC, APNIC,
+   ARIN, ICANN, LACNIC, and the RIPE NCC and named according to
+   [RFC5855].
+
+   The use of anycast nameservers in the AS112 project contributed to
+   the operational experience of anycast DNS services, and it can be
+   seen as a precursor to the anycast distribution of other
+   authoritative DNS servers in subsequent years (e.g., various root
+   servers).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                    [Page 17]
+
+RFC 6304               AS112 Nameserver Operations             July 2011
+
+
+Authors' Addresses
+
+   Joe Abley
+   ICANN
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA  90292
+   US
+
+   Phone: +1 519 670 9327
+   EMail: joe.abley@icann.org
+
+
+   William F. Maton Sotomayor
+   National Research Council of Canada
+   1200 Montreal Road
+   Ottawa, ON  K1A 0R6
+   Canada
+
+   Phone: +1 613 993 0880
+   EMail: wmaton@ryouko.imsb.nrc.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Maton                 Informational                    [Page 18]
+