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

[Paul Wouters <[e-mail]>]

On Mon, 7 Mar 2022, [e-mail] wrote:

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

This document looks good. Some comments:

    In fact, the Extensible Provisioning
    Protocol (EPP) [RFC5731], that is often used by TLDs to configure
    delegation parameters has no provision to set the TTL.  This inhibits
    a child zone owner's ability to make more rapid changes

This is somewhat misleading. Even if EPP had the functionality, the
parent zone would still want to set their own TTL to reasonable values
for _their_ dpeloyment considerations. So the implication of the problem
of "EPP cannot set TTL" is not really right. I would remove this text.

    Resolvers should record the TTL of the
    parent's delegating NS RRset, and use it to trigger a revalidation
    action.

Should that "should" be a SHOULD ?

    When a delegation response is received during iteration, a
    validation query should be sent in parallel with the resolution of
    the triggering query

Same here?

    Some resolvers may choose to delay the response

And here for the MAY ?

    In practice, we expect many implementations
    may answer the triggering query in advance of the validation query
    for performance reasons.

This deserves a mention of being incorrect/unsafe for bypassing DNSSEC
security on the NS RRset. In fact, above it is reasoned that iterator
has to wait on the DNSKEY RRset anyway, so there is no "performance
reason" unless there is no DS record at the parent.

    A delegation under re-validation is called a "re-validation point"
    and is "still valid" if its parent zone's servers still respond to an
    in-zone question with a referral to the re-validation point, and if
    that referral overlaps with the previously cached referral by at
    least one name server name, and the DS RRset (if seen) overlaps the
    previously cached DS RRset (if also seen) by at least one delegated
    signer.

This paragraph, from an implemeter's point of view, is super dense. It
might be worth splitting this one sentence into multiple ones.


    If the response is not a referral or refers to a different zone than
    before

What is "different zone" here? Does it mean to say "different NS RRset"
or "new NS RRset with zero overlap of the cached version" ? I am not
sure what from a nameserver point of view it can tell "a different
zone".

    but to a wholly novel NS RRset or a wholly novel DS RRset

Please use a different word from "novel". Maybe "disjoint NS RRset" ?


    If the corresponding child zone's apex NS RRset TTL is
    smaller than the delegating NS RRset TTL, revalidation should happen
    at that interval instead.

Doesn't this conflict earlier text that stated to remember the parental
NS glue TTL and only requery the parental NS RRset when its TTL is up?
What is the reason for this sentence? It seems logical to me to stick
with requerying the child zone for its NS RRset orthogonally from the
parent NS RRset requery TTL.



Should the document mention anything for the case of refreshing before
expiration? Eg to keep a hot cache, to requery items that are still
being queried for before their TTL hits? If this feature is supported,
how should it work with the parent/child TTLs?

Paul