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

From: [email-masked]
Date: Mon, 07 Mar 2022 13:31:31 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Delegation Revalidation by DNS Resolvers
        Authors         : Shumon Huque
                          Paul Vixie
                          Ralph Dolmans
	Filename        : draft-ietf-dnsop-ns-revalidation-02.txt
	Pages           : 7
	Date            : 2022-03-07

Abstract:
   This document recommends improved DNS [RFC1034] [RFC1035] resolver
   behavior with respect to the processing of Name Server (NS) resource
   record sets (RRset) during iterative resolution.  When following a
   referral response from an authoritative server to a child zone, DNS
   resolvers should explicitly query the authoritative NS RRset at the
   apex of the child zone and cache this in preference to the NS RRset
   on the parent side of the zone cut.  Resolvers should also
   periodically revalidate the child delegation by re-quering the parent
   zone at the expiration of the TTL of the parent side NS RRset.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-ns-revalidation-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-ns-revalidation-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Mar 2022 12:19:56 -0500 (EST)

On Mon, 7 Mar 2022, [email-masked] 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

---

From: Shumon Huque <[email-masked]>
Date: Wed, 9 Mar 2022 00:12:14 -0500

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

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

>     Some resolvers may choose to delay the response

Ditto.

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

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

> sure what from a nameserver point of view it can tell "a different

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.

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

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 9 Mar 2022 00:02:25 -0800

see inline.

Shumon Huque wrote on 2022-03-08 21:12:
> On Tue, Mar 8, 2022 at 1:04 PM Paul Wouters 
> <paul.wouters=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On Mon, 7 Mar 2022, [email-masked]
>     <mailto:[email-masked]> wrote:
> 
>     ...
>          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

huh. i think the problem is that this paragraph is only one sentence 
long. my high school english teachers would have berated me, and others 
are welcome to do so now. let's try breaking it up a bit.

<<A delegation under re-validation is called a "re-validation point". To 
be considered "still valid", the ancestor zone whose authority servers 
offered the referral response that gave rise to the re-validation point 
must still offer a compatible referral response if queried again for a 
name considered to be in-bailiwick (a "re-validation query"). To be 
considered compatible, the NS RRset of re-validation response must 
overlap with the previously cached referral response by at least one 
name server name, and if a DS RRset is given, it must overlap with the 
previously cached referral response by at least one delegated signer. 
For avoidance of doubt, this means a change in referral from signed to 
unsigned or from unsigned to signed signals a delegation change for the 
purposes of this specification, even if the NS RRset is unchanged.>>

let me know if this isn't an improvement, or if more improvement is needed.

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

ok by me.

> working on reviving/publishing draft-wkumari-dnsop-hammer ? Warren?
pre-fetching is a degenerate case of re-appearance. sometimes an NS 
RRset will be transmitted without having been solicited with qtype=NS. 
these are not delegations and should not reset the re-validation timers. 
we might want to point that out in the specification being discussed in 
this thread. (shumon?)

if a formal specification for "pre-fetching" some day exists and 
recognizes that some zones do not answer qtype=NS and that the only way 
to learn about delegation points from them is to ask a question that 
solicits a referral, and recommends that this be done when 
"pre-fetching" NS RRsets otherwise due to expire, then it is that 
specification's burden to explain how this would relate to re-validation 
timers from the (earlier) specification we're discussing in this thread.

my hope is that a "pre-fetching" specification would not recommend 
soliciting NS RRsets via referrals, and would instead exclude NS RRsets 
from pre-fetching, with a reference to the specification we're 
discussing in this thread and a recommendation that re-validation and 
not pre-fetching be used when the near-expiry cached RRset is rrtype=NS.

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Mar 2022 08:32:51 -0500 (EST)

On Wed, 9 Mar 2022, Paul Vixie wrote:

> huh. i think the problem is that this paragraph is only one sentence long. my 
> high school english teachers would have berated me, and others are welcome to 
> do so now.

If you like these long sentences, I suggest learning German :)

> <<A delegation under re-validation is called a "re-validation point". To be 
> considered "still valid", the ancestor zone whose authority servers offered 
> the referral response that gave rise to the re-validation point must still 
> offer a compatible referral response if queried again for a name considered 
> to be in-bailiwick (a "re-validation query"). To be considered compatible, 
> the NS RRset of re-validation response must overlap with the previously 
> cached referral response by at least one name server name, and if a DS RRset 
> is given, it must overlap with the previously cached referral response by at 
> least one delegated signer. For avoidance of doubt, this means a change in 
> referral from signed to unsigned or from unsigned to signed signals a 
> delegation change for the purposes of this specification, even if the NS 
> RRset is unchanged.>>
>

That's much better, thanks.

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

Good.

> pre-fetching is a degenerate case of re-appearance. sometimes an NS RRset 
> will be transmitted without having been solicited with qtype=NS. these are 
> not delegations and should not reset the re-validation timers. we might want 
> to point that out in the specification being discussed in this thread. 
> (shumon?)

okay.

> if a formal specification for "pre-fetching" some day exists and recognizes 
> that some zones do not answer qtype=NS and that the only way to learn about 
> delegation points from them is to ask a question that solicits a referral, 
> and recommends that this be done when "pre-fetching" NS RRsets otherwise due 
> to expire, then it is that specification's burden to explain how this would 
> relate to re-validation timers from the (earlier) specification we're 
> discussing in this thread.

Agree.

Thanks for addressing my items,

Paul

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 Mar 2022 10:19:10 -0500

On Mar 9, 2022, at 00:12, Shumon Huque <[email-masked]> wrote:

> The first sentence is fact.

Since the E in EPP stands for extensible, and since there's an active community (an active ietf working group, even, with participants who are registry operators) working on such extensions, I'm not sure the truth of the first sentence is useful generally.

in any case, I agree with Paul that the operator of a child zone generally should have no expectation of being able to influence the TTL in the delegation NS set (above the zone cut).

I also think it makes sense just to remove this commentary. 

>>     validation query should be sent in parallel with the resolution of

"Referral response" not "delegation response" I think. 

Joe

---

From: Shumon Huque <[email-masked]>
Date: Wed, 9 Mar 2022 20:45:53 -0500

On Wed, Mar 9, 2022 at 10:19 AM Joe Abley <[email-masked]> wrote:

> Since the E in EPP stands for extensible, and since there's an active
> community (an active ietf working group, even, with participants who are
> registry operators) working on such extensions, I'm not sure the truth of
> the first sentence is useful generally.
>
> in any case, I agree with Paul that the operator of a child zone generally
> should have no expectation of being able to influence the TTL in the
> delegation NS set (above the zone cut).
>

Ok, I'm persuaded to remove the EPP mention.

> "Referral response" not "delegation response" I think.

Yes, that would be the more commonly used term. Will fix.

Shumon.