We had already a similar discussion at #9220 and a PR at #9281, but stopped without final implementation.
Now I would like to start the discussion again. After some more thinking and some DNSSEC quirks on our system I think Kees approach is most useful. As a secondary provider, we sign customer zones but do not have control over the SOA. So, some customer zones DNSKEY may have a small TTL, others may have a huge TTL (as currently the TTL is derived from the SOA MINIMUM filed). Both are not good. For example with hugh TTLs it takes very long to cleanup in resolver caches after DNSKEY errors.
Usecase
Having a consistent timing on key rollovers, not depending on what end customers configure their SOA records.
Description
So I would propose a global dnskey-ttlsetting. I think 'per zone metadata' is overkill, as I want all my zones to behave similar. Maybe related TTLs (CDS, ...) may be set to the same value.
Short description
We had already a similar discussion at #9220 and a PR at #9281, but stopped without final implementation.
Now I would like to start the discussion again. After some more thinking and some DNSSEC quirks on our system I think Kees approach is most useful. As a secondary provider, we sign customer zones but do not have control over the SOA. So, some customer zones DNSKEY may have a small TTL, others may have a huge TTL (as currently the TTL is derived from the SOA MINIMUM filed). Both are not good. For example with hugh TTLs it takes very long to cleanup in resolver caches after DNSKEY errors.
Usecase
Having a consistent timing on key rollovers, not depending on what end customers configure their SOA records.
Description
So I would propose a global
dnskey-ttl
setting. I think 'per zone metadata' is overkill, as I want all my zones to behave similar. Maybe related TTLs (CDS, ...) may be set to the same value.