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

Philip Homburg <pch-dnsop-7@u-1.phicoh.com> Tue, 14 April 2026 17:57 UTC

Return-Path: <pch-b55F8B228@u-1.phicoh.com>
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 A8C2FDC286D0; Tue, 14 Apr 2026 10:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776189462; bh=9ts+wCxLRnyUuSg33yAIyVXNto+0lD/BxOmROicahpI=; h=To:Cc:Subject:From:References:In-reply-to:Date; b=LuyD7thPjx9I5q+aCkIADap5+uYxv8Qh6lDCFBqAE5SwlJHu2qeQSEZ2S+lZ3m0E+ /SMUEwQGjKYkUByTqUoMF+BBE5egmxC9zkWC9RzYZYMqFNwbEhYesxWbTVy2+OqJFX nrIVGe1nEOjbyQpq/GQPxxoM+K+UKS2OPhEvJjoE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
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 8bPiJp9lGWTG; Tue, 14 Apr 2026 10:57:42 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3EEEADC286CB; Tue, 14 Apr 2026 10:57:42 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305) (Smail #158) id m1wCi0t-0000Q7C; Tue, 14 Apr 2026 19:57:27 +0200
Message-Id: <m1wCi0t-0000Q7C@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-7@u-1.phicoh.com>
Sender: pch-b55F8B228@u-1.phicoh.com
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> <25022.1775841874@obiwan.sandelman.ca> <m1wBGFD-0000PhC@stereo.hq.phicoh.net> <5539.1775850116@obiwan.sandelman.ca> <m1wCHUo-0000QZC@stereo.hq.phicoh.net> <5A969A5C-EE2A-4581-AAC3-20A1423D0D43@consulintel.es>
In-reply-to: Your message of "Mon, 13 Apr 2026 15:45:43 +0200 ." <5A969A5C-EE2A-4581-AAC3-20A1423D0D43@consulintel.es>
Date: Tue, 14 Apr 2026 19:57:27 +0200
Message-ID-Hash: 2QBNY25RIJ2VOFBHNLJUX5LPAHFAN3RK
X-Message-ID-Hash: 2QBNY25RIJ2VOFBHNLJUX5LPAHFAN3RK
X-MailFrom: pch-b55F8B228@u-1.phicoh.com
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: "jordi.palet@consulintel.es" <jordi.palet=40consulintel.es@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [v6ops] Re: 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/fk_YHqSFDjOqPlf4bva4z1tq6Yc>
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 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.