[dns-privacy] Dnsdir telechat review of draft-ietf-dprive-unilateral-probing-12
Florian Obser via Datatracker <noreply@ietf.org> Mon, 04 September 2023 11:32 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F77C151996; Mon, 4 Sep 2023 04:32:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Florian Obser via Datatracker <noreply@ietf.org>
To: dnsdir@ietf.org
Cc: dns-privacy@ietf.org, draft-ietf-dprive-unilateral-probing.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <169382714222.57527.13387268595446853915@ietfa.amsl.com>
Reply-To: Florian Obser <fobser@ripe.net>
Date: Mon, 04 Sep 2023 04:32:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/5mRltLQVTarrznX43ne-TjGVoco>
Subject: [dns-privacy] Dnsdir telechat review of draft-ietf-dprive-unilateral-probing-12
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 04 Sep 2023 11:32:22 -0000
Reviewer: Florian Obser Review result: Ready with Issues -12 does not address the issues that were introduced in version -11. The status of my review does not change. This is the text from the -11 review: ------------------------------------------------------------------------ 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- ------------------------------------------------------------------------
- [dns-privacy] Dnsdir telechat review of draft-iet… Florian Obser via Datatracker
- Re: [dns-privacy] [Ext] Dnsdir telechat review of… Paul Hoffman
- Re: [dns-privacy] [dnsdir] Dnsdir telechat review… Jim Reid