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

[Shumon Huque <[e-mail]>]

On Tue, Mar 8, 2022 at 1:04 PM Paul Wouters <paul.wouters=
[e-mail]> wrote:

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

The first sentence is fact. I agree, the 2nd sentence here is probably a
bit misleading. A hypothetical EPP TTL extension alone would not suffice;
we'd need some cooperation from the TLD operator. I think our point was that
TLD policies willing, it could have allowed registrants to configure values
more reasonable for their operations as compared to the inflexibly
large and unchangeable 1 to 2 day TTLs currently on offer at many TLDs.
Let me ponder and see if I can reword this a bit.


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

Yeah, I think we probably need to make another pass through
the doc and use RFC 2119 keywords throughout.

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

Ditto.


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

Well, we could mention that caveat, but this would be at least no
worse than before NS Revalidation. Eventually, the resolver will get
the signed NS RRset, so I think it's tolerable. The other reason is to
deal with zones that don't respond to NS queries (it's possible that
no such zones exist that are signed, but I wouldn't be surprised if
there are).

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

Yeah, this is Paul V's re-worked text regarding revalidation, so I'll
defer to him. Feel free to suggest specific rewording though.


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

I think a referral to a different zone (the owner of the NS rrset) from the
same parent along the same path, e.g. c.b.a.com vs b.a.com.


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

See the detailed rationale in section 2.

This is to satisfy the 2nd goal of the draft. In addition to making sure
revalidation happens no longer than the delegating TTL to facilitate
timely detection of re-delegation and takedown, we want the child
zone operator to be able to dictate a smaller TTL if they need to, to
allow them to make nameserver configuration changes more rapidly
visible to resolvers.

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

Pre-fetching? That is worth discussing. Although, it'd be nice if the
details of that mechanism had already been published first. Is anyone
working on reviving/publishing draft-wkumari-dnsop-hammer ? Warren?

Shumon.