Summary

  • RFC 9975 requires a parental agent to build its observation set from the child delegation in the parent and query every address of every listed authoritative server before acting on CDS/CDNSKEY or CSYNC data.
  • NODATA is evidence, silence calls for retry, and inconsistency has one safe result: abort the operation without creating, deleting or altering the parent records that the requested change would have touched.
  • Cross-server agreement shows a coherent request, not identity, organizational authority, correct implementation, universal deployment or successful DNSSEC validation. RFC 10026 keeps request consistency and continued validation as separate tests.

One authoritative server says a new key should enter the parent. A second says nothing. Both answers can be validly signed. Both machines can be healthy. If the parent accepts the first answer, it may automate a change that the child service has not finished publishing. If it treats the second as a veto, it may delay an entirely legitimate rollover.

The shortcut is tempting because ordinary DNS resolution does not ask every server. A resolver seeks a usable answer. A parental agent preparing to alter DS, NS or glue data is doing something different: it is turning observed child state into a durable change at a higher point in the namespace.

Peter Thomassen's RFC 9975, published in May 2026, moves that difference into the protocol. Before acting on CDS/CDNSKEY or CSYNC records, the parental agent must establish plausible consistency across the authoritative service described by the parent delegation. The standard does not make servers legislators. It makes a high-consequence automation collect enough evidence to distinguish a shared request from a partial view.

One answer was never the whole child

CDS and CDNSKEY let a child zone describe the DS state it wants its parent to publish. CSYNC lets the child signal desired changes to delegation data such as NS and associated addresses. These mechanisms reduce tickets and credential sharing, but they also move the moment of interpretation into software.

Earlier procedures left room for a consumer to query one authoritative server, much as a resolver normally would. That is efficient when all servers already carry the same zone. It is dangerous during replication delay, a multi-provider transition, partial failure or a configuration split.

A single answer can be authentic as an answer from that server and still fail to represent the service named in the parent delegation. If one provider publishes a new CDS key while another still exposes NODATA, the parent has not observed a coherent replacement request. If one CSYNC response asks to replace nameservers and another keeps the status quo, selecting the faster response would quietly give arrival order decision authority.

RFC 9975 calls the required result “plausible consistency.” The word is disciplined. The parent cannot prove that every packet sent everywhere would be identical. It can query the addresses it derives from the current delegation, compare the relevant record and decision states, and refuse to infer a change from disagreement.

The parent delegation defines who must be asked

The check does not begin with a server list supplied in the request. The parental agent knows the child zone and reads the NS hostnames from the child's delegation in the parent. It obtains all IP addresses for each hostname through a validating resolver, including available glue, then directs the relevant queries to all those addresses.

That ordering closes a subtle gap. If the child-side signal could define its own witness set, a misconfigured or hostile source could omit the server that still carries the old state. The current parent delegation is the operational record of which authoritative service the parent has told the Internet to use.

The address list also matters. One hostname can have several addresses, and those addresses can reach different instances or network paths. Checking the name through one recursive resolver is not equivalent to contacting the full set identified for the standard's purpose.

This remains bounded evidence. Anycast can lead two vantage points to different instances behind the same address. A transient route can hide a reachable service. The RFC therefore permits another network vantage point and recommends retry rather than pretending that the first collection is omniscient.

NODATA is an answer; silence is not agreement

The most consequential sentence in a fail-closed design is often the one that defines nothing. RFC 9975 says consistency is required across received responses and explicitly counts NODATA as a received response.

NODATA means the server answered authoritatively but did not return the requested record type. In CDS/CDNSKEY maintenance, that can mean no automated change is being requested from that view. It cannot be averaged away because another server returned a new key.

No response is different. Packet loss, routing trouble, filtering or a server fault may have prevented observation. The parental agent should try again before deciding that the server is permanently unreachable and excluding it. The RFC recommends a configurable schedule and offers exponential backoff—5, 10, 20, 40 minutes and so on—as an example. A second vantage point may test whether the problem belongs to the server or only to one path.

This distinction prevents two opposite errors. Treating silence as NODATA would let a broken path freeze legitimate updates. Treating silence as assent would let the reachable subset speak for an authority set that the parent itself still publishes.

The standard does not demand infinite waiting. It demands that an operator expose the policy by which a missing witness becomes permanently unreachable. The duration, vantage points and escalation remain local decisions; the absence of evidence does not silently become positive evidence.

Inconsistency preserves the existing parent state

Once an inconsistent state appears, the decision is not to choose the majority, newest serial or fastest server. The parental agent must abort. It must not create records the proposed operation would have created, delete records it would have removed, or alter the existing set.

That makes the old state a bounded safe default, not necessarily the ultimate truth. The parent already publishes it. Changing to either of two conflicting child views could break resolution or validation. Keeping it gives child operators time to finish replication, correct a provider split or use an authenticated out-of-band path.

The whole process can be retried. A retry is not a continuation from a convenient subset; it repeats the queries so that the decision belongs to one coherent observation round. An operator can keep querying for reporting even after the decision path has stopped.

There is also an early stopping case. If an answer confirms the status quo—explicitly or through NODATA—pending decision queries may be dequeued. Any later answer could only confirm no change or reveal inconsistency, which also produces no change. This optimization preserves the invariant because it can never turn the remaining uncertainty into an update.

CDS and CDNSKEY compare keys, not decorative equality

Plausible consistency is not byte-for-byte identity across every response. For CDS/CDNSKEY, the important question is whether each eligible key referenced anywhere is referenced everywhere else. A key present at one server and missing at another makes the state inconsistent.

The same discipline applies to complete removal. One response asking to remove the entire DS set conflicts with another that asks for an update or returns NODATA. Software may not reinterpret this as a staged deletion without an explicit rule that the standard does not supply.

CDS digest handling adds a defined boundary. Only digest types identified by the relevant IANA policy need enter the consistency comparison as specified. The parent retains choices about which permitted digest forms it ultimately publishes, but local hash policy cannot change the set of keys that the child coherently referenced.

RFC 10026, co-authored by Steve Sheng and Thomassen and published as Best Current Practice in July 2026, puts a second gate beside consistency. The parent must also verify that the resulting DS set would preserve a valid DNSSEC path. A unanimous request can still be unsafe to apply. Agreement is evidence of intent; continued validation is evidence of technical continuity.

CSYNC permits defined differences without accepting contradiction

CSYNC needs a more precise comparison because not every field should be equal at every server. The immediate flag and type bitmap must agree across received responses. SOA serial values may differ during ordinary replication or multi-provider operation, so each serial is assessed against the SOA obtained from the same server. The resulting decision—whether the update is permissible—must agree.

When CSYNC identifies data sets to synchronize, such as NS or address records, the relevant servers must return equal RDATA sets, including the case in which all are empty. Other CSYNC rules still apply, including the order in which nameserver and glue changes are processed.

This is why “ask everyone” is an incomplete summary. A serious implementation needs a comparison model for each record family. It must know which differences are permitted, which are evidence of transition and which make the requested parent change undecidable.

A notification starts the check; it does not win it

RFC 9859, which also lists Thomassen among its authors, lets a child send a generalized notification that CDS-related state has changed. The message can eliminate wasteful periodic scanning and shorten the time before the parent looks.

It does not skip the evidence chain. Upon receiving a CDS notification, the parent-side recipient is told to initiate the same DNS lookups and verification it would have used after a timer. A bell can call the inspector to the door; it cannot certify what is inside.

This separation matters when organizations optimize for latency. Notification success, queue acceptance, DNS queries, cross-server consistency, DS validation, parent publication and resolver-visible effect are different receipts. Combining them into one green “automated” badge makes the last message in the chain look like proof of every earlier and later step.

Consistency is not authority, identity or outcome

An agreed child-side record set does not prove who owns the domain, who was entitled to direct the child operator, or whether a provider account was compromised. Existing DNSSEC validation can authenticate maintenance through an established chain. Initial bootstrapping needs methods such as RFC 9615 because the parent DS path does not yet exist. Organizational authorization can still require registry, registrar or domain-owner controls outside the record comparison.

Nor does parent publication prove that every recursive resolver sees the new state. Caches retain the previous DS or delegation data until their TTLs expire. The child may move to its next rollover step too early. RFC 10026 therefore treats timing, validation, rollback and reporting as operational work rather than benefits automatically inherited from consistency.

RFC 9975 keeps an authenticated out-of-band route available when child-side operators cannot reach agreement. That is not a loophole in the consistency rule. It is a different authority path. Automation must not solve a governance or provider deadlock by letting the first reachable server decide.

Thomassen's authorship marks a contribution, not a control plane

The RFC Editor names Peter Thomassen as the sole author of RFC 9975. His public IETF record identifies him as deSEC's founder and Chief Technology Officer, a managing director at SSE, Domain Connect chair and DNSOP secretary at the time reviewed. He also co-authored RFC 9615, RFC 9859 and RFC 10026.

Those facts make him a documented participant in the standards lineage. They do not mean he operates every parental agent, controls a registry or registrar, certifies implementations, or caused any observed incident. An RFC can state the minimum behavior for interoperable software; only deployed evidence can show which code queried which addresses, how it compared the answers and whether the parent actually stayed unchanged on conflict.

That distinction echoes the larger boundary in the mechanism. A named author is evidence of contribution, not authority over every implementation. A named authoritative server is evidence source within a delegation, not sovereign permission to rewrite the parent alone.

The real output is a decision receipt

An implementation worthy of the standard should retain the parent delegation used to define scope, every resolved server address, glue provenance, query time and vantage, the full relevant answer or NODATA state, validation results, comparison outcome, retries, backoff and any exclusion as permanently unreachable.

It should then record the projected parent diff, the continued-validation check, the decision to abort, preserve or apply, and the live parent state after publication. Secret credentials do not belong in that record. The evidence required to reproduce the decision does.

The minimum specification is common: no delegation-changing inference from an inconsistent subset. Future local choices can vary: retry windows, alternate vantage points, reporting channels, digest policy inside the permitted bounds and whether the parent offers automation at all.

Running code settles whether the boundary exists outside the document. When one server differs, the most important output is not an error counter. It is a verifiable record that nothing at the parent moved.

Sources