The DNS64 servers used by nat64.net are based on BIND 9. I chose BIND 9 for the following reasons:
Even though this is a nice selection of features there are some DNS64 related features which would be very useful to a service like nat64.net but non-existing in BIND 9.
This may come as a surprise. But it is true that BIND 9 is not well suited for operating a DNS64 on an IPv6-only host. Even though BIND 9 supports IPv4, IPv6, and DNS64 it's not possible for a BIND 9 recursor on an IPv6-only host to query an IPv4-only authoritative DNS server.
I know of three workarounds for this limitation:
None of these workarounds are particular desirable.
Since BIND 9 is already able to synthesize AAAA records based on the configured NAT64 prefixes it would be very useful if it could do the same when it need an AAAA record of an authoritative DNS server.
When a NAT64 gateway is scheduled for maintainance its prefix is excluded from synthesized AAAA records. Likewise when other NAT64 gateways provider lower latency the gateway with higher latency will be excluded.
Excluding a NAT64 prefix from synthesis of AAAA records will also exclude it from generation of CNAMEs for reverse DNS lookups. This can lead to a situation where reverse DNS for previously established connections will no longer work.
It would be convenient if all disabled prefixes could be configured to still generate the necessary CNAMEs for reverse DNS.
Since AAAA records are larger than A records it's possible that a set of A records which would fit in a UDP packet will not fit in a UDP packet when each A record has been used to synthesize an AAAA record.
When using multiple NAT64 prefixes for redundancy BIND 9 will synthesize an AAAA record for each combination of NAT64 prefix and A record. This will increase the probability of exceeding the maximum UDP packet size.
For example if a domain has 7 A records and BIND 9 is configured to use 3 NAT64 prefixes there will be 21 synthesized AAAA records. That number of AAAA records will not fit in the default UDP packet size used by DNS.
It would be useful if BIND 9 could be configured to discard excess synthesized AAAA records if there are more than can fit in the UDP packet and not have the client retry over TCP.
The synthesized AAAA records which are kept should be chosen to be as evenly distributed over NAT64 prefixes as possible and as evenly distributed over the original A records as possible.
For a domain with a reasonable number of A records the syntehesis will still produce at least one AAAA record from each orignal A record.
Each configured NAT64 prefix can be restricted to only apply to a subset of possible IPv4 server addresses. Moreover it can also be restricted to only apply to a subset of possible IPv6 addresses of the client sending the query.
There is currently no similar method for restricting which domain names BIND 9 will perform DNS64 for.
In certain situations it can be useful to exclude some domain names from DNS64 for policy reasons. For an excluded domain name BIND 9 should then just behave like a standard recursor without DNS64 and provide the client with exactly the records it received from the authoritative server - no more, no less.
This is a feature which would require new standardization, thus it's quite understandable that it does not yet exist.
A network operator who is operating a dual-stack network may not be in control over the domains with A and AAAA records pointing to addresses in that network.
For this reason it's possible that a hosting network which has been upgraded to dual-stack is still receiving large amounts of IPv4 traffic from clients which are dual-stack or IPv6-only.
That nework operator might want to operate a NAT64 on their own network to be in control of the translation and to have peering connections do more IPv6 and less IPv4.
I imagine that an operator responsible for 198.51.100.0/24 could create a domain named _nat64.100.51.198.in-addr.arpa with a set of AAAA records. If that domain name exists and has any AAAA records it would signal that those are the preferred NAT64 prefixes to use for reaching that /24 network.