This paragraph is factually incorrect.
Possibly this problem could have been avoided if we had forced all
NAT64 gateways to use the same Well-Known Prefix for IPv6 address
synthesis [RFC6052]. If the decision had been made to use a single
fixed Well-Known Prefix, then there would have been no need for
clients to discover the local network's NAT64 prefix, and no need for
the 'ipv4only.arpa' [RFC7050] query. However, that was not the
decision that was made.
ipv4only.arpa would still be needed even when using the well known prefix
as it is used to discover if the well-known-prefix is being USED or not.
i.e. ipv4only.arpa performs 2 functions.
1) discovery of whether AAAA synthesis is occurring.
2) discovery of the prefix associated with that synthesis.
Forcing everyone to use the WKP would remove 2 but 1 would still remain.
This paragraph is wrong.
Traditional recursive resolvers SHOULD NOT recognize
'ipv4only.arpa' as special or give that name, or subdomains of
that name, any special treatment. The rationale for this is that
a traditional recursive resolver, such as built in to a home
gateway, may itself be downstream of a DNS64 recursive resolver.
Passing though the 'ipv4only.arpa' queries to the upstream DNS64
recursive resolver will allow the correct NAT64 prefix to be
discovered.
A FORWARDING recursive server needs to pass through the queries.
(For BIND9 that is forward-only)
A ITERATIVE recursive server needs to answer the queries locally
except for ipv4only.arpa/DS.
(For BIND9 that is plain forwarding and not forwarding modes)
CPE recursive servers are often FORWARDING recursive servers.
There is not such thing as a TRADITIONAL recursive server.
This paragraph needs to be re-worded to permit DS queries for ipv4only.arpa
to hit the ARPA servers. Also “domain" should be replaced with “zone”. You
want the servers to serve the ipv4only.arpa zone.
All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' as
special and MUST NOT attempt to look up NS records for it, or
otherwise query authoritative name servers in an attempt to
resolve this name. Instead, DNS64 recursive resolvers MUST act
as authoritative for this domain and generate immediate responses
for all such queries.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
