RFC 7534

AS112 Nameserver Operations

📅 published May 2015, from ietf

1. Introduction ✨

okay bestie, so lots of sites on the Internet use IPv4 addresses that aren't globally unique 🌸 Think private-use addresses set aside in [RFC1918] for use inside one site. It's giving "my house, my rules" 🏠

Devices in those places sometimes send DNS [RFC1034] queries (aka "reverse lookups") about those private addresses 👀 Since those addresses only mean something locally, it's good practice for site admins to make sure those queries get answered locally [RFC6303]. But ngl, those queries often just follow the normal delegation path in the public DNS instead of getting answered inside the site 💀

Public DNS servers can't give useful answers to these queries, period 🙅‍♀️ Plus, with private-use addresses everywhere and the Internet just keeping on growing, the volume of these queries is huge and climbing 📈 The AS112 project wants to be a distributed sink for them, so the load on the IN-ADDR.ARPA authoritative servers goes down [RFC5855]. It's the main character move of DNS 🎀

The AS112 project is a loosely coordinated group of nameservers that are run independently 🧚 Each nameserver acts as one node in an AS112 anycast cloud [RFC4786], and it's set up to answer authoritatively for a specific set of chosen zones 💅

The name comes from the Autonomous System Number (ASN) that got assigned to the project (see Appendix A) 🦋

2. AS112 DNS Service 🌸

2.1. Approach 💜

2.1.1. Direct Delegation 🫶

The AS112 project currently does this thing where zones whose traffic should go to an AS112 sink get directly delegated to AS112 nameservers 📌 To match, each AS112 node is manually configured to answer properly for those zones 🛠️

This document describes that capability for the zones that were originally delegated this way 🎀 Nodes built according to the guidance here will keep serving those zones, no drama 💖

2.1.2. DNAME Redirection 🌈

[RFC7535] describes a different vibe: queries toward specific zones get redirected to an empty zone that's also hosted on AS112 servers, using DNAME [RFC6672] 🔀

The guidance in this document brings this capability in, so any zone administrator can sink query traffic in AS112 infrastructure without any changes to an AS112 node 😤✨ Iconic, honestly 👑

2.2. Zones 🗺️

For Direct Delegation AS112 service, AS112 nameservers answer authoritatively for the following zones, which line up with the [RFC1918] private-use netblocks:

  • 10.IN-ADDR.ARPA
  • 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA
  • 168.192.IN-ADDR.ARPA

They also cover the following zone, which matches the "link local" netblock 169.254.0.0/16 listed in [RFC6890]:

  • 254.169.IN-ADDR.ARPA

For DNAME redirection AS112 service, AS112 nameservers answer authoritatively for the following zone, as specified in [RFC7535]:

  • EMPTY.AS112.ARPA

To help identify AS112 anycast nodes, each node also answers authoritatively for these zones:

  • HOSTNAME.AS112.NET
  • HOSTNAME.AS112.ARPA

See Section 3.5 for the recommended contents of all these zones 📖

2.3. Nameservers 🧚

For 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) 💅

There's also the server PRISONER.IANA.ORG (192.175.48.1, 2620:4f:8000::1), which is listed in the MNAME field of the SOA records of the IN-ADDR.ARPA zones served by AS112 nameservers 🙈 It mostly handles dynamic update queries, so it's the behind-the-scenes one 🍓

All of these nameservers' addresses fall under the single IPv4 prefix 192.175.48.0/24 and the IPv6 prefix 2620:4f:8000::/48 🌸 So far, 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 🎀

For 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) 🦋 That nameserver's addresses 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 📚

Setting up an AS112 node is relatively straightforward, bestie 🥹 That said, experience in these general areas might come in handy:

  • 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 provide a public service to the Internet community (as opposed to private use), it may be a really good idea to pick a spot that's easy (and cheap!) to reach from multiple providers, like an Internet Exchange Point 🤑

AS112 nodes may advertise their service prefix to BGP peers for local use (kinda like a normal peering relationship between two providers) or for global use (kinda like a customer relationship with one or more providers) 🦋

It's good operational practice to tell the community of users that might fall within the reach of a new AS112 node before you install it 📣 At an Internet Exchange, local mailing lists usually exist to make those announcements easy 💌 For nodes that are meant to be globally reachable, coordinating with other AS112 operators is highly recommended 🫶 See also Section 5 ✨

3.3. Operating System and Host Considerations 🧚

okay bestie, the examples in this doc are all UNIX and UNIX-like vibes 💻, but other operating systems exist that are totally valid for building an AS112 node ✨

The platform you pick should have 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.3 get configured on these interfaces so the DNS software can answer queries properly 💖

A host set up as an AS112 anycast node should be dedicated to that job and should not be used to run other services at the same time 🫶 This is because AS112 nodes have been seen to attract traffic that is unpredictable and sometimes really high 😭

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. It's giving domino effect, but make it make sense 🌈

Wrapper scripts or other setups should be used to make sure the anycast service prefix for AS112 is not advertised while either the anycast addresses aren't configured or the DNS software isn't running 🙈 No advertising a service that isn't actually there, periodt 💅

3.4. Routing Software 🦋

AS112 nodes tell the Internet that their nameservers are available 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) ✨

The examples in this document are based on the Quagga Routing Suite <http://www.quagga.net> running on Linux, but other software packages exist that also give suitable BGP support for AS112 nodes 💜

The bgpd.conf file is used by Quagga's bgpd daemon, which provides the BGP support 🧚 In this example, the router ID is 203.0.113.1, and the AS112 node peers with the 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 doesn't need to configure any of the IPv6 elements that follow, and similarly, an IPv6-only AS112 node doesn't need any of the IPv4 elements 🙈 Single-stack hosts can still contribute usefully to IPv4 and IPv6 AS112 services, though, and single-stack operation is not discouraged 🦋

! 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 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
!

 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 🔒 One is a prefix filter that permits only the service prefixes, and the other is an AS_PATH filter that matches only locally originated routes. Together, these measures stop 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 <something>
enable password <supersomething>
!
interface lo
!
interface eth0
!

3.5. DNS Software ✨

okay bestie, the queries AS112 nodes receive are totally misdirected 🙈, but they still have to be answered accurately and consistently 💅. so AS112 nodes work as fully functional, standards-compliant DNS authoritative servers [RFC1034] 👑, which means they need proper DNS software 🫶

the examples in this doc are based on ISC BIND9 http://www.isc.org/software/BIND/, but other DNS software is also totally suitable for building an AS112 node 🌸

here's a sample BIND9 named.conf for a dedicated AS112 server 🎀. the nameserver is set up as authoritative-only (recursion is disabled) 🙅‍♀️, and it listens on the various AS112 anycast nameserver addresses as well as its local addresses ✨

there's also a basic logging example in the sample. AS112 operators get to decide how much logging detail they want and what type of logging to use when maintaining their node 📝. that detail can 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)

  // 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; };
};
// 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";
};

the db.dd-empty file comes right after this 🧚. it's the source data used to populate all the IN-ADDR.ARPA zones listed in Section 2.2 that support Direct Delegation AS112 service 🦋. the RNAME in the SOA record is hostmaster@root-servers.org, which is 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 is next 💖. it's the source data used to populate the EMPTY.AS112.ARPA zone that supports DNAME redirection AS112 service. the RNAME in its SOA record is 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.
;
; 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 hold various resource records that give users operational data for troubleshooting or measurement, so edit the data to suit your local circumstances 🛠️. the responses to "HOSTNAME.AS112.NET IN TXT" and "HOSTNAME.AS112.ARPA IN TXT" should fit within a 512-octet DNS/UDP datagram, which means they're available over UDP transport without requiring EDNS0 support by the client 🙌

the optional LOC record [RFC1876] in each zone apex gives the geospatial location of the node 🗺️. and 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

; 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 grab the TXT resource records tied to the names "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" 🔍. just point it at one of the AS112 anycast nameserver addresses. continuing the example from above, the response should tell you which AS112 node answered the query 🎯. check 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 shows a different node is answering, there's probably a routing problem to solve 🚦. if you get no response at all, there might be a host or nameserver problem 😬. judicious use of tools like traceroute and consulting BGP looking glasses might help you troubleshoot 🔦

one more thing 💅: an appropriate set of tests for a new server includes queries sent from many different places within the node's expected service area, 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 make sure they're functioning correctly, just like any other production service 📈. an AS112 node that stops answering queries correctly can cause failures and timeouts in unexpected places, and it can lead to failures in dependent systems that are a nightmare to troubleshoot 😭

4.2. Downtime 🌙

an AS112 node that needs to go offline (for example, for planned maintenance or while diagnosing 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 making the routing system withdraw the route 🙅‍♀️

withdrawing the service prefixes is super important 🚨 because it avoids blackholing query traffic if the DNS software on the node isn't functioning normally 💀

4.3. Statistics and Measurement ✨

okay so bestie, AS112 nodes should be measured 📊 why? to track long-term trends, spot anomalous conditions, and make sure the node's config can actually handle the query load. no vibes-only ops, we want receipts 💅

these free monitoring tools are giving operators main character energy 🦋:

and ngl, operators should also think about joining collection events as part of a bigger, coordinated effort to gather important baselines 🌈 one of these is Day in the Life <https://www.dns-oarc.net/oarc/data/ditl/>, coordinated by the DNS-OARC <https://www.dns-oarc.net/>. it's literally a group project for the whole internet and we're here for it 🫶

5. Communications 📣

it's good operational practice to tell the community of users who might fall within reach of a new AS112 node before it goes live. no surprises, bestie 🎀 at Internet Exchanges, there are usually local mailing lists that make this super easy.

for nodes meant to be globally reachable, coordination with other AS112 operators is especially recommended 👑 the mailing list <as112-ops@lists.dns-oarc.net> exists for exactly this purpose.

all the pertinent AS112 info lives at <http://www.as112.net/> 💖

information about an AS112 node should also be published in the DNS, in the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones 🧚 see Section 3.5 for more details.

and AS112 operators should be aware of the measures described in [RFC6305], and direct site administrators to them appropriately 💅

6. On the Future of AS112 Nodes 🔮

it is recommended practice for operators of recursive nameservers to answer queries for zones served by AS112 nodes locally, so queries never get the chance to reach AS112 servers [RFC6303] 🙌 real talk though, operational experience with AS112 nodes doesn't currently show an observable trend toward anyone following those recommendations. 😭

some DNS software vendors are expected to ship default configuration that implements measures like those in [RFC6303] 🌸 if that software gets widely deployed, it's reasonable to assume the query load hitting AS112 nodes will drop. BUT it's safe to assume it won't drop to zero, so AS112 nodes will keep providing a useful service for the foreseeable future ✨ they're not going anywhere, babe.

the use of DNAME redirection to provide AS112 service is brand new, so it's informed by minimal operational experience 🍓 and because DNAME means queries for many source zones could get redirected to AS112 infrastructure, there's no real opportunity for coordination. kind of a lot, honestly 💀

if DNAME redirection is successful, and there are no operational concerns, the community might well recommend retiring the original Direct Delegation AS112 service. this document makes no such recommendation, however 🦋 we're not calling that shot today.

7. IANA Considerations 📋

7.1. General

the nameservers for Direct Delegation AS112 service are all named under the domain IANA.ORG (see Section 2.3) 🎀 but the anycast infrastructure itself is run by a loosely coordinated, diverse mix of organisations across the Internet. it is not an IANA function, so don't @ them for that 😭

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 🧚 after a substantial stretch of pre-production testing by AS112 operators, the IANA added AAAA RRSets to those owner names in Section 7.2.1, so the servers can receive queries and generate responses over IPv6 transport. it's giving glow-up 💖

7.2. IANA Actions

7.2.1. IPv6 Transport for Direct Delegation AS112 Servers

the IANA 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 |
             +----------------------+------------------+

7.2.2. Registration in the Special-Purpose AS Numbers Registry

the IANA added AS112 to the "Special-Purpose AS Numbers" registry specified in [RFC7249] like this 🌸

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 added 192.175.48.0/24 to the "IANA IPv4 Special-Purpose Address Registry" specified in [RFC6890], with these fields 🍓

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 added 2620:4f:8000::/48 to the "IANA IPv6 Special-Purpose Address Registry" specified in [RFC6890], with these fields 💜

Address Block:  2620:4f:8000::/48

Name:  Direct Delegation AS112 Service

RFC:  RFC 7534

Allocation Date:  2011-05
Termination Date:  N/A

Source:  True

Destination:  True

Forwardable:  True

Global:  True

Reserved-by-Protocol:  False

8. Security Considerations 🔒

⚠️ bestie, this section is seriously important. read it properly.

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. on top of that, AS112 operators may log this information, which makes it subject to whatever security and privacy risks that might entail. these risks are orthogonal to whether or not there are authoritative servers for these zones in the public DNS infrastructure, though 🥺

queries answered by AS112 servers are usually unintentional, so it follows that the responses from AS112 servers are usually unexpected 💀 unexpected inbound traffic can set off intrusion detection systems or firewall alerts. operators of AS112 servers should be ready to be contacted by operators of remote infrastructure who believe their security has been violated 😭 advice for people who mistakenly think AS112 node responses are an attack on their infrastructure can be found in [RFC6305].

the deployment of AS112 nodes is very loosely coordinated compared to other anycast services. because of that, a malicious compromise of an AS112 node, and subversion of the data it serves, are harder to detect given the lack of central management 🕵️ and since changing the responses to queries received by AS112 nodes might influence how the hosts sending those queries behave, such a compromise could be used as an attack vector against private infrastructure. yikes, periodt.

operators of AS112 should take appropriate measures to make sure AS112 nodes are properly protected from compromise, like what would normally be used for production nameserver or network infrastructure 🛡️ the guidance for root nameservers in [RFC2870] may be instructive.

finally, the zones hosted by AS112 servers are not signed with DNSSEC [RFC4033]. given the distributed, loosely coordinated structure of AS112 service, 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 🔑 not it.

9. References 📚

9.1. Normative References

[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
           <http://www.rfc-editor.org/info/rfc1034>.

[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,
           <http://www.rfc-editor.org/info/rfc1918>.

[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,
           <http://www.rfc-editor.org/info/rfc2870>.

[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,
           <http://www.rfc-editor.org/info/rfc4033>.

[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,
           <http://www.rfc-editor.org/info/rfc4271>.

[RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
           Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
           December 2006, <http://www.rfc-editor.org/info/rfc4786>.

[RFC7535]  Abley, J., Dickson, B., Kumari, W., and G. Michaelson,
           "AS112 Redirection Using DNAME", RFC 7535,
           DOI 10.17487/RFC7535, May 2015,
           <http://www.rfc-editor.org/info/rfc7535>.

9.2. Informative References 📚✨

Okay bestie, these are the "for more context" references, the ones you read when you want the full story 🧚

Appendix A. A Brief History of AS112 🕰️🌸

Okay, story time! 💜 Lots of people started using the private address blocks from [RFC1918] right after it came out in 1996. Back then, the IN-ADDR.ARPA zone was being served by the root servers 👑

Then came the idea of offloading IN-ADDR.ARPA queries about [RFC1918] addresses away from the root nameservers. That idea was first proposed by Bill Manning and John Brown 🙌

Next, the use of anycast for distributing authoritative DNS service for [RFC1918] IN-ADDR.ARPA zones was 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. That's where the project's name came from, literally named after the AS number 🎀

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. It can be seen as a precursor to the anycast distribution of other authoritative DNS servers in subsequent years (e.g., various root servers). Iconic behaviour, honestly 👑✨

Appendix B. Changes since RFC 6304 🌈

A number of changes and enhancements to the AS112 service has been introduced since the publication of [RFC6304]. Here's the glow-up list 💖

  • The addition of IPv6 transport. 🌐
  • The extension of the AS112 service to include the ability to have additional zones delegated for sinking or removed using the DNAME resource record. 🍓
  • Requisite changes to the guidance regarding the configuration of current and future AS112 nodes. 🛠️
  • Further clarification about the leakage of information in the Security Considerations section. 🔐
  • 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. Thank you, queens 👑

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. Such a big crew, I'm obsessed 🥹💜

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
📦 where this page comes from