Hi Philip, Thanks a lot for this, good catch! I've committed the following change:
OLD The reduction should be in effect at least until the previous DS record set has expired from caches, that is, the period during which the low-TTL is applied should exceed the normal TTL value. The routine re-signing of the DS RRset (usually after a few days) provides a convenient opportunity for resetting the TTL. When using EPP, the server MAY advertise its TTL policy via the domain <info> command described in [RFC9803], Section 2.1.1.2. NEW The reduction should be in effect at least for a couple of days and until the previous DS record set has expired from caches, that is, the period during which the low-TTL is applied typically will significantly exceed the normal TTL value. When using EPP, the server MAY advertise its TTL policy via the domain <info> command described in [RFC9803], Section 2.1.1.2. Best, Peter On 1/29/26 18:10, Philip Homburg wrote:
This message starts a WG Last Call for: draft-ietf-dnsop-ds-automation-02I just re-read the draft and I think it is in good shape. I have one minor issue. In Section 2.2.2, the draft requires lowering the TTLs of changed DS RRsets. That is good. The purpose of this is to allow the operator of the child zone to quickly change the DS RRset if something goes wrong. This means the short TTLs should stay for a period long enough that the operator can detect a problem can correct it. The draft ties the period during which the TTL is lowered to the TTL of the previous version of the DS RRset. For example, suppose the normal TTL of the DS RRset is one hour. Then a strict interpretation of this text would allow an operator to switch back to the higher TTL after one hour. Suppose the the child's signer changes the DNSKEY more than one hour after the DS RRset has changed. In that case, the child has no benefit from the lower TTL (unless just publishing the new DS RRset would immediately break something). This is made worse by the fact that scanners run asynchronously, so the operator of the child zone may not be aware when the new DS RRset will be introduced. So I think "The reduction should be in effect at least until the previous DS record set has expired from caches, that is, the period during which the low-TTL is applied should exceed the normal TTL value." should be changed to something like "The reduction should be in effect at least for a couple of days and until the previous DS record set has expired from caches, that is, the period during which the low-TTL is applied should exceed the normal TTL value." I now notice that the next sentence ("The routine re-signing of the DS RRset (usually after a few days) provides a convenient opportunity for resetting the TTL.") seems to assume very specific signing model. For our new signer, the signer has no clue about the policy for DS TTLs, it signs zones. But the software that generates unsigned versions of a zone has no clue when the signer would refresh signatures. So maybe this sentence should just be removed. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
-- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
