1

I've found the following guide on how to setup DNSSEC with NSD DNS server and ldns utilities: https://www.digitalocean.com/community/tutorials/how-to-set-up-dnssec-on-an-nsd-nameserver-on-ubuntu-14-04

Basically it provides the following steps:

  1. Generate ZSK and KSK using ldns-keygen
  2. Sign the zone using ldns-signzone with above keys
  3. Point NSD to the signed version of zone file and reload config
  4. Write DS entries for the domain of subject on registrar panel
  5. Use provided script (dnszonesigner) whenever you change your zone (unsigned file)

And this all works fine. However there is a comment "Have you thought about how to keep the signed zone fresh? RRSIG's will expire and should be refreshed in time. In other words, a signed zone should be resigned every once in a while."

Is it a correct remark? I can't find information about DNSSEC zones staling anywhere. If it correct, should I just run dnszonesigner script via cron, if so, how frequently should I? What will happen (and when) if I don't do this? Will DNSSEC aware resolvers, like Google Public DNS still provide correct answers for the records in my zone?

0

According to the listed below, even if you're data stay's the same, you should resign ones a month.

dnssec-tools.org

0
0

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://tools.ietf.org/html/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:

  1. What are the life cycle states for the management of any signing keys?

  2. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.