Signaling Zone Owner Intent

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4.1. Coordinated NS Record Management

A zone owner uses two DNS Providers -- one signs and serves the zone while another only serves it. The zone owner publishes one HSYNC record per Provider and an HSYNCPARAM record whose Section 11.1 key lists both Providers and whose Section 11.2 key lists only the signing one. The Providers' Agents establish secure communication channels, allowing them to coordinate NS RRset management across all authoritative nameservers without manual intervention. The zone owner can decide whether to retain control of NS records or delegate this responsibility to the Providers via the Section 11.4 key.¶

4.2. Multi-Provider DNSSEC Redundancy

A zone owner needs to eliminate the "signing" single point of failure in their DNSSEC setup. By contracting with multiple "multi-signer capable" DNS Providers and listing them in the HSYNCPARAM Section 11.2 key, the zone owner enables each Provider to:¶

• Locate other designated Providers via the HSYNC RRset and establish secure communications.¶

• Coordinate DNSKEY, CDS, CSYNC and NS RRset management.¶

• Sign the zone using its own DNSKEYs while publishing a DNSKEY RRset that includes keys from all authorized signers.¶

• Distribute the signed zone to its authoritative nameservers and possibly to non-signing downstream Providers.¶

This creates a fully redundant DNSSEC infrastructure with no single point of failure.¶

4.3. Provider Transition Management

A zone owner wishes to replace their current DNSSEC-signing Provider with a new one. Using HSYNC + HSYNCPARAM, they are able to:¶

• Add a new HSYNC record for the incoming Provider and add its Label to the HSYNCPARAM Section 11.2 key, initiating the onboarding process.¶

• Allow the automated synchronization between Providers to handle key exchange and transition.¶

• Once the new Provider is fully operational, remove the outgoing Provider's Label from Section 11.2 when convenient, leaving its HSYNC record in place for the wind-down.¶

• The Providers then automatically coordinate the safe removal of the outgoing Provider's data.¶

This entire process maintains continuous service and valid signatures while transitioning between DNS Providers.¶

4.4. Delegated NS Management

A zone owner wants DNS Providers to handle NS RRset management while retaining control of other zone data. By setting the Section 11.4 key in HSYNCPARAM to "agent", the zone owner explicitly delegates NS management responsibility to the DNS Providers. The DNS Providers then coordinate to maintain a consistent NS RRset across all authoritative servers, adding or removing nameservers as needed based on the current set of authorized Providers.¶

4.5. Phased Migration to Multi-Provider Architecture

A zone owner currently using a single Provider wants to implement a more robust architecture but prefers a gradual transition. They can:¶

• First add a single HSYNC record designating their current Provider, plus an HSYNCPARAM record listing that Provider in Section 11.1 (and, if signing, in Section 11.2), making no immediate operational changes.¶

• Later add a second HSYNC record for the additional Provider and extend the HSYNCPARAM lists accordingly.¶

• Allow the Providers to automatically coordinate the transition.¶

• Optionally delegate NS management to the Providers by changing the Section 11.4 key from "owner" to "agent".¶

This approach enables a controlled, phased migration to a more resilient multi-provider architecture.¶

6.1. The Combiner

The consequence of these requirements is that the DNSKEY, CDS and CSYNC RRsets (and possibly the NS RRset) are maintained via a separate piece of software inserted between the zone owner and the Signer. This is referred to as the Combiner.¶

The Combiner has the following features:¶

• It supports inbound zone transfer of the unsigned zone from the zone owner.¶

• It receives updates for the NS, DNSKEY, CDS and CSYNC RRsets from the Agent. Typically the mechanism used is DNS UPDATE with a TSIG signature, as this is easy to configure in a local context. However, other mechanisms, including APIs, are possible.¶

• It stores all data received from the Agent separate from the zone data received from the zone owner.¶

• Whenever it receives a new unsigned zone from the zone owner it COMBINES zone data from the zone owner (the majority of the zone) with specific zone data under control of the Agent: three specific RRsets, all in the apex of the zone: the DNSKEY, CDS and CSYNC RRsets. According to zone owner policy expressed in the HSYNCPARAM Section 11.4 key it will also update the NS RRset.¶

• It is policy free (apart from being limited to the four specified RRsets). I.e. the Combiner is not making any judgement about what data to include in the zone from the four defined RRsets. That judgement is the role of the Agent.¶

• It does not sign the zone.¶

• It provides outbound zone transfer of the combined zone to the Signer.¶

Example setup with two signers showing the logical flow of zone data between the zone owner, the Combiner, the Signer and the Agent:¶

                            +--------------+
                            |     owner    |
               xfr          +-+---------+--+    xfr
            /----------------/           \----------------------\
           /                                                     \
    +-----+----+    DNS  +-------+ DNS/API +-------+  DNS    +----+-----+
    | combiner +<--------+ agent +---------+ agent +-------->+ combiner |
    +-----+----+  UPDATE +--+----+         +--+----+ UPDATE  +----+-----+
          |                 ^                 ^                 |
          v xfr             |                 |                 v xfr
    +-----+----+     xfr    |                 |   xfr      +----+-----+
    |  signer  +------------+                 +------------+  signer  |
    +-----+----+                                           +----+-----+
          |                                                     |
          v                                                     v
       +--+--+                                               +--+--+
       | NS  |--+                                            | NS  |+
       +-----+  |--+                                         +-----+|-+
          +-----+  |                                            +---+ |
             +-----+                                              +---+

In the reference architecture every Provider deploys all three components -- Combiner, Signer, and Agent -- and every zone the Provider serves flows through the same path: from the upstream zone owner to the Combiner, then to the Signer, then to the Agent and on to the Provider's public secondary nameservers. A Provider typically serves a large number of zones, some signed and some not, and a zone may change between unsigned and signed over its lifetime (for example when the zone owner requests signing via HSYNCPARAM). Rather than maintain a different zone-transfer path per zone, all zones use this one path. For an unsigned zone the Signer makes no modifications -- it is effectively a pass-through -- but it remains in the path, continuing to serve as the dependable upstream for the Provider's public secondaries. Signing status therefore changes what the components do for a given zone, not which components are present or how zone data flows between them.¶

6.2. The DNS Provider

A "DNS Provider" is a term that is most commonly used to refer to an entity that provides authoritative DNS service to one or more zone owners. In the context of this document it is used to refer to an entity that provides some subset of the following services:¶

• Signing a zone received from the zone owner.¶

• Serving the zone via a set of authoritative nameservers.¶

• Distributing the signed zone to other downstream DNS Providers.¶

In addition to the above services, a DNS Provider in the reference architecture provides all three of the internal components:¶

• A Combiner that persists Agent contributions and merges the role-permitted changes into the zone;¶

• a Signer that performs DNSSEC signing (a no-op for unsigned zones, see Section 6.1); and¶

• an Agent for synchronization with the other Providers' Agents.¶

Whether a Provider actually signs a given zone, and which of the coordinated RRsets it applies, depends on its role for that zone (expressed via HSYNCPARAM) -- not on which components it deploys. Every Provider provides all three internal components.¶

6.3. The Auditor

In addition to the DNS Provider role, this document defines an Auditor role. An Auditor is an entity authorized by the zone owner to observe the multi-provider synchronization for a zone without contributing to it. An Auditor does not serve the zone and does not sign the zone; its purpose is to detect inconsistencies (for example, divergence between Providers' DNSKEY contributions, or NS RRset drift) and to flag them to the zone owner.¶

Auditors participate in the Agent-to-Agent communication for the zone. An Auditor is identified via its HSYNC record just like the Agents, and is designated by the zone owner via the Section 11.3 key of the HSYNCPARAM record. Unlike a serving or signing Provider, the Auditor does not contribute zone data; it joins the same communication purely to observe the synchronization state exchanged among the Agents.¶

The Auditor's interpretation of inconsistencies, and the channel through which it reports findings to the zone owner, are out of scope for this document. Implementations are free to express these as alerts, dashboards, periodic reports, or via any other mechanism that suits the deployment.¶

An Auditor SHOULD only receive zone data and observe synchronization state; it MUST NOT contribute zone data (DNSKEY, CDS, CSYNC, NS records, etc.) via the Agent-to-Agent SYNC operation. Any contribution originating from an Auditor MUST be rejected by the Agents.¶

9.1. Offboarding and Staging a Provider

Whether a DNS Provider is currently active for a zone is determined not by the HSYNC record itself but by whether the Provider's Label appears in any of the HSYNCPARAM role keys (Section 11.1, Section 11.2, Section 11.3). The HSYNC record only enrolls the Provider and locates its Agent; the role keys say what, if anything, the Provider currently does. This gives the zone owner two operations that do not require adding or removing fields in the HSYNC record:¶

• Offboarding a Provider is signalled by removing its Label from all HSYNCPARAM role keys while leaving its HSYNC record in place. The HSYNC record is retained so that the Provider remains identifiable (by Label and Identity) to the remaining Agents during the wind-down: the offboarding process typically involves the remaining DNS Providers removing the departing Provider's contributed data in the correct order (either during the multi-signer "remove signer" process of [RFC8901] or a simpler "remove auth nameserver" process). A Provider whose Label is absent from every role key, but whose HSYNC record is still present, is understood to be in the process of being offboarded. Once the offboarding process is complete, the HSYNC record for the offboarded DNS Provider may be removed from the zone at the zone owner's discretion.¶

• Staging a new Provider is signalled by publishing its HSYNC record before adding its Label to any role key. No data from the Provider is used by the other Providers as long as its Label is absent from the role keys, but it is possible to verify that communication and the discovery records all work as intended before the Provider is made active by adding its Label to the appropriate role key.¶

10.1. Unknown Keys and Private Use

A receiver that encounters an HSYNCPARAM key number it does not recognize MUST preserve the key on read-back but MUST NOT take any action based on it. In presentation format, unknown numeric keys MUST be written as keyN (where N is the decimal key number) so that they can be parsed unambiguously by tools that have been updated with the key definition.¶

The key number range 0-32767 is allocated for IANA-registered keys, assigned through Specification Required review (see Section 20.3). The range 32768-65534 is reserved for Private Use; receivers within a single administrative domain may assign meaning to keys in that range without registration. Key number 65535 is reserved and MUST NOT be assigned.¶

11.1. servers

Key number: 0¶

Type: list of Labels.¶

The servers key signals which Providers are designated to serve the zone authoritatively. Each value in the list is a Label matching the Label field of an HSYNC record in the same zone. Providers whose Label appears in servers SHOULD configure themselves as authoritative for the zone.¶

The Labels used in HSYNCPARAM list keys are unqualified tokens, not fully qualified domain names. They are short handles defined by the HSYNC records in the same zone; the FQDN of each Provider's Agent is given by the HSYNC Identity field. See Section 9 for the HSYNC record format.¶

Example:¶

zone.example. IN HSYNCPARAM servers="fox,hare"¶

11.2. signers

Key number: 1¶

Type: list of Labels.¶

The signers key signals which Providers are designated to sign the zone. Each value is an HSYNC Label. A Provider whose Label is in signers is typically also in Section 11.1, but this is not required.¶

Example:¶

zone.example. IN HSYNCPARAM servers="fox,hare" signers="fox,hare"¶

11.3. auditors

Key number: 2¶

Type: list of Labels.¶

The auditors key signals which entities act as Auditors for the zone. See Section 6.3 for the Auditor role definition.¶

Example:¶

zone.example. IN HSYNCPARAM servers="fox,hare" signers="fox,hare" auditors="auditor1"¶

11.4. nsmgmt

Key number: 3¶

Type: value, one of "owner" or "agent".¶

The nsmgmt key signals who is responsible for the contents of the NS RRset for the zone. Two values are defined:¶

• "owner" -- the zone owner is responsible for the NS RRset. Agents MUST NOT instruct their local Combiner to update the NS RRset.¶

• "agent" -- the Providers' Agents collectively are responsible for the NS RRset. Agents whose Provider is listed in Section 11.2 MUST instruct their local Combiner to update the NS RRset based on the union of NS records contributed by Providers via Agent-to-Agent communication.¶

If nsmgmt is absent, the default is "owner".¶

In-bailiwick address records (A/AAAA records for nameservers whose name lies within the zone) are deliberately not covered by nsmgmt. The reasons are to limit the possibility of DNS Providers polluting the zone's namespace, and to keep the specification simpler -- the concept of delegated NS management is already new. See Section 11.6 for the separate signaling that lets Providers add their own nameserver names and addresses, scoped under a label designated by the zone owner.¶

Example:¶

zone.example. IN HSYNCPARAM nsmgmt="agent" signers="fox,hare"¶

11.5. parentsync

Key number: 4¶

Type: value, one of "owner" or "agent".¶

The parentsync key signals who is responsible for synchronizing delegation information (NS, glue, DS) with the parent zone. Two values are defined:¶

• "owner" -- the zone owner is responsible for sending updates to the parent (via whichever mechanism the parent announces in its DSYNC record).¶

• "agent" -- the Providers' Agents collectively are responsible for parent synchronization; this is typically coordinated via leader election among the Agents.¶

If parentsync is absent, the default is "owner". The specific mechanism by which the parent receives the update (NOTIFY, DDNS UPDATE, etc.) is announced by the parent via the DSYNC record defined in [RFC9859].¶

Example:¶

zone.example. IN HSYNCPARAM nsmgmt="agent" parentsync="agent" signers="fox,hare"¶

11.6. suffix

Key number: 5¶

Type: value, a single valid DNS label.¶

When the suffix key is present, DNS Providers MAY add in-bailiwick address records to the zone for nameservers they contribute -- but only for names below {suffix}.{zone}. The value of the key MUST be a single valid DNS label (not a fully qualified domain name).¶

If suffix is absent, Providers MUST NOT add in-bailiwick nameserver records (NS or address records) to the zone. The purpose of this restriction is to prevent unintended namespace collisions between owner-controlled names and Provider-added names.¶

If suffix="ns" is present in HSYNCPARAM, then a Provider with Label "fox" MAY add:¶

zone.example. IN NS fox1.ns.zone.example. fox1.ns.zone.example. IN A 1.2.3.4 fox1.ns.zone.example. IN AAAA 2001::53¶

and similarly for other Providers. Providers MUST coordinate amongst themselves (via Agent-to-Agent communication) to avoid name collisions below {suffix}.{zone}.¶

Example:¶

zone.example. IN HSYNCPARAM nsmgmt="agent" signers="fox,hare" suffix="ns"¶

11.7. pubkey

Key number: 6¶

Type: flag.¶

Keys pubkey and pubcds (see Section 11.8) instruct DNS Providers to publish KEY and CDS/CDNSKEY records on behalf of the zone owner at well-known names. Without these signals, Providers would have to scan customer zones for various conventional content (per [RFC9615] Section 3.1 for CDS, and similar conventions for other RR types). The HSYNCPARAM record provides a single, designed-for-purpose place where the zone owner expresses such intent, making the signaling explicit rather than implicit in zone content.¶

The pubkey flag signals the zone owner's intent that each Provider SHOULD publish the child's SIG(0) KEY at the special name _sig0key.{child}._signal.{their-ns-name}. in their own zone. The use case for this key is the SIG(0) bootstrap mechanism for the cross-zone-cut DNS UPDATE messages defined in [I-D.ietf-dnsop-delegation-mgmt-via-ddns].¶

The _signal label in the name pattern is registered in the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552] by [RFC9615].¶

Example:¶

zone.example. IN HSYNCPARAM signers="fox,hare" pubkey¶

11.8. pubcds

Key number: 7¶

Type: flag.¶

The pubcds flag signals the zone owner's intent that each Provider SHOULD publish the zone's CDS and/or CDNSKEY records at the special name _dsboot.{child}._signal.{their-ns-name}. in their own zone, per the DNSSEC bootstrap mechanism defined in [RFC9615].¶

This signal replaces the implicit RFC 9615 Section 3.1 convention by which Providers would otherwise scan customer zones for CDS or CDNSKEY content. Under pubcds the zone owner's intent is explicit; under absence of pubcds, Providers MUST NOT publish CDS or CDNSKEY records on behalf of the zone.¶

Example:¶

zone.example. IN HSYNCPARAM signers="fox,hare" pubkey pubcds¶

13.1. The Synchronization Problem

The difficulty is that the contributions arrive independently and asynchronously. Each Provider's Agent contributes when its local state changes -- a new DNSKEY is published, a nameserver is added or removed -- and those contributions reach the other Agents at different times, over a communication mesh that may be partitioned or delayed. There is no global lock and no single component that owns the combined result (see Section 6).¶

The synchronization model is therefore one of eventual consistency: given a stable set of contributions, all Providers converge on the same combined RRsets, but they do not do so atomically. Two properties bound this convergence:¶

• Safety over liveness. At every point during synchronization the zone remains available and correctly signed under the data each Provider already holds. If a contribution is delayed or an Agent is unreachable, synchronization pauses rather than producing an inconsistent or unsigned zone; it resumes from where it stopped once the missing input arrives. A multi-signer key rollover illustrates this: when one signing Provider introduces a new key, that key is not relied upon for the zone until every signing Provider has confirmed it has published the new key in the joint DNSKEY RRset. If one signer is slow or temporarily unreachable, the rollover does not fail -- it simply pauses until that signer catches up, and the zone stays valid under the keys already in effect throughout.¶

• Role asymmetry. The Providers do not all play the same role for a zone. A non-signing Provider still participates in coordination (for example, contributing NS records when NS management is delegated), but it must not act on contributions that only a signer may apply. What a Provider does with a contribution depends on its role, expressed by the zone owner through the HSYNCPARAM keys defined in this document.¶

A second consequence of role asymmetry is that not every Provider ends up serving identical zone content: the coordinated RRsets are the same everywhere, but, for example, a Provider's served zone reflects only the NS management policy in force. The model below makes this precise.¶

13.2. Persisting All, Applying by Role

The Combiner (Section 6.1) at each Provider receives contributions from the Agents and merges the role-permitted ones with the owner's zone data, passing the merged zone to the local Signer. Conceptually the Combiner maintains three derived views:¶

• the per-Agent contributions, one set per contributing Agent, retained as received;¶

• a merged view, deduplicating the per-Agent contributions for the same owner name and RRtype into a single combined RRset; and¶

• the live zone served to queries, produced by applying the merged view to the owner's zone data.¶

The central rule that makes distributed synchronization well-defined is the separation of these two actions:¶

• Every Combiner persists all contributions received from authorized Agents; each Combiner applies to its live zone only those contributions that its role permits.¶

Persistence is unconditional: a contribution from an authorized Agent is always retained, regardless of the receiving Provider's role. Application is conditional on role. A non-signing Provider's Combiner therefore holds the same set of contributions as a signing Provider's Combiner; the two differ only in what reaches the served zone. Retaining the full contribution set at every Provider is what allows a Provider's role to change -- or a new signer to be onboarded -- without first having to re-gather data that some Provider had previously discarded.¶

In this architecture the Combiner, not the Agent, is the component responsible for durably persisting contributions, for two reasons:¶

• The Combiner must hold the complete set of contributions so that it can re-apply the role-permitted changes to every new version of the unsigned zone it receives from the zone owner. Each inbound zone transfer from the owner replaces the owner-supplied content, and the coordinated RRsets must be merged in again; the Combiner can only do this if it retains the contributions independently of any single zone version.¶

• Keeping the persistent state in the Combiner lets the Agent be restartable at any time. The Agent holds no durable contribution state of its own; when an Agent restarts, it resynchronizes by requesting the current set of contributions from its Combiner, on a per-zone basis, and resumes from there. This keeps the Agent close to stateless and avoids a separate recovery mechanism in the Agent.¶

13.3. Role-Derived Edit Policy

Whether a Combiner applies a given contribution to its live zone is determined by four conditions, all derived from the zone's HSYNCPARAM record and the Combiner's own role:¶

• whether the zone is signed;¶

• whether this Provider is a signer (its Label appears in the Section 11.2 key);¶

• whether NS management is delegated to the Agents (Section 11.4 is "agent"); and¶

• whether parent synchronization is delegated to the Agents (Section 11.5 is "agent").¶

Each coordinated RRset is applied only when the corresponding conditions hold. A Combiner MUST apply a received contribution to its live zone only when the condition in the following table is satisfied for that RRset, and MUST otherwise retain the contribution without applying it:¶

The KEY RRset in this table is the SIG(0) public key used for parent synchronization via DNS UPDATE; it is unrelated to the JWK-based keys used for Agent-to-Agent authentication. DNSKEY is meaningful only for signed zones, while NS and KEY may be applied by any Provider's Combiner for an unsigned zone, gated only by the nsmgmt and parentsync policies respectively.¶

13.4. Reporting Whether a Contribution Was Applied

Because a contribution may be persisted by a Combiner without being applied, the Agent that originated it needs to learn which of the two happened. A Combiner reports one of three outcomes for each contributed RRset:¶

• applied -- the contribution was persisted and reached the live zone;¶

• persisted-not-applied -- the contribution was persisted but the role-derived edit policy did not permit applying it (the running implementation labels this status IGNORED). This is a definitive outcome: it is not an error, and the originating Agent SHOULD NOT retry; the data is safely held; and¶

• rejected -- the contribution was not accepted at all, for example because the contributing Agent is not authorized to contribute zone data. This is the expected outcome for any contribution originating from an Auditor (Section 6.3), which participates in the synchronization but MUST NOT contribute zone data.¶

Both "applied" and "persisted-not-applied" are definitive answers that allow the originating Agent to stop tracking the contribution as outstanding. When an Agent has sent a contribution to several recipients, the contribution is considered applied for the zone if ANY recipient reports "applied"; it is considered persisted-not- applied only if ALL recipients report "persisted-not-applied". This lets the originating Agent answer the operationally important question: did any Provider actually apply my data? A contribution that every recipient persists but none applies (for example, an NS contribution to a zone whose owner retains NS management) is correctly reported as applied nowhere, without being treated as a failure.¶

13.5. Scope

This section defines the synchronization model and the invariants that every implementation must share: what data is kept in sync, the persist-all / apply-by-role rule, the role-derived edit policy, and the contribution-reporting semantics. The concrete multi-step synchronization processes built on this model -- adding or removing a signer, coordinated key rollovers, NS RRset reconciliation, and parent synchronization -- are out of scope for this document and are specified separately (see [I-D.ietf-dnsop-dnssec-automation]).¶

14.1. Agent Communication via DNS

Structured data -- zone contributions, key state signals, synchronization state, and confirmations -- cannot be sent over DNS as-is, since DNS carries only resource records or opaque option data. The CHUNK framing mechanism defined in [I-D.berra-dnsop-chunk-framing] encodes such structured data for transport over DNS; this document relies on that mechanism without constraining how it works.¶

CHUNK optionally secures payloads using the JOSE framework: authentication via JWS signatures ([RFC7515]) and confidentiality via JWE ([RFC7516]) encryption, using cryptographic keys discovered from JWK records ([RFC7517]) published in the DNS.¶

This model builds on the approach used by [I-D.berra-dnsop-keystate] for delegation synchronization between child and parent, which has already been implemented and shown to work.¶

14.2. Agent Communication via REST API

REST APIs are well-known and a natural fit for many distributed systems. Because a REST API can carry arbitrary JSON-serialized data structures directly, the same Agent messages (HELLO, BEAT, SYNC, etc.) are sent as JSON in the request and response bodies, with no CHUNK framing required. The challenge is mostly in the initial setup of secure communication. The certificates need to be validated, preferably without a requirement on trusting a third party CA. The API endpoints for each Agent need to be located. Once secure communication has been established, using a REST API for Agent communication is straight-forward.¶

14.3. Locating Remote Agents

When an Agent receives a zone via zone transfer from the Signer it analyzes the zone to see whether it contains an HSYNC RRset. If there is no HSYNC RRset the zone MUST be ignored by the Agent from the point-of-view of provider synchronization.¶

If the zone contains an HSYNC RRset, the Agent MUST analyze it to identify the other Agents for the zone via the Identity field in each HSYNC record. If any of the other Agents identified by the HSYNC RRset is previously unknown to this Agent then secure communication with this other Agent MUST be established.¶

This document defines two transports: "DNS" (the baseline, which all Agents MUST support) and "API". An Agent signals which transports it supports by publishing the corresponding discovery records in the DNS; this record publication is what replaced the in-band transport signaling of earlier designs.¶

Each transport is discovered through the same three-step shape -- a URI record at the HSYNC Identity, the SVCB record of the URI target, and a final record at that target -- but the two flows are independent, starting from different service-prefixed URI names and ending in different records: _dns._tcp ending in a JWK record for DNS transport, and _https._tcp ending in a TLSA record for API transport. The following two subsections describe each flow.¶

14.4. The Initial HELLO Phase

When two Agents need to communicate with each other for the first time (because they are both designated DNS Providers for the same zone), they need to establish secure communication. This is done in a "HELLO" phase where the two Agents exchange HELLO messages to establish mutual identity.¶

If all the information needed for API-based transport for the remote party was available, the Agent SHOULD attempt an API-based HELLO. If, however, this fails for some reason, it should fall back to DNS-based HELLO.¶

14.5. Defined Message Types

Each CHUNK message carries a message type that identifies the kind of message being sent. CHUNK message types are strings, and implementations may define additional message types as needed. The message types used by the Agent-to-Agent communication described in this document are listed below. The structured data payload for each message type is carried using the CHUNK framing mechanism ([I-D.berra-dnsop-chunk-framing]), which defines how the message type and payload are encoded and which DNS carriage is used.¶

16.1. Enabling Remote Agents to Locate This Agent

For a group of Agents to be able to communicate securely and synchronize data for a zone, each Agent must ensure that the DNS records needed for secure communication with other Agents are published:¶

• URI, SVCB and JWK records required for DNS-based communication using CHUNK framing (see [I-D.berra-dnsop-chunk-framing]).¶

• URI, SVCB and TLSA records required for API-based communication secured by TLS (if supported).¶

• All of the above MUST be published in a DNSSEC-signed zone under the domain name that is the identity of the Agent.¶

16.2. Exchanging Zone Data Between Agents

Agents exchange synchronization messages -- HELLO, BEAT, SYNC, and the other message types defined in Section 14.5 -- over either DNS- or API-transport. The messages themselves are the same in both cases; in the DNS case they are encapsulated in CHUNKs, the framing mechanism defined in [I-D.berra-dnsop-chunk-framing], whereas API-transport carries the JSON-serialized messages directly.¶

The zone data that each Agent contributes to the other Agents for a zone consists of:¶

• The DNSKEY RRset for the zone consisting of the DNSKEYs that the local Signer for this DNS Provider uses to sign the zone.¶

• The CDS RRset for the zone, representing the KSK that the local Signer uses to sign the zone (when needed).¶

• The CSYNC RRset for the zone (when needed).¶

• The NS RRs for the zone, consisting of the NS records of the authoritative nameservers that this DNS Provider is responsible for (when NS management is delegated to the Agents).¶

Each Agent sends its zone data contributions to all other Agents for the zone using the SYNC message type (see Section 14.5). The receiving Agent is responsible for instructing its local Combiner to incorporate the received data.¶

17.1. Adding HSYNC and HSYNCPARAM Records To an Already Signed Zone

Adding HSYNC and HSYNCPARAM records to a zone that is already signed by a single DNS Provider, while keeping that Provider as the sole signer and the zone owner in charge of NS management, is a no-op that does not change anything in the zone:¶

zone.example. IN HSYNC provider agent.provider.com. . zone.example. IN HSYNCPARAM servers="provider" signers="provider"¶

The zone was already signed by the DNS Provider "provider.com" and the Provider added any needed DNSSEC records, including DNSKEYs. The zone NS RRset was managed by the zone owner (the default in the absence of Section 11.4). All of this is unchanged by the addition of the two records.¶

What does change is the possibility of further migration steps that build on the now-published signaling.¶

17.2. Promoting a Provider from Server-Only to Signer

A zone owner may want to start having a Provider sign the zone without changing which Providers serve it. With the HSYNC records already in place, this is signaled by adding the Provider's Label to the Section 11.2 list of HSYNCPARAM. For example, starting from a zone where "fox" serves but does not sign:¶

zone.example. IN HSYNC fox agent.fox.example. . zone.example. IN HSYNC hare agent.hare.example. fox zone.example. IN HSYNCPARAM servers="fox,hare" signers="hare"¶

the zone owner adds "fox" to the signers list:¶

zone.example. IN HSYNCPARAM servers="fox,hare" signers="fox,hare"¶

The HSYNC records are unchanged. From this point onward, both Providers are designated signers, and the multi-signer "add signer" process (see [I-D.ietf-dnsop-dnssec-automation]) is initiated by the Agents to bring the new signer's keys into the joint DNSKEY RRset.¶

17.3. Delegating NS Management to the Agents

To migrate from owner-maintained NS RRset to Agent-maintained, the zone owner must first verify that the NS RRset as it would be computed by the Agents (from the union of their NS contributions) is in sync with the NS RRset currently published by the zone owner. After this verification the zone owner adds (or changes) the nsmgmt key in the HSYNCPARAM record to nsmgmt="agent". The HSYNC records are unchanged.¶

17.4. Migrating from a Multi-Signer Architecture Back to Single-Signer.

If, for some reason, a zone owner wants to migrate back to a single-signer architecture (i.e. offboarding the second DNS Provider), the process is essentially the reverse of the migration from single-signer to multi-signer:¶

1. The zone owner offboards the second signing DNS Provider (only keeping one signing DNS Provider).¶

Offboarding the second signing DNS Provider is signalled by removing its Label from the HSYNCPARAM Section 11.2 key, leaving its HSYNC record in place for the wind-down. This initiates the multi-step "remove signer" process (as defined in [I-D.ietf-dnsop-dnssec-automation]), which removes the second DNS Provider's data from the zone in a series of steps.¶

The zone is now essentially back to a single-signer architecture. Once the offboarding is complete, the zone owner may remove the HSYNC record for the offboarded DNS Provider from the zone.¶

TO BE REMOVED BEFORE PUBLICATION: # Rationale¶

17.5. Choice of the HSYNC Mnemonic

Initially the mnemonic "MSIGNER" was used for the HSYNC RRset. However, as work progressed it became clear that we want also non-signing DNS Providers to be able to participate. So the RRset is a signalling mechanism from zone owner to DNS Providers, some of which may or may not be instructed to sign the zone. Therefore we suggest the mnemonic "HSYNC" to indicate that this is a mechanism for "horizontal synchronization" inside a zone.¶

But the mnemonic chosen is a very minor point and should a better suggestion come up it would be great.¶

17.6. Separation of Agent and Combiner

It is possible to integrate all three multi-signer components (Signer, Agent and Combiner) into a single piece of software (or two pieces, depending on the preferred way of slicing the functionality). However, such a composite module would be a fairly complex piece of software.¶

This document aims to describe the functional separation of the different components rather than make a judgement on software design alternatives. Hence possible implementation choices are left to the implementer.¶

20.1. HSYNC RR Type

IANA is requested to add the following entry to the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group:¶

Type

HSYNC¶

Value

TBD¶

Meaning

Per-provider enrollment for zone-owner-designated DNS Providers¶

Reference

(This document)¶

20.2. HSYNCPARAM RR Type

IANA is requested to add the following entry to the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group:¶

Type

HSYNCPARAM¶

Value

TBD¶

Meaning

Zone-wide multi-provider policy expressed as key-value pairs¶

Reference

(This document)¶

20.3. A New Registry for HSYNCPARAM Keys

The HSYNCPARAM record carries policy as a list of key-value pairs. IANA is requested to create and maintain a new registry entitled "HSYNCPARAM Keys", used by the HSYNCPARAM RR type. The keys defined by this document are listed below; future assignments in the 8-32767 range are to be made through Specification Required review [BCP26].¶

21.1. Normative References

[RFC1996]

Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/rfc/rfc1996>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2136]

Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/rfc/rfc2136>.

[RFC3007]

Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <https://www.rfc-editor.org/rfc/rfc3007>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.

[RFC8901]

Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, September 2020, <https://www.rfc-editor.org/rfc/rfc8901>.

[RFC9615]

Thomassen, P. and N. Wisiol, "Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024, <https://www.rfc-editor.org/rfc/rfc9615>.

[RFC9859]

Stenstam, J., Thomassen, P., and J. Levine, "Generalized DNS Notifications", RFC 9859, DOI 10.17487/RFC9859, September 2025, <https://www.rfc-editor.org/rfc/rfc9859>.

21.2. Informative References

[BCP26]

Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[I-D.berra-dnsop-chunk-framing]

"*** BROKEN REFERENCE ***".

[I-D.berra-dnsop-keystate]

Bergström, E., Fernandez, L., and J. Stenstam, "Signalling Key State Via DNS EDNS(0) OPT", Work in Progress, Internet-Draft, draft-berra-dnsop-keystate-02, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-berra-dnsop-keystate-02>.

[I-D.ietf-dnsop-delegation-mgmt-via-ddns]

Stenstam, J., Bergström, E., and L. Fernandez, "Automating DNS Delegation Management via DDNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-delegation-mgmt-via-ddns-01, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-mgmt-via-ddns-01>.

[I-D.ietf-dnsop-dnssec-automation]

Wisser, U., Huque, S., and J. Stenstam, "DNSSEC automation", Work in Progress, Internet-Draft, draft-ietf-dnsop-dnssec-automation-03, 19 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-automation-03>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7516]

Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/rfc/rfc7516>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.