Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-00.txt

Vladimír Čunát <> Tue, 17 November 2020 08:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CADC3A0957 for <>; Tue, 17 Nov 2020 00:32:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mjGf0bJTehzg for <>; Tue, 17 Nov 2020 00:32:13 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D04483A0954 for <>; Tue, 17 Nov 2020 00:32:11 -0800 (PST)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by (Postfix) with ESMTPSA id CF2F1140A24 for <>; Tue, 17 Nov 2020 09:32:09 +0100 (CET)
References: <>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>
Message-ID: <>
Date: Tue, 17 Nov 2020 09:32:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2020 08:32:14 -0000


I think the draft should also mention glue *addresses*, as that's
another closely related piece that often comes from the parent side (and
is also unavoidable to use in some situations).  Even if that means not
really recommending anything about them, though I'd personally expect
these to be handled similarly to NS records.

I'm not really sure if the whole draft is a good thing, but maybe that's
due to not experiencing the difficulties to update records in a way that
wouldn't need or even benefit from this draft (me being resolver
developer and indirectly operator).  Maybe it would generally be helpful
to expand the motivation section around the topic of why this is so
difficult that it's worth a standards-track RFC.

I'm also a bit puzzled... if the RFC won't make any *hard* requirements,
zone operators still won't be able to rely on the specified behavior
(n/ever perhaps), so can this still help them noticeably?  (I may have
missed this discussion, so point me there.)

--Vladimir | Knot Resolver dev.