Hi all, We have updated our I-D on DNSSEC bootstrapping. For those who haven't heard of it: It creates a mechanism through which DS records can be automatically provisioned at the parent. We purpose of this is to overcome one of the main DNSSEC adoption obstacles by making it automatic, especially for large managed DNS providers with lots of domains.
* -01 version: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/01/ * dev version (currently same as -01): https://desec-io.github.io/draft-thomassen-dnsop-dnssec-bootstrapping/ This message lists the major changes since the initial version, and gives an update on the implementation status. As a next step, we would like to elicit more feedback from the WG and spark discussion on the direction in which to proceed. We are also interested in operators/registries/registrars who would like to advance the implementation effort. Major changes since -00 ----------------------- Over the past months, we have received comments from individuals, registries, registrars, and DNS operators, which resulted in the following changes: 1.) The protocol now supports enumeration of child domains ready for bootstrapping, directly from the nameserver hosting them. This "to-do list" is available per parent, so that the parent registry or registrar can conveniently retrieve relevant entries to bulk-provision DNSSEC for a large number of delegations. This use case no longer requires any extra records, and can be turned on and off easily by the child DNS operator. 2.) There is now a dedicated section about when/how to trigger the bootstrapping algorithm. 3.) The signaling mechanism essentially provides a authenticated, in-band, unidirectional channel from the DNS operator to the world. It is conceivable that this may be useful beyond DS bootstrapping. To demonstrate this, there is now an appendix explaining how key exchanges between operators could be done in an RFC 8901 multisigner setup. Implementation Status --------------------- Implementations are on the way for all three relevant types of actors (registries, registrars, and DNS operators). As I'm not sure how public those commitments are yet, I am not dropping any names for now. (People are welcome to do that themselves.) At deSEC, we have configured bootstrapping signaling for ~10k domains under _boot.ns1.desec.io and _boot.ns2.desec.org. We also developed the "dsbootstrap" tool, which can be used to generate DS records for a specific delegation, or for all delegations under a given parent. Usage is straightforward. For example, getting DS records for domains under .cl which are hosted on our nameservers, simply do: $ echo ".cl. ns1.desec.io. ns2.desec.org." | dsbootstrap Check it out: https://github.com/desec-io/dsbootstrap#installation-and-usage Thanks, Peter -------- Forwarded Message -------- Subject: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-01.txt Date: Thu, 23 Sep 2021 08:56:37 -0700 From: internet-dra...@ietf.org To: Nils Wisiol <n...@desec.io>, Peter Thomassen <pe...@desec.io> A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-01.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-dnssec-bootstrapping Revision: 01 Title: Automatic Commissioning of New Signers: Solving the DNSSEC Bootstrapping Problem using Authenticated Signals from the Zone's Operator Document date: 2021-09-23 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-01.txt Status: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ Html: https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping Diff: https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-dnssec-bootstrapping-01 Abstract: This document describes an authenticated in-band method for automatic signaling of a Child DNS zone's delegation signer information from the zone's DNS operator(s). The zone's registrar or registry may subsequently use this signal for automatic DS record provisioning in the parent zone. The protocol is particularly useful in case of managed DNS providers hosting registrant's domains, where DS provisioning has so far been cumbersome. The signaling channel is not specific to the DS bootstrapping use case, but equally suitable for announcing other zone-specific information from the DNS Operator in an authenticated fashion. Further potential applications thus include, for example, key exchange between parties in an [RFC8901] multisigner setup. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on at https://github.com/desec-io/draft-thomassen- dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft- thomassen-dnsop-dnssec-bootstrapping/). The most recent version of the document, open issues, etc. should all be available there. The authors gratefully accept pull requests. ]
The IETF Secretariat _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
