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

P Vixie <paul@redbarn.org> Thu, 19 November 2020 07:47 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B623A1133 for <dnsop@ietfa.amsl.com>; Wed, 18 Nov 2020 23:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx5G_1WD71Vh for <dnsop@ietfa.amsl.com>; Wed, 18 Nov 2020 23:47:49 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058023A1131 for <dnsop@ietf.org>; Wed, 18 Nov 2020 23:47:48 -0800 (PST)
Received: by family.redbarn.org (Postfix, from userid 716) id B1E2EC3F03; Thu, 19 Nov 2020 07:47:46 +0000 (UTC)
Date: Thu, 19 Nov 2020 07:47:46 +0000
From: P Vixie <paul@redbarn.org>
To: Vladim??r ??un??t <vladimir.cunat+ietf@nic.cz>
Cc: dnsop@ietf.org
Message-ID: <20201119074746.yfg5frhu6kf55vni@family.redbarn.org>
References: <159956594812.3592.13644698132444130394@ietfa.amsl.com> <67e85e10-50c0-ab4d-db72-890b296eac16@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <67e85e10-50c0-ab4d-db72-890b296eac16@nic.cz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7JL2cIPfcqucTJcGdhVqWdYt_Y4>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2020 07:47:50 -0000

On Tue, Nov 17, 2020 at 09:32:09AM +0100, Vladim??r ??un??t wrote:
> Hello.
> 
> 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.

do you mean where the NSDNAME is in-zone and there is a non-authoritative
copy of the AAAA or A RRs held in the parent zone for delegation purposes,
but which might have a lower TTL than the authoritative in-zone copy of the
same data? i feel sure that the draft's co-authors would agree that this is
an omission in the older resimprove draft and should be corrected here. it
raises a grandparent edge condition (some server is authoritative for both
the parent and the child) but in this case the revalidation will just fetch
authoritative (high-TTL) data and be satisfied.

in the more common case where the NSDNAME is in some other zone altogether,
the only revalidation that could come into play is for that other zone's
delegation, which might never be learned by a full resolver. what do you
think is the right way to revalidate that information? (what triggering
TTL interval would be used? and should missing delegations be discovered
for this kind of glue so that they can be revalidated as specified?)

> 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.

there are two use cases, the first of which is difficult to make compelling
to a non-security audience. takedown is vital, and must be instant. the
publishers of malicious DNS information only need a few minutes of uptime to
complete most crimes, and even intervals less than a minute are adequate for
some such crimes.

second, when an error of omission occurs during a renumbering or rehoming
event, and now-stale DNS data is harmful in a way that only time can fix,
being able to trigger a distributed "rm -rf" of that data using the parent
delegation is far better for all parties than waiting what may be hours or
days for the stale data to expire naturally.

i hope that one of the draft's coauthors can simplify that explaination and
make it clear and compelling.

> 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.)

it can say SHOULD but not MUST, because not doing it will never be incorrect,
owing to the older implementations who don't do it. it's desirable in that
it will do more good than harm for both the zone and resolver operators,
but still opportunistic from a protocol correctness point of view.

-- 
Paul Vixie