RFC 7535

AS112 Redirection Using DNAME

📅 published May 2015, from ietf

Part 1 of 3 🎀

RFC 7535: AS112 Redirection Using DNAME 💖

Okay bestie, so this one is an Informational RFC from May 2015 (ISSN 2070-1721) 🌸. It was written by J. Abley from Dyn, Inc., B. Dickson from Twitter, Inc., W. Kumari from Google, and G. Michaelson from APNIC 🫶. The title block doesn't list any RFCs that it obsoletes or updates, so it's standing on its own ✨.

Abstract

AS112 is the service that handles reverse lookups for IP addresses that aren't globally unique, like the RFC 1918 addresses 🙈. This document changes how AS112 infrastructure gets deployed and used so zones can be added and dropped way more easily, using DNAME resource records 🦋.

The best part is that any DNS zone administrator can sink traffic for parts of the global DNS namespace they control into the AS112 infrastructure, and they don't need to coordinate with the AS112 operators first 💅.

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 document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for more on that 🌈.

For info on the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7535 💜.

Copyright (c) 2015 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 they stood on the date of publication. Please read these documents carefully, because they describe your rights and restrictions regarding this document 👑. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💀.

Table of Contents

1. Introduction ....................................................3
2. Design Overview .................................................4
3. AS112 Operations ................................................5
   3.1. Extensions to Support DNAME Redirection ....................5
   3.2. Redirection of Query Traffic to AS112 Servers ..............5
4. Continuity of AS112 Operations ..................................6
5. Candidate Zones for AS112 Redirection ...........................6
6. DNAME Deployment Considerations .................................7
7. IAB Statement Regarding This .ARPA Request ......................8
8. IANA Considerations .............................................8
   8.1. Address Assignment .........................................8
   8.2. Hosting of AS112.ARPA .....................................10
   8.3. Delegation of AS112.ARPA ..................................10
9. Security Considerations ........................................10
10. References ....................................................11
   10.1. Normative References .....................................11
   10.2. Informative References ...................................11
Appendix A. Assessing Support for DNAME in the Real World .........13
  A.1. Methodology ................................................13
  A.2. Results ....................................................15
Acknowledgements ..................................................16
Authors' Addresses ................................................16

1. Introduction ✨

Loads of sites on the Internet use IPv4 addresses that aren't globally unique. The addresses set aside in [RFC1918] for private use inside individual sites are a big example 🌸.

Devices in these environments sometimes send Domain Name System (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 administrators to make sure these queries get answered locally 🏡. Still, it's not uncommon for them 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 everywhere and the Internet keeps growing, so the volume of these queries is huge and getting bigger 📈. The AS112 project wants to be a distributed sink for these queries so it takes some weight off the IN-ADDR.ARPA authoritative servers 🫶. It's named after the Autonomous System Number (ASN) that was assigned to it 🔥.

Before this technique came along, the AS112 project didn't handle adding and removing DNS zones elegantly. Since there are additional zones with definitively local significance out there, that's a real problem 💅. This document describes changes to how AS112 infrastructure is deployed and used, so zones can be added and dropped much more easily ✨.

The AS112 project is described in detail in [RFC7534].

The AS112 nameservers (PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG) are required to answer authoritatively for each and every zone delegated to them. If a zone gets delegated to AS112 nameservers without them being configured ahead of time to answer authoritatively for that zone, clients following referrals for queries in that zone take a real hit 💀. This misconfiguration is colloquially known as a "lame delegation" 🙃.

AS112 nameserver operators are only loosely coordinated, so adding support for a new zone (or removing support for one that's no longer delegated to the AS112 nameservers) is hard to do accurately 😩. Testing AS112 nameservers remotely to see whether they're configured to answer authoritatively for a particular zone is just as tricky, since AS112 nodes are distributed using anycast [RFC4786] 🌀.

This document defines a more flexible way to sink queries on AS112 infrastructure, one that can be deployed alongside unmodified, existing AS112 nodes 🧚. Instead of delegating additional zones directly to AS112 nameservers, it uses DNAME [RFC6672] redirection 🦋. The big win is that query traffic for arbitrary parts of the namespace can be pointed at AS112 servers without those servers having to be reconfigured every time a zone is added or removed 👑.

Once again, the key thing: this approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure 💖.

2. Design Overview

A new zone, EMPTY.AS112.ARPA, is delegated to a single nameserver, BLACKHOLE.AS112.ARPA (IPv4 address 192.31.196.1, IPv6 address 2001:4:112::1) 🎀.

The IPv4 address 192.31.196.1 was picked from the prefix the IANA assigned, so that the address is coverable by a single IPv4 /24 prefix and no other address covered by that prefix is in use 🧠. The IPv6 address 2001:4:112::1 was assigned in a similar way, so that no other address within a covering /48 is in use 🌟. This addressing plan lets the BLACKHOLE.AS112.ARPA service be distributed by anycast using a single IPv4 service prefix and a single IPv6 service prefix 📡. See [RFC4786] for more on anycast service distribution, and see Section 8 for the specific actions IANA completed for this document 🫶.

Some or all of the existing AS112 nodes should be extended to support these new nameserver addresses and to host the EMPTY.AS112.ARPA zone. See [RFC7534] for revised guidance for AS112 server operators 🍓.

Each part of the DNS namespace where it's desirable to sink queries at AS112 nameservers should be redirected to the EMPTY.AS112.ARPA zone using DNAME [RFC6672]. See Section 3.2 for guidance for zone administrators 🌈.

3. AS112 Operations

3.1. Extensions to Support DNAME Redirection

Guidance for operators of AS112 nodes gets extended to include configuring the 192.31.196.1 and 2001:4:112::1 addresses, announcing the corresponding covering routes for those addresses, and hosting the EMPTY.AS112.ARPA zone 🛠️.

IPv4-only AS112 nodes should only configure the 192.31.196.1 nameserver address. IPv6-only AS112 nodes should only configure the 2001:4:112::1 nameserver address 💜.

Only one AS112 server operator needs to implement these extensions for this mechanism to work as intended 🎯. It's beneficial if many more than one operator makes these changes, though, because that gives the nameservers serving the EMPTY.AS112.ARPA zone more distribution and capacity 🔥. It's not necessary for every AS112 server operator to make these changes for the mechanism to be viable 🫶.

Detailed instructions for implementing these extensions are included in [RFC7534] 📖.

3.2. Redirection of Query Traffic to AS112 Servers

Once the EMPTY.AS112.ARPA zone has been deployed on the nameservers described in Section 3.1, redirections may be installed in the DNS namespace for queries that are meant to be answered by the AS112 infrastructure 🦋.

For example, reverse queries for TEST-NET-1 (192.0.2.0/24) [RFC5737] could be redirected to AS112 nameservers by installing a DNAME resource record in the 192.IN-ADDR.ARPA zone, like in Figure 1 👀.

  $ORIGIN 192.IN-ADDR.ARPA.
  ...
  2.0     IN      DNAME   EMPTY.AS112.ARPA.
  ...

Figure 1

There's no practical limit to the number of redirections that can be configured this way 🌸. A redirection for a particular part of the namespace to EMPTY.AS112.ARPA can be removed at any time, under the control of the administrators of that part of the DNS namespace 🧹. No changes to deployed AS112 nodes that include the extensions in this document are needed to support additional redirections ✨. A list of possible candidates for AS112 redirection is in Section 5 💅.

DNAME resource records deployed for this purpose can be signed with DNSSEC [RFC4033], which gives a secure way to authenticate the legitimacy of each redirection 🔐.

4. Continuity of AS112 Operations ✨

okay so bestie, this part is all about not breaking stuff that's already working 🫶 The existing advice to AS112 server operators is that they should keep accepting and answering queries aimed at the PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG nameservers, and nobody should change the delegation of the zones already hosted on AS112 servers. The whole point is continuity for the zones that are currently delegated to AS112 servers, so clients don't get accidentally hurt by the changes in this document 💖

Here's the glow-up plan 💅 Once it's been shown, both empirically and quantitatively, that the EMPTY.AS112.ARPA zone is hosted well enough that the existing, unmodified AS112 servers host 10.IN-ADDR.ARPA, people might decide to swap the delegation of those [RFC1918] zones over to DNAME redirection. Once that's live, the PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG nameservers could be retired 🌸 BUT this document does not tell the IANA to do that, so no pressure 🙈

4.1. ...

Not applicable, there are no subsections in this section.

5. Candidate Zones for AS112 Redirection 🎀

Every zone listed in [RFC6303] is a candidate for AS112 redirection 🦋

Also, the vibe here is that AS112 operators don't have to pre-provision anything to sink a name in the DNS namespace. So this mechanism lets any zone owner in the DNS use AS112 redirection 👑

This document is just about providing the AS112 redirection service. It doesn't say that any particular redirection has to be put in place 🧚

6. DNAME Deployment Considerations 🌈

DNAME came out years after the original implementations of [RFC1035], so universal deployment can't be expected 💀 That's why [RFC6672] specifies a fallback that uses synthesised CNAME RRSets 🫶 The idea that DNAME's design choices should cover any lack of deployment gets reviewed below, and experimental validation of those expectations is in Appendix A ✨

It's a fundamental design requirement of AS112 service that responses be cached 💜 We can safely say DNAME support on the authoritative server is a prerequisite for DNAME redirection. But the cases where individual elements in resolver chains don't support DNAME processing deserve a closer look 🔥

When a DNAME response goes to a resolver that doesn't support DNAME, the expected behaviour is that the accompanying, synthesised CNAME gets accepted and cached. How often it gets re-queried is decided by the TTLs (Time to Live) returned by the DNAME-responding authoritative servers ⏰

Resolving the CNAME target is simple and works exactly the way the AS112 project has operated since it was deployed 🍓 The negative caching [RFC2308] of the CNAME target follows the parameters defined in the target zone, EMPTY.AS112.ARPA. Side effect: every redirected name that ends up on an AS112 node gets negatively cached with those same parameters. But this lack of flexibility seems non-controversial, since lowering the negative cache TTL would mean more query volume on the AS112 node operator concerned, so the controls seem well aligned with operation 😭

Validating resolvers (the ones requesting and processing DNSSEC [RFC4033] metadata) MUST implement DNAME, so they SHOULD NOT use synthesised CNAME RRs. Not having a signature over a received CNAME RR shouldn't limit the ability to sign the (DNAME) redirection point, or for those (DNAME) signatures to be validated 🔐

If a recursive server implements DNAME but a stub resolver doesn't, CNAME synthesis will again be a viable path 🧚‍♀️

DNAME support on AS112 nodes themselves is NEVER required under this proposal 🙅‍♀️

7. IAB Statement Regarding This .ARPA Request 👑

With this document published, the IAB approves of the delegation of 'AS112' in the ARPA domain. Under [RFC3172], the IAB asked IANA to delegate and provision "AS112.ARPA" as specified in this specification. HOWEVER, the IAB isn't taking any architectural or technical position on this specification 🙈

8. IANA Considerations 🦋

8.1. Address Assignment 💖

IANA assigned IPv4 and IPv6 number resources in line with Section 4 of [RFC2860] for this document 🌸

IANA assigned one IPv4 /24 netblock and registered its use in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890] like this:

+----------------------+-----------------+
| Name                 | Value           |
+----------------------+-----------------+
| Address Block        | 192.31.196.0/24 |
|                      |                 |
| Name                 | AS112-v4        |
|                      |                 |
| RFC                  | RFC 7535        |
|                      |                 |
| Allocation Date      | 2014-12         |
|                      |                 |
| Termination Date     | N/A             |
|                      |                 |
| Source               | True            |
|                      |                 |
| Destination          | True            |
|                      |                 |
| Forwardable          | True            |
|                      |                 |
| Global               | True            |
|                      |                 |
| Reserved-by-Protocol | False           |
+----------------------+-----------------+

IANA also assigned one IPv6 /48 netblock and registered its use in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890] like this:

+----------------------+-----------------+
| Name                 | Value           |
+----------------------+-----------------+
| Address Block        | 2001:4:112::/48 |
|                      |                 |
| Name                 | AS112-v6        |
|                      |                 |
| RFC                  | RFC 7535        |
|                      |                 |
| Allocation Date      | 2014-12         |
|                      |                 |
| Termination Date     | N/A             |
|                      |                 |
| Source               | True            |
|                      |                 |
| Destination          | True            |
|                      |                 |
| Forwardable          | True            |
|                      |                 |
| Global               | True            |
|                      |                 |
| Reserved-by-Protocol | False           |
+----------------------+-----------------+

8.2. Hosting of AS112.ARPA 🧁

IANA hosts and signs the zone AS112.ARPA using nameservers and DNSSEC signing infrastructure of their choosing, as shown in Figure 2. IANA may adjust the SOA RDATA to suit their operational requirements 🛠️

$ORIGIN AS112.ARPA.
$TTL 3600

@       IN      SOA     BLACKHOLE.AS112.ARPA. NOC.DNS.ICANN.ORG. (
                                1               ; serial
                                10800           ; refresh
                                3600            ; retry
                                1209600         ; expire
                                3600 )          ; negative cache TTL

                NS      A.IANA-SERVERS.NET.
                NS      B.IANA-SERVERS.NET.
                NS      C.IANA-SERVERS.NET.

BLACKHOLE       A       192.31.196.1
                AAAA    2001:4:112::1

HOSTNAME        NS      BLACKHOLE

EMPTY           NS      BLACKHOLE

Figure 2

8.3. Delegation of AS112.ARPA 🌷

IANA arranged delegation from the ARPA zone according to normal IANA procedure for ARPA zone management, to the nameservers used in carrying out the direction in Section 8.2. The whois contact information for the new record is specified by the IAB under [RFC3172] 📇

9. Security Considerations 🔐

This document presents no known additional security concerns to the Internet. 😭🔥

For security considerations relating to AS112 service in general, see [RFC7534] 💅

10. References 📚

10.1. Normative References 💜

10.2. Informative References 🦋

Appendix A. Assessing Support for DNAME in the Real World ✨

okay so this appendix is where they actually went out and tested whether DNAME works for real people on the real Internet 🧚 the goal is to see how much DNAME support is out there by testing the DNS resolvers that end hosts use 💖

A.1. Methodology 🔍

the test works by loading a user's browser with four URLs to fetch 🫶 the first three are the setup, and the last one sends the result back to the experiment controller 💅

A  http://a.<unique_string>.dname.example.com/1x1.png?
   a.<unique_string>.dname

B  http://b.dname.example.com/1x1.png?
   b.<unique_string>.dname

C  http://c.<unique_string>.target.example.net/1x1.png?
   c.<unique_string>.target

D  http://results.recorder.example.net/1x1.png?
   results.<unique_string>?za=<a_result>&zb=<b_result>&zc=<c_result>

URL A is there to check whether the user can resolve a name nobody has ever seen before 👀 because the name is brand new, the lookup will reliably hit the authoritative nameserver 🌸 it's testing domain names that have a dynamic part and also use DNAME, which is lowkey the whole point 🦋

URL B is deliberately built to get cached by the caching resolvers that handle the lookup 🍓

URL C is the control 🎀 it's a unique URL like A, but it doesn't use a DNAME structure at all, so it gives us a baseline to compare against ✨

URL D uses a static domain name that can be cached 💜

the <unique_string> is the same across all four URLs in one run of the test, but it changes from test to test 🌈 so every end user gets their own unique string 🫶

the contents of the EXAMPLE.COM, TARGET.EXAMPLE.NET, and RECORDER.EXAMPLE.NET zones are shown in Figure 3 😭

$ORIGIN EXAMPLE.COM.
...
DNAME.             IN  DNAME  TARGET.EXAMPLE.NET.
...

$ORIGIN TARGET.EXAMPLE.NET.
...
B                  IN  A      192.0.2.0
*                  IN  A      192.0.2.0
...

$ORIGIN RECORDER.EXAMPLE.NET.
...
RESULTS            IN  A      192.0.2.0
...

Figure 3

the first three URLs (A, B, and C) get loaded as tasks in the user's browser as soon as the script runs 🚀 the script starts a timer for each one to measure how long the fetch takes ⏱️ then it waits for all three to finish, or for 10 seconds, whichever comes first 💀 after that, it loads the three timer results into the GET arguments of URL D and fetches it, which sends everything back to the experiment's server 🎀

the logs on the web server at RESULTS.RECORDER.EXAMPLE.NET will show entries that look like Figure 4 👑 if any of the URLs fail to load within 10 seconds, URL D reports that failure as a "null" timer value 🙈

GET /1x1.png?results.<unique_string>?za=1822&zb=1674&zc=1582
GET /1x1.png?results.<unique_string>?za=null&zb=null&zc=161

Figure 4

the script was encoded in Adobe Flash, using a simple image that looks like an online advertisement 📺 an online advertisement network was used to distribute it 💅 the script runs when the ad shows up in the user's browser or app, and the user doesn't have to click the image at all 🫶 the ad placement settings were set to the broadest possible scope, so it could sample users from across the entire Internet 🌍✨

A.2. Results 📊

the test ran in an advertisement distributed on 2013-10-10 and 2013-10-11 🎀

           +--------------------+---------+------------+
           |                    |   Count | Percentage |
           +--------------------+---------+------------+
           | Recorded Results:  | 338,478 |            |
           |                    |         |            |
           | A or B Loaded:     | 331,896 |      98.1% |
           |                    |         |            |
           | A Fail and B Fail: |   6,492 |       1.9% |
           |                    |         |            |
           | A Fail and B Load: |   4,249 |       1.3% |
           |                    |         |            |
           | A Load and B Fail: |   1,624 |       0.5% |
           |                    |         |            |
           | C Fail:            |   9,355 |       2.8% |
           +--------------------+---------+------------+

Table 1

so these results say that at most 1.9% of the clients tested use DNS resolvers that fail to resolve a domain name containing a DNAME redirection 👀 but the control URL failed at a rate slightly under 3%, which means the DNAME failure rate sits inside the margin of error for the experiment 🦋 the conclusion is that there's no evidence of a consistent failure by deployed DNS resolvers when it comes to correctly resolving a DNAME construct 💖✨

this experiment was conducted by Geoff Huston and George Michaelson 🫶

Acknowledgements 🌸

the authors thank Bob Harold and the other participants in the DNSOP working group for their valuable contributions to this document 💜

Authors' Addresses 💅

Joe Abley
Dyn, Inc.
103-186 Albert Street
London, ON  N6A 1M1
Canada

Phone: +1 519 670 9327
EMail: jabley@dyn.com


Brian Dickson
Twitter, Inc.

EMail: bdickson@twitter.com


Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA  94043
United States

EMail: warren@kumari.net


George Michaelson
APNIC

EMail: ggm@apnic.net

and that's the whole RFC, bestie 🌈🦋👑

📦 where this page comes from