[DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147) to Internet Standard
"jordi.palet@consulintel.es" <jordi.palet@consulintel.es> Mon, 13 April 2026 15:12 UTC
Return-Path: <prvs=1563c5a74c=jordi.palet@consulintel.es>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 98450DB54053; Mon, 13 Apr 2026 08:12:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776093156; bh=3QRlLqtTw+qZM/6rBQoUXrDLleFKgi1xsNxNRYihbwI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IA2p5UCCM2efWv2xfq+VgRrbyXW8CqwRCmCDr6L92wNUA8h14GsJZKhlgkYlIuhV6 dPPEzefJ2xVwxqN2AM7pjAHuPpCp7GWCfd9O6i+eYmLpTGEPUCnzTjH1vLCZ8Eym0y hpsavave8qRp545xB0svV2CuJo1Oe19DdJEiyd9g=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=consulintel.es
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1MKXe13HdQp; Mon, 13 Apr 2026 08:12:35 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 98A11DB53ED5; Mon, 13 Apr 2026 08:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=consulintel.es; s=mailer; t=1776093145; x=1776697945; i=jordi.palet@consulintel.es; q=dns/txt; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; bh=vgjY1H8cc MP2jCrYmEnIF7W7n6ofa669CsxL9bDThqU=; b=KbIE1pCaGXvYqdRYSP3BM7vPZ qDarktlvPHJY4dc4ZrexoNFFCvFC6L/TA3j+dyF04/YeDQrZYPR+ZXCQlQPqemkW jMwT6sw2ybcG86H4xnt0rkXqHW7QvOkwDPs+H41/5aC9IsRCaqnOGT5+bFI25q4M hJZE6SKTdcsWDRxFPJAyr5qhy2VgmheEnJ9SUR/R/2zqWU5Xw4kb5LOMQwVYEUjo P9YBHpo+Rffk2P7f26IAGcuPLg5zvoMx+bw0SOat9tQZjEXBaMlSeUg9ekh/NJnM vmWbyn9n/KMkWjXUZdwUB90RKSTgR1tSIP3g2G1Vi5qLJDDOeHMJmVzDTdCIA==
X-MDAV-Processed: mail.consulintel.es, Mon, 13 Apr 2026 17:12:24 +0200 (not processed: message from trusted source)
X-Spam-Processed: mail.consulintel.es, Mon, 13 Apr 2026 17:12:24 +0200
Received: from smtpclient.apple by mail.consulintel.es (10.10.10.5) (MDaemon PRO v25.5.0) with ESMTPSA id md5001002622830.msg; Mon, 13 Apr 2026 17:12:22 +0200
X-MDRemoteIP: 2001:470:1f09:495:39c0:8573:a909:1d84
X-MDArrival-Date: Mon, 13 Apr 2026 17:12:22 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1563c5a74c=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
From: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>
In-Reply-To: <13416.1776092025@obiwan.sandelman.ca>
Date: Mon, 13 Apr 2026 17:12:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1EA4646-93B5-4BCE-9853-3BFF20339D27@consulintel.es>
References: <m1wAunU-0000NEC@stereo.hq.phicoh.net> <2338256.t9SDvczpPo@localhost> <038ae9d1-34fc-4085-aa6d-76ef79287857@gmail.com> <PARP264MB6760A67BB8F2060962E8A64088592@PARP264MB6760.FRAP264.PROD.OUTLOOK.COM> <B93DB6C8-2974-4915-93DE-DFCB6B858AFA@consulintel.es> <m1wB6jW-0000VYC@stereo.hq.phicoh.net> <9A70D5B5-F58A-471E-9CC6-7A0874B53B80@consulintel.es> <m1wCHbM-0000ORC@stereo.hq.phicoh.net> <13416.1776092025@obiwan.sandelman.ca>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3864.500.181)
X-MDCFSigsAdded: consulintel.es
Message-ID-Hash: TQV2QQMNOEFBQUQ2PQY3N6VSYE3E3AM3
X-Message-ID-Hash: TQV2QQMNOEFBQUQ2PQY3N6VSYE3E3AM3
X-MailFrom: prvs=1563c5a74c=jordi.palet@consulintel.es
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IPv6 Operations <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147) to Internet Standard
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PubTEw9KaOOSen23eAGfFjTmsOA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
I think the point is that we are assuming that in all the cases, DNSSEC is broken using DNS64 if there is no CLAT, or there is a DNSSEC validating proxy, or whatever, and this is incorrect.
That’s ignoring that if you *properly* configure the DNS64 servers, they will do the right thing and in some cases will not do the synthesis.
For example, in the case of bind9 you have by default “break-dnsec no;"
In some strange cases, you could also set special exclusions to avoid some destinations to be synthesised.
If you don’t have a CLAT (so NAT64+DNS64 case), it means those DNSSEC destinations can’t be reached at all if the host or the access network is IPv6-only. That’s why in most of the cases, NAT64+DNS64 is a bad idea (unless the host can do self-synthesis), and that’s why we invented 464XLAT. Clearly this is a very different problem, is not DNS64 breaking anything, is the destination deploying DNSSEC and not considering that there are IPv6-only networks or hosts that will only work if they deploy DNSSEC+IPv6.
So repenting myself, do we have real world deployment cases where there are complains of DNSSEC being broken?
Rergards,
Jordi
@jordipalet
> El 13 abr 2026, a las 16:53, Michael Richardson <mcr+ietf@sandelman.ca> escribió:
>
>
> Philip Homburg <pch-dnsop-7@u-1.phicoh.com> wrote:
>> You never installed a DNSSEC validating proxy on a laptop without CLAT?
>
> Yes, I've done it. Any bog-standard Ubuntu laptop with systemd-resolve usually has
> DNSSEC enabled, and has no CLAT. (Of course, systemd-resolver screws up so
> badly for other reasons, one usually has to disable it)
> I agree, it's a fail.
>
>>> I think the point is to understand that DNSSEC with DNS64 is broken
>>> only in a very very very small % of situation, which can also be
>>> resolved.
>
>> The problem with DNS64 is that it seems to work (to some extent at least)
>> without CLAT. But as soon as you install a DNSSEC validating proxy,
>> or some other DNSSEC validation, access to IPv4 is lost.
>
> From what I understand, Smartphones, Windows and OSX all have CLATs, but do
> not come with DNSSEC enabled by default. I think that those systems are all
> moving (perhaps slowly) to PREF64 and local synthesis. That's good, right?
>
>> That means that devices that rely on DNS64 make it is a lot harder to
>> deploy those technologies.
>
> Only if they are mobile/nomadic.
> If they stay in one place, one does whatever the correct thing is.
> Remember that people deploying IPv6-{mostly,only} **today** know what the correct
> thing is. If DNS64 goes away, then many servers will have to go back to
> dual-stack. That's who loses.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
> ** My working hours and your working hours may be different. **
> ** Please do not feel obligated to reply outside your normal working hours **
>
>
>
>
**********************************************
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] Moving DNS64 (RFC6147) to Internet Standa… mohamed.boucadair
- [DNSOP] Re: [v6ops] Moving DNS64 (RFC6147) to Int… Scott Morizot
- [DNSOP] Re: Moving DNS64 (RFC6147) to Internet St… Philip Homburg
- [DNSOP] Re: Moving DNS64 (RFC6147) to Internet St… Paul Vixie
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Brian E Carpenter
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… mohamed.boucadair
- [DNSOP] Re: [v6ops] Moving DNS64 (RFC6147) to Int… Chenhao Ma
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Ole Trøan
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Michael Richardson
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Michael Richardson
- [DNSOP] Re: [Ext] Re: [v6ops] Re: Re: Re: Moving … Paul Hoffman
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … Nick Buraglio
- [DNSOP] Re: [v6ops] Moving DNS64 (RFC6147) to Int… Dan Wing
- [DNSOP] Re: [v6ops] Moving DNS64 (RFC6147) to Int… Philip Homburg
- [DNSOP] Re: [v6ops] Moving DNS64 (RFC6147) to Int… Ole Trøan
- [DNSOP] Re: [Ext] Re: [v6ops] Re: Re: Re: Moving … Michael Richardson
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Michael Richardson
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] [Ext] Re: Re: Re: Re: Moving … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Moving DNS64 (RFC6147) to Int… mohamed.boucadair
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Gert Doering
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Tim Chown
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Michael Richardson
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … Brian E Carpenter
- [DNSOP] Re: [Ext] Re: [v6ops] Re: Re: Re: Moving … Warren Kumari
- [DNSOP] Re: [Ext] Re: [v6ops] Re: Re: Re: Moving … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … Ted Lemon
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Re: Moving DN… Mark Andrews
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Re: Moving DN… Mark Andrews
- [DNSOP] Re: [v6ops] Re: [Ext] Re: Re: Re: Re: Mov… Michael Richardson
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Re: Moving DN… Brian E Carpenter
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Michael Richardson
- [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147… Michael Richardson
- [DNSOP] Re: [v6ops] Re: [Ext] Re: Re: Re: Re: Mov… Brian E Carpenter
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Moving DNS64 (RFC… Philip Homburg
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … marka
- [DNSOP] (Concluded) RE: Moving DNS64 (RFC6147) to… mohamed.boucadair
- [DNSOP] Re: (Concluded) RE: Moving DNS64 (RFC6147… jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Moving DNS64 … jordi.palet@consulintel.es
- [DNSOP] Re: [v6ops] Re: Re: Re: Re: Re: Moving DN… Philip Homburg
- [DNSOP] Re: (Concluded) RE: Moving DNS64 (RFC6147… Philipp Tiesel
- [DNSOP] Re: (Concluded) RE: Moving DNS64 (RFC6147… jordi.palet@consulintel.es