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

From: Vladimír Čunát <[email-masked]>
Date: Tue, 17 Nov 2020 09:32:09 +0100

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.

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.

---

From: P Vixie <[email-masked]>
Date: Thu, 19 Nov 2020 07:47:46 +0000

On Tue, Nov 17, 2020 at 09:32:09AM +0100, Vladim??r ??un??t wrote:
> is also unavoidable to use in some situations).?? Even if that means not

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

> developer and indirectly operator).?? Maybe it would generally be helpful

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.

> (n/ever perhaps), so can this still help them noticeably??? (I may have

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

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 24 Nov 2020 15:29:13 +0100

I'm sorry for the delay.

On 11/19/20 8:47 AM, P Vixie wrote:
>> I think the draft should also mention glue *addresses* [...]

If it belongs into another zone, I think it should be "revalidated" in
that other zone (whatever you choose "revalidation" to mean) - I don't
see how it matters that I use the record somewhere else.  Resolvers
should accept parent-side (i.e. unauthoritative) data only if they
belong to bailiwick of the auth which sent the data, so I think in
practice it's just about descendant zones.

> make it clear and compelling.

I assumed the issues around ghost domain names are well known, though
maybe not documented in any RFC.  That's the parts when the child-side
records (and transitive delegations) should not be allowed to live "too
long".

My question was focused on the case why the RFC requests to avoid (the
possibility of) using the *parent*-side data all the time - naturally
just in cases that don't include putting them into resolver answers, but
typically noone asks resolver for nameserver records and addresses. 
Your "second" (paragraph) doesn't seem to explain that either.

> but still opportunistic from a protocol correctness point of view.

OK, I guess.  I assume you meant this mainly for the take-down parts
which I wasn't intended to ask about, but...

--Vladimir | knot-resolver.cz