[DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 (RFC6147) to Internet Standard

["[e-mail]" <[e-mail]>]

Hi Philip,

See below in-line.

Saludos,
Jordi

@jordipalet


> El 14 abr 2026, a las 19:57, Philip Homburg <[e-mail]> escribió:
> 
>> I will like to see that long list of things that dont work with
>> DNS64 in the real world.
> 
> I don't have a complete list, but here is a start. Let's assume a host
> that relies on DNS64 to obtain IPv4 connectivity. What doesn't work in
> that case:
> 1) An IPv4 literal

This is not a DNS64 issue, it is NAT64, that’s why we invented 464XLAT.

> 2) Any kind of local DNSSEC validation, either in the stub resolver or in
>   a local DNS forwarder.

This is incorrect if you properly configure the DNS64 server (by default, as explained in an earlier email, bind9 does it correctly).
There may be corner cases, I’ve not seen those, but in lab I can force them and I can configure the DNS64 servers to avoid them. You can exclude specific destinations from synthesis. You can also exclude hosts behind the DNS64 servers to not get synthesised responses, etc.

The point here is how much of this happens in real deployments *not labs* and if that happens, how much can’t be avoided. What I’m asking is a list of failures in mobile or fix DNS64 deployments. I never hear about such cases from operators deploying DNS64.

Any protocol can be broken, either because a wrong deployment, corner cases, or a mix of both. We can break DMARC, SPF, MPLS, HTTP, QUIC, whatever we look for. Most of the time there are details in the deployment that are not 100% perfect. That doesn’t means that the protocols is wrong or broken, or should not be recommended, you need to put the right balance, because I doubt every protocol can be perfect, so how much resolves  vs how much breaks that can’t be fixed by a better deployment model.

> 3) Any resolver configuration that by-passes the local (DNS64) resolver
>   such as an (optionally DoH, DoT) connection to a public resolver.

If you bypass the DNS64 then is not a DNS64 failure. In fact, if you have only NAT64, it will not work at all. So that’s not a DNS64 failure, is part of the NAT64 deployment model. If you have 464XLAT this doesn’t happen, because CLAT will do an extra translation, so by not using DNS64 you have 2 translations instead of one and you lose some connection optimization. Please see the discussion about all this points and different deployment models in RFC 8683.

> 4) Any kind of code that implement STUN for IPv4 but not for
>   IPv6.

Haven’t seen that happening in real deployments, anyway I think it is a NAT64 issue?

> 5) As far as I can tell, any kind of code that tries STUN on an IPv6 address
>   that was mapped by the DNS64 resolver.
> 

Not sure about that, but same as the previous one, haven’t seen that in real deployments.

> A few corners cases:
> 6) A DNS recursive resolver

I don’t think if you have a DNS you will be behind a NAT64/DNS64, I will always recommend that a DNS resolver must have dual-stack. In fact I believe there is a document about that. In my deployments, typically I suggest that enterprise networks should be dual-stack in the access if they have any kind of DC facilities.

> 7) DNS code that tries to disable EDNS Client Subnet

Didn’t saw that in actual deployments, so again not sure about that.

> 
> I think there are more protocols that somehow encode whether IPv4 or IPv6
> is used, but this is just from the top of my head.

My point, may be I was not clear in previous emails, is that DNS64 has been widely deployed and we aren’t getting *any* reports from operators or customer complains that this or that is not working anymore after you provided me the 464XLAT service instead of just IPv4 or dual-stack. This is the list I will love to have. What is being broken in *real world*. And then we can analyse if there is something in that deployment that is not being done correctly (for example, if someone disabled “do not break dnssec in bind9” (obviously will get broken), and also if we are unable to fix those cases either with a correct deployment or using exclusions for destinations or ACLs for internal customers of the DNS64, etc. All that can be done in bind9, as well as in other DNS64-capable servers.

What we can improve in RFC6747-bis is to add an applicability statement, or something similar, regardless or advancing it or not. Those are different discussions in my opinion, but clearly not deprecate it.

> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.