BIND 9 is an open source software DNS server that is widely used on the Internet by enterprises and service providers. It is feature-rich and is being kept up to date with the latest developments in IETF standards, including the work on Multi-Signer.
Enterprises can use multiple DNS providers to serve their zone. This increases the reliability of the service and will likely help them to keep their zone available if one provider is suffering from a critical failure.
Adding DNSSEC to such a setup is not an issue if the zone is signed at the primary server and copied to secondaries using normal zone transfer (XFR). However, DNS providers typically use non-standardized features, such as load-balancing and health checks, and usually require online signing, things that are not compatible with XFR. In other words, these providers require a different model. The Multi-Signer DNSSEC model, specified in RFC 8901, allows providers to sign the zone data themselves, so they can still apply their non-standardized features.
A signer that is part of a Multi-Signer group is required to accept dynamic updates of DNSKEY, CDS, CDNSKEY, CSYNC, and NS records from other providers. Back in 2021, when I was asked if BIND 9 was capable of doing so, I tested a simple setup and concluded it was working just fine. However, I later noticed there were some quirks.
The Multi-Signer model changes the rules of the game. No longer is a single signer responsible for adding DNSSEC records to the zone; coordination between multiple parties is required. This violates some assumptions that were valid with just one signer.
A draft in the IETF describes algorithms for various use cases:
1. A signer joins the Multi-Signer group.
2. A signer leaves the Multi-Signer group.
3. A signer performs a Zone Signing Key (ZSK) rollover.
4. A signer performs a Key Signing Key (KSK) or Combined Signing Key (CSK) rollover.
5. Algorithm rollover.
The document relies on Model 2 from RFC 8901, managing DS records from the parent via CDS/CDNSKEY (RFC 8078), and child-to-parent synchronization with CSYNC (RFC 7477).
There exists a proof-of-concept implementation that implements these algorithms, called MuSiC. At the time of writing, the first two use cases are supported. I have tested these against the following three configurations.
Multi-Signer with dnssec-policy
BIND 9 has a section about Multi-Signer in the Administrator Reference Manual (ARM); it recommends auto-dnssec allow. But this option is marked deprecated and will be removed in the near future, so we want to make sure that it also works with its replacement, dnssec-policy. The configuration looks like this:
dnssec-policy "music" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
};
zone "music1.example." {
type primary;
file "db/music1.example.db";
dnssec-policy music;
update-policy {
grant music. name music1.example. DNSKEY CDS CDNSKEY CSYNC NS;
};
};The configured DNSSEC policy uses the default settings, except for which keys to use. In this experiment, we want to have a KSK/ZSK setup. The update-policy grants the MuSiC tool access to update the required records via TSIG authentication.
Adding a new signer to the Multi-Signer group with the MuSiC software was done successfully but for the wrong reasons.
BIND 9 tries to sign the zone with the keys that have published DNSKEY records. Examining the log files, we can see complaints about missing private key files. But because this provider has access to its own keys, the zone can still be signed and the end result is the same. Nevertheless, the assumption that a published DNSKEY means it should be used for signing is no longer valid, because not all DNSKEY records belong to us. In future versions of BIND 9, the existence of key files will determine which keys should be used for signing.
Secondly, it can be problematic if providers use different CDS/CDNSKEY publication methods. There are two variants — either you keep the CDS and CDNSKEY RRset published, keeping it in sync with the DS RRset that you wish to publish in the parent zone, or you remove the CDS and CDNSKEY records as soon as you detect that the desired DS RRset is published. BIND 9 uses the first strategy. But if another provider, or in this case the MuSiC tool, removes these records, the BIND 9 signer will, at a later point, try to put the CDS/CDNSKEY records back, so that it is in sync again with the DS RRset. Since it does not have state information of the keys from the other providers, BIND 9 can only publish the records related to its own keys. This is problematic for software that consumes these records because the existence of a CDS/CDNSKEY RRset means that it should check them against what is currently published. Now that one CDS/CDNSKEY set is missing, the parent will likely remove the accompanying DS record from the other provider.
In other words, signers in a Multi-Signer model must use the same CDS/CDNSKEY publication method. To accommodate for that, BIND 9 introduces new configuration options that determine which records should be put in the zone. The DNSSEC policy example below is updated to neither publish CDS nor CDNSKEY records (we leave that up to the zone owner in this case).
dnssec-policy "music" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
cds-digest-types {};
cdnskey no;
};Multi-Signer with inline-signing
Let’s take a look at the next configuration. We have a zone that is almost identical to the previous one, except this one is using inline-signing.
zone "music2.example." {
type primary;
file "db/music2.example.db";
dnssec-policy music;
inline-signing yes;
update-policy {
grant music. name music2.example. DNSKEY CDS CDNSKEY CSYNC NS;
};
};This means that the server will maintain two versions of the zone, one unsigned and one signed. The unsigned zone can be used to make updates without having to deal with the DNSSEC clutter. The assumption, therefore, is that the unsigned version of the zone does not contain any DNSSEC records. If BIND 9 encounters such records it will filter them out, to make sure they don’t interfere with our signing process.
When a signer joins a Multi-Signer group, we can no longer assume this. After all, other providers need to be able to update our zone with their DNSKEY (and CDS/CDNSKEY) records.
To cope with this, we need to relax the assumption and allow DNSKEY, CDS, and CDNSKEY records to exist in the unsigned zone.
Bump in the wire
The last configuration is a more complex scenario, attempting to simulate a DNS provider that uses non-standardized features and online signing. While BIND 9 does not support online signing, both setups sign zone data on the secondary server as zone updates are performed on a hidden primary.
With fixes for all the previous issues in place, we still encounter an issue when we try to synchronize the CDS/CDNSKEY RRset between the providers.
If we were the only signer, we could assume that if we are going to publish a CDS/CDNSKEY set, there needs to be a KSK with its DNSKEY record published in the zone. If there is not, BIND 9 refuses to add the CDS/CDNSKEY records. This makes perfect sense, because if a DS record is being published in the parent zone without having the accompanying DNSKEY record available, this is an invalid secure delegation, making your zone bogus.
However, this assumption is no longer true in a Multi-Signer setup. You should be able to publish CDS/CDNSKEY records from other providers.
BIND 9 relaxes this rule and now checks for the existence of any DNSKEY record with the same algorithm.
Roundup
We have tested BIND 9 as a signer with multiple configurations, joining and leaving a Multi-Signer group. We have seen that Multi-Signer changes the rules of the game. Assumptions that were made when there was just a single signer are not necessarily true with multiple signers.
The software tested was BIND 9.18. Fixes for the encountered issues are scheduled to be released in 9.19.X and the subscription release 9.18-S. Follow-up work will include further testing with the MuSiC tool, once the key rollover scenarios have been implemented.
I presented this work at RIPE 86, watch the video or view the slides.
Matthijs Mekking (Twitter, Mastodon) is a software developer who has been involved in the DNS community for over 15 years. He is currently working at ISC on BIND 9 software.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.