In my experience, the possible breach of DNSSEC in actual NAT64+DNS64 deployments is meaningless, and the advantages vastly supersede that.
In all of the cases, the DNS64 server, default configuration, avoids breaking DNSSEC. I recall an article from Jen, a few years ago, that mention 1.7% chances of breaking DNSSEC. Assuming that more and more people deploying DNSSEC also deployed or should be deploying IPv6, that problem vanishes. In my own deployment experience in hundreds of NAT64+DNS64 deployment, I have *never* seen a single failure (or at least it was not reported to me) and be sure that I paid a lot of attention to this. Has anyone with real deployment experience a different perspective? Clearly it will be very important to know that. We also should remember that if a specific server in Internet, or a set of them, have this problem, the DNS64 server configuration always allow to exclude them from the synthesis. So no harm is created, and as said the advantages supersede those cases. Also, how many mobile or fix operating systems are actually verifying DNSSEC so DNS64 in case the DNS64 server is not able to fix it, is broken? Regards, Jordi @jordipalet > El 10 abr 2026, a las 9:13, Ole Trøan <[email protected]> escribió: > > Mohamed, > > Exactly, and I think there are concerns raised against “successful > operational experience”. > And of course the IETF does not reclassify any or all documents just because > they fulfil the criteria. > > Ole > >> On 10 Apr 2026, at 06:07, [email protected] wrote: >> >> Hi all, >> >> Brian clarified the point, but I'd like to remind the exact criteria >> required by this process: >> >> The request for reclassification is sent to the IESG along with an >> explanation of how the criteria have been met. The criteria are: >> >> (1) There are at least two independent interoperating implementations >> with widespread deployment and successful operational experience. >> >> (2) There are no errata against the specification that would cause a >> new implementation to fail to interoperate with deployed ones. >> >> (3) There are no unused features in the specification that greatly >> increase implementation complexity. >> >> (4) If the technology required to implement the specification >> requires patented or otherwise controlled technology, then the >> set of implementations must demonstrate at least two independent, >> separate and successful uses of the licensing process. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Brian E Carpenter <[email protected]> >>> Envoyé : jeudi 9 avril 2026 22:21 >>> À : Paul Vixie <[email protected]>; [email protected] >>> Cc : IPv6 Operations <[email protected]>; Philip Homburg <pch-dnsop- >>> [email protected]> >>> Objet : [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147) to >>> Internet Standard >>> >>> >>> On 10-Apr-26 07:17, Paul Vixie wrote: >>>> On Thursday, April 9, 2026 12:12:12 PM PDT Philip Homburg wrote: >>>> >>>>>> ... >>>> >>>>> >>>> >>>>> In my opinion we should strongly discourage deploying DNS64. >>> So >>>> moving >>>> >>>>> DNS64 to Internet Standard sends completely the wrong >>> message. >>> >>> I'm very torn on that, because like it or not DNS64 is stable, >>> well-defined, and widely implemented. (I'd also prefer to abolish >>> the problem by abolishing the distinction between Proposed >>> Standard and Internet Standard, but that's another story.) >>> >>>> >>>> so, i agree, but: >>>> >>>>> DNS64 is incompatible with local DNSSEC validation. This >>> combines >>>> the > worst of both worlds: something doesn't work both because >>> of >>>> DNSSEC and > IPv6. >>>>> >>>>> New deployments of NAT64 should either use some kind of >>> address >>>> synthesis > in a library or deploy a CLAT. >>> >>> I don't think there's much disagreement with that. >>> >>>> we should not need new deployments of v6/v4 transition >>> technology almost 20 years after june 6 2006, and it's time for >>> the IETF to occupy that position. >>> >>> But we still do need co-existence for very practical reasons. >>> That's why v6ops is developing the IPv6-mostly approach in draft- >>> ietf-v6ops-6mops, which explicitly says: >>> "Those concerns make DNS64 a suboptimal and undesirable solution >>> long-term. >>> To eliminate the needs for DNS64..." etc. >>> >>> So we might end up with DNS64 completely meeting the requirements >>> for Internet Standard status and being operationally deprecated. >>> Yes, it's a paradox. >>> >>> Brian >>> >>> _______________________________________________ >>> DNSOP mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> _______________________________________________ >> DNSOP mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > v6ops mailing list -- [email protected] > To unsubscribe send an email to [email protected] ********************************************** 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 -- [email protected] To unsubscribe send an email to [email protected]
