Authenticated DNSSEC Bootstrapping: From Hackathon Project to Useful Software

The hackathon took place in May 2023, back to back with the RIPE 86 meeting in Rotterdam, and the hackathon group consisted of Adam Burns, Vincent Jumpertz, Rudi Kraus, Joeri de Ruiter, and myself. At this event, the first lines of code were written to support Authenticated DNSSEC Bootstrapping protocol in Knot DNS.

After the hackathon, the work has continued, and culminated in the completion of ahe Knot DNS module. This outcome is a great example of a successful hackathon project! Congratulations to the team :-)

Background

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 a 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:

1. Initialisation (bootstrapping): This is when the delegation does not have DS records yet, and the child wants to enable DNSSEC for the first time.
2. 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 standardised so-called CDS records (RFC 7344). They represent a “tentative” set of DS records, 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 proceeds only if authenticity checks succeed.

However, when DNSSEC is being enabled for the first time, the child zone does not have a chain of trust than 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 standardising 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 “signalling 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 signalling 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.

How to turn on Authenticated DNSSEC Bootstrapping in Knot DNS

Thanks to the hackathon project, Knot DNS is now able to generate the signalling records needed for authenticated DNSSEC bootstrapping.

We’ll assume you have a Knot DNS nameserver ns1.provider.test. If that server is authoritative for the example.com zone, your configuration will typically contain something like the following:

To enable authenticated DNSSEC bootstrapping, a signalling zone needs to be configured. With the most recent release of Knot DNS, this can be done as follows:

1. Make sure that the nameserver ns1.provider.test itself is in a secure zone (with DS records).

2. Ensure there is appropriate configuration of the module for online signing. At least:

3. Add the following to your configuration’s zone section:

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.

4. Delegate the signalling 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.)

Conclusion

The development of this Knot DNS module was enabled through the RIPE DNS hackathon, and showcases the value of such community gatherings.

Do you have some cool functionality in mind that needs running code, or are you interested in getting yourself immersed deeper in the community? Join the next hackathon!

This implementation was contributed by deSEC through the Authenticated DNSSEC Bootstrapping project funded by NLnet Foundation.