Re: [DNSOP] New draft on delegation revalidation

[Daniel Migault <[e-mail]>]

Thanks, that will be appreciated. I will make sure the two documents are
synchronised.
Yours,
Daniel

On Mon, May 4, 2020 at 8:20 AM Shumon Huque <[e-mail]> wrote:

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

-- 
Daniel Migault
Ericsson