[DNSOP] Re: New Version Notification for draft-sury-dnsop-parent-centric-resolver-01.txt

Ralf Weber <dns@fl1ger.de> Wed, 01 April 2026 16:06 UTC

Return-Path: <dns@fl1ger.de>
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 0B329D4E82A7 for <dnsop@mail2.ietf.org>; Wed, 1 Apr 2026 09:06:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775059569; bh=xESIIXYuOgBiiXZo5dci61p8bg1EkQY8xwOIenvithc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=dfgxZsQrlgecuGU5DPFxRqM+RVe7HPgNqAaz9ghV9hmm8WrkVIz7GQ9pF4nr0aqUi unob7JUFwPHzWGVpyg3srj/yfQKjZCeQ0UaqQ+nCNw2jNXaTsKwjaaaE4jMI0Vgei+ NoJ6yFrlTJuFrnxaYUDrtwDr4wCakkrQyrEGIpkg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
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 7AhWqHlr9h-y for <dnsop@mail2.ietf.org>; Wed, 1 Apr 2026 09:06:04 -0700 (PDT)
Received: from smtp.guxx.net (nox.guxx.net [91.98.89.191]) (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 0A434D4E829B for <dnsop@ietf.org>; Wed, 1 Apr 2026 09:06:04 -0700 (PDT)
Received: from [192.168.42.135] (86-103-42-17.ip.tng.de [86.103.42.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by nox.guxx.net (Postfix) with ESMTPSA id C3C913E6DD; Wed, 1 Apr 2026 16:05:56 +0000 (UTC)
From: Ralf Weber <dns@fl1ger.de>
To: Dave Lawrence <tale=40dd.org@dmarc.ietf.org>
Date: Wed, 01 Apr 2026 18:05:56 +0200
X-Mailer: MailMate (2.0r6292)
Message-ID: <74E176B0-7273-4EFF-9223-48BB96442602@fl1ger.de>
In-Reply-To: <27085.15901.387333.288862@gro.dd.org>
References: <177364466468.250409.3258111596991249669@dt-datatracker-5477d56788-5pkt5> <AB5761BD-4306-44BA-9A7F-A76752A85E0B@sury.org> <e3c5dec2-b52e-4245-9329-211a31fefc4d@time-travellers.org> <27085.15901.387333.288862@gro.dd.org>
MIME-Version: 1.0
Content-Type: text/plain
Message-ID-Hash: R36OLMRROMSXDVEB4CGVGINVOOCILU3X
X-Message-ID-Hash: R36OLMRROMSXDVEB4CGVGINVOOCILU3X
X-MailFrom: dns@fl1ger.de
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
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: New Version Notification for draft-sury-dnsop-parent-centric-resolver-01.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Irr5sadHY0UmEJHLv378PE53j4o>
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!

On 1 Apr 2026, at 17:47, Dave Lawrence wrote:

> Shane Kerr writes:
>> One thing that I really like about the draft is that it documents
>> refreshing TTL values for NS on any lookup at the parent. This is
>> probably something resolver implementers already do, but writing it
>> down seems useful.
>
> It would seem to obviate 11 versions and over 6 years of work on
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
>
> Or maybe not.  I haven't tried to reconcile them.

Section 9.3 in this document does that. This is about implementation
deciding to do re validation or do what Ondrejs draft proposes. We
currently have both and I think that is fine.

So long
-Ralf
---
Ralf Weber