DNSSEC Key States
  • 04 Oct 2024
  • 7 Minutes to read
  • Contributors
  • PDF

DNSSEC Key States

  • PDF

Article summary

To sign a zone in BIND 9, you will need to specify a DNSSEC Key and Signing Policy and configure the zone to make use of that policy:

zone "example.com" {
    dnssec-policy "default";
};

By default, three new key files will be created per key inside the configured key directory: .private, .key and .state.

In addition to the public and private key files, the state files contain information about the current status of the respective key. State files look something like this: Kexample.com.+008+12345.state

Inside these files there is a lot of information using some terminology that might, at first, seem confusing. For example omnipresent, unretentive, DNSKEYState, and GoalState.

These terms come from the paper Flexible and Robust Key Rollover in DNSSEC. This paper describes an algorithm to ensure key rollover correctness.

A View On Keys

Various key materials are published in the DNS in a variety of record types. The public key is stored in a DNSKEY record, signatures generated by the key are stored as RRSIGs and if the KSK also signs the DNSKEY RRset, the DS record in the parent zone signals there is a secure delegation.

When a new key is introduced these records need to be published, but not at the same time. In fact, the timing of when to introduce and when to withdraw data from the zone is vital, because of propagation delay to resolvers due to TTLs of any existing records. If a resolver has an older public key cached and it tries to validate a freshly resolved RRset with signatures from the successor key, the DNS response will be bogus.

We could just derive the publication state of a record by examining the zone file: a record is either published or it is not. But with just two states we wouldn't know whether a record has been published long enough, such that any validator in the world has picked up the new data. For the process to work reliably a total of four states are needed. These are: hidden, rumoured, omnipresent, and unretentive (these may not be obvious words to signal the publication status of a DNS record, but they are the ones that are used in the paper).

Key States

A DNS record that is hidden is not in the authoritative zone and it cannot be in any resolver cache.

As soon as the record is published in the zone it becomes rumoured. The record may or may not be known to resolvers, it all depends on what was in the resolver's cache previously. If there was no RRset of the same owner name, type and class, the record may be picked up immediately. Otherwise it may take up to the TTL of the record before the new RRset is resolved. In other words, if the key material is rumoured we have no way of knowing whether a resolver is using this data and the name of the state reflects this.

After enough time has passed (the TTL of the record plus some propagation delay values, as a precaution), the record is in so-called omnipresent state, meaning that it is present in all places at all times. As an authoritative server we can now safely assume that this key material is being used by all validators.

When we remove the record from the zone it becomes unretentive. In a similar way when the record is added, it takes some time before all resolvers have expired the previous version of the corresponding RRset from their caches. After enough time has passed - TTL plus a propagation delay, as before - we can be assured that no caches have retained this record and it becomes hidden again.

The status of the record can be illustrated by a diagram of the state machine, as shown below:

dnssec-key-state-machine.png

A shortcut from rumoured to unretentive

The above state machine shows that a record can also move directly from rumoured to unretentive and vice versa. This can happen if a record is removed/added back before the new RRset has propagated to all resolver caches. In practice this will not occur during normal operation.

Four Is A Party

Let's examine a key state file:

; This is the state of key 12345, for example.com.
Algorithm: 8
Length: 2048
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210818090144 (Wed Aug 18 11:01:44 2021)
Published: 20210818090144 (Wed Aug 18 11:01:44 2021)
Active: 20210818090144 (Wed Aug 18 11:01:44 2021)
PublishCDS: 20210818090144 (Wed Aug 18 11:01:44 2021)
DNSKEYChange: 20210818090149 (Wed Aug 18 11:01:49 2021)
KRRSIGChange: 20210818090149 (Wed Aug 18 11:01:49 2021)
ZRRSIGChange: 20210818090149 (Wed Aug 18 11:01:49 2021)
DSChange: 20210818090149 (Wed Aug 18 11:01:49 2021)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
ZRRSIGState: rumoured
DSState: hidden
GoalState: omnipresent

The state file contains some key metadata such as the cryptographic algorithm, key lifetime, and key roles. The above key acts as a CSK (it has both the KSK and ZSK role).

At the end of the file we see the key states. These correspond to the possible DNS records in which the key material can be published. DNSKEYState tracks whether the DNSKEY record is published, DSState is for the DS record. For signatures we need two states: KRRSIGState represents the RRSIG covering the DNSKEY RRset and ZRRSIGState is for all other zone signatures.

Thus, in order to keep track of the publication status of all key material we need four state machines; one for each of the DNSKEYChange, DSChange, KRRSIGChange and ZRRSIGChange statuses.

For each key there is one more state value, GoalState. This is the state that all four state machines are aiming for and it can take only one of the two values omnipresent (if the key should be published), or hidden (if the key should be withdrawn).

The same terms can be found in the output of rndc dnssec -status, as shown below:

$ rndc dnssec -status example.com
dnssec-policy: default
current time:  Thu Feb  2 12:00:27 2023

key: 12345 (ECDSAP256SHA256), CSK
  published:      yes - since Sat Dec  3 18:45:40 2022
  key signing:    yes - since Sat Dec  3 18:45:40 2022
  zone signing:   yes - since Sat Dec  3 18:45:40 2022

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         omnipresent
  - ds:             hidden
  - zone rrsig:     rumoured
  - key rrsig:      omnipresent

Cache-centric Rollover

Replacing keys is a non-trivial operation, though it needs to be done from time to time. Whether it is to maintain operational practices, or whether it is an emergency, there will be times when you want to perform a key rollover. When that time comes, you want to keep your zone valid.

There are several procedural steps to replace a key. A ZSK can be replaced by following the ZSK Pre-Publication Rollover Method. For a KSK you can use the Double-KSK or Double-DS method. When you use a CSK it is a combination of methods. These recipes, described in RFC 7583, are there to ensure that, at any point in time, the resolver has the right combination of key material in order to validate a DNS response, whether that material came from cache, from the authoritative name server, or a combination of both.

Rather than creating recipes for every use case, our approach is cache centric, meaning when we publish or remove DNSSEC records from the zone, all validators in the world will still be able to validate records in it.

Key State Transitions

Each transition in the four state machines from above can only be taken if the DNSSEC Validity remains valid. These depend on the Key and Signing Policy, the DNSSEC Formal Rules, and Key Timings.

First of all, the DNSSEC policy dictates how many keys of what type should be published. Typically you choose whether to use a KSK/ZSK split, or a Single-Type Signing Scheme (one CSK).

Second, the DNSSEC Formal Rules are being considered. There are only three basic rules that need to be followed and these rules should be followed whenever we make a publication change.

The first rule simply states that there must be a DS record published at all times. After all, if there is no secure delegation, the zone is not considered to be DNSSEC signed.

If you just enabled DNSSEC for a zone, this rule is most likely violated. This is expected and the algorithm tries to push the state machines towards valid states.

The second rule ensures that the DNSKEY RRset is in the correct state. Without going into detail, this rule basically says that either there exists a key with its DS record, public key and DNSKEY signature in omnipresent state, or there are two (or more) KSKs as part of a key rollover. When a Double-KSK style rollover occurs, all keys will have their DNSKEYState and KRRSIGState in omnipresent, while the DSState is either in rumoured, omnipresent, or unretentive. With a Double-DS rollover, all keys have their DSState in omnipresent, and their DNSKEYState and KRRSIGState in rumoured, omnipresent, or unretentive.

The third rule is very similar to the second one, but is about the zone signatures. Either there exists a key where both DNSKEYState and ZRRSIGState are in the omnipresent state, or there are two (or more) ZSKs as part of a key rollover. In this case, the DNSKEYState of the keys would be omnipresent and the ZRRSIGState in either rumoured, omnipresent, or unretentive.

Finally, in addition to the DNSSEC formal rules, DNSSEC Key Timings are being honored. These come into effect when a record is published into, or withdrawn from, the zone. This means that it takes time for a state machine to transition from rumoured to omnipresent and from unretentive to hidden.