[DNSOP] Re: draft-ietf-dnsop-3901bis
Mark Andrews <marka@isc.org> Tue, 05 August 2025 01:51 UTC
Return-Path: <marka@isc.org>
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 AF5234FCBFA3 for <dnsop@mail2.ietf.org>; Mon, 4 Aug 2025 18:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="ZE50uPzX"; dkim=pass (1024-bit key) header.d=isc.org header.b="N5J84J8Y"
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 3vb4PJdOSeSM for <dnsop@mail2.ietf.org>; Mon, 4 Aug 2025 18:51:00 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 459A44FCBF9E for <dnsop@ietf.org>; Mon, 4 Aug 2025 18:51:00 -0700 (PDT)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 802CF4D0BF7 for <dnsop@ietf.org>; Tue, 05 Aug 2025 01:50:59 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 802CF4D0BF7
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1754358659; cv=none; b=GhURJU5+QSxSqPPugSmx9fTPcHnKj0pKilFlnaTZdmz+yloTQ9BAPbYYEtNb0HwIRI1t668n8Z1GJCirRp8Lwr/g96AQL6Me5ZrhZu8meiCa+ivlUpWOhwh74FaieWCP/hCQsHAwj4oOde9jlvL5f5DqPUNFx2MoRv4FtrcssE0=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1754358659; c=relaxed/relaxed; bh=+bMvnejXeOXFky9+c9a+w1M0s7EKh7ASrrqeIuKgtKk=; h=DKIM-Signature:DKIM-Signature:From:Mime-Version:Subject: Message-Id:Date:To; b=TauOrn0etSFHlR5SDJgPfgYAWX3/hIs4No0G+yjx3Xbu2eLzBw20EddvySxkk61UmDm8u/NYxAFAbXYw1xaS9GYZnBIzVIpD24aFB7AB7EnwS5+Eu7+iGX+3qOrannjtluj3+5vjgLKakvF1pMvNFsQRnSHN3Rqy0xdajekwbNA=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 802CF4D0BF7
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1754358659; bh=Sg02dcFNX2FRWlN2ZDEI1+9gUColHuUwQbCuXVXjQDw=; h=From:Subject:Date:To; b=ZE50uPzXbEyuc2o4TI8IR9nndHuwiUvlMtQWjVDi1VsZpSNtTVf1v0BaxgwVw1hix rjZpTOiphXfiIN6LrAq+ni9bf9TSaMlhFuwMrwVeeAoW8+1wgA1Gon1C5bVDjrcaG7 Hc6MXo2g/m4VSWFBGzjwsDyYVdpfZbE1b62w+2gI=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 7C3262E601C9 for <dnsop@ietf.org>; Tue, 5 Aug 2025 01:50:59 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 78A3C2E601CA for <dnsop@ietf.org>; Tue, 5 Aug 2025 01:50:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org 78A3C2E601CA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1754358659; bh=+bMvnejXeOXFky9+c9a+w1M0s7EKh7ASrrqeIuKgtKk=; h=From:Mime-Version:Message-Id:Date:To; b=N5J84J8YTdBdtbeRsjoXBbHQHgay7lZBZ1q1Xw2eqtQmENF6K4nfxdTNzeAtNRPEQ CqLjbgdi6biTUF6yFaD8PtkGiPF9X+VZdddeFl8WJCcCAoijwPxHBGglrzjTc1wWhI kCfsC+kFvV0O3Gu6e11nPdONNrCNHAgYGNzFsk4I=
Received: from smtpclient.apple (n49-187-18-238.bla1.nsw.optusnet.com.au [49.187.18.238]) by zimbra10.isc.org (Postfix) with ESMTPSA id DC1F72E601C9 for <dnsop@ietf.org>; Tue, 5 Aug 2025 01:50:58 +0000 (UTC)
From: Mark Andrews <marka@isc.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.11\))
Message-Id: <05AC29AA-840B-439E-81CD-316459522478@isc.org>
Date: Tue, 05 Aug 2025 11:50:45 +1000
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3731.700.6.1.11)
Message-ID-Hash: QHDH7TML37Y6DKGR2KXRDT5P2OE2UGW7
X-Message-ID-Hash: QHDH7TML37Y6DKGR2KXRDT5P2OE2UGW7
X-MailFrom: marka@isc.org
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: draft-ietf-dnsop-3901bis
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ric5B0QQ0-0xgElWZ4BdQVxL9DU>
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>
Repeating so this gets tied to the draft name. Guidelines for DNS Resolvers states: If a recursive DNS resolver runs in a network that uses XLAT [RFC6877], and the recursive DNS resolver is aware of the used PREF64 [RFC6146], it SHOULD synthesize mapped IPv6 addresses for remote authoritative DNS servers directly for DNS resolution, instead of relying on the socket translation layer of the operating system. A recursive DNS resolver SHOULD prefer non-synthesized IPv6 addresses over synthesized IPv6 addresses based on a PREF64. Additionally, the PREF64 in use MAY also be statically configured for the DNS resolver. I am going to be contrary here and say that DNS servers MUST NOT synthesis IPv6 address records from the PREF64 option. This is the wrong level of the stack to perform this translation as the DNS server is not an IP router and to do this properly the DNS server would need to process the kernels routing table. Just use the IPv4AAS built into the operating system as it reached via the routing table in the kernel. The DNS is an application that deals with IP literals. CLAT is the correct mechanism to deal with this with XLAT as is B4 with DS-Lite. For anyone here at IETF that has an OS that supports IPv6 mostly, connect the “ietf” network and fire up a DNS server and perform DNS lookups using that server. You will see that they just work regardless of whether the zones are served by IPv4 only, dual stack or IPv6 only. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [DNSOP] Re: draft-ietf-dnsop-3901bis Mark Andrews
- [DNSOP] Re: draft-ietf-dnsop-3901bis Tobias Fiebig
- [DNSOP] Re: draft-ietf-dnsop-3901bis Tobias Fiebig
- [DNSOP] Re: draft-ietf-dnsop-3901bis Mark Andrews
- [DNSOP] Re: draft-ietf-dnsop-3901bis Tobias Fiebig
- [DNSOP] Re: draft-ietf-dnsop-3901bis Mark Andrews
- [DNSOP] Re: draft-ietf-dnsop-3901bis Tobias Fiebig
- [DNSOP] Re: draft-ietf-dnsop-3901bis Philipp S. Tiesel
- [DNSOP] Re: draft-ietf-dnsop-3901bis Tommy Jensen