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

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

Hi Mark,

Some responses below, in-line.

Saludos,
Jordi

@jordipalet


> El 16 abr 2026, a las 7:46, marka <[e-mail]> escribió:
> 
> 
> 
>> On 15 Apr 2026, at 17:10, [e-mail] <jordi.palet=[e-mail]> wrote:
>> 
>> Hi Mark,
>> 
>> In line, below.
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 14 abr 2026, a las 23:20, Mark Andrews <[e-mail]> escribió:
>>> 
>>> Continuing on:
>>> 
>>> I was using my iPhone as a hot spot and tests that just work when normally work just started falling.  This is all because people interfere with address lookups. We have decades of complaints about people interfering with address lookups.  There was the whole Site Finder snafu.
>> 
>> So you’re saying that is not DNS64, but many wrong deployments of DNS by interfering with lookups?
> 
> DNS64 (or any other manipulation at the DNS layer) fails to take into account ROUTING.
> Yes, even machines with a single external interface do routing.  DNS64 says to do address
> translation when DNSSEC is in use after discovering the prefix.  Apple does this with
> IPv6 mostly and it DOES NOT WORK.
> 
> CLAT happens AFTER routing is performed.  As a result only the packets that are sent to
> the CLAT get translated.  Packets that get sent to other interfaces get delivered as
> intended.

I haven’t heard about Apple implementation being broken.

> 
>>> DNS64 “appears” to work because there are still not a lot of zones that are signed and most of them also are IPv6 enabled.  Add to that all the OS vendors that have been slack in deploying DNSSEC on the devices they ship.  
>>> 
>> 
>> Agree, and it seems we are in agreement also that any DNSSEC deployment, in 2026, should be also with IPv6.
>> 
>>> Now BIND doesn’t do DNS64 as described.  It does an approximation of it.
>> 
>> I’m not sure to follow what you mean. BIND doesn’t follow RFC6147 or ? What is different, may be we could learn about that and see how to improve it.
> 
> The whole "break-dnssec yes/no;” is not part of DNS64.  BIND, by default, does not perform DNS64 mapping
> if the request has DO=1 and the response to be sent is signed.

My reading of RFC6147 is that this is in section 5.5.3. A different question is if only bind is implementing it as “we don't follow 5.5.3 you decide to change break-dnssec to yes”.

> 
>>> DNS64 isn’t needed anywhere. 464XLAT doesn’t needed it.  Discovery of the prefix doesn’t need it. You can just publish an ip4only.arpa zone with the correct AAAA records.
>> 
>> That’s a different problem. RFC7050 is what I think is broken and not needed and actually I believe not being used in actual deployments. I’ve asked in private to the major vendors of mobile OSs, will report to the list when they reply. That’s also why asked folks in v6ops to test by themselves if they have their mobiles in an operator doing 464XLAT.
> 
> Mobiles don’t do the things you do with a desktop machine.
> 
>> I don’t agree DNS64 is not needed, it avoids double translation and helps optimizing timing.
> 
> So does just preferring IPv6 addresses when they are available.
> 
>>> Figuring out how to do DNS64 correctly  automatically is impossible even ignoring DNSSEC.  You just break things.
>> 
>> Don’t agree here, but happy to learn what may be broken apart for DNSSEC.
> 
> For DNS64 to work properly you need to encode routing into the DNS64 configuration.
> It works reasonable well when you use RFC1918 addresses internally and exclude them
> from the translation.  It doesn’t work well when you use other address ranges
> internally.
> 
> On a mobile you usually only have external address and loopback 127.0.0.1/::1.  Thats
> a very simple device routing wise.   A desktop machine quite often has virtual machines
> coming and going on it, other addresses configured on the loopback, etc.  The DNS64
> configuration has to be adjusted for all of these changes and the server may not
> even be on the same machine.
> 
> Mark
> 
>>> -- 
>>> Mark Andrews
>>> 
>>>> On 15 Apr 2026, at 06:42, Mark Andrews <[e-mail]> wrote:
>>>> 
>>>> Even local synthesis es wrong. It is at the wrong level in the stack.  I had test fail on my Mac because curl decided that 10.53.0.4 was out on the internet despite it being an address on the loopback interface.
>>>> 
>>>> The
>>>> --
>>>> Mark Andrews
>>>> 
>>>>> On 15 Apr 2026, at 04:42, Ted Lemon <[e-mail]> wrote:
>>>>> 
>>>>> I think it's also worth asking whether the devices that care about DNSSEC or DOH are the devices that don't do local synthesis. E.g. I'm pretty sure Apple devices will do local synthesis. I get the sense that Google devices will as well. Not sure about Windows, maybe Jen Linkova knows? Also not sure about Linux, probably varies. Of course, if e.g. your browser is doing DoH, it may not bother with DNSSEC anyway, even if your local resolver does do DNSSEC. But it had better do local synthesis, or it's not going to work in a v6only NAT64 environment regardless of whether or not DNS64 is present.
>>>>> 
>>>>> But my point is, your printer that's downloading firmware probably isn't doing DNSSEC validation, although it should, and it's probably not using DoH to bypass the local resolver either.
>>>>> 
>>>>>>>> On 14 Apr 2026, at 19:57, Philip Homburg <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> 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
>>>>>> 2) Any kind of local DNSSEC validation, either in the stub resolver or in
>>>>>> a local DNS forwarder.
>>>>>> 3) Any resolver configuration that by-passes the local (DNS64) resolver
>>>>>> such as an (optionally DoH, DoT) connection to a public resolver.
>>>>>> 4) Any kind of code that implement STUN for IPv4 but not for
>>>>>> IPv6.
>>>>>> 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.
>>>>>> 
>>>>>> A few corners cases:
>>>>>> 6) A DNS recursive resolver
>>>>>> 7) DNS code that tries to disable EDNS Client Subnet
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> v6ops mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>> 
>>>>> _______________________________________________
>>>>> v6ops mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>> 
>>> _______________________________________________
>>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> DNSOP mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [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.