AS112: The global, community-operated anycast network

July 10, 2021

Overview

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.

Deployment

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 blackhole-1.iana.org
...
 9  bbr01-fh-0-2-0-7.bsn05.twdx.net (198.160.62.4)  67.385 ms  67.382 ms  67.374 ms
10  dcr03-fh-0-10-0-19.bsn04.twdx.net (198.160.62.203)  68.288 ms  68.345 ms  68.280 ms
11  blackhole-1.iana.org (192.175.48.6)  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.

DNS

AS112 nodes listen on 4 address pairs:

  • prisoner.iana.org (192.175.48.1 and 2620:4f:8000::1)
  • blackhole-1.iana.org (192.175.48.6 and 2620:4f:8000::6)
  • blackhole-2.iana.org (192.175.48.42 and 2620:4f:8000::42)
  • blackhole.as112.arpa (192.31.196.1 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 hostname.as112.net zone which stores TXT records unique to each AS112 node.

Direct Delegation

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

  • 10.in-addr.arpa.
  • 16.172.in-addr.arpa. through 31.172.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 254.169.in-addr.arpa.
; db.dd-empty
; Empty zone for Direct Delegation AS112 service.
$TTL 1W
@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (1 1W 1M 1W 1W)
@ IN NS blackhole-1.iana.org.
@ IN NS blackhole-2.iana.org.

DNAME Redirection

RFC 7535 defines DNAME redirection for empty.as112.arpa.

; db.dr-empty
; Empty zone for DNAME redirection AS112 service.
$TTL 1W
@ IN SOA blackhole.as112.arpa. noc.dns.icann.org. (1 1W 1M 1W 1W)
@ IN NS blackhole.as112.arpa.

Node Identification

AS112 nodes identify themselves with unique hostname.as112.net 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.

; db.hostname.as112.net
; Unique zone file for AS112 node metadata.
$TTL 1W
@ SOA {{ domain }}. {{ email | replace('@', '.') }}. (2 1W 1M 1W 1W)
@ IN NS blackhole-1.iana.org.
@ IN NS blackhole-2.iana.org.
@ IN TXT "See http://as112.net/ for more information."
@ IN TXT "{{ description }}"
@ IN LOC {{ loc }}

BGP

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

asn: 112
router-id: 204.138.0.112
prefixes:
  - 192.175.48.0/24
  - 192.31.196.0/24
  - 2620:4f:8000::/48
  - 2001:4:112::/48
peers:
  PRIX Route Servers:
    asn: 18804
    neighbors:
    - "204.138.0.251"
    - "2620:102:b000::251"
    - "204.138.0.252"
    - "2620:102:b000::252"

Validation

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 @blackhole-1.iana.org TXT hostname.as112.arpa | grep arpa.
;hostname.as112.arpa.		IN	TXT
hostname.as112.arpa.	604800	IN	TXT	"See http://as112.net/ for more information."
hostname.as112.arpa.	604800	IN	TXT	"AS112 @ Puerto Rico Internet Exchange"
hostname.as112.arpa.	604800	IN	NS	blackhole.as112.arpa.

~ # ping blackhole-1.iana.org
PING blackhole-1.iana.org(blackhole-1.iana.org (2620:4f:8000::6)) 56 data bytes
64 bytes from blackhole-1.iana.org (2620:4f:8000::6): icmp_seq=1 ttl=64 time=0.637 ms
64 bytes from blackhole-1.iana.org (2620:4f:8000::6): icmp_seq=2 ttl=64 time=0.706 ms
64 bytes from blackhole-1.iana.org (2620:4f:8000::6): icmp_seq=3 ttl=64 time=0.417 ms
64 bytes from blackhole-1.iana.org (2620:4f:8000::6): icmp_seq=4 ttl=64 time=0.638 ms
64 bytes from blackhole-1.iana.org (2620:4f:8000::6): icmp_seq=5 ttl=64 time=0.799 ms
^C
--- blackhole-1.iana.org 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

Conclusion

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 https://github.com/natesales/as112/.