Hi Ben, > On 26 Jun 2026, at 16:18, Ben Schwartz <[email protected]> > wrote: > > 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.
I agree completely. I’ve turned from being an SVCB skeptic to instead looking at SVCB as a template for how to build extensible custom RRtypes. RRtypes are cheap, debating the exact RDATA syntax of a new RRtype for several years is expensive. Re-using SVCB syntax is a very promising middle ground. Johan > 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]
