One of the known concerns with DNS64 is that it conflicts with DNSSEC. If DNSSEC is used to assert cryptographically that a name has no IPv6 AAAA records, then this interferes with using DNS64 address synthesis to tell a client that those nonexistent IPv6 AAAA records do exist.
Section 3 of
RFC 6147 discusses this:
... DNS64 receives a query with the DO bit set and the CD bit set. In thiscase, the DNS64 is supposed to pass on all the data it gets to the queryinitiator. This case will not work with DNS64, unless the validating resolveris prepared to do DNS64 itself.
The [
RFC 7050] provides the mechanism for the query initiator to learn the NAT64 prefix so that 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 is conceivable that, over time, if DNSSEC adoption continues to grow, the majority of clients could move to this validate-and-synthesize-locally model, which reduces the DNS64 machinery to the vestigial role of simply 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 additional 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. Avoiding this unnecessary query improves performance and reliability for the client and reduces unnecessary load for 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.
With respect to the question of whether 'ipv4only.arpa' should be a secure or insecure delegation, we need to consider two paths of information flow through the network:
-
The path from the server authoritative for 'ipv4only.arpa' to the DNS64 recursive resolver
-
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, then 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 serve to introduce potential failures into the system for minimal benefit.
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.
Consequently, the 'ipv4only.arpa' zone
MUST be an insecure delegation to give 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'. Note that the name 'ipv4only.arpa' has no use outside of being used for 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 [
RFC 7050] 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 withDNSSEC.
This document updates [
RFC 7050] to correct that error. The 'ipv4only.arpa' zone
MUST be an insecure delegation.