Special Use Domain Name 'ipv4only.arpa'
updates
- rfc-7050 — Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
Extracted elements (25)
The DS record is explicitly exempted from the DNS64 authoritative-response rule: DNS64 resolvers must resolve DS queries the usual way to allow clients to securely verify that 'ipv4only.arpa' has an insecure delegation. However, this exception is not expected to see widespread use since compliant clients already know 'ipv4only.arpa' is an insecure delegation.
The 'ipv4only.arpa' queries are not normal DNS lookups; they are an improvised client-to-middlebox communication protocol co-opting the DNS protocol to discover the local network's DNS64/NAT64 IPv6 address synthesis prefix. No client ever needs to look up the IPv4 addresses for this name since those are already known by specification; the purpose is solely to interrogate the local DNS64/NAT64 gateway.
The 'ipv4only.arpa' zone must be an insecure delegation rather than a secure one because (1) the path from authoritative server to DNS64 resolver carries only A records whose values are already known by specification, so DNSSEC adds no value there, and (2) the path from DNS64 resolver to client carries synthesized AAAA records that cannot be signed by the resolver. Run-time cryptographic signatures are not needed to verify compile-time constants.
The name 'ipv4only.arpa' was not originally recorded in the Special-Use Domain Names registry because RFC 7050's Domain Name Reservation Considerations section incorrectly indicated the name had no special properties. This omission left software implementers without a clear mandate to implement the special behavior necessary for correct operation, forcing a choice between noncompliance and non-functioning software.
The original RFC 7050 incorrectly stated that 'ipv4only.arpa' should be a signed zone with DNSSEC protection to allow validating DNS64 servers to detect malicious AAAA records. RFC 8880 corrects this error: because DNS64 resolvers cannot sign synthesized AAAA records, a secure delegation would defeat the entire purpose of the name by making synthesized answers unacceptable to DNSSEC-validating clients.
A serious problem occurs when a device on a NAT64 network is configured to use a recursive resolver other than the one learned from the network (e.g., a public resolver like Cloudflare 1.1.1.1 or Google 8.8.8.8, or a corporate VPN resolver). Such resolvers cannot synthesize IPv6 addresses for the local NAT64 prefix, so 'ipv4only.arpa' queries sent to them will not return the correct NAT64 prefix.
Multiple NAT64 services may be simultaneously available to a client (e.g., one from the local network and one from a corporate VPN), each with a different address synthesis prefix. It is essential that the NAT64 prefix used on each interface be learned from that interface's own recursive resolver, not from a shared or overriding resolver.
Without a formal mandate for special treatment, DNS64 gateways performed unnecessary run-time queries to the authoritative 'arpa' name servers for values already known by specification (two fixed A records), generating unnecessary load and introducing latency and failure modes when those servers were slow or unresponsive.
A client that uses the 'ipv4only.arpa' query to discover IPv6 prefixes and performs its own local address synthesis MUST also synthesize 'ip6.arpa' reverse mapping PTR records for those discovered prefixes, returning 'ipv4only.arpa' for addresses 192.0.0.170 and 192.0.0.171 and performing IPv4 reverse mapping for all other addresses.
Application software SHOULD NOT recognize the reverse mapping names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' as special and SHOULD NOT treat them differently from other names.
DNS64 recursive resolvers MUST generate the 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries (qtype A), synthesized IPv6 address record responses for AAAA queries, and a negative ('no error no answer') response for all other query types except DS. For all subdomains of 'ipv4only.arpa', DNS64 resolvers MUST generate immediate NXDOMAIN responses.
DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' (and all subdomains) as special and MUST NOT attempt to look up NS records or otherwise query authoritative name servers to resolve this name. Instead, they MUST act as authoritative for this zone by generating immediate responses for all queries, with the sole exception of DS record queries.
DNSSEC-capable resolvers MUST NOT attempt to validate answers received in response to queries for the IPv6 AAAA address records for 'ipv4only.arpa', since such answers are generated by the local network's DNS64/NAT64 gateway and not by the authoritative server.
Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as special and MUST give it special treatment. All queries for 'ipv4only.arpa' and any subdomains MUST be sent to the recursive resolver learned from the network interface via IPv6 Router Advertisement Options (RFC 8106), DHCPv6 (RFC 3646), or other configuration mechanisms, regardless of any manual DNS configuration, VPN overrides, or local resolver.
Name resolution APIs and libraries SHOULD recognize the two reverse mapping names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' as special and generate required responses locally: PTR queries yield 'ipv4only.arpa', all other query types yield a negative response, and all subdomains yield NXDOMAIN. This avoids unnecessary load on the authoritative 'in-addr.arpa' name servers.
On multihomed devices (devices with more than one logical or physical IP interface active simultaneously, including VPN connections), clients MUST use interface-aware name resolution APIs. DNS64 answers are only valid for the interface on which they were received, and different interfaces may yield different DNS64 answers.
The 'ipv4only.arpa' zone MUST be an insecure delegation to give DNS64/NAT64 gateways the freedom to synthesize answers to AAAA queries without those answers being rejected by DNSSEC-capable resolvers. Making it a secure delegation would make it impossible for DNS64 resolvers to create synthesized AAAA answers acceptable to DNSSEC validating clients.
Traditional forwarding recursive resolvers SHOULD NOT recognize 'ipv4only.arpa' as special or give that name any special treatment, because a traditional forwarding resolver may itself be downstream of a DNS64 recursive resolver and should pass through queries to allow correct NAT64 prefix discovery.
The name 'ipv4only.arpa' is defined to have exactly two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171, and no other IPv4 or IPv6 address records. When queried via a DNS64 recursive resolver, it also has synthesized IPv6 AAAA records derived from the NAT64 prefix(es) and those two IPv4 addresses. All subdomains of 'ipv4only.arpa' are defined as nonexistent (NXDOMAIN).
The reverse mapping names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' are defined by RFC 7050 to each have exactly one DNS PTR record with rdata 'ipv4only.arpa'. All subdomains of these names are defined as nonexistent (NXDOMAIN).
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: 'ipv4only.arpa.', '170.0.0.192.in-addr.arpa.', and '171.0.0.192.in-addr.arpa.'. IANA has also recorded IPv4 addresses 192.0.0.170 and 192.0.0.171 in the IANA IPv4 Special-Purpose Address Registry.
DNS64 conflicts with DNSSEC: if DNSSEC cryptographically asserts a name has no IPv6 AAAA records, this interferes with DNS64 address synthesis. Clients can resolve this by using the 'ipv4only.arpa' query to learn the NAT64 prefix, then querying for signed IPv4 records, validating the DNSSEC response, and performing local IPv6 address synthesis.
Hardcoding the known answers for 'ipv4only.arpa' IPv4 address record queries in recursive resolvers reduces the risk of malicious devices intercepting those queries and returning incorrect answers, since the 'ipv4only.arpa' zone must be an insecure delegation and DNSSEC cannot protect these A record answers from tampering.
The 'ipv4only.arpa' zone must be an insecure delegation because DNS64 resolvers synthesize IPv6 AAAA answers and do not possess the DNSSEC secret key required to sign those answers. The path from DNS64 resolver to client cannot be DNSSEC-protected. DNSSEC-capable resolvers following this specification MUST NOT attempt to validate AAAA answers for 'ipv4only.arpa'.