[dns-privacy] Artart last call review of draft-ietf-dprive-unilateral-probing-12

Bron Gondwana via Datatracker <noreply@ietf.org> Thu, 07 September 2023 14:16 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 03A58C1519A7; Thu, 7 Sep 2023 07:16:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bron Gondwana via Datatracker <noreply@ietf.org>
To: art@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: <169409620800.15857.16759296263081674061@ietfa.amsl.com>
Reply-To: Bron Gondwana <brong@fastmailteam.com>
Date: Thu, 07 Sep 2023 07:16:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/7BIMQ6ic-_YtUG0KbGZ_sAiyz6Q>
Subject: [dns-privacy] Artart last call 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: Thu, 07 Sep 2023 14:16:48 -0000

Reviewer: Bron Gondwana
Review result: Ready with Nits

I am the ARTART reviewer for this document.  Apologies for the delay in sending
my review.

I found it very well written and easy to follow.  It's clear why this guidance
is being written, and it's clear to me how to implement it.

My only concern is that it does fall back very easily to cleartext, for a long
damping period.  As a protocol implementer myself, I would generally expect to
retry something one or two more times over the course of a few minutes before
giving up entirely for 24h, since the server at the other end may have just
been restarting and either dropped an existing connection or rejected a SYN
packet, but be ready a moment later.  I'd be happy with a limit of something
like 5 tries over 2 minutes (one every 30 seconds) before giving up.

Thanks again for this document, and I look forward to my DNS being slightly
safer in future.