DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
Extracted elements (27)
Appendix A explains why an administrator may choose to synthesize AAAA records even when real AAAA records exist: an IPv4-only application running on a dual-stack host may have a AAAA record (for the host), but an IPv6-only client can only reach it via NAT64. Without synthesis of the translated address, communication fails despite the real AAAA being present.
DNS64 synthesis is prohibited in the additional section because clients cannot rely on the additional section being complete and will re-query for needed records anyway. Replacing A records in the additional section with synthetic AAAA records could cause an IPv6-only host to query a name server unaware of NAT64, resulting in resolution failure.
For the 'IPv6 Internet to an IPv4 network' scenario, publishing real AAAA RRs (pre-computed using RFC 6052 algorithm) is recommended over on-the-fly AAAA synthesis, because static DNS records are easier to debug than dynamically synthesized responses.
Non-zero, non-NXDOMAIN RCODE responses to AAAA queries are treated as empty answers (triggering A-record fallback) because many deployed name servers incorrectly return various error codes when no AAAA record exists, rather than returning NOERROR with an empty answer section (see RFC 4074).
The DNS64 implementation SHOULD support mapping separate IPv4 address ranges to separate IPv6 prefixes, allowing special-use IPv4 addresses (RFC 5735) to be handled with appropriate per-range Pref64::/n values, enabling correct translation for addresses like private RFC 1918 space.
An existing DNSSEC validator that is unaware of DNS64 will reject synthesized AAAA records as tampered data. For DNSSEC validation behind DNS64, the validator must either implement DNS64 itself or establish a trusted relationship with a vDNS64 resolver that validates on its behalf.
Dual-stack hosts with both native IPv4 and IPv6 connectivity via NAT64 should avoid using DNS64 resolvers. Per RFC 3484 default address selection (preferring IPv6), the host may route traffic through NAT64 even when native IPv4 would be more efficient or functional. Hosts with IPv4 Internet connectivity should not use DNS64.
Full-service resolvers unaware of DNS64 cannot be used as mixed iterative/forwarding resolvers in a DNS64 environment, because they may obtain IPv4-only glue records and be unable to answer AAAA queries without the DNS64 synthesis capability.
On IPv6 multihomed hosts with interfaces connected to different networks (e.g., one via NAT64 and one with native IPv6), synthetic AAAA records received on one interface may be unusable on other interfaces. Hosts should treat DNS answers as local to the interface on which they were received.
All DNS resource records other than AAAA (and PTR for Pref64::/n addresses) MUST be returned unchanged by DNS64. This includes responses to queries for A RRs.
By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real (non-excluded) AAAA RRs already exist for the queried name. DNS64 SHOULD NOT include synthetic AAAA RRs in responses when real AAAA data is available.
DNS64 operation is only defined for class IN. For any DNS class other than IN, a DNS64 MUST behave as though no DNS64 function is configured.
DNS64 SHOULD provide a configurable exclusion set of IPv6 prefix ranges; AAAA records whose addresses fall within these ranges are treated as empty answers. Implementations SHOULD include ::ffff:0:0/96 in the exclusion set by default. If all returned AAAA records are within excluded ranges, the DNS64 MUST treat the answer as empty and MUST NOT return the offending records.
DNS64 synthesis MUST NOT be performed on any records in the additional section of synthesized answers. The DNS64 MUST pass the additional section unchanged.
Each Pref64::/n prefix length MUST be less than or equal to 96 bits. DNS64 MUST support and MUST use as its default the IPv6-address-generation algorithm defined in Section 2 of RFC 6052. If no Pref64::/n is configured, DNS64 MUST use the Well-Known Prefix 64:ff9b::/96.
If the AAAA query returns an RCODE other than 0 (No error) or 3 (Name Error), DNS64 treats it as RCODE=0 with an empty answer section and proceeds to query for A records. RCODE=3 is returned normally to the client without triggering A-record synthesis.
In validating DNS64 (vDNS64) mode with CD not set and DO set, vDNS64 MUST validate the negative AAAA response before querying for A records, to confirm no legitimate AAAA exists. If both the negative AAAA and the A query validate, vDNS64 MAY synthesize and SHOULD set the AD bit. If validation fails, vDNS64 MUST return RCODE=2.
The same algorithm used by DNS64 to generate the IPv6 representation of an IPv4 address MUST also be used by the paired IPv6/IPv4 translator. The algorithm MUST be reversible (the original IPv4 address must be derivable from the IPv6 representation). Input MUST be limited to the IPv4 address, Pref64::/n, and optionally stable configured parameters.
When a DNS64 server receives a PTR query for an address in IP6.ARPA, it MUST strip the IP6.ARPA labels, reverse the address portion, and check whether the prefix matches any configured Pref64::/n or the Well-Known Prefix. The DNS64 server MUST provide exactly one of two defined response strategies (authoritative response or synthetic CNAME to IN-ADDR.ARPA) and SHOULD NOT provide both simultaneously.
When a vDNS64 receives a query with both the CD bit and DO bit set, it MAY perform validation but MUST NOT perform synthesis. It MUST return all data to the query initiator as a regular recursive resolver would, allowing the client to perform its own DNSSEC validation and DNS64 synthesis.
When synthesizing a AAAA RR, the TTL MUST be set to the minimum of the original A RR's TTL and the SOA RR's TTL for the queried domain. If the SOA was not delivered with the negative AAAA response, the DNS64 SHOULD use the minimum of the A RR TTL and 600 seconds.
DNS64 is a logical function that synthesizes AAAA resource records from A records. It creates synthetic AAAA RRs whose RDATA contains an IPv6 representation of the IPv4 address, algorithmically derived using a configured prefix (Pref64::/n). DNS64 may be implemented in a stub resolver, recursive resolver, or authoritative name server.
Pref64::/n is the IPv6 prefix used by DNS64 to construct IPv6 representations of IPv4 addresses. It may be the Well-Known Prefix 64:ff9b::/96 (reserved by RFC 6052) or a Network-Specific Prefix (NSP) assigned by the operating organization. The same Pref64::/n must be configured identically in both DNS64 and the paired IPv6/IPv4 translator.
DNS64 fundamentally conflicts with DNSSEC: DNS64 modifies DNS answers, and DNSSEC is designed to detect such modifications and treat them as bogus. In validating resolver mode, DNS64 must validate the negative AAAA response before proceeding to A-record synthesis, or an attacker could use DNS64 to circumvent DNSSEC protections.
If an attacker modifies the Pref64::/n configured in DNS64, traffic from hosts receiving synthetic AAAA replies will be delivered to the attacker-controlled prefix. This enables denial-of-service (if the altered prefix is unrouted), flooding attacks (if it routes to unwilling recipients), or eavesdropping (if it routes through the attacker).
DNS64 DNSSEC handling is governed by the DO and CD bits: (1) DO=0: no DNSSEC concern, synthesize normally; (2) DO=1, CD=0, non-validating: pass data unchanged; (3) DO=1, CD=0, validating (vDNS64): validate both negative AAAA and A response before synthesis, set AD bit on success; (4) DO=1, CD=1: MUST NOT synthesize, pass raw data to client for self-validation.
A synthetic AAAA RR is constructed from an A RR as follows: NAME copied from A RR; TYPE=28 (AAAA); CLASS=1 (IN); TTL set to the minimum of the A RR TTL and the SOA RR TTL (or min(A TTL, 600s) if SOA is unavailable); RDLENGTH=16; RDATA set to the 16-byte IPv6 representation of the A record's IPv4 address using the configured Pref64::/n.