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

[Vladimír Čunát <[e-mail]>]

I'm sorry for the delay.

On 11/19/20 8:47 AM, P Vixie wrote:
> On Tue, Nov 17, 2020 at 09:32:09AM +0100, Vladim??r ??un??t wrote:
>> I think the draft should also mention glue *addresses* [...]
> 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?)

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.


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


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

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