Re: [DNSOP] New draft on delegation revalidation

[Petr Špaček <[e-mail]>]

On 10. 04. 20 15:45, Shumon Huque wrote:
> Hi folks,
> 
> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
> consideration:
> 
>    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01

I would appreciate a practical example of changes envisioned in the following paragraph:

>    A common reason that zone owners want to ensure that resolvers place
>    the authoritative NS RRset preferentially in their cache is that the
>    TTLs may differ between the parent and child side of the zone cut.
>    Some DNS Top Level Domains (TLDs) only support long fixed TTLs in
>    their delegation NS sets, and this inhibits a child zone owner's
>    ability to make more rapid changes to their nameserver configuration
>    using a shorter TTL, if resolvers have no systematic mechanism to
>    observe and cache the child NS RRset.

Could someone please post an example in steps? Something like:
- time 0, NSSET parent = {P0}, NSSET child = {C0}
- time 1, NSSET parent = {P1}, NSSET child = {C1}
... along with textual description what operator is hoping to achieve?

It would help me to appreciate the value of the proposal.


Ad 4.  Delegation Revalidation:

I agree with author's note "we would prefer to discard the extensive mechanism" but the simple mechanism has simple description for me to understand consequences.

>    The simple mechanism:
> 
>    o  Cap the time to cache the child NS RRset to the lower of child and
>       parent NS RRset TTL.  The normal iterative resolution algorithm
>       will then cause delegation revalidation to naturally occur at the
>       expiration of the capped child NS TTL, along with dispatching of
>       the validation query to upgrade NS RRset credibility.

So far so good, but it does not specify what should happen with RRsets other than NS. Even if nothing is prescribed please state that explicitly.

Most importantly:
- Does the NS affect maximum TTL of _other_ data in the zone?
- If it does, doesn't it increase risk of thundering herd behavior?
- If it does not, is it even worth the effort if attacker can put week long TTL for A/AAAA and keep using that?
- How should resolver handle RCODE=NXDOMAIN? Should it have different effect than changing NS set to different set of servers? Or change in DS record value?

For me personally mixing two problems (GHOST domains and NS inconsistency) in single proposal does not help me to understand reasoning behind the proposal and its intended effects.

Take care.

-- 
Petr Špaček  @  CZ.NIC