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 <shu...@gmail.com> wrote: > On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault <mglt.i...@gmail.com> > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
