RFC 8880

Special Use Domain Name 'ipv4only.arpa'

📅 published August 2020, from ietf

RFC 8880: Special Use Domain Name 'ipv4only.arpa' 🎀

okay so this one is a Standards Track doc from August 2020, written by S. Cheshire at Apple Inc. and D. Schinazi at Google LLC 💖 It's the official ISSN 2070-1721 one, and it updates RFC 7050. The title block doesn't list anything it obsoletes.

Abstract ✨

okay so NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) is the thing that lets IPv6-only client devices talk to servers that only have IPv4 🦋

RFC 7050 is the spec for how a client finds out its local network's NAT64 prefix, and it uses the special name 'ipv4only.arpa' to do it. BUT, in its Domain Name Reservation Considerations section (Section 8.1), RFC 7050 says the name doesn't actually have any special properties that would need special handling 🙈

so, even though 'ipv4only.arpa' has a super clear special purpose, it never got recorded in the Special-Use Domain Names registry as a name with special properties 💅

this doc updates RFC 7050. It describes the special treatment that's needed and formally declares the name's special properties. It also adds similar declarations for the matching reverse mapping names 🌸

Status of This Memo 🌈

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 ✨

you can check the current status, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8880 🫶

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please actually read those, bestie, because they explain your rights and restrictions for this doc 📜

and if you pull Code Components out of this doc, they have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💅

Table of Contents 🧚

1.  Introduction
  1.1.  Conventions and Terminology
2.  Reasons to Declare 'ipv4only.arpa' as Special
3.  Consequences of 'ipv4only.arpa' Not Being Declared Special
  3.1.  Consequences for Name Resolution APIs and Libraries
  3.2.  Consequences for DNS64 Implementations
4.  Remedies
5.  Security Considerations
6.  IANA Considerations
7.  Domain Name Reservation Considerations
  7.1.  Special Use Domain Name 'ipv4only.arpa'
  7.2.  Names '170.0.0.192.in-addr.arpa' and
        '171.0.0.192.in-addr.arpa'
    7.2.1.  ip6.arpa Reverse Mapping PTR Records
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Example BIND 9 Configuration
Acknowledgements
Authors' Addresses

1. Introduction 🍓

okay so NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) [RFC6146] is the one that lets IPv6 client devices reach servers that only have IPv4 connectivity 🌸

DNS64 (DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) [RFC6147] helps clients use NAT64. It does this by making synthesized IPv6 addresses for IPv4 servers that don't have an IPv6 address of their own. Or it tells clients the local network's NAT64 prefix so they can do the IPv6 address synthesis themselves 🧚

now, RFC 7050 [RFC7050] is the spec for how a client finds its local network's NAT64 prefix. It defines the special name 'ipv4only.arpa' for this job. But in its Domain Name Reservation Considerations section (Section 8.1), RFC 7050 [RFC7050] says the name doesn't really have any special properties that need special handling. It also does not ask IANA to record the name in the Special-Use Domain Names registry [SUDN] 🙈

so even though 'ipv4only.arpa' has a super well-articulated special purpose, it never got recorded in the Special-Use Domain Names registry [SUDN] as a name with special properties 💀

this whole omission was discussed in the document "Special-Use Domain Names Problem Statement" [RFC8244] 📚

and because of that omission, when software has to give this name special treatment to work correctly, there was no clear mandate for software authors to do it. Implementers were stuck choosing between skipping the special behavior the name queries need to work right, or implementing it and getting accused of not complying with IETF DNS specs. Bruh 😭

this doc describes the special treatment that's required, formally declares the name's special properties, and adds similar declarations for the corresponding reverse mapping names 🦋

1.1. Conventions and Terminology 💖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📏

2. Reasons to Declare 'ipv4only.arpa' as Special 🌟

the hostname 'ipv4only.arpa' is kinda peculiar, because it was never meant to be treated like a normal hostname 🙈

a typical client has no reason at all to look up the IPv4 address records for 'ipv4only.arpa'. No normal user is trying to view a website on that domain name, or send email to an address at it. RFC 7050 [RFC7050] already tells us that 'ipv4only.arpa' has exactly two IPv4 address records: 192.0.0.170 and 192.0.0.171. So no client ever has to look up the name to learn those two addresses 🧚

but here's the tea ☕ clients often DO look up the IPv6 AAAA address records for 'ipv4only.arpa'. That's contrary to general DNS expectations, because RFC 7050 [RFC7050] says it's an IPv4-only name and it has no IPv6 AAAA address records. And yet clients expect to get, and actually do get, positive answers for those IPv6 AAAA records that apparently shouldn't exist 💀

this weird query behavior isn't because clients are using DNS to learn legit answers from the name's legit authoritative server. It's because the DNS protocol has basically been co-opted as an improvised client-to-middlebox communication protocol. Clients use it to look for a DNS64/NAT64 [RFC6147] [RFC6146] gateway and, if one's there, ask it to disclose the prefix it's using for IPv6 address synthesis 🫶

this use of specially crafted DNS queries as an improvised client-to-middlebox protocol has a bunch of specific consequences, outlined below. Client software needs to account for them if the queries are going to give the desired results. This is especially true on a multihomed host or when a VPN tunnel is in use 🔥

bottom line: 'ipv4only.arpa' is most definitely a special name, and it needs to be listed in IANA's registry along with other DNS names that have special uses [SUDN] 👑

3. Consequences of 'ipv4only.arpa' Not Being Declared Special 💅

okay so, because the original spec [RFC7050] never formally declared 'ipv4only.arpa' to have special properties, there was no clear mandate for DNS software to treat this name specially 🙈

the lack of mandate matters in two places in particular: (a) the name resolution APIs and libraries on client devices, and (b) DNS64 [RFC6147] implementations. Those two get more detail below 🌈

(part 1 of 5 — part 2 is coming, stay tuned bestie 🎀)

3.1. Consequences for Name Resolution APIs and Libraries 💅

okay so this is where things get messy, bestie 😭 A serious problem can happen with DNS64/NAT64 when a device is set up to use a recursive resolver that is not the one it learned from the network 🙈

A device that joins a NAT64 network learns the recursive resolver recommended for that network, usually through IPv6 Router Advertisement Options [RFC8106] or through DHCPv6 [RFC3646] 🧚 On a NAT64 network, it is essential (no cap, this is a BIG deal) that the client uses the DNS64 recursive resolver recommended for that network. Only that resolver can be relied upon to know the right prefix(es) to use when synthesizing IPv6 addresses that the NAT64 gateway will actually accept 👑

However, it is getting more and more common for people to manually override their default DNS configuration because they want some other public recursive resolver on the Internet. It might offer better speed, reliability, or privacy than the local network's default recursive resolver, and honestly that's very relatable 🌈 At the time of writing, examples of widely known public recursive resolver services include Cloudflare Public DNS [DNS1], Google Public DNS [DNS8], and Quad9 [DNS9] 🦋

Another super common scenario is corporate or personal VPN client software. For privacy reasons, and because the local network's recursive resolver will typically be unable to answer for the company's private internal host names, VPN client software usually overrides the local network's default configuration. It diverts some or all DNS requests so they go to the company's own private internal recursive resolver instead of the default one the client learned from its local network 💼 (The company's own private internal recursive resolvers typically have addresses that are themselves reached through the VPN tunnel, not via the public Internet.) Just like with the public recursive resolver services above, the company's private internal recursive resolver cannot be expected to synthesize IPv6 addresses correctly for use with the local network's NAT64 gateway. It's unlikely to be aware of the NAT64 prefix in use on the NAT64 network the client device is currently attached to 😵 So it is clear that a single recursive resolver cannot meet both needs. The local network's recursive resolver cannot be expected to give answers for some unknown company's private internal host names, and a company's private internal recursive resolver cannot be expected to give correctly synthesized IPv6 addresses for some unknown local network's NAT64 gateway 💀

Note that multiple NAT64 services may be available to a client at the same time ✨ For example, the local network may provide NAT64 service (so an IPv6-only client device can reach IPv4-only Internet services), while a corporate VPN also provides NAT64 service (so a client connecting through an IPv6-only VPN tunnel can reach IPv4-only corporate services). The NAT64 address synthesis prefixes for the two services may be different. In this case, it is essential that the NAT64 address synthesis prefix used on the local network is the prefix learned from the local network's recursive resolver, and that the NAT64 address synthesis prefix used on the VPN tunnel is the prefix learned from the VPN tunnel's recursive resolver 🎀

The difficulty here comes from the fact that DNS is being used for two totally unrelated purposes 🙃 The first purpose is retrieving data from a (nominally) global database, which usually means getting the IP address(es) associated with a hostname. The second purpose is using the DNS protocol as a middlebox communication protocol, to interrogate the local network infrastructure and discover the IPv6 prefix(es) in use by the local NAT64 gateway for address synthesis. Two jobs, one protocol, zero chill 😤

3.2. Consequences for DNS64 Implementations 🌸

Because there was no mandate for special treatment, queries for 'ipv4only.arpa' had to be handled normally. That meant DNS64 gateways kept making unnecessary queries to the authoritative 'arpa' name servers. These included unnecessary IPv6 address record queries (DNS qtype AAAA, which always returned negative responses) and unnecessary IPv4 address record queries (DNS qtype A, which always returned the same positive responses) 🙄

Having DNS64 gateways all around the world issue these queries added load to the authoritative 'arpa' name servers. That load was redundant, because the name 'ipv4only.arpa' is defined, by IETF specification [RFC7050], to have exactly two IPv4 address records, 192.0.0.170 and 192.0.0.171, and no other IPv4 or IPv6 address records 📚 Like, why ask a question you already know the answer to? 🫠

Also, at times, for reasons that are still unclear, the authoritative 'arpa' name servers have been observed to be slow or unresponsive 😩 When these 'ipv4only.arpa' queries fail, the DNS64 gateways fail unnecessarily too, and so do the client devices that depend on them for DNS64 [RFC6147] address synthesis. Major main character failure 💔

Even when the authoritative 'arpa' name servers are working perfectly, having to do an unnecessary query for an answer that is already known in advance can add precious milliseconds of delay. That hurts the user experience on client devices that are waiting for those synthesized replies ⏱️

4. Remedies ✨

This document builds on real operational experience to update the Domain Name Reservation Considerations section [RFC6761] of the earlier prefix discovery specification [RFC7050]. The update is a new section that more accurately lists the actual special properties of the name 'ipv4only.arpa'. That way, software can legitimately implement the correct behavior needed for better performance, better reliability, and correct operation 🫶

These changes affect two bodies of software: (a) the name resolution APIs and libraries on client devices, and (b) DNS64 implementations 💜

The new special rules in this document for name resolution APIs and libraries explain how they should pick which recursive resolver to query to learn the IPv6 address synthesis prefix in use on a particular physical or virtual interface. Specifically, when querying for the name 'ipv4only.arpa', name resolution APIs and libraries should use the recursive resolver recommended by the network for the interface in question. They should not use a recursive resolver configured manually, a recursive resolver configured by VPN software, or a full-service recursive resolver running on the local host 🎯

Superficially, this might seem like a security issue, right? The user might have explicitly configured the DNS resolver they want, and instead of using it, the name resolution code ignores the user's stated preference and uses untrusted input received from the network 😬 But the 'ipv4only.arpa' query is not really a DNS query in the usual sense. Even though it may look like one, it is actually an improvised client-to-middlebox communication protocol in disguise 🥸 For NAT64 to work at all, the interface where NAT64 translation happens has to tell the host the address of the DNS64 recursive resolver the host must use to learn the NAT64 prefix that NAT64 is using. This is typically done via IPv6 Router Advertisement Options for DNS Configuration [RFC8106] or via DNS Configuration options for DHCPv6 [RFC3646] ✨

The new special rules in this document for DNS64 implementations recommend that they avoid performing run-time network queries for values that are known to be fixed by specification 🧠

A useful property of the way NAT64 Prefix Discovery [RFC7050] was originally specified is that it allowed for incremental deployment 🚀 Even if existing DNS64 gateways that didn't know about the special 'ipv4only.arpa' name were already deployed, clients could start using the new facility immediately once IANA created the appropriate 'ipv4only.arpa' records. Clients could send their special queries for 'ipv4only.arpa' to an ipv4only-unaware DNS64 gateway. As a side effect of its usual query processing (after a query to IANA's servers), the DNS64 gateway would then generate the correct synthesized response. Iconic, honestly 👑

While this was a great transition strategy for rapid adoption, it isn't the ideal end situation. For better performance, better reliability, and lower load on IANA's servers, it's preferable for DNS64 gateways to be aware of the special 'ipv4only.arpa' name, so they can skip unnecessary queries. Network operators who want to give their customers reliable, high-performance service are motivated to prefer DNS64 gateways that recognize the special 'ipv4only.arpa' name and apply the appropriate optimizations 💖🌈

5. Security Considerations ✨

Okay bestie, let's talk security 🔥 One of the known concerns with DNS64 is that it clashes with DNSSEC 💀 If DNSSEC is used to cryptographically assert that a name has no IPv6 AAAA records, then that gets in the way of DNS64 address synthesis telling a client that those nonexistent AAAA records do exist. Major mood conflict 😭

Section 3 of the DNS64 specification [RFC6147] talks about this:

|  ... DNS64 receives a query with the DO bit set and the CD bit set.
|  In this case, the DNS64 is supposed to pass on all the data it
|  gets to the query initiator.  This case will not work with DNS64,
|  unless the validating resolver is prepared to do DNS64 itself.

The NAT64 Prefix Discovery specification [RFC7050] gives the query initiator a way to learn the NAT64 prefix, so it can do its own validation and DNS64 synthesis, as described above 🧚 With this mechanism, the client can (i) interrogate the local DNS64/NAT64 gateway (with an ipv4only.arpa query) to learn the IPv6 address synthesis prefix, (ii) query for the (signed) IPv4 address records for the desired hostname and validate the response, and then (iii) perform its own IPv6 address synthesis locally, combining the IPv6 address synthesis prefix learned from the local DNS64/NAT64 gateway with the validated DNSSEC-signed data learned from the global Domain Name System. It's giving self-sufficient 💅

It is conceivable that, over time, if DNSSEC adoption keeps growing, the majority of clients could move to this validate-and-synthesize-locally model 👑 That would shrink the DNS64 machinery down to the vestigial role of just responding to the ipv4only.arpa query to report the local IPv6 address synthesis prefix. At the time of publication, network operators have been observed "in the wild" deploying NAT64 service with DNS recursive resolvers that reply to ipv4only.arpa queries but otherwise perform no other NAT64 address synthesis. In no case does the client care what answer(s) the authoritative 'arpa' name servers might give for that query. The ipv4only.arpa query is being used purely as a local client-to-middlebox communication message 🙈

This validate-and-synthesize-locally approach is even more attractive if it does not create an extra dependency on the authoritative 'arpa' name servers to answer a query that is unnecessary, because the DNS64/NAT64 gateway already knows the answer before it even issues the query. Skipping that unnecessary query improves performance and reliability for the client and reduces unnecessary load on the authoritative 'arpa' name servers ✨

Hardcoding the known answers for ipv4only.arpa IPv4 address record queries (DNS qtype "A") in recursive resolvers also reduces the risk of malicious devices intercepting those queries and returning incorrect answers 🔒 Because the ipv4only.arpa zone has to be an insecure delegation (see below), DNSSEC cannot be used to protect these answers from tampering by malicious devices on the path. Scary but true 💀

With respect to whether ipv4only.arpa should be a secure or insecure delegation, we need to consider two paths of information flow through the network:

  1. The path from the server authoritative for ipv4only.arpa to the DNS64 recursive resolver
  2. The path from the DNS64 recursive resolver to the ultimate client

The path from the authoritative server to the DNS64 recursive resolver (queries for IPv4 address records) need not be protected by DNSSEC, because the DNS64 recursive resolver already knows, by specification, what the answers are 🍓 In principle, if this were a secure delegation and ipv4only.arpa were a signed zone, the path from the authoritative server to the DNS64 recursive resolver would still work, but DNSSEC is not necessary here. Run-time cryptographic signatures are not needed to verify compile-time constants 🤓 Validating the signatures could only introduce potential failures into the system for minimal benefit. Why would we do that to ourselves? 😭

The path from the DNS64 recursive resolver to the ultimate client (queries for IPv6 address records) cannot be protected by DNSSEC, because the DNS64 recursive resolver is synthesizing IPv6 address answers and does not possess the DNSSEC secret key required to sign those answers 🥺

So, the ipv4only.arpa zone MUST be an insecure delegation, which gives DNS64/NAT64 gateways the freedom to synthesize answers to those queries at will, without the answers being rejected by DNSSEC-capable resolvers 🦋 DNSSEC-capable resolvers that follow this specification MUST NOT attempt to validate answers received in response to queries for the IPv6 AAAA address records for ipv4only.arpa. Also, the name ipv4only.arpa has no use outside of this special DNS pseudo-query used to learn the DNS64/NAT64 address synthesis prefix, so the lack of DNSSEC security for that name is not a problem 🌈

The original NAT64 Prefix Discovery specification [RFC7050] stated, incorrectly:

|  A signed "ipv4only.arpa." allows validating DNS64 servers (see
|  [RFC6147] Section 3, Case 5, for example) to detect malicious AAAA
|  resource records.  Therefore, the zone serving the well-known name
|  has to be protected with DNSSEC.

This document updates the previous specification [RFC7050] to correct that error. The ipv4only.arpa zone MUST be an insecure delegation. Oops, but we fixed it 💖

6. IANA Considerations 🎀

IANA has created an insecure delegation for ipv4only.arpa to allow DNS64 recursive resolvers to create synthesized AAAA answers within that zone 🌸

IANA has recorded the following names in the Special-Use Domain Names registry [SUDN]:

ipv4only.arpa.
170.0.0.192.in-addr.arpa.
171.0.0.192.in-addr.arpa.

IANA has recorded the following IPv4 addresses in the IANA IPv4 Special-Purpose Address Registry [SUv4]:

192.0.0.170
192.0.0.171

7. Domain Name Reservation Considerations 🦋

7.1. Special Use Domain Name 'ipv4only.arpa' ✨

okay bestie, so 'ipv4only.arpa' is a special name 🦋 IETF spec [RFC7050] says it has two IPv4 address records, 192.0.0.170 and 192.0.0.171 🌸

When you ask a DNS64 recursive resolver [RFC6147] about it, it also gets IPv6 AAAA records 💅 Those get built from your NAT64 IPv6 prefix (or prefixes) plus those same IPv4 addresses. If you have more than one NAT64 prefix, you can get more than one pair of IPv6 addresses back. It's giving multiple options 🧚

'ipv4only.arpa' has no other IPv4 or IPv6 address records 💜 It has no subdomains either, and every name under it is defined to be nonexistent (NXDOMAIN) 🙈

The name is special to three groups 👑:

  • a. client software that wants to do DNS64 address synthesis,
  • b. the APIs that go get the right info, and
  • c. the DNS64 recursive resolver that answers those requests.

Here's the breakdown of those three in items 2, 3, and 4 below, plus some other roles:

  1. Normal users should never have a reason to run into the 'ipv4only.arpa' domain name 🎀 If they do, they should expect queries for it to get the answers the [RFC7050] spec requires. Normal users don't need to know this name is special at all 💖
  2. Application software is allowed to use 'ipv4only.arpa' on purpose for DNS64/NAT64 address synthesis, and it should expect to get the answers [RFC7050] requires ✨ If app software runs into 'ipv4only.arpa' while handling regular user input, it should resolve it like any other name and doesn't need to treat it in any special way 🌈
  3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as special and MUST give it special treatment 🔥

Learning a network's NAT64 prefix is, by its nature, an interface-specific operation 🫶 The special DNS query used to learn that interface-specific NAT64 prefix MUST be sent to the DNS recursive resolver address(es) the client learned through the configuration machinery for that particular client interface. The NAT64 prefix is a per-interface property, not a per-device property. It's not a per-device thing, bestie 💅

No matter what manual DNS config the client has, what DNS overrides a VPN client software sets, or any other mechanism that changes which recursive resolver address the client uses (even when a device runs its own local recursive resolver and uses the loopback address as its configured resolver address), all queries for 'ipv4only.arpa' and any of its subdomains MUST be sent to the recursive resolver learned from the network interface in question. That resolver can come from IPv6 Router Advertisement Options for DNS Configuration [RFC8106], DNS Configuration options for DHCPv6 [RFC3646], or other configuration mechanisms 🧚 Because DNS queries for 'ipv4only.arpa' are actually a special middlebox communication protocol, they have to go to the correct middlebox for the interface in question 😭 If you don't honor this requirement, the NAT64 Prefix Discovery mechanism [RFC7050] fails. Big yikes 💀

One implication: on multihomed devices (devices that let more than one logical or physical IP interface be active at the same time, like cellular data and Wi-Fi, or one physical interface plus a VPN connection), clients MUST use interface-aware name resolution APIs 🍓 Different interfaces can hand back different DNS64 answers, and DNS64 answers are only valid for the interface they came in on. On multihomed devices (including devices that support VPN), name resolution APIs that don't include interface parameters won't work reliably with NAT64 🙈 On single-homed devices, interface-unaware name resolution APIs are fine, since when only one interface can be active at a time there's no need to specify which one 🌸

DNSSEC-capable resolvers MUST NOT attempt to validate answers received in response to queries for the IPv6 AAAA address records for 'ipv4only.arpa' 🔒 The reason is simple: by definition, those answers are generated by the local network's DNS64/NAT64 gateway, not by the authoritative server responsible for that name. Validating them would be a whole mess 🙅‍♀️

  1. Okay, for this section there are two categories of recursive resolvers 🦋 The first is traditional recursive resolvers. That includes forwarding recursive resolvers, which you commonly find in residential home gateways, and iterative recursive resolvers, which ISPs commonly deploy. The second is DNS64 recursive resolvers, whose whole job is synthesizing IPv6 address records 💖 These can be forwarding DNS64 recursive resolvers or iterative DNS64 recursive resolvers. They work together with a companion NAT64 gateway to tell clients the right NAT64 address synthesis prefix ✨ If you want more on these terms, check the DNS Terminology document [RFC8499] 📚

Traditional forwarding recursive resolvers SHOULD NOT recognize 'ipv4only.arpa' as special or give that name, or any of its subdomains, any special treatment 💅 The reason is that a traditional forwarding recursive resolver, like the one built into a residential home gateway, might itself sit downstream of a DNS64 recursive resolver. Passing the 'ipv4only.arpa' queries up to the upstream DNS64 recursive resolver lets the correct NAT64 prefix get discovered 🧚

Traditional iterative recursive resolvers that aren't explicitly configured to synthesize IPv6 prefixes for a companion NAT64 gateway don't need to recognize 'ipv4only.arpa' as special or take any special action 🌈

Forwarding or iterative recursive resolvers that have been explicitly configured to do DNS64 address synthesis for a companion NAT64 gateway (aka "DNS64 recursive resolvers") MUST recognize 'ipv4only.arpa' as special 🔥 The authoritative name servers for 'ipv4only.arpa' can't be expected to know the local network's NAT64 address synthesis prefix, so asking them for IPv6 address records for 'ipv4only.arpa' is futile 🙃

All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' (and all of its subdomains) as special 👑 They MUST NOT try to look up NS records for 'ipv4only.arpa', or otherwise query authoritative name servers to resolve this name 🙅‍♀️ Instead, DNS64 recursive resolvers MUST act as authoritative for this zone, generating immediate responses to all queries for 'ipv4only.arpa' (and any subdomain of it). The one exception is queries for the DS record 🫶 Those get resolved the usual way, so a client can securely verify that the 'ipv4only.arpa' zone has an insecure delegation. This exception probably won't see a ton of use, since any client that follows this spec already knows 'ipv4only.arpa' is an insecure delegation and won't attempt DNSSEC validation for this name 💅

DNS64 recursive resolvers MUST generate the 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries (DNS qtype "A") 🌸 They MUST also give the appropriate synthesized IPv6 address record responses for IPv6 address queries (DNS qtype "AAAA"), and a negative ("no error no answer") response for all other query types except DS ✨

For all subdomains of 'ipv4only.arpa', DNS64 recursive resolvers MUST generate immediate NXDOMAIN responses 🙈 All names falling below 'ipv4only.arpa' are defined to be nonexistent 💜

An example configuration for BIND 9 showing how to get the desired result is in Appendix A 🧚

Note that this is not a locally served zone in the usual sense of that term [RFC6303], because this rule applies only to DNS64 recursive resolvers, not to traditional forwarding or iterative recursive resolvers. Not the same vibe at all 💅
  1. Authoritative name server software need not recognize 'ipv4only.arpa' as special or handle it in any special way 🌈
  2. Generally speaking, operators of authoritative name servers don't need to know anything about 'ipv4only.arpa', just like they don't need to know about any other names they aren't responsible for 🎀 Only the administrators of the 'arpa' namespace need to be aware of this name's purpose and how it should be configured 👑 In particular, 'ipv4only.arpa' MUST have the required records, and MUST be an insecure delegation, so DNS64 recursive resolvers can create synthesized AAAA answers within that zone 🔥 If the 'ipv4only.arpa' zone became a secure delegation, DNS64 recursive resolvers couldn't create synthesized AAAA answers that DNSSEC validating clients would accept, and that would defeat the entire purpose of the 'ipv4only.arpa' name 😭
  3. DNS Registries/Registrars don't need to know anything about 'ipv4only.arpa', just like they don't need to know anything about any other name they aren't responsible for 🍓

7.2. Names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' ✨

Okay so, the IPv4 addresses 192.0.0.170 and 192.0.0.171 are officially special 🦋 and they're listed in the IANA IPv4 Special-Purpose Address Registry [SUv4]. That means their reverse mapping names in the in-addr.arpa domain are special too. Iykyk 💅

The name '170.0.0.192.in-addr.arpa' is defined by [RFC7050] to have only one DNS record: type PTR, with rdata 'ipv4only.arpa'. ✨

The name '171.0.0.192.in-addr.arpa' is defined by [RFC7050] to have only one DNS record too: type PTR, with rdata 'ipv4only.arpa'. Same energy, different address 🌸

There are no subdomains of '170.0.0.192.in-addr.arpa' or '171.0.0.192.in-addr.arpa'. Anything underneath these names is defined to be nonexistent (NXDOMAIN). Not them trying to exist 💀

Practically speaking, these two names are rarely used. But to the extent that they might be, they're only special to resolver APIs and libraries, as described in item 3 below. Here's the breakdown 🎀

  1. Normal users should basically never run into these two reverse mapping names. But if they do, queries for them should return the expected answer 'ipv4only.arpa'. Normal users don't need to know these names are special, bestie 🫶
  2. Application software SHOULD NOT recognize these two reverse mapping names as special, and it SHOULD NOT treat them differently. For example, if someone runs the Unix command "host 192.0.0.170", the "host" command should call the name resolution API or library as usual and display whatever result comes back. No drama, just vibes 🍓
  3. Name resolution APIs and libraries SHOULD recognize these two reverse mapping names as special and generate the required responses locally. For '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa', PTR queries yield the result 'ipv4only.arpa', and all other query types yield a negative ("no error no answer") response. For all subdomains of these two reverse mapping domains, every query yields an NXDOMAIN response. All names falling below these two reverse mapping domains are defined to be nonexistent. This is the main character moment 👑

Generating these responses locally and self-contained is the whole point. It stops us from placing unnecessary load on the authoritative 'in-addr.arpa' name servers 🙈

  1. Recursive resolvers SHOULD NOT recognize these two reverse mapping names as special, and they SHOULD NOT, by default, give them any special treatment. Recursives, keep it chill 🧚
  2. Authoritative name server software need not recognize these two reverse mapping names as special or handle them in any special way. Totally optional, slay 💜
  3. Most operators of authoritative name servers don't need to know anything about these two reverse mapping names, just like they don't need to know about any other names they aren't responsible for. Only the operators of the authoritative name servers for these two reverse mapping names need to be aware that they're special, and they require fixed answers specified by IETF specification 🌈
  4. DNS Registries and Registrars don't need to know anything about these two reverse mapping names, same as any other name they aren't responsible for. Not their problem, not their drama 🦋

7.2.1. ip6.arpa Reverse Mapping PTR Records 🎀

For all IPv6 addresses synthesized by a DNS64 recursive resolver, the DNS64 recursive resolver is responsible for synthesizing the matching 'ip6.arpa' reverse mapping PTR records too, if it chooses to provide reverse mapping PTR records at all. The same goes for the synthesized IPv6 addresses that correspond to the IPv4 addresses 192.0.0.170 and 192.0.0.171 ✨

Generally, a DNS64 recursive resolver makes these 'ip6.arpa' reverse mapping PTR records by pulling the embedded IPv4 address out of the encoded IPv6 address, doing a reverse mapping PTR query for that IPv4 address, and then synthesizing a matching 'ip6.arpa' reverse mapping PTR record with the same rdata. Glow-up energy 💖

For synthesized IPv6 addresses that correspond to the IPv4 addresses 192.0.0.170 and 192.0.0.171, though, the DNS64 recursive resolver doesn't issue reverse mapping queries for those IPv4 addresses. Instead, following rule 3 above, it immediately returns the answer 'ipv4only.arpa'. Shortcut unlocked 🧚

Now, a client might use the 'ipv4only.arpa' query to discover the IPv6 prefixes in use by its local NAT64 gateway, then do its own address synthesis locally. That's a good move, since it allows things like DNSSEC validation 🔥 In that case, the client MUST also synthesize 'ip6.arpa' reverse mapping PTR records for the discovered prefix(es), following the rules above. Here's how that works: when a client's name resolution APIs and libraries get a request to look up an 'ip6.arpa' reverse mapping PTR record for an address inside one of the discovered NAT64 address synthesis prefixes, the software pulls out the embedded IPv4 address. For the IPv4 addresses 192.0.0.170 and 192.0.0.171, it returns the fixed answer 'ipv4only.arpa'. For all other IPv4 addresses, it does a reverse mapping PTR query for that IPv4 address, then synthesizes a matching 'ip6.arpa' reverse mapping PTR record with the same rdata. Client-side synthesis, but make it iconic 💅

8. References 📚

8.1. Normative References

8.2. Informative References

Appendix A. Example BIND 9 Configuration 🌸

A BIND 9 recursive resolver can be configured to act as authoritative for the necessary DNS64 names, as shown below. It's giving self-hosting 💻

In /etc/named.conf, add this line:

zone "ipv4only.arpa"            { type master; file "ipv4only"; };

Then create the file /var/named/ipv4only with the following content:

$TTL 86400               ; Default TTL 24 hours
@ IN SOA nameserver.example. admin.nameserver.example. (
         2016052400      ; Serial
         7200            ; Refresh ( 7200 = 2 hours)
         3600            ; Retry   ( 3600 = 1 hour)
         15724800        ; Expire  (15724800 = 6 months)
         60              ; Minimum
         )
@ IN NS  nameserver.example.

@ IN A    192.0.0.170
@ IN A    192.0.0.171
@ IN AAAA 64:ff9b::192.0.0.170 ; If not using Well-Known Prefix
@ IN AAAA 64:ff9b::192.0.0.171 ; place chosen NAT64 prefix here

Acknowledgements 🫶

Huge thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for devising the NAT64 Prefix Discovery mechanism [RFC7050] and for their feedback on this document. Legends 👑

Thanks to Geoff Huston for his feedback on this document. ✨

Thanks to Erik Kline for pointing out that the in-addr.arpa names are special, too. Didn't see that coming, but iconic 🙈

Thanks to Mark Andrews for conclusively pointing out the reasons why the 'ipv4only.arpa' zone must be an insecure delegation in order for the NAT64 Prefix Discovery mechanism [RFC7050] to work, and for many other very helpful comments. 🧚

Thanks particularly to Lorenzo Colitti for an especially spirited hallway discussion at IETF 96 in Berlin, which lead directly to significant improvements in how this document presents the issues. That's what I call a plot twist 🔥

Thanks to Scott Bradner, Bernie Volz, Barry Leiba, Mirja Kuehlewind, Suresh Krishnan, Benjamin Kaduk, Roman Danyliw, Eric Vyncke, and the other IESG reviewers for their thoughtful feedback. 💜

Thanks to Dave Thaler and Warren Kumari for generously helping shepherd this document through the publication process. Team effort, periodt 🌈

Authors' Addresses 💌

Stuart Cheshire
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America

Phone: +1 (408) 996-1010
Email: cheshire@apple.com


David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, California 94043
United States of America

Email: dschinazi.ietf@gmail.com
📦 where this page comes from