[DNSOP] Re: draft-ietf-dnsop-3901bis
Tobias Fiebig <tobias@fiebig.nl> Mon, 11 August 2025 08:10 UTC
Return-Path: <tobias@fiebig.nl>
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 EDA40527C6D7 for <dnsop@mail2.ietf.org>; Mon, 11 Aug 2025 01:10:03 -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 (2048-bit key) header.d=fiebig.nl
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 p3ccT8yYErlH for <dnsop@mail2.ietf.org>; Mon, 11 Aug 2025 01:10:03 -0700 (PDT)
Received: from mail.aperture-labs.org (mail.aperture-labs.org [195.191.197.3]) (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 D09F6527C6D2 for <dnsop@ietf.org>; Mon, 11 Aug 2025 01:10:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiebig.nl; s=key01; t=1754899800; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q1mC21CCXTeuZRRLH/0Jc6leSPm7CdlaSfjVhRMI5S0=; b=cp1Wz7eJzanWlicT9hfbkHXlA7rintPJYpdxbY07oDQtx+P4/scPkKXhcb38ZJP+RJh45N /mZbq4j34ooNdsNa2TZUS2HiKbNXKSwUxsWBbeYdg1teOum6AhzEJ18yoNhzhZcKU05CcC Z7l4BCki9xcCQ9OItsW8yqZyY7AB+Qanhz4f7yB/FSGAhZD4waqcGG5JJZoFmK1lx2B3l/ jUVmLLvY10f76qntckDvR/LQ7MS7arNxdHn/tH/0VZMFhr4HXHEWCNg1ciljfLDu3VHtGc +UvZLMfcC08dUkOn6WKJRraSOB1eGNASqOnC/I9fdFRDwbFYu20PzV6wpfRN6w==
Received: by mail.aperture-labs.org (OpenSMTPD) with ESMTPSA id e1a4ff61 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) auth=yes user=tobias@aperture-labs.org for <dnsop@ietf.org>; Mon, 11 Aug 2025 08:10:00 +0000 (UTC)
Message-ID: <f92ed89cf4eac68860c9a45927f20b592ca9a67c.camel@fiebig.nl>
From: Tobias Fiebig <tobias@fiebig.nl>
To: dnsop@ietf.org
Date: Mon, 11 Aug 2025 10:09:57 +0200
In-Reply-To: <05AC29AA-840B-439E-81CD-316459522478@isc.org>
References: <05AC29AA-840B-439E-81CD-316459522478@isc.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2
MIME-Version: 1.0
Message-ID-Hash: XEBVJNULNCLKLRTZONTUTP6NJZ3IKZXO
X-Message-ID-Hash: XEBVJNULNCLKLRTZONTUTP6NJZ3IKZXO
X-MailFrom: tobias@fiebig.nl
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
Reply-To: tobias@fiebig.nl
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/nfEaxzQ2yuRlV0zAfnqZx5SPwcU>
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>
Moin, sorry for the high RTT; Had some unexpected events after 123. On Tue, 2025-08-05 at 11:50 +1000, Mark Andrews wrote: > Repeating so this gets tied to the draft name. > > ... > > 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. No, actually it does not need to access the routing table. The process is: - Configure PREF64 (2001:db8:6464::/96) in daemon - Daemon gets: example.com IN NS ns01.example.com ADDITIONAL ns01.example.com IN A 192.0.2.1 It then calculates 2001:db8:6464::c000:201 from that and just directly opens an IPv6 socket to talk to 2001:db8:6464::c000:201. This effectively skips one step of translation. Beyond 'skipping a translation step', hence reducing the need for state-keeping in the kernel doing said translation', the advantage is that this is a much more straight forward way of configuring things on a host that generally does not do XLAT, e.g., a recursive DNS server run by a provider, i.e., not a client/stub behind XLAT for anything but the service (i mean; what is there? Management and getting packages from an ideally local mirror). This is basically also described here: https://www.ietf.org/archive/id/draft-ietf-v6ops-ipv6-only-resolver-00.html (Expired, hence touched upon in the -bis) Unbound actually already implements this feature: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-nat64 And I am running 2a06:d1c7:: as a (semi public cause rate limited but usually works good enough) public resolver using that feature. > 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. See above; I would argue, though, that the benefit of 'skip one additional translation step and state keeping' still outweighs things here. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl Pronouns: he/him/his
- [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