diff --git a/CHANGES b/CHANGES index 0cd6bea82b..8f8e3fb678 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +4117. [protocol] Add EMPTY.AS112.ARPA as per RFC 7534. + 4113. [test] Check for Net::DNS is some system test prerequisites. [RT #39369] diff --git a/bin/named/server.c b/bin/named/server.c index 8c4eb25876..b3ecb8101a 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -352,6 +352,9 @@ const char *empty_zones[] = { /* Example Prefix, RFC 3849. */ "8.B.D.0.1.0.0.2.IP6.ARPA", + /* RFC 7534 */ + "EMPTY.AS112.ARPA", + NULL }; diff --git a/doc/rfc/index b/doc/rfc/index index e70716322f..eddffa39c7 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -159,3 +159,5 @@ 6844: DNS Certification Authority Authorization (CAA) Resource Record 6891: Extension Mechanisms for DNS (EDNS(0)) 7314: Extension Mechanisms for DNS (EDNS) EXPIRE Option +7534: AS112 Nameserver Operations +7535: AS112 Redirection Using DNAME diff --git a/doc/rfc/rfc7534.txt b/doc/rfc/rfc7534.txt new file mode 100644 index 0000000000..be962e648d --- /dev/null +++ b/doc/rfc/rfc7534.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Abley +Request for Comments: 7534 Dyn, Inc. +Obsoletes: 6304 W. Sotomayor +Category: Informational OttIX +ISSN: 2070-1721 May 2015 + + + 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 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 obsoletes RFC 6304. + + + + + + + + + + + + + + + + +Abley & Sotomayor Informational [Page 1] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +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. + + 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/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. + + + + + + + + + + + + + + + + + + + + + +Abley & Sotomayor Informational [Page 2] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. AS112 DNS Service ...............................................4 + 2.1. Approach ...................................................4 + 2.1.1. Direct Delegation ...................................4 + 2.1.2. DNAME Redirection ...................................5 + 2.2. Zones ......................................................5 + 2.3. Nameservers ................................................6 + 3. Installation of a New Node ......................................6 + 3.1. Useful Background Knowledge ................................6 + 3.2. Topological Location .......................................6 + 3.3. Operating System and Host Considerations ...................7 + 3.4. Routing Software ...........................................7 + 3.5. DNS Software ..............................................10 + 3.6. Testing a Newly Installed Node ............................15 + 4. Operations .....................................................16 + 4.1. Monitoring ................................................16 + 4.2. Downtime ..................................................16 + 4.3. Statistics and Measurement ................................16 + 5. Communications .................................................17 + 6. On the Future of AS112 Nodes ...................................17 + 7. IANA Considerations ............................................18 + 7.1. General ...................................................18 + 7.2. IANA Actions ..............................................18 + 7.2.1. IPv6 Transport for Direct Delegation AS112 + Servers ............................................18 + 7.2.2. Registration in the Special-Purpose AS + Numbers Registry ...................................19 + 7.2.3. Registration in the IANA IPv4 + Special-Purpose Address Registry ...................19 + 7.2.4. Registration in the IANA IPv6 + Special-Purpose Address Registry ...................19 + 8. Security Considerations ........................................20 + 9. References .....................................................21 + 9.1. Normative References ......................................21 + 9.2. Informative References ....................................22 + Appendix A. A Brief History of AS112 ..............................23 + Appendix B. Changes since RFC 6304 ................................23 + Acknowledgements ..................................................24 + Authors' Addresses ................................................24 + + + + + + + + + + +Abley & Sotomayor Informational [Page 3] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +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]. + + 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 (see Appendix A). + +2. AS112 DNS Service + +2.1. Approach + +2.1.1. Direct Delegation + + The AS112 project 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. + + + + + + +Abley & Sotomayor Informational [Page 4] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +2.1.2. DNAME Redirection + + [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. + +2.2. Zones + + To support Direct Delegation AS112 service, 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 [RFC6890]: + + o 254.169.IN-ADDR.ARPA + + To support DNAME redirection AS112 service, AS112 nameservers answer + authoritatively for the following zone, as specified in [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 Section 3.5 for the recommended contents of all these zones. + + + + + + + + + + + +Abley & Sotomayor Informational [Page 5] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +2.3. Nameservers + + To support Direct Delegation AS112 service, the relevant zones listed + in Section 2.2 are delegated to the two nameservers + BLACKHOLE-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 AS112 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. IANA has added AAAA RRSets for the owner + names of these nameservers; see Section 7. + + To support DNAME redirection AS112 service, the single zone + EMPTY.AS112.ARPA is delegated to the single nameserver + BLACKHOLE.AS112.ARPA (192.31.196.1, 2001:4:112::1). The addresses of + that nameserver are covered by the single IPv4 prefix 192.31.196.0/24 + and the single IPv6 prefix 2001:4:112::/48. + +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. + + + + + + + +Abley & Sotomayor Informational [Page 6] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + 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.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. + +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 Section 2.3). + + + +Abley & Sotomayor Informational [Page 7] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + The examples in this document are based on the Quagga Routing Suite + 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, 192.0.2.2, 2001: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 prefix + 192.31.196.0/24 and the IPv6 prefix 2001:4:112::/48 support DNAME + 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 + enable password + ! + ! Note that all AS112 nodes use the local Autonomous System Number + ! 112, and originate the IPv4 prefixes 192.175.48.0/24 and + ! 192.31.196.0/24 and the IPv6 prefixes 2620:4f:8000::/48 and + ! 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 + ! + + + +Abley & Sotomayor Informational [Page 8] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + 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 + network 192.31.196.0/24 + ! + address-family ipv6 unicast + network 2620:4f:8000::/48 + network 2001:4:112::/48 + exit-address-family + ! + ip prefix-list AS112-v4 permit 192.175.48.0/24 + ip prefix-list AS112-v4 permit 192.31.196.0/24 + ! + ipv6 prefix-list AS112-v6 permit 2620:4f:8000::/48 + ipv6 prefix-list AS112-v6 permit 2001: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 only + locally 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 + enable password + ! + interface lo + ! + interface eth0 + ! + + + + + + +Abley & Sotomayor Informational [Page 9] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +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 + , 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 to single out + bad implementors or badly managed nameservers, 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 + // AS112 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) + + + + + + + +Abley & Sotomayor Informational [Page 10] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + // The following address is used to support DNAME redirection + // AS112 service and is the same for all AS112 nodes. + + 192.31.196.1; // blackhole.as112.arpa (anycast) + }; + + listen-on-v6 { + ::1; // localhost + + // The following addresses are used to support Direct Delegation + // AS112 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 DNAME redirection + // AS112 service and is the same for all AS112 nodes. + + 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 of 500 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; }; + }; + + + + + + + + + + +Abley & Sotomayor Informational [Page 11] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + // 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"; }; + + // DNAME redirection 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, which contain 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"; + }; + + + + + + + +Abley & Sotomayor Informational [Page 12] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + The "db.dd-empty" file follows, below. This is the source data used + to populate all the IN-ADDR.ARPA zones listed in Section 2.2 that + support Direct Delegation AS112 service. 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.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" file follows, below. This is the source data used + to populate the EMPTY.AS112.ARPA zone that supports DNAME redirection + 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 for DNAME 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. + ; + + + +Abley & Sotomayor Informational [Page 13] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + ; 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 a 512-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 + + + + + + + + + + + + +Abley & Sotomayor Informational [Page 14] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + ; 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 10m + +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 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 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. + + + + + + + + + +Abley & Sotomayor Informational [Page 15] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +4. Operations + +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. + +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. + +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 + + o dnstop + + o DSC + + Operators of AS112 nodes should also consider participating in + collection events as part of a larger, coordinated effort to gather + important baselines. One example of such an effort is Day in the + Life , coordinated by the + DNS-OARC . + + + + + + + + +Abley & Sotomayor Informational [Page 16] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +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 is operated for this purpose. + + Information pertinent to AS112 operations is maintained at + . + + Information about an AS112 node should also be published within the + DNS, within the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones. + See Section 3.5 for more details. + + AS112 operators should also be aware of the measures described in + [RFC6305] and direct site administrators appropriately. + +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 DNAME redirection to provide AS112 service is 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 DNAME redirection 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. + + + + +Abley & Sotomayor Informational [Page 17] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +7. IANA Considerations + +7.1. General + + The nameservers associated with Direct Delegation AS112 service are + all named under the domain IANA.ORG (see Section 2.3). 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, the IPv4 prefix 192.175.48.0/24, + and the IPv6 prefix 2620:4f:8000::/48 were assigned by ARIN. + + The IPv4 prefix 192.31.196.0/24 and the IPv6 prefix 2001:4:112::/48, + used for DNAME redirection AS112 service, were assigned by the IANA + [RFC7535]. + + The three nameservers BLACKHOLE-1.IANA.ORG, BLACKHOLE-2.IANA.ORG, and + PRISONER.IANA.ORG are also reachable over IPv6, as described in + Section 2.3. Following a substantial period of pre-production + testing by AS112 operators, the IANA has added AAAA RRSets to those + owner names in Section 7.2.1, to allow the servers to receive queries + and generate responses over IPv6 transport. + +7.2. IANA Actions + +7.2.1. IPv6 Transport for Direct Delegation AS112 Servers + + The IANA has 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 | + +----------------------+------------------+ + + + + + + + + + + + +Abley & Sotomayor Informational [Page 18] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +7.2.2. Registration in the Special-Purpose AS Numbers Registry + + The IANA has 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 RFC 7534. + +7.2.3. Registration in the IANA IPv4 Special-Purpose Address Registry + + The IANA has 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: RFC 7534 + + Allocation Date: 1996-01 + + Termination Date: N/A + + Source: True + + Destination: True + + Forwardable: True + + Global: True + + Reserved-by-Protocol: False + +7.2.4. Registration in the IANA IPv6 Special-Purpose Address Registry + + The IANA has added 2620:4f:8000::/48 to the "IANA IPv6 Special- + Purpose Address Registry" specified in [RFC6890] as follows: + + Address Block: 2620:4f:8000::/48 + + Name: Direct Delegation AS112 Service + + RFC: RFC 7534 + + Allocation Date: 2011-05 + + + + +Abley & Sotomayor Informational [Page 19] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + Termination Date: N/A + + Source: True + + Destination: True + + Forwardable: True + + Global: True + + Reserved-by-Protocol: False + +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 this information, 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. + + + +Abley & Sotomayor Informational [Page 20] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + 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.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + . + + [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root + Name Server Operational Requirements", BCP 40, RFC 2870, + DOI 10.17487/RFC2870, June 2000, + . + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + . + + [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast + Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, + December 2006, . + + [RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson, + "AS112 Redirection Using DNAME", RFC 7535, + DOI 10.17487/RFC7535, May 2015, + . + + + + + + + + + +Abley & Sotomayor Informational [Page 21] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +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, DOI 10.17487/RFC1876, January + 1996, . + + [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", + RFC 5001, DOI 10.17487/RFC5001, August 2007, + . + + [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 + Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, + May 2010, . + + [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, + RFC 6303, DOI 10.17487/RFC6303, July 2011, + . + + [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", + RFC 6304, DOI 10.17487/RFC6304, July 2011, + . + + [RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by + PRISONER.IANA.ORG!", RFC 6305, DOI 10.17487/RFC6305, + July 2011, . + + [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the + DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, + . + + [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, + "Special-Purpose IP Address Registries", BCP 153, + RFC 6890, DOI 10.17487/RFC6890, April 2013, + . + + [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, + DOI 10.17487/RFC7249, May 2014, + . + + + + + + + + + + + + +Abley & Sotomayor Informational [Page 22] + +RFC 7534 AS112 Nameserver Operations May 2015 + + +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 that time, the + IN-ADDR.ARPA zone was served by root servers. + + The idea of offloading 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. Changes since 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. + + + + +Abley & Sotomayor Informational [Page 23] + +RFC 7534 AS112 Nameserver Operations May 2015 + + + o Further clarification about the leakage of information in the + Security Considerations section. + + o A direction to the IANA to register the AS112 project's prefixes + in the IANA Special-Purpose Address registries. + +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 supersedes. + +Authors' Addresses + + Joe Abley + Dyn, Inc. + 103-186 Albert Street + London, ON N6A 1M1 + Canada + + Phone: +1 519 670 9327 + EMail: jabley@dyn.com + + + William F. Maton Sotomayor + Ottawa Internet Exchange + Constitution Square + 1400-340 Albert Street + Ottawa, ON K1R 0A5 + Canada + + EMail: wfms@ottix.net + + + + + + + + + + + + + + +Abley & Sotomayor Informational [Page 24] + diff --git a/doc/rfc/rfc7535.txt b/doc/rfc/rfc7535.txt new file mode 100644 index 0000000000..0c33549763 --- /dev/null +++ b/doc/rfc/rfc7535.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Abley +Request for Comments: 7535 Dyn, Inc. +Category: Informational B. Dickson +ISSN: 2070-1721 Twitter, Inc. + W. Kumari + Google + G. Michaelson + APNIC + May 2015 + + + AS112 Redirection Using DNAME + +Abstract + + AS112 provides a mechanism for handling reverse lookups on IP + addresses that are not unique (e.g., RFC 1918 addresses). This + document describes modifications to the deployment and use of AS112 + infrastructure that will allow zones to be added and dropped much + more easily, using DNAME resource records. + + This approach makes it possible for any DNS zone administrator to + sink traffic relating to parts of the global DNS namespace under + their control to the AS112 infrastructure without coordination with + the operators of AS112 infrastructure. + +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. + + 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/rfc7535. + + + + + + + + + + +Abley, et al. Informational [Page 1] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +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. Introduction ....................................................3 + 2. Design Overview .................................................4 + 3. AS112 Operations ................................................5 + 3.1. Extensions to Support DNAME Redirection ....................5 + 3.2. Redirection of Query Traffic to AS112 Servers ..............5 + 4. Continuity of AS112 Operations ..................................6 + 5. Candidate Zones for AS112 Redirection ...........................6 + 6. DNAME Deployment Considerations .................................7 + 7. IAB Statement Regarding This .ARPA Request ......................8 + 8. IANA Considerations .............................................8 + 8.1. Address Assignment .........................................8 + 8.2. Hosting of AS112.ARPA .....................................10 + 8.3. Delegation of AS112.ARPA ..................................10 + 9. Security Considerations ........................................10 + 10. References ....................................................11 + 10.1. Normative References .....................................11 + 10.2. Informative References ...................................11 + Appendix A. Assessing Support for DNAME in the Real World .........13 + A.1. Methodology ................................................13 + A.2. Results ....................................................15 + Acknowledgements ..................................................16 + Authors' Addresses ................................................16 + + + + + + + + + + + + +Abley, et al. Informational [Page 2] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +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) 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. + + Prior to implementation of this technique, the AS112 project did not + accommodate the addition and removal of DNS zones elegantly. Since + additional zones of definitively local significance are known to + exist, this presents a problem. This document describes + modifications to the deployment and use of AS112 infrastructure that + will allow zones to be added and dropped much more easily. + + The AS112 project is described in detail in [RFC7534]. + + The AS112 nameservers (PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and + BLACKHOLE-2.IANA.ORG) are required to answer authoritatively for each + and every zone that is delegated to them. If a zone is delegated to + AS112 nameservers without those nameservers being configured ahead of + time to answer authoritatively for that zone, there is a detrimental + impact on clients following referrals for queries within that zone. + This misconfiguration is colloquially known as a "lame delegation". + + AS112 nameserver operators are only loosely coordinated, and hence + adding support for a new zone (or, correspondingly, removing support + for a zone that is no longer delegated to the AS112 nameservers) is + difficult to accomplish with accuracy. Testing AS112 nameservers + remotely to see whether they are configured to answer authoritatively + for a particular zone is similarly challenging, since AS112 nodes are + distributed using anycast [RFC4786]. + + + + + +Abley, et al. Informational [Page 3] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + + This document defines a more flexible approach for sinking queries on + AS112 infrastructure that can be deployed alongside unmodified, + existing AS112 nodes. Instead of delegating additional zones + directly to AS112 nameservers, DNAME [RFC6672] redirection is used. + This approach has the advantage that query traffic for arbitrary + parts of the namespace can be directed to AS112 servers without those + servers having to be reconfigured every time a zone is added or + removed. + + This approach makes it possible for any DNS zone administrator to + sink traffic relating to parts of the global DNS namespace under + their control to the AS112 infrastructure without coordination with + the operators of AS112 infrastructure. + +2. Design Overview + + A new zone, EMPTY.AS112.ARPA, is delegated to a single nameserver + BLACKHOLE.AS112.ARPA (IPv4 address 192.31.196.1, IPv6 address + 2001:4:112::1). + + The IPv4 address 192.31.196.1 has been selected from the prefix + assigned by the IANA such that the address is coverable by a single + IPv4 /24 prefix, and that no other address covered by that prefix is + in use. The IPv6 address 2001:4:112::1 has been similarly assigned + such that no other address within a covering /48 is in use. This + addressing plan accommodates the anycast distribution of the + BLACKHOLE.AS112.ARPA service using a single IPv4 service prefix and a + single IPv6 service prefix. See [RFC4786] for more discussion of + anycast service distribution; see Section 8 for the specific actions + completed by IANA per this document. + + Some or all of the existing AS112 nodes should be extended to support + these new nameserver addresses and to host the EMPTY.AS112.ARPA zone. + See [RFC7534] for revised guidance to AS112 server operators. + + Each part of the DNS namespace for which it is desirable to sink + queries at AS112 nameservers should be redirected to the + EMPTY.AS112.ARPA zone using DNAME [RFC6672]. See Section 3.2 for + guidance to zone administrators. + + + + + + + + + + + + +Abley, et al. Informational [Page 4] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +3. AS112 Operations + +3.1. Extensions to Support DNAME Redirection + + Guidance to operators of AS112 nodes is extended to include + configuration of the 192.31.196.1 and 2001:4:112::1 addresses, and + the corresponding announcement of covering routes for those + addresses, and to host the EMPTY.AS112.ARPA zone. + + IPv4-only AS112 nodes should only configure the 192.31.196.1 + nameserver address; IPv6-only AS112 nodes should only configure the + 2001:4:112::1 nameserver address. + + It is only necessary for a single AS112 server operator to implement + these extensions for this mechanism to function as intended. It is + beneficial if many more than one AS112 server operator makes these + changes, however, since that provides for greater distribution and + capacity for the nameservers serving the EMPTY.AS112.ARPA zone. It + is not necessary for all AS112 server operators to make these changes + for the mechanism to be viable. + + Detailed instructions for the implementation of these extensions are + included in [RFC7534]. + +3.2. Redirection of Query Traffic to AS112 Servers + + Once the EMPTY.AS112.ARPA zone has been deployed using the + nameservers described in Section 3.1, redirections may be installed + in the DNS namespace for queries that are intended to be answered by + the AS112 infrastructure. + + For example, reverse queries corresponding to TEST-NET-1 + (192.0.2.0/24) [RFC5737] could be redirected to AS112 nameservers by + installing a DNAME resource record in the 192.IN-ADDR.ARPA zone, as + illustrated in Figure 1. + + $ORIGIN 192.IN-ADDR.ARPA. + ... + 2.0 IN DNAME EMPTY.AS112.ARPA. + ... + + Figure 1 + + There is no practical limit to the number of redirections that can be + configured in this fashion. Redirection of a particular part of the + namespace to EMPTY.AS112.ARPA can be removed at any time, under the + control of the administrators of the corresponding part of the DNS + namespace. No changes to deployed AS112 nodes incorporating the + + + +Abley, et al. Informational [Page 5] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + + extensions described in this document are required to support + additional redirections. A list of possible candidates for AS112 + redirection can be found in Section 5. + + DNAME resource records deployed for this purpose can be signed with + DNSSEC [RFC4033], providing a secure means of authenticating the + legitimacy of each redirection. + +4. Continuity of AS112 Operations + + Existing guidance to AS112 server operators to accept and respond to + queries directed at the PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and + BLACKHOLE-2.IANA.ORG nameservers should continue to be followed, and + no changes to the delegation of existing zones hosted on AS112 + servers should occur. These measures are intended to provide + continuity of operations for zones currently delegated to AS112 + servers and avoid any accidental client impact due to the changes + proposed in this document. + + Once it has become empirically and quantitatively clear that the + EMPTY.AS112.ARPA zone is well hosted to the extent that it is thought + that the existing, unmodified AS112 servers host 10.IN-ADDR.ARPA, the + decision might be made to replace the delegation of those [RFC1918] + zones with DNAME redirection. Once implemented, the + PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG + nameservers could be retired. This document gives no such direction + to the IANA, however. + +5. Candidate Zones for AS112 Redirection + + All zones listed in [RFC6303] are candidates for AS112 redirection. + + Since no pre-provisioning is required on the part of AS112 operators + to facilitate sinking of any name in the DNS namespace by AS112 + infrastructure, this mechanism supports AS112 redirection by any zone + owner in the DNS. + + This document is simply concerned with provision of the AS112 + redirection service and does not specify that any particular AS112 + redirection be put in place. + + + + + + + + + + + +Abley, et al. Informational [Page 6] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +6. DNAME Deployment Considerations + + DNAME was specified years after the original implementations of + [RFC1035], and hence universal deployment cannot be expected. + [RFC6672] specifies a fallback mechanism that makes use of + synthesised CNAME RRSets for this reason. The expectation that + design choices in the DNAME specification ought to mitigate any lack + of deployment is reviewed below. Experimental validation of those + expectations is included in Appendix A. + + It is a fundamental design requirement of AS112 service that + responses be cached. We can safely declare DNAME support on the + authoritative server to be a prerequisite for DNAME redirection, but + the cases where individual elements in resolver chains do not support + DNAME processing deserve closer examination. + + The expected behaviour when a DNAME response is supplied to a + resolver that does not support DNAME is that the accompanying, + synthesised CNAME will be accepted and cached. Re-query frequency + will be determined by the TTLs (Time to Live) returned by the + DNAME-responding authoritative servers. + + Resolution of the CNAME target is straightforward and functions + exactly as the AS112 project has operated since it was deployed. The + negative caching [RFC2308] of the CNAME target follows the parameters + defined in the target zone, EMPTY.AS112.ARPA. This has the side + effects that all redirected names ultimately landing on an AS112 node + will be negatively cached with the same parameters, but this lack of + flexibility seems non-controversial; the effect of reducing the + negative cache TTL would be increased query volume on the AS112 node + operator concerned, and hence controls seem well aligned with + operation. + + Validating resolvers (i.e., those requesting and processing DNSSEC + [RFC4033] metadata) are required to implement DNAME and hence should + not make use of synthesised CNAME RRs. The lack of signature over a + received CNAME RR should hence not limit the ability to sign the + (DNAME) redirection point, and for those (DNAME) signatures to be + validated. + + In the case where a recursive server implements DNAME but DNAME is + not implemented in a stub resolver, CNAME synthesis will again + provide a viable path. + + DNAME support on AS112 nodes themselves is never required under this + proposal. + + + + + +Abley, et al. Informational [Page 7] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +7. IAB Statement Regarding This .ARPA Request + + With the publication of this document, the IAB approves of the + delegation of 'AS112' in the ARPA domain. Under [RFC3172], the IAB + has requested that IANA delegate and provision "AS112.ARPA" as + specified in this specification. However, the IAB does not take any + architectural or technical position about this specification. + +8. IANA Considerations + +8.1. Address Assignment + + Per this document, IANA has assigned IPv4 and IPv6 number resources + in conformance with Section 4 of [RFC2860]. + + The IANA has assigned one IPv4 /24 netblock and registered its use in + the "IANA IPv4 Special-Purpose Address Registry" [RFC6890] as + follows: + + +----------------------+-----------------+ + | Name | Value | + +----------------------+-----------------+ + | Address Block | 192.31.196.0/24 | + | | | + | Name | AS112-v4 | + | | | + | RFC | RFC 7535 | + | | | + | Allocation Date | 2014-12 | + | | | + | Termination Date | N/A | + | | | + | Source | True | + | | | + | Destination | True | + | | | + | Forwardable | True | + | | | + | Global | True | + | | | + | Reserved-by-Protocol | False | + +----------------------+-----------------+ + + + + + + + + + +Abley, et al. Informational [Page 8] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + + IANA has assigned one IPv6 /48 netblock and registered its use in the + "IANA IPv6 Special-Purpose Address Registry" [RFC6890] as follows: + + +----------------------+-----------------+ + | Name | Value | + +----------------------+-----------------+ + | Address Block | 2001:4:112::/48 | + | | | + | Name | AS112-v6 | + | | | + | RFC | RFC 7535 | + | | | + | Allocation Date | 2014-12 | + | | | + | Termination Date | N/A | + | | | + | Source | True | + | | | + | Destination | True | + | | | + | Forwardable | True | + | | | + | Global | True | + | | | + | Reserved-by-Protocol | False | + +----------------------+-----------------+ + + + + + + + + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 9] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +8.2. Hosting of AS112.ARPA + + The IANA hosts and signs the zone AS112.ARPA using nameservers and + DNSSEC signing infrastructure of their choosing, as shown in + Figure 2. SOA RDATA may be adjusted by the IANA to suit their + operational requirements. + + $ORIGIN AS112.ARPA. + $TTL 3600 + + @ IN SOA BLACKHOLE.AS112.ARPA. NOC.DNS.ICANN.ORG. ( + 1 ; serial + 10800 ; refresh + 3600 ; retry + 1209600 ; expire + 3600 ) ; negative cache TTL + + NS A.IANA-SERVERS.NET. + NS B.IANA-SERVERS.NET. + NS C.IANA-SERVERS.NET. + + BLACKHOLE A 192.31.196.1 + AAAA 2001:4:112::1 + + HOSTNAME NS BLACKHOLE + + EMPTY NS BLACKHOLE + + Figure 2 + +8.3. Delegation of AS112.ARPA + + The IANA has arranged delegation from the ARPA zone according to + normal IANA procedure for ARPA zone management, to the nameservers + used in carrying out the direction in Section 8.2. The whois contact + information for the new record is specified by the IAB under + [RFC3172]. + +9. Security Considerations + + This document presents no known additional security concerns to the + Internet. + + For security considerations relating to AS112 service in general, see + [RFC7534]. + + + + + + +Abley, et al. Informational [Page 10] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +10. References + +10.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, + . + + [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the + DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, + . + + [RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", + RFC 7534, DOI 10.17487/RFC7534, May 2015, + . + +10.2. Informative References + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + . + + [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of + Understanding Concerning the Technical Work of the + Internet Assigned Numbers Authority", RFC 2860, + DOI 10.17487/RFC2860, June 2000, + . + + [RFC3172] Huston, G., Ed., "Management Guidelines & Operational + Requirements for the Address and Routing Parameter Area + Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, + September 2001, . + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . + + [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast + Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, + December 2006, . + + + + + +Abley, et al. Informational [Page 11] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + + [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks + Reserved for Documentation", RFC 5737, + DOI 10.17487/RFC5737, January 2010, + . + + [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, + RFC 6303, DOI 10.17487/RFC6303, July 2011, + . + + [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, + "Special-Purpose IP Address Registries", BCP 153, + RFC 6890, DOI 10.17487/RFC6890, April 2013, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 12] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +Appendix A. Assessing Support for DNAME in the Real World + + To measure the extent to which the DNAME construct is supported in + the Internet, we have used an experimental technique to test the DNS + resolvers used by end hosts and derive from the test a measurement of + DNAME support within the Internet. + +A.1. Methodology + + The test was conducted by loading a user's browser with four URLs + to retrieve. The first three comprise the test setup, while the + final URL communicates the result to the experiment controller. + The URLs are: + + A http://a..dname.example.com/1x1.png? + a..dname + + B http://b.dname.example.com/1x1.png? + b..dname + + C http://c..target.example.net/1x1.png? + c..target + + D http://results.recorder.example.net/1x1.png? + results.?za=&zb=&zc= + + The A URL is designed to test the end user's capability to resolve a + name that has never been seen before, so that the resolution of this + domain name will reliably result in a query at the authoritative + nameserver. This is intended to test the use of domain names where + there is a dynamic component that also uses the DNAME construct. + + The B URL is deliberately designed to be cached by caching resolvers + that are used in the process of resolving the domain name. + + The C URL is a control URL. This is a unique URL, similar to A, but + does not refer to a DNAME structure. + + The D URL uses a static cacheable domain name. + + The value is common to the four URLs used in each + individual instance of this test but varies from test to test. The + result is that each end user is presented with a unique string. + + + + + + + + +Abley, et al. Informational [Page 13] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + + The contents of the EXAMPLE.COM, TARGET.EXAMPLE.NET, and + RECORDER.EXAMPLE.NET zones are shown in Figure 3. + + $ORIGIN EXAMPLE.COM. + ... + DNAME. IN DNAME TARGET.EXAMPLE.NET. + ... + + $ORIGIN TARGET.EXAMPLE.NET. + ... + B IN A 192.0.2.0 + * IN A 192.0.2.0 + ... + + $ORIGIN RECORDER.EXAMPLE.NET. + ... + RESULTS IN A 192.0.2.0 + ... + + Figure 3 + + The first three URLs (A, B, and C) are loaded as tasks into the + user's browser upon execution of the test's script. The script + starts a timer with each of these URLs to measure the elapsed time to + fetch the URL. The script then waits for the three fetches to + complete, or 10 seconds, whichever occurs first. The script then + loads the results of the three timers into the GET arguments of the + D URL and performs a fetch to pass these results back to the + experiment's server. + + Logs on the web server reached at RESULTS.RECORDER.EXAMPLE.NET will + include entries of the form shown in Figure 4. If any of the URLs + fail to load within 10 seconds, the D URL will report the failure as + a "null" timer value. + + GET /1x1.png?results.?za=1822&zb=1674&zc=1582 + GET /1x1.png?results.?za=null&zb=null&zc=161 + + Figure 4 + + The script has been encoded in Adobe Flash with a simple image in the + form of an online advertisement. An online advertisement network has + been used to distribute the script. The script is invoked when the + advertisement is presented in the end user's browser or application + and does not require the user to click on the supplied image in any + way. The advertisement placement parameters were set to the broadest + possible scope to sample users from across the entire Internet. + + + + +Abley, et al. Informational [Page 14] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +A.2. Results + + The test was loaded into an advertisement distributed on 2013-10-10 + and 2013-10-11. + + +--------------------+---------+------------+ + | | Count | Percentage | + +--------------------+---------+------------+ + | Recorded Results: | 338,478 | | + | | | | + | A or B Loaded: | 331,896 | 98.1% | + | | | | + | A Fail and B Fail: | 6,492 | 1.9% | + | | | | + | A Fail and B Load: | 4,249 | 1.3% | + | | | | + | A Load and B Fail: | 1,624 | 0.5% | + | | | | + | C Fail: | 9,355 | 2.8% | + +--------------------+---------+------------+ + + Table 1 + + These results indicate that at most 1.9% of tested clients use DNS + resolvers that fail to resolve a domain name that contains a DNAME + redirection. However, the failure rate of slightly lower than 3% for + the control URL indicates that the failure rate for the DNAME + construct lies within the bounds of error within the experimental + framework. We conclude that there is no evidence of a consistent + failure on the part of deployed DNS resolvers to correctly resolve a + DNAME construct. + + This experiment was conducted by Geoff Huston and George Michaelson. + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 15] + +RFC 7535 AS112 Redirection Using DNAME May 2015 + + +Acknowledgements + + The authors acknowledge the valuable contributions of Bob Harold and + other participants in the DNSOP working group in the preparation of + this document. + +Authors' Addresses + + Joe Abley + Dyn, Inc. + 103-186 Albert Street + London, ON N6A 1M1 + Canada + + Phone: +1 519 670 9327 + EMail: jabley@dyn.com + + + Brian Dickson + Twitter, Inc. + + EMail: bdickson@twitter.com + + + Warren Kumari + Google + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States + + EMail: warren@kumari.net + + + George Michaelson + APNIC + + EMail: ggm@apnic.net + + + + + + + + + + + + + + +Abley, et al. Informational [Page 16] +