I have taken a look at that doh document. From the document I cannot tell if it is compatible with the clients directive in a dns64 block in a BIND 9 configuration. I suspect what's going to happen is that BIND 9 will see all requests as originating from ::1 and any attempt to direct clients to a nearby NAT64 would be futile as BIND 9 would have no idea which client it is responding to.
The installation instructions involved downloading source code, so I figured at least I should try downloading that source and look for myself if there was anything in the code to deal with that issue. Alas the repository mentioned in the document requires authentication and I don't have credentials for that service.
As for DoT I have serious doubt it's going to work with a separate daemon implementing SSL. If that separate daemon only handles the SSL part and doesn't itself understand the inner protocol (in this case DNS), it also cannot insert any information about the client IP address into the DNS communication. And again I wouldn't know which NAT64 would be closest to the client.
Since I am writing this post anyway I just wanted to mention a couple of things which has been happening.
- I have made some performance improvements. So now my NAT64 gateways can handle a little more traffic than before. And the abusive traffic that everyone with IPv4 access is receiving I am now able to drop 10 times faster than before.
- In January I decided it was time to create a page with a list of all the public NAT64 gateways I know about: https://nat64.net/public-providers
- I am looking into the possibility of bringing up some NAT64 gateways in North America as well. To do that I want to find two cheap providers (nobody is paying me for operating this service). I'll probably use Dreamhost as one of the providers, I'm happy to hear suggestions for a second hosting provider.