Summary

  • Revision 12 is an active Experimental Internet-Draft, not an RFC or evidence that a zone factory or origin implements it.
  • An HTTPS-authenticated /.well-known/origin-svcb document expresses desired service-binding data; operator enrollment and zone-factory policy still decide whether any DNS record may change.
  • JSON validity, endpoint checks, authoritative publication, multi-authority convergence, cache expiry, client RR selection, ECH success and application outcome are separate receipts.
  • General clients should not use the well-known URI as an alternative to HTTPS/SVCB DNS queries, because that bootstrap can reveal the name and enable per-client configuration tracking.

A control document is proposed state

SVCB and HTTPS records let DNS describe how a client should reach a service. ECH configurations may rotate more quickly than traditional zone workflows, especially when TLS operations and authoritative DNS are managed by different systems. Revision 12 of the origin-svcb draft proposes a bridge: an origin publishes JSON at an HTTPS well-known URI, and a zone factory polls, validates and converts that material into DNS records.

The bridge does not collapse its endpoints. A successful fetch proves that a particular HTTPS origin served a document under a certificate accepted by the fetcher. It does not prove that the zone factory was configured to trust that document, that its contents were valid, that local policy permitted the resulting records, that a zone update committed or that clients saw the new generation.

Treat the JSON as desired state. Treat validation as a control decision, the generated zone fragment as planned state, the authoritative serial and RRset as applied state, and independent client observations as distributed state. Each needs a timestamp, identity and digest of its own.

Default silence is a governance control

The draft says a zone factory should not synthesize records from origin JSON in its default configuration. Enabling synthesis should require an operator change. That default prevents the presence of a public file from becoming an unexpected DNS delegation.

Enrollment is therefore a first-class receipt. It should identify the origin URL, allowed owner name and record type, port, validation policy, responsible operator and activation epoch. A discovered well-known resource is not enrollment. An A or AAAA owner name can support an optional discovery workflow on port 443, but that workflow remains off by default.

For arbitrary SVCB-compatible names, there may be no HTTP origin intrinsically authorized to control the record. The zone factory needs an explicit mapping from owner name and record type to a full URL or local source. This prevents a certificate for one HTTPS origin from silently acquiring authority over unrelated DNS state.

The origin can speak only for itself

The well-known URL is bound to an origin and port. If a backend operates on 8443, the zone factory must fetch the well-known resource for that origin when considering the port-prefixed HTTPS owner name. A file on port 443 does not discover another service merely because both share an address.

The distinction becomes sharper with aliases and intermediaries. JSON may express ServiceMode endpoints or an AliasMode target. An origin that uses a CDN or client-facing server remains responsible for ensuring that the published document reflects current intermediary configuration. The file is not a transfer of responsibility to DNS.

Split-mode ECH also contains two authenticated relationships. The backend may learn parameters from the client-facing server, then expose its selected document to the zone factory. Authenticating the backend's document does not retrospectively authenticate how the backend obtained every upstream value. That handoff needs its own receipt.

Parsing is not validation

The JSON object contains regeninterval and endpoints; unknown top-level keys are ignored. An empty endpoint list is an error. Endpoint entries can express service parameters, priorities, targets or aliasing, but their resulting DNS form must still satisfy SVCB and HTTPS rules.

If conversion fails, an unknown SvcParamKey cannot be handled, or the resulting zone fragment fails checks, the zone factory must not update DNS. The origin may not see that failure directly. A dashboard that records only HTTP 200 turns a refused request into a false publication.

The useful ledger preserves fetch status, certificate identity, response body hash, parse verdict, normalized semantic hash, every rejected field, generated RRset hash and final policy decision. It should distinguish “unchanged document” from “changed but invalid” and “valid but denied by local policy.”

Endpoint testing has a coverage problem

For ECH, the zone factory should test that the presented configuration works with the backend before publication. It may need a bespoke TLS client able to use an ECHConfigList that has not yet appeared in DNS and able to report whether ECH actually succeeded.

One successful connection does not approve an entire list. ECHConfigList may deliberately contain values that fail because of GREASE. Multi-CDN deployments may expose several addresses while the zone factory reaches only one. IP hints that differ from A or AAAA records need webPKI authentication checks at the relevant addresses.

Validation coverage should therefore be explicit: endpoint, address family, presented ECHConfig index, expected GREASE behavior, certificate name, ALPN, target port, test time and result. “ECH test passed” without a denominator is not enough to justify publishing all endpoints.

Publication has several clocks

regeninterval says how often an origin may generate replacement values. It is not a notAfter field. The draft allows operational lifetime stretching because ECH retry configurations can tolerate version skew and because abruptly removing HTTPS records or address data can fail open or fail closed in harmful ways.

The zone factory should select a TTL below regeninterval and must attempt refresh and zone regeneration before that time. Even then, at least four clocks remain: origin generation, zone-factory polling, authoritative publication and recursive or client cache expiry. A fifth appears when several zone factories update at different times.

A correct control model records each clock instead of compressing them into “rotation complete.” The authoritative serial proves one publication event at one authority. It does not prove secondary convergence, recursive expiry or that a client selected the new RRset. Canary queries from several paths must finish the chain.

Failure can be invisible and divergent

When conversion or policy validation fails, the client-facing server may receive no direct signal. Operators need reporting from the zone factory. Without it, the origin continues rotating keys while DNS remains on an older generation.

Multiple zone factories can make the problem asymmetric. One may understand a parameter and publish; another may reject it. One may adjust TTLs or correct a common error under local policy; another may preserve the input. Both can have a valid HTTPS fetch while clients receive different authoritative answers.

The reconciliation unit should be the generated RRset semantics, not raw JSON text. Whitespace or member ordering can change without a DNS change, while local normalization can create different records from apparently similar input. Store both document and RRset hashes, plus the policy version that linked them.

Withdrawal is not merely another update

Revision 12 does not specify how origins are added to or removed from a zone factory's polling list, nor how a client-facing server requests deletion of all HTTPS records. That omission is operationally important. A former participant can leave a stale JSON resource behind while the zone factory continues polling and publishing it.

Withdrawal needs explicit authority, effective time, replacement or removal plan, last successful poll, zone serial and cache-drain observation. An HTTP 404 is not automatically an instruction to delete DNS: it may be transient, misrouted or caused by an outage. Conversely, retaining stale records indefinitely because deletion is ambiguous can preserve unwanted endpoints.

Leadership must choose the fail state. It should not be improvised by a cron job. The choice may differ between ECH parameters, address hints, aliases and other service metadata.

The client should not shortcut DNS

The well-known resource may be publicly reachable, but the draft says general HTTP clients should not use it instead of querying HTTPS or SVCB through their preferred DNS resolver. Direct bootstrap cannot itself use ECH, so it reveals the name and other ClientHello information ECH aims to protect.

It also opens a tracking surface. An origin could return a uniquely identifying service configuration to a particular fetcher. DNS distribution and caching have different aggregation and policy properties; the control interface is not a client discovery interface merely because both carry similar parameters.

Client telemetry should prove the RRset source, resolver path, DNSSEC or secure-transport state where applicable, cache age, selected endpoint, chosen ECHConfig and handshake result. A direct JSON fetch belongs in zone-factory operations, not in the application's success path.

Short compromise can cast a longer shadow

The draft warns that wrong values can cause privacy leakage or degraded service through repeated ECH retry_configs. It also notes a more structural risk: webPKI often relies on DNS or HTTP control. A temporary backend compromise that controls JSON could influence IP hints and, under a weak validation chain, help bootstrap longer-lasting DNS-name or certificate control.

This is not a report that such an attack occurred. It is a reason to separate control authorities. Divergent address hints should be compared with A and AAAA data and authenticated at every relevant address. CAA history can provide additional context when the zone factory also controls it. Certificate validation should not depend solely on a routing hint that came from the same compromised origin.

Filesystem-backed handlers introduce another boundary. Directory traversal or enumeration must not expose ECH private keys adjacent to public configuration. The public JSON contains public ECH material; its storage path must not become a doorway to the private half.

Sources and limits

The frozen packet contains revision 12 and its official record, history and references; the TLS Working Group; SVCB and HTTPS; ECH DNS bootstrapping; ECH; well-known URIs; TLS 1.3; ACME; CAA; the IANA well-known and DNS-SVCB registries; and current key-share-prediction work.

These sources establish protocol, registry and risk-analysis text. They do not establish a deployed zone factory, a real JSON resource, DNS publication, ECH success, cache convergence, certificate issuance, tracking event, compromise, privacy leak or application result. The opening rotation is a constructed case used to expose the missing receipts.

Sources