[DNSOP] Re: draft-leon-dnsop-signaling-zone-owner-intent-01

[Ben Schwartz <[e-mail]>]

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
<johan.stenstam=[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]