RFC 6304
AS112 Nameserver Operations
Okay bestie, let's talk about RFC 6304 🎀✨ It's AS112 Nameserver Operations, and it's giving infrastructure glow-up 💅
Who made it: J. Abley (ICANN) and W. Maton (NRC-CNRC) 🫶 It's an Informational doc (ISSN 2070-1721), published July 2011 🌸 The title block doesn't list anything it obsoletes or updates, so nothing to flag there 💜
Abstract ✨
Okay so, tons of sites on the Internet use IPv4 addresses that aren't globally unique 😭 The addresses in [RFC1918] are the classic example, reserved for private use inside individual sites 🏠
Devices in those places can occasionally send DNS queries (the so-called "reverse lookups") for those private-use addresses 👀 Since those addresses only mean something locally, it's good practice for site admins to make sure those queries get answered locally 🧚 But honestly? It's not rare for those queries to just follow the normal delegation path in the public DNS instead, which is a whole mess 💀
Public DNS servers literally can't give useful answers to these queries 🙈 Plus, with private-use addresses everywhere and the Internet just keeps growing, the volume is huge and climbing 📈 The AS112 project is the fix: a distributed sink for these queries, so the load on the IN-ADDR.ARPA authoritative servers goes down 🦋 It's named after the Autonomous System Number (ASN) that got assigned to it 👑
This doc walks through the steps to install a new AS112 node and gives advice on running one 🔥
Status of This Memo
This document is not an Internet Standards Track specification; it's published for informational purposes 🌈
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you're curious 🤓
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6304 💖
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💅
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date it was published 📜 Please read these carefully, because they describe your rights and restrictions for this document 🙏 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🎀
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🕰️ The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process ⚠️ Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 🚫 The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 4
3. Installation of a New Node . . . . . . . . . . . . . . . . . . 5
3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 5
3.2. Topological Location . . . . . . . . . . . . . . . . . . . 5
3.3. Operating System and Host Considerations . . . . . . . . . 5
3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 6
3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Testing a Newly Installed Node . . . . . . . . . . . . . . 11
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 12
5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 12
6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 171. Introduction ✨
Okay so, lots of sites on the Internet use IPv4 addresses that aren't globally unique 🌸 The example here is the addresses set aside in [RFC1918] for private use within individual sites 🏠
Devices in these environments can occasionally send Domain Name System (DNS) [RFC1034] queries (the so-called "reverse lookups") for those private-use addresses 👀 Since those addresses only have local significance, it's good practice for site administrators to make sure these queries get answered locally [RFC6303] 🧚 Still, it's not uncommon for the queries to follow the normal delegation path in the public DNS instead of being answered inside the site 💀
Public DNS servers can't give useful answers to these queries 🙈 On top of that, private-use addresses are deployed everywhere and the Internet keeps growing, so the volume of these queries is large and getting bigger 📈 The AS112 project wants to provide a distributed sink for them, to reduce the load on the IN-ADDR.ARPA authoritative servers [RFC5855] 🦋
The AS112 project is a loosely coordinated group of independently operated nameservers 🫶 Each nameserver works as a single node in an AS112 anycast cloud [RFC4786] and is set up to answer authoritatively for a particular set of nominated zones 💜
The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it 👑
2. AS112 DNS Service
2.1. Zones
AS112 nameservers answer authoritatively for the following zones, which match the [RFC1918] private-use netblocks 🎀
10.IN-ADDR.ARPA16.172.IN-ADDR.ARPA,17.172.IN-ADDR.ARPA, ...,31.172.IN-ADDR.ARPA168.192.IN-ADDR.ARPA
They also answer for this one, which matches the "link local" netblock 169.254.0.0/16 listed in [RFC5735] 🧚
254.169.IN-ADDR.ARPA
To help spot AS112 anycast nodes, each node also answers authoritatively for the zone HOSTNAME.AS112.NET 🔍
Check out Section 3.5 for the recommended contents of all these zones 📚
It's possible that other zones matching private-use infrastructure will get delegated to AS112 servers in the future 🔮 There's a list of the zones AS112 servers answer authoritatively for, maintained at http://www.as112.net/ 🌈
2.2. Nameservers
The zones listed in Section 2.1 are delegated to the two nameservers BLACKHOLE-1.IANA.ORG (192.175.48.6) and BLACKHOLE-2.IANA.ORG (192.175.48.42) 🖤
The server PRISONER.IANA.ORG (192.175.48.1) is also listed in the MNAME field of the SOA records of the IN-ADDR.ARPA zones served by AS112 nameservers 👀 It mostly gets dynamic update queries 💅
The addresses of all these nameservers are covered by the single IPv4 prefix 192.175.48.0/24 🌸
3. Installation of a New Node
3.1. Useful Background Knowledge
Setting up an AS112 node is relatively straightforward 🍓 That said, experience in these general areas could be super helpful:
- inter-domain routing with BGP [RFC4271];
- DNS authoritative server operations; and
- anycast [RFC4786] distribution of DNS services.
3.2. Topological Location
AS112 nodes can be located anywhere on the Internet 🌍 If a node is meant to be a public service for the Internet community (as opposed to private use), it may be really worth picking a spot that's easy and cheap to reach from multiple providers, like an Internet Exchange Point 💜
AS112 nodes can advertise their service prefix to BGP peers for local use (kind of like a normal peering relationship between two providers) or for global use (kind of like a customer relationship with one or more providers) 🦋
It's good operational practice to tell the community of users who might fall within reach of a new AS112 node before you install it 📣 At an Internet Exchange, local mailing lists usually exist for exactly this kind of announcement 📬 For nodes meant to be globally reachable, coordinating with other AS112 operators is highly recommended 🫶 Also see Section 5 ✨
3.3. Operating System and Host Considerations
The examples in this document are based on UNIX and UNIX-like operating systems, but other operating systems exist that work fine for building an AS112 node 💻
The chosen platform should include either support for cloned loopback interfaces or the ability to bind multiple addresses to a single loopback interface 🔁 The addresses of the nameservers listed in Section 2.2 will be configured on these interfaces so the DNS software can respond to queries properly 🎯
A host set up as an AS112 anycast node should be dedicated to that job and should not be used to provide other services at the same time 🛑 This is because AS112 nodes have been seen to attract unpredictable (and occasionally high) traffic levels 😭
⚠️ Heads up: the system startup scripts should be arranged so the various AS112-related components start automatically after a reboot. The order matters too: routing software startup should follow DNS software startup, and DNS software startup should follow loopback interface configuration 🔄
Wrapper scripts or other arrangements should be used so the anycast service prefix for AS112 is not advertised while either the anycast addresses aren't configured or the DNS software isn't running 🙅♀️🫶
3.4. Routing Software
Okay so AS112 nodes tell the rest of the Internet they exist using BGP [RFC4271] 🌐✨ each AS112 node is a BGP speaker and announces the prefix 192.175.48.0/24 to the Internet with origin AS 112 (see also Section 2.2) 🦋
The examples here are based on the Quagga Routing Suite [QUAGGA] running on Linux 💻 but other software packages exist that also give AS112 nodes suitable BGP support 🎀
The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides BGP support 💖 In this example the router ID is 203.0.113.1, and the AS112 node peers with external peers 192.0.2.1 and 192.0.2.2 🌸 Note that the local AS number is 112, and the service prefix originated from the AS112 node is 192.175.48.0/24 💅
! bgpd.conf
!
hostname as112-bgpd
password <something>
enable password <supersomething>
!
! Note that all AS112 nodes use the local Autonomous System
! Number 112, and originate the IPv4 prefix 192.175.48.0/24.
! All other addresses shown below are illustrative, and
! actual numbers will depend on local circumstances.
!
router bgp 112
bgp router-id 203.0.113.1
network 192.175.48.0
neighbor 192.0.2.1 remote-as 64496
neighbor 192.0.2.1 next-hop-self
neighbor 192.0.2.1 prefix-list AS112 out
neighbor 192.0.2.1 filter-list 1 out
neighbor 192.0.2.2 remote-as 64497
neighbor 192.0.2.2 next-hop-self
neighbor 192.0.2.2 prefix-list AS112 out
neighbor 192.0.2.2 filter-list 1 out
!
ip prefix-list AS112 permit 192.175.48.0/24
!
ip as-path access-list 1 permit ^$The configuration above includes a double-blinded restriction 🙈 on what the AS112 node shall advertise to the pair of BGP neighbors 👀 Firstly, the prefix-list "AS112", which only contains the service prefix 192.175.48.0/24, shall be advertised 🧚 Secondly, the "ip as-path access-list 1" statement contains a one-line regular expression that permits only the local AS number (112 in this case) and no other to be advertised as well 🍓 Both statements prevent the node from becoming a transit router 🙅♀️ Equivalent restrictions using other BGP implementations should be utilised ✨
The "zebra.conf" file is required to provide integration between protocol daemons (bgpd, in this case) and the kernel 🫶
! zebra.conf
!
hostname as112
password <something>
enable password <supersomething>
!
interface lo
!
interface eth0
!3.5. DNS Software
Although the queries received by AS112 nodes are definitively misdirected 🙃 it is important that they be answered in a manner that is accurate and consistent 💜 For this reason, AS112 nodes operate as fully functional and standards-compliant DNS authoritative servers [RFC1034], and hence require DNS software 🔥
Examples in this document are based on ISC BIND9 [BIND], but other DNS software exists that is suitable for use in construction of an AS112 node 🌈
The following is a sample BIND9 "named.conf" file for a dedicated AS112 server 🎀 Note that the nameserver is configured to act as an authoritative-only server (i.e., recursion is disabled) 💅 The nameserver is also configured to listen on the various AS112 anycast nameserver addresses, as well as its local addresses ✨
// named.conf
// global options
options {
listen-on {
127.0.0.1; // localhost
// The following address is node-dependent and should be set to
// something appropriate for the new AS112 node.
203.0.113.1; // local address (globally unique, unicast)
// the following addresses correspond to AS112 addresses, and
// are the same for all AS112 nodes
192.175.48.1; // prisoner.iana.org (anycast)
192.175.48.6; // blackhole-1.iana.org (anycast)
192.175.48.42; // blackhole-2.iana.org (anycast)
};
directory "/var/named";
recursion no; // authoritative-only server
query-source address *;
};
// Log queries, so that when people call us about unexpected
// answers to queries they didn't realise they had sent, we
// have something to talk about. Note that activating this
// has the potential to create high CPU load and consume
// enormous amounts of disk space.
logging {
channel "querylog" {
file "/var/log/query.log" versions 2 size 500m;
print-time yes;
};
category queries { querylog; };
};
// RFC 1918
zone "10.in-addr.arpa" { type master; file "db.empty"; };
zone "16.172.in-addr.arpa" { type master; file "db.empty"; };
zone "17.172.in-addr.arpa" { type master; file "db.empty"; };
zone "18.172.in-addr.arpa" { type master; file "db.empty"; };
zone "19.172.in-addr.arpa" { type master; file "db.empty"; };
zone "20.172.in-addr.arpa" { type master; file "db.empty"; };
zone "21.172.in-addr.arpa" { type master; file "db.empty"; };
zone "22.172.in-addr.arpa" { type master; file "db.empty"; };
zone "23.172.in-addr.arpa" { type master; file "db.empty"; };
zone "24.172.in-addr.arpa" { type master; file "db.empty"; };
zone "25.172.in-addr.arpa" { type master; file "db.empty"; };
zone "26.172.in-addr.arpa" { type master; file "db.empty"; };
zone "27.172.in-addr.arpa" { type master; file "db.empty"; };
zone "28.172.in-addr.arpa" { type master; file "db.empty"; };
zone "29.172.in-addr.arpa" { type master; file "db.empty"; };
zone "30.172.in-addr.arpa" { type master; file "db.empty"; };
zone "31.172.in-addr.arpa" { type master; file "db.empty"; };
zone "168.192.in-addr.arpa" { type master; file "db.empty"; };
// RFC 5735
zone "254.169.in-addr.arpa" { type master; file "db.empty"; };
// Also answer authoritatively for the HOSTNAME.AS112.NET zone,
// which contains data of operational relevance.
zone "hostname.as112.net" {
type master;
file "db.hostname.as112.net";
};The "db.empty" file follows, below 📜 This is the source data used to populate all the IN-ADDR.ARPA zones listed in Section 2.1 🌷 Note that the RNAME specified in the SOA record corresponds to hostmaster@root-servers.org, a suitable email address for receiving technical queries about these zones 📬
; db.empty
;
; Empty zone for AS112 server.
;
$TTL 1W
@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (
1 ; serial number
1W ; refresh
1M ; retry
1W ; expire
1W ) ; negative caching TTL
;
NS blackhole-1.iana.org.
NS blackhole-2.iana.org.
;
; There should be no other resource records included in this zone.
;
; Records that relate to RFC 1918-numbered resources within the
; site hosting this AS112 node should not be hosted on this
; nameserver.The "db.hostname.as112.net" file follows, below 🎀 This zone contains various resource records that provide operational data to users for troubleshooting or measurement purposes 🔍 the data should be edited to suit local circumstances 💖 Note that the response to the query "HOSTNAME.AS112.NET IN TXT" should fit within a 512-octet DNS/UDP datagram: i.e., it should be available over UDP transport without requiring EDNS0 support 🧚
The optional LOC record [RFC1876] included in the zone apex provides information about the geospatial location of the node 🌍
; db.hostname.as112.net
;
$TTL 1W
@ SOA server.example.net. admin.example.net. (
1 ; serial number
1W ; refresh
1M ; retry
1W ; expire
1W ) ; negative caching TTL
;
NS blackhole-2.iana.org.
NS blackhole-1.iana.org.
;
TXT "Name of Facility or similar" "City, Country"
TXT "See http://www.as112.net/ for more information."
;
LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m3.6. Testing a Newly Installed Node
The BIND9 tool "dig" can be used to retrieve the TXT resource records associated with the domain "HOSTNAME.AS112.NET" 🔎 directed at one of the AS112 anycast nameserver addresses 🎯 Continuing the example from above, the response received should indicate the identity of the AS112 node that responded to the query 🫶 See Section 3.5 for more details about the resource records associated with "HOSTNAME.AS112.NET" 💅
% dig @prisoner.iana.org hostname.as112.net txt +short +norec
"Name of Facility or similar" "City, Country"
"See http://www.as112.net/ for more information."
%If the response received indicates a different node is being used, then there is probably a routing problem to solve 🗺️ If there is no response received at all, there might be a host or nameserver problem 🤔 Judicious use of tools such as traceroute and consultation of BGP looking glasses might be useful in troubleshooting 🔧
Note that an appropriate set of tests for a new server will include queries sent from many different places within the expected service area of the node 🌍 using both UDP and TCP transport, and exercising all three AS112 anycast nameserver addresses 🦋
4. Operations ⚙️
4.1. Monitoring
AS112 nodes should be monitored to ensure they are functioning correctly, just as with any other production service 👀 An AS112 node that stops answering queries correctly can cause failures and timeouts in unexpected places and can lead to failures in dependent systems that can be difficult to troubleshoot 😭
4.2. Downtime
An AS112 node that needs to go off-line (e.g., for planned maintenance or as part of the diagnosis of some problem) should stop advertising the AS112 service prefix to its BGP peers 🛑 This can be done by shutting down the routing software on the node altogether or by causing the routing system to withdraw the route 🌙
Withdrawing the service prefix is important in order to avoid blackholing query traffic in the event that the DNS software on the node is not functioning normally 🫣
4.3. Statistics and Measurement
Use of the AS112 node should be measured in order to track long-term trends, identify anomalous conditions, and ensure that the configuration of the AS112 node is sufficient to handle the query load 📊
Examples of free monitoring tools that might be useful to operators of AS112 nodes include:
- bindgraph [BINDGRAPH] 📈
- dnstop [DNSTOP] 🧐
- DSC [DSC] 💜
5. Communications 📣
It is good operational practice to notify the community of users that may fall within the reach of a new AS112 node before it is installed 💌 At Internet Exchanges, local mailing lists usually exist to facilitate such announcements 🎀
For nodes that are intended to be globally reachable, coordination with other AS112 operators is especially recommended 🫶 The mailing list <as112-ops@lists.dns-oarc.net> is operated for this purpose 📮
Information pertinent to AS112 operations is maintained at <http://www.as112.net/> 🌐
Information about an AS112 node should also be published within the DNS, within the "HOSTNAME.AS112.NET" zone 🧚 See Section 3.5 for more details ✨
6. On the Future of AS112 Nodes 🔮
okay so the recommended practice for operators of recursive nameservers is to answer queries for zones served by AS112 nodes locally, so those queries never get a chance to reach AS112 servers [RFC6303]. ngl, the operational experience so far doesn't show an observable trend toward people actually doing this 💀
It is expected that some DNS software vendors will include default configuration that implements measures like the ones in [RFC6303]. If that software gets widely deployed, it's reasonable to assume the query load hitting AS112 nodes will decrease. It's still safe to assume it won't drop to zero, though, so AS112 nodes will keep providing a useful service for the foreseeable future 🫶
There may be a requirement in the future for AS112 nodes to answer for their current set of zones over IPv6 transport. That would mean assigning a matching IPv6 netblock to use as an anycast service prefix 🧚
There may also be a requirement in the future for AS112 nodes to serve additional zones or stop serving particular zones they currently serve. Changes like that would be widely announced in operational forums and published at http://www.as112.net/ 📣
7. IANA Considerations 🎀
The AS112 nameservers are all named under the domain IANA.ORG (see Section 2.2). However, the anycast infrastructure itself is run by a loosely coordinated, diverse mix of organisations across the Internet, so it is not an IANA function 🌍
The Autonomous System Number 112 and the IPv4 prefix 192.175.48.0/24 were assigned by ARIN.
8. Security Considerations 🚨
Okay, this section is serious, so let's go 😤
Hosts should never normally send queries to AS112 servers. Queries about private-use addresses should be answered locally within a site. Hosts that send queries to AS112 servers may well leak information about private infrastructure to the public network, and that could be a real security risk. This risk is totally separate from whether or not these zones have authoritative servers in the public DNS infrastructure, though.
Queries that AS112 servers answer are usually unintentional, which means the responses are usually unexpected too. Unexpected inbound traffic can trigger intrusion detection systems or firewall alerts. Operators of AS112 servers should be ready to hear from operators of remote infrastructure who think their security has been violated. If you're one of those people who wrongly believes AS112 node responses are an attack on your infrastructure, the advice you need is in [RFC6305] 😭
The deployment of AS112 nodes is very loosely coordinated compared to other services distributed using anycast. That makes a malicious compromise of an AS112 node, and tampering with the data it serves, harder to detect, because there's no central management. Changing the responses to queries an AS112 node receives might influence how the sending hosts behave, so a compromise like that could be used as an attack vector against private infrastructure. Yikes 💀
Operators of AS112 should take appropriate measures to make sure AS112 nodes are protected from compromise, the same way you'd protect 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 how distributed and loosely coordinated the AS112 service is, those zones could only be signed if the private key material were effectively public, which would cancel out any security benefit from using those keys 🙈
9. Acknowledgements 💜
The authors would like to thank Bill Manning, John Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes, S. Moonesamy, and Mehmet Akcin for helping with this document. Iconic squad 👑
10. References 📚
10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak,
"Root Name Server Operational Requirements", BCP 40,
RFC 2870, June 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006.10.2. Informative References
[BIND] Internet Systems Consortium, "BIND",
<http://www.isc.org/software/BIND/>.
[BINDGRAPH] Delaurenti, M. and M. d'Itri, "bindgraph",
<http://www.linux.it/~md/software/>.
[DNSTOP] The Measurement Factory, "Dnstop: Stay on Top of Your
DNS Traffic",
<http://dns.measurement-factory.com/tools/dnstop/>.
[DSC] The Measurement Factory, "Dsc: A DNS Statistics
Collector",
<http://dns.measurement-factory.com/tools/dsc/>.
[QUAGGA] "Quagga Software Routing Suite",
<http://www.quagga.net>.
[RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
Means for Expressing Location Information in the Domain
Name System", RFC 1876, January 1996.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and
IPv6 Reverse Zones", BCP 155, RFC 5855, May 2010.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, July 2011.
[RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by
PRISONER.IANA.ORG!", RFC 6305, July 2011.Appendix A. History 🕰️
Widespread use of the private address blocks listed in [RFC1918] followed that document's publication in 1996. Back then, the IN-ADDR.ARPA zone was served by root servers 🌱
The idea of off-loading IN-ADDR.ARPA queries about [RFC1918] addresses from the root nameservers was first proposed by Bill Manning and John Brown 💡
Later, a private meeting of root server operators proposed using anycast to distribute authoritative DNS service for [RFC1918] IN-ADDR.ARPA zones 🤝
ARIN provided an IPv4 prefix for the anycast service, plus autonomous system number 112 to originate that prefix. That assignment is where the project got its name 🎉
In 2002, the first AS112 anycast nodes were deployed 🚀
In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers to a new set of servers, operated independently by AfriNIC, APNIC, ARIN, ICANN, LACNIC, and the RIPE NCC, and named according to [RFC5855] ✨
The anycast nameservers in the AS112 project added to the operational experience of anycast DNS services. You could call it a precursor to the anycast distribution of other authoritative DNS servers in later years, like various root servers 👑
Authors' Addresses 💌
Joe Abley
ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
US
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
William F. Maton Sotomayor
National Research Council of Canada
1200 Montreal Road
Ottawa, ON K1A 0R6
Canada
Phone: +1 613 993 0880
EMail: wmaton@ryouko.imsb.nrc.ca📦 where this page comes from
- ietf: rfc6304 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms