When a domain owner decides to have their zone secured with DNSSEC, adding validation keys and signatures to the zone are only half the story. To allow resolvers to start validating signatures, it is also necessary to link at least one of the domain’s validation keys (DNSKEY records) to the global DNSSEC chain of trust.
This works using so-called DS records which contain a hash of a DNSKEY validation key, and are published in the parent zone (next to the domain’s delegation NS records). By signing and publishing a DS record, the parent endorses the associated key to be used for validating DNSSEC responses of the child zone.
When it comes to putting DS records into the parent zone, there are two qualitatively different scenarios:
- Initialization (bootstrapping): This is when the delegation does not have DS records yet, and the child wants to enable DNSSEC for the first time.
- DS updates (key rollover): In this case, DS records are added to or removed from an existing set of DS records for the domain in question.
How to transfer DS information to the parent?
An obvious question is how the parent gets the DS information in order to publish it. To enable this information transfer, the IETF has standardized so-called CDS records (RFC 7344). They represent a “tentative” set of DS record(s), and are signed and published in the child zone (thus the record type CDS = “child-side DS”). The parent can discover these CDS records and publish DS records accordingly. (Alternatively, the child can re-publish one or more DNSKEY validation keys using the CDNSKEY record type, which the parent can also discover and then use to generate DS records.)
It is clear that authentication is needed for this process to work securely. In the case of DS updates (second scenario), that’s comparatively easy: As the domain already has a chain of trust, the DNS operator can use an existing key (already endorsed by a DS record in the parent) to sign its CDS/CDNSKEY records. When the parent fetches them, they can then validate the response with DNSSEC, as usual, and reject the DS update when the signature isn’t valid. The DS update only proceeds if authenticity checks succeed.
However, when DNSSEC is being enabled for the first time, the child zone does not have a chain of trust that can be used by the parent to validate the authenticity of CDS/CDNSKEY records. While some parents do some sanity checks (such as observing these records for a while from multiple vantage points), acting upon such unauthenticated CDS/CDNSKEY records eventually comes down to TOFU (“trust on first use”). This is not a cryptographically sound procedure.
The Bootstrapping Protocol
The IETF therefore has been working on standardizing the Authenticated DNSSEC Bootstrapping protocol, which allows the child zone operator to publish a signed copy of the child’s CDS/CDNSKEY records under a different name that has an existing chain of trust. This works by using a subdomain of the child’s nameserver hostnames, such as _dsboot.example.com._signal.ns1.provider.test (so-called signaling names).
For this to work, the zone containing the nameserver hostname (e.g. provider.test) is assumed to be secured with DNSSEC. A parent discovering CDS or CDNSKEY records in a child zone for the first time can then construct the corresponding signaling names, in order to query and validate the CDS/CDNSKEY records published there.
If all is in order, these records are identical to the ones in the child zone, except that they are signed using the DNS operator’s chain of trust. This detour allows cryptographic validation of CDS/CDNSKEY records found under insecure delegations, thereby solving the authentication catch-22 in the bootstrapping scenario.
The protocol specification has recently passed IETF Last Call and has been submitted for publication as an RFC. Some production implementations exist already (both on the child and the parent side), so we decided to add this feature to Knot DNS as well. This means that nameserver operators do not need to co-publish their zones’ CDS/CDNSKEY records manually under the corresponding signaling names, but instead can designate a zone to be a “signaling zone”, so that all required bootstrapping records are synthesized automatically.
How to turn on Authenticated DNSSEC Bootstrapping in Knot DNS
We’ll assume you have a nameserver ns1.provider.test. If that server is authoritative for the example.com zone, your configuration will typically contain something like the following:
zone: - domain: example.com dnssec-signing: on - domain: ... - domain: ...
To enable authenticated DNSSEC bootstrapping, a signaling zone needs to be configured. Since Knot DNS version 3.3.5, this can be done as follows:
- Make sure that the nameserver ns1.provider.test itself is in a secure zone (with DS records).
- Ensure there is appropriate configuration of the module for online signing. At least:
mod-onlinesign: - id: authsignal nsec-bitmap: [CDS, CDNSKEY]
- Add the following to your configuration’s zone section:
- domain: _signal.ns1.provider.test module: [mod-authsignal, mod-onlinesign/authsignal]
and prepare necessary zone contents (SOA and NS records). You can do this on ns1.provider.test directly, or on another nameserver that serves the same zones (so that it knows which CDS/CDNSKEY records to publish). This is useful when not all of your nameservers are able to generate bootstrapping records. - Delegate the signaling zone (_signal.ns1.provider.test) to this Knot DNS instance, and publish DS records for the delegation (in the zone from step 1).
The above steps need to be repeated for each NS hostname used by the domain(s) that you want to bootstrap, such as ns2.provider.test etc. This is because parents will check that the signaling names under all nameserver hostnames serve consistent CDS/CDNSKEY records, to prevent accidental mis-provisioning of DS records.
(Note that as a nameserver can’t bootstrap its own parent, you can skip any in-bailiwick nameservers. In the above example, this means that you won’t be able to bootstrap provider.test if all its NS records are subdomains of that name.)
This blog post was written by Peter Thomassen. The module implementation was contributed by deSEC through the Authenticated DNSSEC Bootstrapping project funded by NLnet Foundation.