License Portal
Deutsch

DNSSEC Migration

Category: DNS
Created: 2025-04-09

LiveConfig supports DNSSEC since version 1.8.2 (see article Using DNSSEC). With the LiveConfig update to Version 2.18 or Version 3.0, a technically necessary migration of the DNSSEC configuration takes place, which we describe in more detail in this document.

Migration from auto-dnssec to dnssec-policy

Until now, LiveConfig used the BIND option auto-dnssec: maintain for DNSSEC. However, this is now deprecated and has been replaced by the dnssec-policy method. As of BIND 9.20 at the latest, auto-dnssec is no longer supported - the changeover is therefore mandatory.

The new method (dnssec-policy) is very powerful and simplifies the use of DNSSEC considerably. The improved key management requires BIND to have write access to the keys. However, BIND with AppArmor does not have write access to the /etc/bind/keys/ directory used up to now, so we have to move the keys to /var/lib/bind/keys/. In addition, some metadata must be added to the keys (e.g. time of publication in the DNS) so that BIND can calculate the validity periods and automatically trigger a rotation.

With the update of LiveConfig to version 2.18 or 3.0, the following changes are therefore made to the BIND/DNSSEC configuration:

  • the file /etc/bind/named.conf.options gets dnssec-policy entries, in which the supported algorithms and rotation periods are managed
  • the keys are moved from /etc/bind/keys/ to /var/lib/bind/keys/ and their file permissions are adjusted
  • in /etc/bind/zones.liveconfig, auto-dnssec maintain; is replaced by dnssec-policy <policy>;, the option dnssec-secure-to-insecure yes; is removed and the key-directory statement is adjusted
  • in addition, the existing KSK keys are given a DSPublish date (so that BIND assumes that they are already published in the DNS)
  • BIND in turn automatically adds a SyncPublish date and automatically creates corresponding CDS and CDNSKEY records.

Basically, only DNS zones with activated DNSSEC are affected, and these are only migrated on the primary DNS server. Secondary servers are not affected by any of this.

It is best to wait about five minutes after the update before checking whether everything is working correctly.

DNSSEC keys that are still in /etc/bind/keys/ after the update to 2.18 or 3.0 were either added there manually at some point (i.e. are not managed by LiveConfig), or are obsolete/unused and can be deleted.

Multi-server installations

For multi-server installations of LiveConfig, it does not matter in which order you update the servers. DNSSEC migration is only triggered for zones if both the client (with BIND as primary DNS) and the LiveConfig server are running at least version 2.18.

Diagnostics & Tools

  • after the LiveConfig update, check whether there are any anomalies in the BIND log (either /var/log/named/messages, /var/log/messages or via journalctl -S today -u named.service)

  • With rndc dnssec -status <zone> the DNSSEC status of a zone and its keys can be checked - it looks like this, for example:

    # rndc dnssec -status example.org
dnssec-policy: lc-nsec3rsasha1-2048
current time:  Wed Apr  9 12:43:45 2025

key: 13968 (NSEC3RSASHA1), KSK
  published:      yes - since Tue Apr  8 09:40:00 2025
  key signing:    yes - since Tue Apr  8 09:40:00 2025

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         omnipresent
  - ds:             omnipresent
  - key rrsig:      omnipresent

key: 42374 (NSEC3RSASHA1), ZSK
  published:      yes - since Tue Apr  8 09:40:01 2025
  zone signing:   yes - since Tue Apr  8 09:40:01 2025

  Next rollover scheduled on Sat Jun  7 08:35:01 2025
  - goal:           omnipresent
  - dnskey:         omnipresent
  - zone rrsig:     omnipresent

    It is important here that omnipresent is written everywhere in the key states. Documentation of the key states can be found at https://kb.isc.org/docs/dnssec-key-states.

  • The website https://dnsviz.net/ enables a detailed external check of whether DNSSEC is working correctly

Outlook

In the long term, an automated deployment of DNSSEC is also planned with dnssec-policy - thanks to CDS and CDNSKEY records. The procedure is described in RFC8078, among others - but hardly any registrars support it yet. But we are keeping an eye on it. :-)