Re: [DNSOP] New draft on delegation revalidation

[Shumon Huque <[e-mail]>]

On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault <[e-mail]> wrote:

> Hi,
>
> I discovered this draft during the interim meeting. We had similar
> thoughts in our "Recommendations for DNSSEC Resolvers Operators". Our
> motivation for supporting this work are that it  1) improves the
> reliability of the resolution as well as 2) removes the temptation to
> (inadvertently) break resolution by fixing in appearance a
> misconfiguration. In other words it eases the operation.
>

Thank you Daniel. Will read your draft shortly, but in the meantime ..

Your note reminded me of the question you asked during the interim
meeting about why we can't just use the DS TTL as the revalidation
interval. Our response was that the main impediment was that DNSSEC
deployment is far from ubiquitous, but also that there is no reason that it
could not be factor, when available.

Here's what the draft already says about DS:

   Technically, if both parent and child zone are DNSSEC [RFC4033]
   [RFC4034] [RFC4035] signed with a corresponding secure delegation
   between them, then expiration of the DS record will cause
   revalidation of the current child zone's DNSKEY set, so responses
   from the orphaned child nameservers would no longer be trusted.
   However, delegation revalidation is still necessary to locate the
   current nameserver addresses.

In practice, the DS and delegating NS TTL do not always match.
COM for example uses 2 day NS and 1 day DS TTL for all its
delegations. So where DS is lower, that could be used as the upper
bound. We'll queue up some text on this subject for the next revision
of the draft.

Shumon.