I like the choice, in this case, of reusing the SVCB parsing logic with a new RR type and a separate registry. SVCB is for connection establishment, and this is something else, so this is better than reusing SVCB. I hope this will become a pattern: use SVCB if you are bootstrapping a connection; otherwise just borrow the syntax.
--Ben On Thu, Jun 25, 2026 at 3:56 PM Johan Stenstam <[email protected]> wrote: > > Hi again, We've posted the -01 version of this draft, and the changes are. . > . substantial. The draft is about letting a zone owner signal, in the zone > itself, which DNS providers are authorized to do what for the zone -- serve > it, sign it, manage > > > Hi again, > > > We've posted the -01 version of this draft, and the changes are... > substantial. > > > The draft is about letting a zone owner signal, in the zone itself, which DNS > providers are authorized to do what for the zone -- serve it, sign it, manage > the apex NS RRset, etc; the DNS providers then discover each other and set up > secure communication. The original motivating case was multi-signer DNSSEC > (RFC 8901 "model 2"), but the signaling is more general: the broader > multi-provider use case is arguably much larger than pure multi-signer. > > > The most obvious structural change in -01 is that the single HSYNC record has > been split into two: > > > HSYNC -- per-provider enrollment (Label, Identity, Upstream) > > HSYNCPARAM -- zone-wide policy, as SVCB-shaped key-value pairs > > > HSYNCPARAM now carries eight defined keys (servers, signers, auditors, > nsmgmt, parentsync, suffix, pubkey, pubcds). A provider's role is expressed > by whether its Label appears in the relevant HSYNCPARAM key, which also gave > us a cleaner way to signal onboarding/offboarding. There's a new section > explaining the Label indirection that ties the two records together. > > > This is also no longer only a theoretical model: we have a complete prototype > implementation. Work on the prototype has clarified a number of issues which > have been reflected in the new version of the draft. Two immediate examples > are: > > > 1. The previous version split provider responsibilities into three functional > components: the Combiner (receives the zone from the customer and applies > necessary changes to managed RRsets), the Signer (signs the zone) and the > Agent (interacts with the Agents of other providers to sort out > synchronization needs). > > > This has now expanded to a fourth role, the Auditor. The Auditor is not > part of a provider; it is an independent participant in the synchronization > communication among Agents, whose task is to provide an audit trail and > verify that each participant behaves as specified. > > > 2. The focus has migrated from "what to synchronize" (eg. DNSKEYs in the > multi-signer case) to "how to do multi-party distributed synchronization of > DNS data". The synchronization semantics matter much more than whether it is > the NS, CDS or some other RRset being synchronized -- and once the > synchronization model is right, "multi-signer" comes almost for free. > > > The document has also been re-scoped to the architecture: the problem > statement, the HSYNC/HSYNCPARAM signaling, the provider model and the > synchronization framework. The detailed agent-to-agent wire mechanics are > deferred to a companion draft (draft-berra-dnsop-chunk-framing). > > > We'd especially welcome views on the HSYNC/HSYNCPARAM split and the addition > of the independent Auditor. > > > Erik Bergström, Leon Fernandez and Johan Stenstam > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
