On Tue, Jan 28, 2025 at 8:36 PM Wessels, Duane <dwessels=
40verisign....@dmarc.ietf.org> wrote:
> Willem/Shumon/Paul,
>
> Here’s some comments on draft-ietf-dnsop-ns-revalidation-08.txt
>
Thanks Duane!
> > Resolvers should also periodically revalidate the
> > child delegation by re-querying the parent zone at the expiration of
> > the TTL of the parent side NS RRset.
>
> The TTL for delegation revalidation is the minimum of the parent and child,
> right? Later in the draft it says "If the corresponding child zone's apex
> NS RRset TTL is smaller than the delegating NS RRset TTL, revalidation
> MUST happen at that interval instead.
>
Yes, the latter statement is the correct one. We'll fix that inconsistency.
Some more detailed rationale on this (this is explained in the draft but I'm
paraphrasing here ..):
When data ranking rules cause the child authoritative NS set to replace the
parent NS set in the resolvers cache, we don't want the child zone operator
to intentionally set the NS TTL to a much larger value than the parent, and
then
cause the zone to potentially live on in resolver caches long after that
parent
may have removed the delegation for whatever reason (takedown actions). The
"minimum" rule is for that reason. See the ghost domains category of
attacks.
If the child NS TTL is smaller than the delegation NS set, we want
resolvers
implementing this technique to prefer that one (with sensible lower bounds),
so that the child zone operator has the agility to switch DNS operators
quickly
in the face of parents that only allow very large delegating TTLs.
> a validation
> > query SHOULD be sent in parallel with the resolution of the
> > triggering query,
>
> The term “triggering query” is used a number of times. Should it be
> defined
> as a term, or does everyone just know what it means?
>
Yeah, I guess that we should. It means the outbound DNS query that caused
("triggered") a referral response.
> Positive responses to this
> > validation query will be cached with an authoritative data ranking.
>
> The draft uses “will” many times. Maybe these should be MUST, given
> its a standards track doc.
>
I think we intentionally avoided the RFC keyword MUST in this doc, because
some parent centric resolvers want to keep their current behavior without
running afoul of a standards track RFC. We could consider using a
qualified MUST in some of these places (or SHOULD). We're open to
suggestions, but the current text is where we landed after many discussions
with misc implementers.
> A No Data response (see Section 2.2 of [RFC2308]) for the validating
> > NS query should be treated the same as a failed validating NS query.
>
> Maybe there is something to say about not retrying failed failed queries
> too
> aggressively ala RFC 5920.
>
RFC 9520 I assume you mean.
Yes, I think we can say that and reference that document.
> Additional validation queries for the "glue" address RRs of referral
> > responses (if not already authoritatively present in cache) SHOULD be
>
> I found this a little confusing at this place given that the next section
> is Upgrading A and AAAA RRset Credibility. Maybe Updating Glue Credibility
> should be a separate section.
>
We actually do have a separate glue credibility section:
"4. Upgrading A and AAAA RRset Credibility"
Okay, we'll review that text and perhaps we can relocate it.
> > Positive
> > responses will be cached authoritatively and replace the non
> > authoritative "glue" entries.
> >
> > A resolver
> > MAY choose to keep the non-authoritative value for the "glue" next to
> > the preferred authoritative value for fallback purposes.
>
> I was surprised to first read that non-authoritative glue will (MUST?) be
> replaced because it doesnt account for the case you describe later, when
> all authoritative names are not reachable. Maybe this could be reordered
> or rewritten.
>
Yes, good point.
> > In cases where the delegated
> > nameservers respond incorrectly to an NS query
>
> Could you be specific about what constitutes an incorrect response
> to an NS query?
Okay. This is any response other than a NOERROR response from the
child nameserver that contains an NS RRset in the answer section. So,
NXDOMAIN, NODATA, FORMERR, SERVFAIL, etc. We can elaborate.
> > Additional addresses in authoritative NS RRset responses SHOULD be
> > validated if they are not already authoritatively in cache. Only
> > when such additional addresses are DNSSEC verifiable, (because the
> > complete RRset is included, including a verifiable signature for the
> > RRset), such additional addresses can be cached authoritatively
> > immediately without additional validation queries. DNSSEC validation
> > is enough validation in those cases. Otherwise, the addresses cannot
> > be assumed to be complete or even authoritatively present in the same
> > zone, and additional validation queries SHOULD be made for these
> > addresses.
>
> I suggest rewriting this to talk about the DNSSEC verifiable case first
> (no address validation needed) and then say to do the address validation.
> As written I find it sort of mixed up, like: "do address validation.
> except
> sometimes you dont have to. otherwise you have to".
>
Okay, that sounds reasonable. I'll defer to Willem to review this text and
propose
a rewrite.
> > Note that there may be outstanding address validation queries for the
> > names of the authoritative NS RRset (from referral address validation
> > queries).
>
> I don’t think “referral address validation query” is a term previously
> used or defined.
>
Hmm, I'm not fully clear what this paragraph is saying either. Willem - can
you review and chime in?
>
> > 4.1. Strictly revalidating referral and authoritative NS RRset
> > responses
> >
>
> This subsection feels out of place to me, and maybe a little redundant
> with the second-to-last paragraph of section 3.
>
Yes, currently it is a bit redundant. The strict revalidation mode applies
to both NS and glue, so perhaps we can move the text out of section
3 and just put it in a new section.
> 7. Security and Privacy Considerations
>
> I think there should be a discussion of revalidation in the context of the
> NXNS or other types of excessive work attacks. I dont think the draft
> currently gives any advice about limiting the amount of revalidation.
>
I do recall that we had discussed putting in text about resolvers applying
sensible bounds on the amount of work they are willing to do to resolve a
query. We'll review and see if we can add some text on this point.
Even in non-attack situations, it seems that delegation revalidation could
> have very significant traffic impacts. Willem and his colleagues performed
> a study for ICANN, looking at consequences of having signed root name
> server data. One of their conclusions was that revalidation would provide
> better security than a signed root priming response.
>
> The tradeoff is more traffic. If every root priming query today resulted
> in an additional 1 NS query and 26 more A/AAAA queries (worst case), total
> root zone traffic would grow by 30%. Of course not all zones have that
> property, but some do, and it should probably be documented.
>
Yes, the glue revalidation section is a relatively new addition to the
draft,
and came about because of that ICANN study. I agree that the draft
might need a clearer statement about the traffic amplification implications
of doing it. Willem - let's review and propose some text.
Shumon.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
