On Mon, 7 Mar 2022, [email protected] 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
