Taking the Load Off the DNS Root System
Cloudflare has joined the AS112 project, a community-operated anycast deployment of DNS servers that answer reverse DNS lookup queries for private-use IP addresses — queries that have no legitimate answer in the public DNS and create significant unwanted traffic on the Internet. With Cloudflare's global network footprint, this distributed public service gains additional capacity for handling these junk queries.
To understand why AS112 exists, it helps to understand the problem it solves. IP addresses reserved for private use (as defined in RFC 1918) are common inside local networks — for example, a home router might assign a device the address 192.168.1.42. These addresses have only local significance and are never meant to traverse the public Internet; NAT translates them when devices need to reach external resources.
Despite this, devices and programs in private environments sometimes issue reverse DNS lookups for these addresses. A reverse lookup asks the DNS whether a name is associated with a given IP address, typically to help administrators and researchers understand network paths. PTR records store these mappings with segments reversed and appended with .in-addr.arpa for IPv4 (or .ip6.arpa for IPv6). For instance, the IP address 192.0.2.1 corresponds to the PTR record 1.2.0.192.in-addr.arpa.
There is no useful answer for such queries in the public DNS — they concern addresses with no global meaning. When they leak out of private networks, they follow the normal delegation path and end up at the root servers serving the IN-ADDR.ARPA zone. Over time, as private address usage and Internet traffic grew, this junk query load on root infrastructure became a concern. The AS112 project was launched to provide a dedicated target for these queries, using blackhole servers as the authoritative name servers for reverse lookups of the private-use address blocks 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and the link-local block 169.254.0.0/16.
The project takes its name from AS number 112, provided by the American Registry for Internet Numbers. It started with a small subset of root server operators and has since grown to include many volunteer name server operators who run anycasted instances of the blackhole servers. The first two servers were blackhole-1.iana.org and blackhole-2.iana.org. A reverse lookup for a private-use address against these servers returns NXDOMAIN — the name does not exist.
Two Ways to Answer
AS112 nodes operate in one of two modes, each defined by an RFC.
Direct Delegation
The original approach, defined in RFC 7534, delegates reverse lookup zones directly to the blackhole servers. RFC 7534 specifies a static set of zones these servers must answer authoritatively — one zone for 10.in-addr.arpa, sixteen for the 16–31.172.in-addr.arpa range, plus 168.192.in-addr.arpa and 254.169.in-addr.arpa (the latter corresponding to the IPv4 link-local block). The zone files themselves are minimal, containing essentially just the required SOA and NS records. The direct delegation name servers are addressed via the IPv4 prefix 192.175.48.0/24 and IPv6 prefix 2620:4f:8000::/48.
DNAME Redirection
Because adding new zones to the direct delegation approach requires reconfiguring all AS112 servers — a challenge in a loosely-coordinated system — RFC 7535 introduced an alternative using DNAME records. A DNAME record (RFC 6672) creates an alias for an entire subtree of the domain name tree, unlike a CNAME which aliases a single name. When a name server receives a query for a name in that subtree, it substitutes the owner name with the alias target and retries the lookup with the substituted name.
RFC 7535 specifies a special zone, empty.as112.arpa, to support this redirection. When new zones need to be added, their parents set up DNAME records pointing to empty.as112.arpa — no reconfiguration of existing AS112 nodes required. Since the blackhole servers themselves don't need to understand DNAME records, but do need to serve the target zone, this zone was delegated to a new blackhole server, blackhole.as112.arpa, using addresses 192.31.196.1 and 2001:4:112::1. Queries involving DNAME redirection only land on nodes operated by entities that also set up this new server, preserving the loose coordination of the overall system. The relevant address prefixes are 192.31.196.0/24 and 2001:4:112::/48.
Node Identification
RFC 7534 also recommends that every AS112 node host two metadata zones: hostname.as112.net and hostname.as112.arpa. These zones contain only TXT records, providing identification information about a given node. Cloudflare servers host zone files following this pattern.
$ORIGIN hostname.as112.net.
;
$TTL 604800
;
@ IN SOA ns3.cloudflare.com. dns.cloudflare.com. (
1 ; serial number
604800 ; refresh
60 ; retry
604800 ; expire
604800 ) ; negative caching TTL
;
NS blackhole-1.iana.org.
NS blackhole-2.iana.org.
;
TXT "Cloudflare DNS, <DATA_CENTER_AIRPORT_CODE>"
TXT "See http://www.as112.net/ for more information."
;
$ORIGIN hostname.as112.arpa.
;
$TTL 604800
;
@ IN SOA ns3.cloudflare.com. dns.cloudflare.com. (
1 ; serial number
604800 ; refresh
60 ; retry
604800 ; expire
604800 ) ; negative caching TTL
;
NS blackhole.as112.arpa.
;
TXT "Cloudflare DNS, <DATA_CENTER_AIRPORT_CODE>"
TXT "See http://www.as112.net/ for more information."
;Why This Matters
The AS112 project reduces unwanted load on the public DNS infrastructure, which is critical to maintaining Internet stability and efficiency. In the seven days before Cloudflare's announcement, for example, Cloudflare's 1.1.1.1 resolver alone received more than 98 billion reverse DNS queries for private-use addresses — all without useful answers.
Cloudflare brings one of the largest global anycast networks and DNS operations to the project. The company runs authoritative DNS for millions of Internet properties and operates the public DNS resolver 1.1.1.1. That scale of presence makes the AS112 service more resilient and more widely available to absorb misdirected queries.
A Closer Look at the Platform
Cloudflare’s AS112 service is not a standalone project. It runs on the same platform that powers 1.1.1.1, WARP, Gateway, and Oblivious DNS over HTTPS (ODoH). The core of this platform is a non-traditional DNS server, written in Rust, that combines a built-in recursive resolver with a forwarder. The server itself contains no business logic; instead, it hosts guest applications in a sandbox built on a WebAssembly runtime.
The architecture is split into four modules: a listener for incoming requests, a query router that determines resolution paths, a conductor that manages upstream message exchanges, and the sandbox environment for guest apps. Guest applications handle concrete tasks like filtering, logging, and attack mitigation. They interact with the host through APIs called hostcalls, which are conceptually similar to Linux syscalls. These calls provide functions for tasks such as fetching timestamps, looking up IP geolocation data, spawning async tasks, forwarding queries, and emitting logs or metrics.
DNS request processing is broken into phases. At each phase, sandboxed applications can register callbacks to inspect or alter the course of resolution. This design keeps the core server lean while allowing flexible, custom logic to be injected safely.
The AS112 Guest Application
The AS112 service itself is implemented as a guest application written in Rust and compiled to WebAssembly. The zones defined in RFC 7534 and RFC 7535 are loaded into memory as static zones and indexed as a tree structure. Incoming queries are answered directly by looking them up in this tree, without any recursion or forwarding.
The application manifest declares two key settings: a router setting that tells the host which queries the app should process, and a fallback_action setting that defines what happens when the app cannot handle a query. The application is compiled and deployed through a pipeline that uses Cloudflare’s Quicksilver system for worldwide asset storage and replication.
Adding the new IP prefixes did not require restarting the DNS server. Cloudflare used Tubular, a tool it previously developed, to change service addresses on the fly, routing packets for the AS112 prefixes to the correct server process. On the network side, the four AS112 IP prefixes were onboarded to Cloudflare’s Bring Your Own IP (BYOIP) product, which announces customer-owned prefixes from all Cloudflare locations globally.
Testing in Production
Before announcing the service to the public Internet, Cloudflare needed to verify that the AS112 nodes would respond correctly. The 1.1.1.1 resolver already handles over 13 billion misdirected queries per day, returning NXDOMAIN locally per the recommended practice in RFC 7534. To test the new service, Cloudflare used a dynamic rule to change how these queries are handled in designated testing locations.
phase = post-cache and qtype in { PTR } and colo in { test1 test2 } and qname-suffix in { 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa 254.169.in-addr.arpa } forward 192.175.48.6:53This rule intercepts PTR queries for the listed reverse DNS zones at the post-cache phase in specific data centers and forwards them to one of the AS112 service IPs on port 53. Since the AS112 prefixes were already provisioned in the same nodes, the service received and answered those queries.
The rule is executed by another guest application called override, which loads dynamic rules written in a DSL, parses them, and registers callbacks at the phases each rule declares. When a query matches the rule’s conditions, the designated action is executed.
Reporting and Rollout
AS112 operators are expected to share operational statistics with the community. Cloudflare collects the following metrics to fulfil this requirement: queries by type, response code, protocol, and IP version, as well as counts of queries with EDNS or DNSSEC support, and breakdowns by ASN or data center. This data will be presented on a public statistics page hosted on Cloudflare Radar; the backend API and frontend are still under development.
The AS112 prefixes were scheduled to be announced globally starting December 15, 2022. After that date, operators can run a dig command to verify that they are reaching an AS112 node operated by Cloudflare.
