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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
