The chain of trust is better off without leaps of faith: Automatic authenticated DNSSEC Bootstrapping in PowerDNS Authoritative Server
Authors: Barbara Jantzen & Peter Thomassen (both from deSEC)
Joining the DNSSEC Chain of Trust
The DNS is a two-way system, where information travels up from child to parent and trust moves down from parent to child.
DNSSEC establishes a chain of trust by an initial transfer of public key information between child and parent domain, enabling DNS queries to yield validatable DNS responses, which successful validation will prove both authentic and complete.
The problem: messy and potentially insecure initialization
Initial DS provisioning in the parent zone has long been performed in various, but unsatisfactory ways with regard to usability: manual submission by the registrant, use of REST interfaces with or without 2-factor-login, use of multiple communication channels, staggered communication between multiple parties … Similar concerns exist with regard to security (e.g. choosing TOFU as a leap-of-faith “authentication” scheme, in blunt contradiction with DNSSEC’s security aspirations).
The downsides are obvious: out of band, slow, stateful and error-prone communication, involving too many parties and/or steps, while being potentially unauthenticated.
The solution: the “Bootstrapping” protocol
The DNSSEC Bootstrapping protocol (RFC 9615) allows automated and authenticated in-band DS provisioning. It is now built in as a feature in PowerDNS. How does it work?
In short:
The Bootstrapping Protocol uses an existing chain of trust within the DNS to authenticate information for DS provisioning:
After creating a subdomain in one of the domain’s nameservers (requirement: the nameserver must be located in a different bailiwick than the target zone, and be securely delegated), the CDS/CDNSKEY record set is published both on the apex of the target domain and at the subdomain in the zone of the nameserver. There it is signed, acting as a signal to the registry or registrar. By validating these CDS/CDNSKEY records, the registry or registrar verifies the CDS/CDNSKEY records published at the apex of the target domain, and proceeds with provisioning the DS record in the parent zone.
In detail:
You own the child domain example.com and want DNSSEC enabled for it. For redundancy and resiliency reasons, you have two nameservers for your domain, hosted in two different TLDs, e.g. ns1.provider.net and ns2.example.com (see figure below). The zone of ns1.provider.net is signed and securely delegated (which is an essential requirement to proceed, whereas the other nameserver is in-bailiwick of your domain, so does not contribute to DNSSEC bootstrapping, and consequently does not have to meet this requirement.)
To trigger DS provisioning in the parent zone (.com), your child DNS operator:
1) creates a namespace under each out-of-bailiwick nameserver hostname: _signal.ns1.provider.net.
2) publishes the CDS/CDNSKEY records at the apex of the target zone (example.com) → RFC 8078,
3) co-publishes these records under a zone-specific subdomain of the nameserver’s signaling namespace, and signs them with the nameserver zone’s key, as a signal to be picked up by your registry or registrar (CDS _dsboot.example.com._signal.ns1.provider.net.)
The good news: In PowerDNS Autoritative Server 5, instead of doing this by hand, you can trigger automation just by running the following commands:
nshost=ns1.provider.net
pdnsutil zone create _signal.$nshost $nshost
pdnsutil zone set-signaling _signal.$nshost
This will cause PowerDNS to automatically co-publish CDS/CDNSKEY records of all zones it knows under the appropriate subdomains of _signal.ns1.provider.net. For details, check out the documentation.
Having picked up your child DNS operator’s signal (through scanning or after a notification → RFC 9859), your registry or registrar:
4) validates the CDS/CDNSKEY records in the child target domain against this signal, and if this validation is successful
5) “transfers” its trust in the name server domain (ns1.provider.net) to the child’s target domain (example.com), by acting on the verified CDS/CDNSKEY records and provisioning the DS record in the parent zone (.com).
The take-away
DS provisioning completed: automated, immediate, in-band, stateless, and without any leap of faith. Check it out!
