Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-11.txt
Florian Obser <florian+ietf@narrans.de> Tue, 08 August 2023 18:27 UTC
Return-Path: <florian+ietf@narrans.de>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A769C153CBF for <dns-privacy@ietfa.amsl.com>; Tue, 8 Aug 2023 11:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP0BA_SCHWgM for <dns-privacy@ietfa.amsl.com>; Tue, 8 Aug 2023 11:27:45 -0700 (PDT)
Received: from imap.narrans.de (michelangelo.narrans.de [IPv6:2001:19f0:6c01:821:5400:1ff:fe33:a36d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC40C1524DB for <dns-privacy@ietf.org>; Tue, 8 Aug 2023 11:27:43 -0700 (PDT)
Received: from pinkunicorn (2001-1c00-270d-e800-945d-d130-d60c-4116.cable.dynamic.v6.ziggo.nl [2001:1c00:270d:e800:945d:d130:d60c:4116]) by michelangelo.narrans.de (OpenSMTPD) with ESMTPSA id affc16a0 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <dns-privacy@ietf.org>; Tue, 8 Aug 2023 20:27:38 +0200 (CEST)
From: Florian Obser <florian+ietf@narrans.de>
To: dns-privacy@ietf.org
In-Reply-To: <169151485727.52839.10580373736526971224@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Tue, 08 Aug 2023 10:14:17 -0700")
References: <169151485727.52839.10580373736526971224@ietfa.amsl.com>
Date: Tue, 08 Aug 2023 20:27:36 +0200
Message-ID: <m1msz1tmnb.fsf@narrans.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/MFAmHRLu-9M7uLRIynjNzv1ZE8A>
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-11.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2023 18:27:50 -0000
On 2023-08-08 10:14 -07, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the DNS PRIVate Exchange > (DPRIVE) WG of the IETF. > > Title : Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS > Authors : Daniel Kahn Gillmor > Joey Salazar > Paul Hoffman > Filename : draft-ietf-dprive-unilateral-probing-11.txt > Pages : 33 > Date : 2023-08-08 This introduced at least a nit For example, consider an authoritative server named ns0.example.com that is served by two installations (with two A records), one at 192.0.2.7 that follows this guidance, and one at 2001:db8::8 that is a legacy (cleartext port 53-only) deployment. It doesn't have two A records. It has an A and AAAA record. I know that Éric asked for a non-legacy IP example, but I don't think this makes things better. I find it very confusing, usually the server would be dual stacked so why would it do different things depending on the address family? Maybe just go v6 only, thusly? For example, consider an authoritative server named ns0.example.com that is served by two installations (with two AAAA records), one at 2001:db8::7 that follows this guidance, and one at 2001:db8::8 that is a legacy (cleartext port 53-only) deployment. A recursive client who associates state with the NS name and reaches 2001:db8::7 first will Same in 4.5: For example, if a recursive resolver can send a packet to authoritative servers from IP addresses 192.0.2.100 and 2001:db8::200, it could keep two distinct sets of per-authoritative- IP state, one for each source address it uses, if the recursive resolver knows the addresses in use. Keeping these state tables distinct for each source address makes it possible for a pooled authoritative server behind a load balancer to do a partial rollout while minimizing accidental timeouts (see Section 3.1). It seems unlikely that the load balancer would do a address family translation. Maybe: For example, if a recursive resolver can send a packet to authoritative servers from IP addresses 2001:db8::100 and 2001:db8::200, it could keep two distinct sets of per-authoritative- -- In my defence, I have been left unsupervised.
- [dns-privacy] I-D Action: draft-ietf-dprive-unila… internet-drafts
- Re: [dns-privacy] I-D Action: draft-ietf-dprive-u… Florian Obser
- Re: [dns-privacy] [Ext] I-D Action: draft-ietf-dp… Paul Hoffman
- Re: [dns-privacy] [Ext] I-D Action: draft-ietf-dp… Florian Obser