Network Working GroupInternet Engineering Task Force (IETF) J. AbleyInternet-DraftRequest for Comments: 7534 Dyn, Inc. Obsoletes: 6304(if approved)W. SotomayorIntended status:Category: Informational OttIXExpires: August 18, 2015 February 14,ISSN: 2070-1721 May 2015 AS112 Nameserver Operationsdraft-ietf-dnsop-rfc6304bis-06Abstract 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 corresponding 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. This document obsoletesRFC6304.RFC 6304. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe 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 amaximumcandidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 18, 2015.http://www.rfc-editor.org/info/rfc7534. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1.NOTE TO RFC EDITOR AND REVIEWERS . . . . . . . . . . . . . . 3 2.Introduction. . . . . . . . . . . . . . . . . . . . . . . . 4 3.....................................................4 2. AS112 DNS Service. . . . . . . . . . . . . . . . . . . . . . 4 3.1................................................4 2.1. Approach. . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1....................................................4 2.1.1. Direct Delegation. . . . . . . . . . . . . . . . . . 4 3.1.2....................................4 2.1.2. DNAME Redirection. . . . . . . . . . . . . . . . . . 5 3.2....................................5 2.2. Zones. . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.......................................................5 2.3. Nameservers. . . . . . . . . . . . . . . . . . . . . . . 5 4.................................................6 3. Installation of a New Node. . . . . . . . . . . . . . . . . 6 4.1.......................................6 3.1. Useful Background Knowledge. . . . . . . . . . . . . . . 6 4.2.................................6 3.2. Topological Location. . . . . . . . . . . . . . . . . . 6 4.3........................................6 3.3. Operating System and Host Considerations. . . . . . . . 7 4.4....................7 3.4. Routing Software. . . . . . . . . . . . . . . . . . . . 7 4.5............................................7 3.5. DNS Software. . . . . . . . . . . . . . . . . . . . . . 9 4.6...............................................10 3.6. Testing a Newly Installed Node. . . . . . . . . . . . . 15 5.............................15 4. Operations. . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1......................................................16 4.1. Monitoring. . . . . . . . . . . . . . . . . . . . . . . 15 5.2.................................................16 4.2. Downtime. . . . . . . . . . . . . . . . . . . . . . . . 15 5.3...................................................16 4.3. Statistics and Measurement. . . . . . . . . . . . . . . 16 6.................................16 5. Communications. . . . . . . . . . . . . . . . . . . . . . . 16 7..................................................17 6. On the Future of AS112 Nodes. . . . . . . . . . . . . . . . 16 8....................................17 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 17 8.1.............................................18 7.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2....................................................18 7.2. IANA Actions. . . . . . . . . . . . . . . . . . . . . . 18 8.2.1...............................................18 7.2.1. IPv6 Transport for Direct Delegation AS112 Servers. 18 8.2.2.............................................18 7.2.2. Registration in the Special-Purpose AS Numbers Registry. . . . . . . . . . . . . . . . . . . . . . 18 8.2.3....................................19 7.2.3. Registration in the IANA IPv4 Special-Purpose Address Registry. . . . . . . . . . . . . . . . . . 18 8.2.4....................19 7.2.4. Registration in the IANA IPv6 Special-Purpose Address Registry. . . . . . . . . . . . . . . . . . 19 9....................19 8. Security Considerations. . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11.........................................20 9. References. . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1......................................................21 9.1. Normative References. . . . . . . . . . . . . . . . . . 20 11.2.......................................21 9.2. Informative References. . . . . . . . . . . . . . . . . 21 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22....................................22 Appendix A. A Brief History of AS112. . . . . . . . . . . . . . 22..............................23 Appendix B. ChangesSincesince RFC 6304. . . . . . . . . . . . . . . 23 Appendix C. Revision History and Venue . . . . . . . . . . . . . 23 C.1. draft-jabley-dnsop-rfc6304bis-00 . . . . . . . . . . . . 23 C.2. draft-ietf-dnsop-rfc6304bis-00 . . . . . . . . . . . . . 23 C.3. draft-ietf-dnsop-rfc6304bis-01 . . . . . . . . . . . . . 23 C.4. draft-ietf-dnsop-rfc6304bis-02 . . . . . . . . . . . . . 24 C.5. draft-ietf-dnsop-rfc6304bis-03 . . . . . . . . . . . . . 24 C.6. draft-ietf-dnsop-rfc6304bis-04 . . . . . . . . . . . . . 24 C.7. draft-ietf-dnsop-rfc6304bis-05 . . . . . . . . . . . . . 24 C.8. draft-ietf-dnsop-rfc6304bis-06 . . . . . . . . . . . . . 25................................23 Acknowledgements ..................................................24 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 25................................................24 1.NOTE TO RFC EDITOR AND REVIEWERS This document uses the phrases "TBA-prefix-v4" and "TBA-prefix-v6" in anticipation of the address assignments requested in the IANA Considerations section of [I-D.ietf-dnsop-as112-dname]. "TBA-address-v4" refers to the address within TBA-prefix-v4 assigned to the nameserver BLACKHOLE.AS112.ARPA. Similarly, "TBA-address-v6" refers to the corresponding address within TBA-prefix-v6. All of "TBA-prefix-v4", "TBA-address-v4", "TBA-prefix-v6" and "TBA- address-v6" in this document should be replaced with their assigned values prior to publication. The delegation of the AS112.ARPA zone is specified (and requested) in [I-D.ietf-dnsop-as112-dname]. See Appendix C for an abridged revision history, and discussion of an appropriate venue for discussion. This section should be removed prior to publication. 2.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]. 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],[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 (see Appendix A).3.2. AS112 DNS Service3.1.2.1. Approach3.1.1.2.1.1. Direct Delegation The AS112Projectproject currently uses an approach whereby zones whose traffic should be directed towards an AS112 sink should be directly delegated to AS112 nameservers. Correspondingly, each AS112 node is manually configured to answer appropriately for those zones. The guidance in this document describes this capability for the zones that were originally delegated in this fashion. AS112 nodes that were implemented in accordance with the guidance found here will continue to provide service for those zones.3.1.2.2.1.2. DNAME Redirection[I-D.ietf-dnsop-as112-dname][RFC7535] describes a different approach whereby queries towards specific zones are redirected to an empty zone also hosted on AS112 servers, using DNAME [RFC6672]. The guidance in this document introduces this capability, allowing any zone administrator to sink query traffic in AS112 infrastructure without requiring changes to any AS112 node.3.2.2.2. Zones To support Direct Delegation AS112 service, AS112namenameservers 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 [RFC6890]: o 254.169.IN-ADDR.ARPA To support DNAMERedirectionredirection AS112 service, AS112name serversnameservers answer authoritatively for the following zone, as specified in[I-D.ietf-dnsop-as112-dname]:[RFC7535]: o EMPTY.AS112.ARPA To aid identification of AS112 anycast nodes, each node also answers authoritatively for the following zones: o HOSTNAME.AS112.NET o HOSTNAME.AS112.ARPA See Section4.53.5 for the recommended contents of all these zones.3.3.2.3. Nameservers To support Direct Delegation AS112 service, the relevant zones listed in Section3.22.2 are delegated to the two nameserversBLACKHOLE- 1.IANA.ORGBLACKHOLE-1.IANA.ORG (192.175.48.6, 2620:4f:8000::6) and BLACKHOLE-2.IANA.ORG (192.175.48.42, 2620:4f:8000::42). Additionally, the server PRISONER.IANA.ORG (192.175.48.1, 2620:4f:8000::1) is listed in the MNAME field of the SOA records of the IN-ADDR.ARPA zones served by AS112name servers.nameservers. PRISONER.IANA.ORG receives mainly dynamic update queries. The addresses of all these nameservers are covered by the single IPv4 prefix 192.175.48.0/24 and the IPv6 prefix 2620:4f:8000::/48. To date, IPv6 transport for these nameservers has only been available for pre-production testing.Direction to theIANAto addhas added AAAA RRSets for the owner names of thesenameservers can be found innameservers; see Section8.7. To support DNAMERedirectionredirection AS112 service, the single zone EMPTY.AS112.ARPA is delegated to the single nameserver BLACKHOLE.AS112.ARPA(TBA-address-v4, TBA-address-v6).(192.31.196.1, 2001:4:112::1). The addresses of that nameserver are covered by the single IPv4 prefixTBA-prefix- v4,192.31.196.0/24 and the single IPv6 prefixTBA-prefix-v6. 4.2001:4:112::/48. 3. Installation of a New Node4.1.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,and o anycast [RFC4786] distribution of DNS services.4.2.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 Section6. 4.3.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 Section3.32.3 will be configured on these interfaces in order that the DNS software can respond to queries properly. 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.4.4.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 prefixes 192.175.48.0/24 and 2620:4f:8000::/48 to the Internet with origin AS 112 (see also Section3.3).2.3). The examples in this document are based on the Quagga Routing Suite[1]<http://www.quagga.net> running on Linux, but other software packages existwhichthat 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, 192.0.2.2,2001:db8::12001:db8::1, and 2001:db8::2. Note that the local AS number is 112, and the service prefixes originated from the AS112 node to support Direct Delegation service are 192.175.48.0/24 and 2620:4f:8000::/48; the IPv4 prefixTBA-prefix-v4192.31.196.0/24 and the IPv6 prefixTBA-prefix-v62001:4:112::/48 support DNAMERedirection.redirection. For clarity, an IPv4-only AS112 node need not configure any of the IPv6 elements that follow; similarly, an IPv6-only AS112 node need not configure any of the IPv4 elements. Such single-stack hosts can still contribute usefully to IPv4 and IPv6 AS112 services, however, and single-stack operation is not discouraged. ! 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 prefixes 192.175.48.0/24 and !TBA-prefix-v4192.31.196.0/24 and the IPv6 prefixes 2620:4f:8000::/48 and !TBA-prefix-v6.2001:4:112::/48. ! ! All other addresses shown below are illustrative, and ! actual numbers will depend on local circumstances. ! ! IPv4-only or IPv6-only AS112 nodes should omit advertisements ! for address families they do not support. ! router bgp 112 bgp router-id 203.0.113.1 neighbor 192.0.2.1 remote-as 64496 neighbor 192.0.2.1 next-hop-self neighbor 192.0.2.1 prefix-list AS112-v4 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-v4 out neighbor 192.0.2.2 filter-list 1 out ! neighbor 2001:db8::1 remote-as 64498 neighbor 2001:db8::1 next-hop-self neighbor 2001:db8::1 prefix-list AS112-v6 out neighbor 2001:db8::1 filter-list 1 out ! neighbor 2001:db8::2 remote-as 64499 neighbor 2001:db8::2 next-hop-self neighbor 2001:db8::2 prefix-list AS112-v6 out neighbor 2001:db8::2 filter-list 1 out ! network 192.175.48.0/24 networkTBA-prefix-v4192.31.196.0/24 ! address-family ipv6 unicast network 2620:4f:8000::/48 networkTBA-prefix-v62001:4:112::/48 exit-address-family ! ip prefix-list AS112-v4 permit 192.175.48.0/24 ip prefix-list AS112-v4 permitTBA-prefix-v4192.31.196.0/24 ! ipv6 prefix-list AS112-v6 permit 2620:4f:8000::/48 ipv6 prefix-list AS112-v6 permitTBA-prefix-v62001:4:112::/48 ! ip as-path access-list 1 permit ^$ The configuration above includes two restrictions on what the AS112 should advertise to its BGP neighbours: a prefix filter that permits only the service prefixes, and an AS_PATH filter that matches onlylocally-originatedlocally originated routes. Together, these measures prevent the node from becoming a transit point for its adjacent ASes. The "zebra.conf" file is required to provide integration between protocol daemons (bgpd, in this case) and the kernel. ! zebra.conf ! hostname as112 password <something> enable password <supersomething> ! interface lo ! interface eth0 !4.5.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 appropriate DNS software. Examples in this document are based on ISC BIND9[2],<http://www.isc.org/software/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. A basic logging example is included in the sample as well. AS112 operators may exercise discretion at the amount of logging detail they desire or the type of logging they may use in the maintenance of their node. The detail of information can then be used tosingle-outsingle out badimplementors,implementors or badly managednameserversnameservers, or it can be used for simple measurement analysis. // 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 are used to support Direct Delegation // AS112service,service 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) // The following address is used to support DNAMERedirectionredirection // AS112service,service and is the same for all AS112 nodes.TBA-address-v4;192.31.196.1; // blackhole.as112.arpa (anycast) }; listen-on-v6 { ::1; // localhost // The following addresses are used to support Direct Delegation // AS112service,service and are the same for all AS112 nodes. 2620:4f:8000::1; // prisoner.iana.org (anycast) 2620:4f:8000::6; // blackhole-1.iana.org (anycast) 2620:4f:8000::42; // blackhole-2.iana.org (anycast) // The following address is used to support DNAMERedirectionredirection // AS112service,service and is the same for all AS112 nodes.TBA-address-v6;2001:4:112::1; // blackhole.as112.arpa (anycast) }; directory "/var/named"; recursion no; // authoritative-only server }; // 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 // naively has the potential to create high CPU load and consume // enormous amounts of disk space. This example retains 2 old // versions at a maximum of500MB500 MB each before rotating out the // oldest one. logging { channel "querylog" { file "/var/log/query.log" versions 2 size 500m; print-time yes; }; category queries { querylog; }; }; // Direct Delegation AS112 Service // RFC 1918 zone "10.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "16.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "17.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "18.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "19.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "20.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "21.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "22.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "23.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "24.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "25.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "26.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "27.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "28.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "29.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "30.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "31.172.in-addr.arpa" { type master; file "db.dd-empty"; }; zone "168.192.in-addr.arpa" { type master; file "db.dd-empty"; }; // RFC 6890 zone "254.169.in-addr.arpa" { type master; file "db.dd-empty"; }; // DNAMERedirectionredirection AS112 Service zone "empty.as112.arpa" { type master; file "db.dr-empty"; }; // Also answer authoritatively for the HOSTNAME.AS112.NET and // HOSTNAME.AS112.ARPA zones, whichcontainscontain data of operational // relevance. zone "hostname.as112.net" { type master; file "db.hostname.as112.net"; }; zone "hostname.as112.arpa" { type master; file "db.hostname.as112.arpa"; }; The "db.dd-empty" file follows, below. This is the source data used to populate all the IN-ADDR.ARPA zones listed in Section3.22.2 that support Direct Delegation AS112 service. Note that the RNAME specified in the SOA record corresponds tohostmaster@root- servers.org,hostmaster@root-servers.org, a suitable email address for receiving technical queries about these zones. ; db.dd-empty ; ; Empty zone for Direct Delegation AS112 service. ; $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.dr-empty" filefollowsfollows, below. This is the source data used to populate the EMPTY.AS112.ARPA zone that supports DNAMERedirectionredirection AS112 service. Note that the RNAME specified in the SOA record corresponds to noc@dns.icann.org, a suitable email address for technical queries about this zone. ; db.dr-empty ; ; Empty zone forDirect DelegationDNAME redirection AS112 service. ; $TTL 1W @ IN SOA blackhole.as112.arpa. noc.dns.icann.org. ( 1 ; serial number 1W ; refresh 1M ; retry 1W ; expire 1W ) ; negative caching TTL ; NS blackhole.as112.arpa. ; ; 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" and "db.hostname.as112.arpa" files follow, below. These zones contain 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 responses to the queries "HOSTNAME.AS112.NET IN TXT" and "HOSTNAME.AS112.ARPA IN TXT" should fit within a512 octet512-octet DNS/ UDP datagram: i.e., it should be available over UDP transport without requiring EDNS0 support by the client. The optional LOC record [RFC1876] included in each zone apex provides information about the geospatial location of the node. Where software implementations support it, operational data should also be carried using NSID [RFC5001]. ; 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-1.iana.org. NS blackhole-2.iana.org. ; TXT "Name of Facility or similar" "City, Country" TXT "See http://www.as112.net/ for more information." TXT "Unique IP: 203.0.113.1." ; LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m ; db.hostname.as112.arpa ; $TTL 1W @ SOA server.example.net. admin.example.net. ( 1 ; serial number 1W ; refresh 1M ; retry 1W ; expire 1W ) ; negative caching TTL ; NS blackhole.as112.arpa. ; 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 10m4.6.3.6. Testing a Newly Installed Node The BIND9 tool "dig" can be used to retrieve the TXT resource records associated with the names "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA", 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 Section4.53.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 that 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.5.4. Operations5.1.4.1. Monitoring AS112 nodes should be monitored to ensure that 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.5.2.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 prefixes 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 prefixes is important in order to avoid blackholing query traffic in the event that the DNS software on the node is not functioning normally.5.3.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[3]<http://www.linux.it/~md/software/> o dnstop[4]<http://dns.measurement-factory.com/tools/dnstop/> o DSC[5]<https://www.dns-oarc.net/tools/dsc/> Operators of AS112 nodes should also consider participating in collection events as part of a larger,co-ordinatedcoordinated effort to gather important baselines. One example of such an effort isDay-in-the-Day in the Life[6]<https://www.dns-oarc.net/oarc/data/ditl/>, coordinated by the DNS-OARC[7]. 6.<https://www.dns-oarc.net/>. 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[8]<as112-ops@lists.dns-oarc.net> is operated for this purpose. Information pertinent to AS112 operations is maintained at[9].<http://www.as112.net/>. Information about an AS112 node should also be published within the DNS, within the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones. See Section4.53.5 for more details. AS112 operators should also be aware of the measures described in [RFC6305] and direct site administrators appropriately.7.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. The use of DNAMERedirectionredirection to provide AS112 service isnew,new and hence is informed by minimal operational experience. The use of DNAME means that queries for many source zones could be redirected to AS112 infrastructure with no real opportunity for coordination. If the DNAMERedirectionredirection approach is successful, and in the absence of any operational concerns, the community might well recommend the retirement of the original Direct Delegation AS112 service. This document makes no such recommendation, however.8.7. IANA Considerations8.1.7.1. General The nameservers associated with Direct Delegation AS112 service are all named under the domain IANA.ORG (see Section3.3).2.3). However, the anycast infrastructure itself is operated by aloosely-coordinated,loosely coordinated, diverse mix of organisations across theInternet,Internet and is not an IANA function. The autonomous system number 112, the IPv4 prefix192.175.48.0/24192.175.48.0/24, and the IPv6 prefix 2620:4f:8000::/48 were assigned by ARIN. The IPv4 prefixTBA-prefix-v4192.31.196.0/24 and the IPv6 prefixTBA-prefix-v6,2001:4:112::/48, used for DNAMERedirectionredirection AS112 service, were assigned by the IANA[I-D.ietf-dnsop-as112-dname].[RFC7535]. The three nameservers BLACKHOLE-1.IANA.ORG,BLACKHOLE-2.IANA.ORGBLACKHOLE-2.IANA.ORG, and PRISONER.IANA.ORG are also reachable over IPv6, as described in Section3.3.2.3. Following a substantial period of pre-production testing by AS112 operators, the IANAis directed to addhas added AAAA RRSets to those owner names in Section8.2.1,7.2.1, to allow the servers to receive queries and generate responses over IPv6 transport.8.2.7.2. IANA Actions8.2.1.7.2.1. IPv6 Transport for Direct Delegation AS112 Servers The IANAis directed to addhas added the following AAAA resource records for the three Direct Delegation AS112 nameservers named under IANA.ORG: +----------------------+------------------+ | Owner Name | AAAA RDATA | +----------------------+------------------+ | PRISONER.IANA.ORG | 2620:4f:8000::1 | | | | | BLACKHOLE-1.IANA.ORG | 2620:4f:8000::6 | | | | | BLACKHOLE-2.IANA.ORG | 2620:4f:8000::42 | +----------------------+------------------+8.2.2.7.2.2. Registration in the Special-Purpose AS Numbers Registry The IANAis directed to addhas added AS112 to the "Special-Purpose AS Numbers" registry specified in [RFC7249] as follows: AS Numbers: 112 Reason for Reservation: Used by the AS112 project to sink misdirected DNS queries; see[THIS DOCUMENT] 8.2.3.RFC 7534. 7.2.3. Registration in the IANA IPv4 Special-Purpose Address Registry The IANAis directed to addhas added 192.175.48.0/24 to the "IANA IPv4 Special-Purpose Address Registry" specified in [RFC6890] as follows: Address Block: 192.175.48.0/24 Name: Direct Delegation AS112 Service RFC:[THIS DOCUMENT]RFC 7534 Allocation Date:1996-01-051996-01 Termination Date: N/A Source: True Destination: True Forwardable: True Global: True Reserved-by-Protocol: False8.2.4.7.2.4. Registration in the IANA IPv6 Special-Purpose Address Registry The IANAis directed to addhas added 2620:4f:8000::/48 to the "IANA IPv6Special-PurposeSpecial- Purpose Address Registry" specified in [RFC6890] as follows: Address Block: 2620:4f:8000::/48 Name: Direct Delegation AS112 Service RFC:[THIS DOCUMENT]RFC 7534 Allocation Date:2011-05-312011-05 Termination Date: N/A Source: True Destination: True Forwardable: True Global: True Reserved-by-Protocol: False9.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. Additionally, AS112 operators may log thisinformationinformation, making it further subject to whatever security and privacy risks that might entail. These risks are 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.10. Acknowledgements This document benefited from review and suggestions from Leo Vegoda and Pearl Liang. 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, Mehmet Akcin and Aleksi Suhonen in the preparation of [RFC6304], which this document supercedes. 11.9. References11.1.9.1. Normative References[I-D.ietf-dnsop-as112-dname] Abley, J., Dickson, B., Kumari, W., and G. Michaelson, "AS112 Redirection using DNAME", draft-ietf-dnsop- as112-dname-03 (work in progress), March 2014.[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November1987.1987, <http://www.rfc-editor.org/info/rfc1034>. [RFC1918] Rekhter, Y., Moskowitz,R.,B., Karrenberg, D., J. de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February1996.1996, <http://www.rfc-editor.org/info/rfc1918>. [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June2000.2000, <http://www.rfc-editor.org/info/rfc2870>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March2005.2005, <http://www.rfc-editor.org/info/rfc4033>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January2006.2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December2006. 11.2.2006, <http://www.rfc-editor.org/info/rfc4786>. [RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson, "AS112 Redirection Using DNAME", RFC 7535, May 2015, <http://www.rfc-editor.org/info/rfc7535>. 9.2. Informative References [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January1996.1996, <http://www.rfc-editor.org/info/rfc1876>. [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007, <http://www.rfc-editor.org/info/rfc5001>. [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 Reverse Zones", BCP 155, RFC 5855, May2010.2010, <http://www.rfc-editor.org/info/rfc5855>. [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July2011.2011, <http://www.rfc-editor.org/info/rfc6303>. [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July2011.2011, <http://www.rfc-editor.org/info/rfc6304>. [RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by PRISONER.IANA.ORG!", RFC 6305, July2011.2011, <http://www.rfc-editor.org/info/rfc6305>. [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June2012.2012, <http://www.rfc-editor.org/info/rfc6672>. [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April2013.2013, <http://www.rfc-editor.org/info/rfc6890>. [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May2014. 11.3. URIs [1] http://www.quagga.net/ [2] http://www.isc.org/software/BIND/ [3] http://www.linux.it/~md/software/ [4] http://dns.measurement-factory.com/tools/dnstop/ [5] http://dns.measurement-factory.com/tools/dsc/ [6] https://www.dns-oarc.net/oarc/data/ditl/ [7] https://www.dns-oarc.net/ [8] mailto:as112-ops@lists.dns-oarc.net [9] http://www.as112.net/2014, <http://www.rfc-editor.org/info/rfc7249>. Appendix A. A Brief History of AS112 Widespread use of the private address blocks listed in [RFC1918] followed that document's publication in 1996. At thattimetime, theIN- ADDR.ARPAIN-ADDR.ARPA zone was served by root servers. The idea ofoff-loadingoffloading 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]. [RFC6304], the precursor to this document, was published in July 2011. 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). Appendix B. ChangesSincesince RFC 6304 A number of changes and enhancements to the AS112 service has been introduced since the publication of [RFC6304]. o The addition of IPv6 transport. o The extension of the AS112 service to include the ability to have additional zones delegated for sinking or removed using the DNAME resource record. o Requisite changes to the guidance regarding the configuration of current and future AS112 nodes. o Further clarification about the leakage of information in the Security Considerations section. o A direction to the IANA to register the AS112Project'sproject's prefixes in the IANA Special-Purpose AddressRegistries. Appendix C. Revision History and Venue A suitable venue for discussion of this document is the dnsop working group. Private comments may also be directed at the authors.registries. Acknowledgements Thissection (and sub-sections) should be removed prior to publication. C.1. draft-jabley-dnsop-rfc6304bis-00 Initial revision of [RFC6304] intended to provide guidance consistent with [I-D.ietf-dnsop-as112-dname]. C.2. draft-ietf-dnsop-rfc6304bis-00 Change of filename following working group adoption. C.3. draft-ietf-dnsop-rfc6304bis-01 Correct "Obsoletes" header indocumentmetadata from "RFC6304" to "6304" as requested by Tim Wicinski. C.4. draft-ietf-dnsop-rfc6304bis-02 Add IPv6 details for Direct Delegation AS112 service, including IANA considerations to add AAAA RRs to PRISONER.IANA.ORG and friends. Add IANA considerations that will add AS112 to the "Special-Purpose AS Numbers" registry, as created in [RFC7249]. Merge in some AUTH48 changes from RFC6304 that had been overlooked. C.5. draft-ietf-dnsop-rfc6304bis-03 Change referencebenefited fromRFC 5735 to RFC 6890. C.6. draft-ietf-dnsop-rfc6304bis-04 Add change section for -03 that was previously overlooked. Register IPv4 netblock in IANA special-use registry. Register IPv6 netblock in IANA special-use registry. Modify registration data for AS112 in corresponding special-use registry. Add shout-out to Pearl and Leo. C.7. draft-ietf-dnsop-rfc6304bis-05 As per IESGreview anda replay of the same comment made by Pete Resnick of the review of the draft of RFC 6304, switchsuggestions fromInformational to Best Current Practice. Amend the abstract slightly to shorten it and re-state second-last paragraph as if RFC 6304 neever existed. Amend AS112 DNS Service section slightly to remove references to RFC 6304Leo Vegoda andmake this a little more standalone. Add a paragraph about logging. Expand the first paragraph in the Security Considerations sectionPearl Liang. The authors wish toinclude a word onacknowledge theloggingassistance ofsuch leaked information. Add mention about further measurementBill Manning, John Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes, S. Moonesamy, Mehmet Akcin, andanalysis contribution through the DNS-OARC. Add another reference to RFC 6305Aleksi Suhonen inCommunication section. Add some more missing changes suggested during RFC 6304 AUTH48 phase. Re-sync some more language with RFC 6304 after another edit round post-AUTH48 that was missing fromthecurrent draft. Expand the TXT record return to include info about the unique IPpreparation ofthe AS112 node. Add shout-out to Aleksi Suhonen. C.8. draft-ietf-dnsop-rfc6304bis-06 As per WG Chairs, switch from Best Current Practice to Informational.[RFC6304], which this document supersedes. Authors' Addresses Joe Abley Dyn, Inc.470 Moore103-186 Albert Street London, ONN6C 2C2N6A 1M1 Canada Phone: +1 519 670 9327Email:EMail: jabley@dyn.com William F. Maton Sotomayor Ottawa Internet Exchange Constitution Square 1400-340 Albert Street Ottawa, ON K1R 0A5 CanadaEmail: wmaton@ottix.netEMail: wfms@ottix.net