TL;DR You just discovered what could be a major drawback of DNSSEC (specially in relation with DNS) or at least a very important point to always have in mind: DNSSEC is NOT just a one-time toggle, something you add and be finished with it. No, on the contrary, it forces regular maintenance of the zone, which means dedicated resources for that (automation, monitoring, etc.).
RRSIG records have an inception date (not valid before, typically around "now" when created) and an expiration date (not valid after).
Having an RRSIG record with an expiration date in the past, so already expired, is an error, it means there is no valid signature on the record signed, so it is a DNSSEC failure.
Which is why you don't want to have expired RRSIG records.
Now the instinctive reply could be: "Let's us then just make them expire in years in the future".
Sure, technically you can. Some resolver may be unhappy with that, but should comply, and some security tools will certainly flag that as a problem.
Why you shouldn't though?
For basically two reasons:
- you are dealing with cryptographic stuff; cryptography, as a science, evolves; new attacks arrive, both on a theoretical level and a practical one with CPUs going faster, quantum computing arriving, etc. which all means that signatures may become exploited in a way; if you rotate them regularly you give less options to attacker because it needs they both need to find a way to attack and also that their operation is fast enough, as least not longer than your resign cycle
- if you take the habit of changing something regularly you obviously put in place all processes and procedures to make sure that happens normally easily and with as large automation as possible... which will also help tremendously in the rare and unfortunate occasion where you have to do that exact change in an hurry after some catastrophic event
See 4.4.2 of https://www.rfc-editor.org/rfc/rfc6781#section-4.4.2
4.4.2. Signature Validity Periods
4.4.2.1. Maximum Value
The first consideration for choosing a maximum signature validity
period is the risk of a replay attack. For low-value, long-term
stable resources, the risks may be minimal, and the signature
validity period may be several months. Although signature validity
periods of many years are allowed, the same "operational habit"
arguments as those given in Section 3.2.2 play a role: When a zone is
re-signed with some regularity, then zone administrators remain
conscious of the operational necessity of re-signing.
Note that for similar reasons, keys should expire too. They don't have expiration dates in their DNS records but yet the operational practices are to rotate them.
Typical timeframes are like few months for ZSKs and few years for KSKs. You have to also factor in changes in cryptography, where for example currently SHA-1 is considered obsolete, and RSA based keys have lengths recommendation changing over the year (first 1024bits, now 2048, etc.)
Any "serious" zone using DNSSEC, and especially TLDs and the root, have to publish a "DNSSEC Practice Statement" outlining their policies and lifecycles of keys and signatures.
See RFC 6841 for example: "A Framework for DNSSEC Policies and DNSSEC Practice Statements"
which says:
4.5.3. Other Aspects of Key Pair Management
Other aspects of key management need to be considered for the zone
operator and other participants. For each of these types of
entities, the following questions may need to be answered:
What are the life cycle states for the management of any signing
keys?
What is the operational period of these keys? What are the usage
periods or active lifetimes for the pairs?
and
4.6.5. Signature Lifetime and Re-Signing Frequency
This subcomponent describes the life cycle of the Resource Record
Signature (RRSIG) record.
For example you can read root (.) DNSSEC practices at https://www.iana.org/dnssec/procedures/zsk-operator/dps-zsk-operator-v2.1.pdf
Among other things it says:
For each of these slots there is a pre-generated DNSKEY key set whichis signed at the key ceremony with at least 15 days validity time toallow for up to 50% overlap.
If you do a DNS query right now:
$ dig . DNSKEY +dnssec
[..]
;; ANSWER SECTION:
[..]
. 6h17m42s IN RRSIG DNSKEY 8 0 172800 (
20210512000000 20210421000000 20326 .
[..]
Current signature is valid from 2021-04-21T00:00:00 to 2021-05-12T00:00:00, exactly 21 days.
