Nate Sales

AS112: The global, community-operated anycast network

July 10, 2021


Most client devices on the Internet use private addresses combined with some sort of address translation to communicate with the IPv4 internet. When these clients make garbage DNS queries towards private ranges, the query will wind up getting forwarded all the way to the roots. This increases load on the root server infrastructure for no benefit to anyone involved.

RFC 7534 (AS112 Nameserver Operations) explains the problem in more detail:

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.

AS112 solves this problem by simply serving as the authoritative nameserver for these private reverse zones. The name AS112 comes from the assigned origin ASN of the DNS cluster. AS112 is especially interesting because it’s not operated by a single entity or even a select few entities like the root servers. DNS-OARC manages the ASN, but individual nodes can be deployed by anyone with help from a DNS server and BGP daemon.


I’ve been helping with the Puerto Rico Internet Exchange (PRIX) lately. I noticed that latency to AS112 was over 60ms due to a scenic route off the island and to a node near Boston.

~ # traceroute
 9 (  67.385 ms  67.382 ms  67.374 ms
10 (  68.288 ms  68.345 ms  68.280 ms
11 (  66.565 ms  66.585 ms  66.559 ms

PRIX is all about improving local connectivity on the island, so 60ms is just far too high for my liking. Let’s fix that.

AS112 Node Configuration

My stack of choice for a new AS112 node is NSD, BIRD, and Pathvector running on a Debian VM.


AS112 nodes listen on 4 address pairs:

  • ( and 2620:4f:8000::1)
  • ( and 2620:4f:8000::6)
  • ( and 2620:4f:8000::42)
  • ( and 2001:4:112::1)

RFC 7534 defines a few zone files for direct delegation and DNAME redirection of reverse zones, as well as the zone which stores TXT records unique to each AS112 node.

Direct Delegation

Direct delegation zones (RFC 1918 and RFC 3927) include:

  • through
; db.dd-empty
; Empty zone for Direct Delegation AS112 service.
@ IN SOA (1 1W 1M 1W 1W)

DNAME Redirection

RFC 7535 defines DNAME redirection for

; db.dr-empty
; Empty zone for DNAME redirection AS112 service.
@ IN SOA (1 1W 1M 1W 1W)

Node Identification

AS112 nodes identify themselves with unique TXT records, including the location and operator of the node. A LOC record can also be added if you want to get extra fancy with DNS and store the node’s precise location too.

; Unique zone file for AS112 node metadata.
@ SOA {{ domain }}. {{ email | replace('@', '.') }}. (2 1W 1M 1W 1W)
@ IN TXT "See for more information."
@ IN TXT "{{ description }}"
@ IN LOC {{ loc }}


The Pathvector config is pretty simple. We just need to announce 4 prefixes for AS112.

asn: 112
  - 2620:4f:8000::/48
  - 2001:4:112::/48
  PRIX Route Servers:
    asn: 18804
    enforce-first-as: false
    enforce-peer-nexthop: false
    - ""
    - "2620:102:b000::251"
    - ""
    - "2620:102:b000::252"


After setting up the node, establishing peering sessions with the PRIX route servers, and running a quick query to test, we can see the node is now correctly responding to DNS queries and latency has decreased to ~1ms.

~ # dig TXT | grep arpa.
;		IN	TXT	604800	IN	TXT	"See for more information."	604800	IN	TXT	"AS112 @ Puerto Rico Internet Exchange"	604800	IN	NS

~ # ping
PING (2620:4f:8000::6)) 56 data bytes
64 bytes from (2620:4f:8000::6): icmp_seq=1 ttl=64 time=0.637 ms
64 bytes from (2620:4f:8000::6): icmp_seq=2 ttl=64 time=0.706 ms
64 bytes from (2620:4f:8000::6): icmp_seq=3 ttl=64 time=0.417 ms
64 bytes from (2620:4f:8000::6): icmp_seq=4 ttl=64 time=0.638 ms
64 bytes from (2620:4f:8000::6): icmp_seq=5 ttl=64 time=0.799 ms
--- ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 57ms
rtt min/avg/max/mdev = 0.417/0.639/0.799/0.128 ms


If you’re interested in deploying an AS112 node of your own, the complete config files and Ansible roles for configuring it all can be found at