Summary

  • RFC 9432 carries a list of member zones and their properties inside an ordinary DNS zone so that consumers can add, remove or reconfigure authoritative service automatically. It transfers configuration, not the authoritative contents of those member zones.
  • Five facts must stay separate: the catalog is structurally valid; the transfer peer is authenticated; the member is locally admissible; the exact catalog owns the state it proposes to remove or transfer; and the running server applied the intended result. Passing one test cannot supply the others.
  • A safe consumer retains its last valid state when the catalog becomes broken, limits admissible members independently of transport trust, records provenance by catalog and member label, stops unexpected mass changes, archives recoverable state and proves the result with configuration and authoritative-answer canaries.

The empty catalog that passed every technical test

Picture an operator serving hundreds of thousands of zones from several secondary clusters. A generator reads the customer inventory, creates a catalog zone and increments its SOA serial. The new version is syntactically correct. Its version TXT record contains the expected value. The transfer completes over an authenticated channel. Every check on the object and the journey reports success.

The zones collection is empty.

Perhaps the inventory query returned no rows after a credential expired. Perhaps a filter interpreted a new status incorrectly. Perhaps a human intended to remove one customer and selected the wrong export. The catalog cannot explain which event occurred. It only presents a valid new state.

RFC 9432 makes the consequence explicit. A consumer may apply catalog changes automatically, without manual intervention. Its operational note warns that an empty catalog generated by a script could delete millions of member zones from secondaries within seconds. The standard does not hide the danger behind vague language: the feature's efficiency and its failure radius are the same mechanism.

This is why “the catalog validated” is not an adequate change record. Validation can prove that the object belongs to the protocol. It cannot prove that the proposed absence belongs to reality.

A DNS zone that carries configuration, not zone data

A catalog zone is an ordinary DNS zone with a specialised interpretation. It lists member zones as PTR records beneath zones and can attach properties beneath each uniquely labelled member node. The member's own A, AAAA, MX, NS, DNSSEC and other authoritative records are not stored there. After a member is admitted, its contents travel through the ordinary primary-to-secondary transfer path.

That separation matters. The catalog answers, “Which zones should this server manage, and with which recognised properties?” The member transfer answers, “What contents should this zone serve?” A healthy transfer of one does not prove completion of the other. A consumer may accept a new member into configuration and then fail to obtain its zone data. It may remove a member from configuration while another node in the fleet continues serving an older copy. It may receive NOTIFY for a member before the catalog has introduced that member.

The evidence chain therefore cannot stop at the catalog SOA serial. It must cross from catalog receipt to consumer decision, running configuration, member transfer, zone load and authoritative answers from each relevant serving group.

Five gates, not one green light

The first gate is structural validity. Version 2 requires exactly one expected version TXT record. Member PTR RRsets must be singular, and two labels must not point to the same member. Known properties with invalid shapes break the catalog. Unsupported records are ignored rather than granted accidental meaning. If this gate fails, the consumer must not process the object as a catalog.

The second gate is transfer provenance. TSIG can authenticate DNS transactions; DNS zone transfer over TLS can add protected transport, including confidentiality. These controls answer which configured peer participated in the observed exchange and whether the message was unexpectedly altered or exposed. They do not know whether the producer's inventory was correct.

The third gate is local admission. RFC 9432 states that administrative control over served zones shifts completely to the catalog producer, then recommends that consumers scope admissible members—for example with a regular expression or by checking another database. This is not distrust of the protocol. It is the protocol acknowledging that interoperability cannot decide a commercial and operational boundary for every consumer.

The fourth gate is state ownership. The consumer must know which catalog originally created a member and the associated local state. A removal from Catalog A has no authority to erase a zone that was configured independently or by Catalog B. The member-node label is not descriptive, but it is operationally consequential because changing it triggers removal and re-addition, resetting associated state.

The fifth gate is running consequence. A configuration database can say that a zone exists while a process has not loaded it, a transfer is still failing, one anycast site retains an old view or an implementation has rejected a property. Only release-specific runtime evidence and DNS observations prove what the fleet now serves.

These gates form a direction of travel. None is a substitute for the one after it.

Broken input must not erase the last valid world

RFC 9432 draws a useful line between a broken catalog and a valid catalog with an unfortunate meaning. A missing or unsupported version, duplicate member, malformed known property or other defined structural defect makes the catalog broken. A consumer may still store or transfer it as an ordinary DNS zone, but it must not process it as provisioning input.

More importantly, if a previously valid catalog becomes broken, the consumer must not remove or reconfigure the members already established from the last valid version. After a restart, the broken catalog should not stop those members from being served. Processing resumes only when a correct catalog returns.

That is a strong fail-safe, but it does not catch the empty-catalog scenario. An empty version-2 catalog can be perfectly valid. The parser sees no contradiction. The safety control must therefore operate on the semantic diff: how many additions, removals and property changes are proposed; which suffixes and customer partitions they affect; whether the change matches the producer's declared maintenance window; and whether the deletion ratio crosses an independently configured threshold.

A mass-change stop is not a protocol extension. It is a local refusal to convert valid syntax into unbounded execution.

Deletion authority follows provenance

Member removal is where the specification becomes unusually precise. A consumer must not remove the zone or its associated state unless that zone was initially configured from the same catalog that now removes it. If the provenance matches, the RFC says the zone and state—including zone data and DNSSEC keys—are removed. It also suggests temporary archiving to support recovery from mistakes.

This creates a necessary ledger. For every member, record the originating catalog, member-node label, first accepted serial, local configuration profile, state stores created, later property changes and current ownership. A flat list of active zones is insufficient because it cannot answer which producer has deletion authority.

Archiving also needs an expiry and restoration test. Keeping every deleted key and journal forever widens confidentiality and custody risks. Keeping nothing converts one faulty transfer into irreversible loss. The organisation must define which state is recoverable, how long it remains quarantined, who can restore it and how the restored member is reconciled with any authoritative change that occurred while it was absent.

Rollback is not simply transferring the previous catalog. If an implementation has already purged files, journals, timers or DNSSEC keys, replaying the old PTR may create a fresh member rather than restore the prior operational state.

A label can carry more authority than its appearance suggests

The unique label beneath zones is deliberately opaque. It is not the member's identity; the PTR target supplies the zone name. Yet a label change has a defined effect: the member is treated as removed and immediately added again. State reset is encoded in a naming change that can look inconsequential in a casual diff.

Change of Ownership, expressed through the coo property, makes the label even more important. The old catalog points to the new catalog. The consumer waits until the new catalog also contains the member, then verifies that the old signal is still present. Only then may ownership move.

If the new catalog preserves the same member-node label, associated state can travel with the member. That may be exactly what an orderly migration needs. It may also give the new catalog owner access to state the old owner never intended to transfer. RFC 9432 therefore requires the old owner to reset state—by changing the label—before or together with coo when takeover is not intended.

A leadership record for migration must state the desired treatment of zone data, journals, timers, keys and product-specific metadata. “Move the zone” is not precise enough. The label is a custody switch.

Groups and extensions remain local agreements

The group property lets a producer signal different treatment for different members. The value has no universal meaning. A consumer can map a recognised group to a local configuration profile, ignore an unknown value or decide how to handle several values. Agreement between producer and consumer supplies the semantics.

Custom properties below ext go further: their meaning is implementation-specific, without an expectation of interoperability. IANA registers the common version-2 property prefixes—zones, version, coo, group and *.ext—but registration does not turn a private extension into a globally understood command.

This is Minimum Initial Specification in protocol form. The common layer identifies a small grammar and safe failure behavior. Local operators decide which catalogue, group vocabulary, extension and member scope they will execute. A producer cannot make a private word universal by publishing it, and a consumer cannot claim conformance proves that its private interpretation is shared elsewhere.

Authentication narrows the question; it does not answer it

Catalog transfers should be authenticated against unexpected modification. DNS UPDATE used to alter a catalog should also be authenticated, and member-zone transfers deserve their own protection. Because a catalog reveals the zones a consumer serves and their properties, access should be restricted and transfers should be confidential where appropriate.

These controls are indispensable. They are also easy to overstate. A valid TSIG tells the receiver that a party holding the configured secret authenticated the DNS message. A protected transfer session establishes transport properties with the configured peer. Neither reveals whether a human approved the inventory, whether an automation credential selected the right tenant, whether the empty set was intended, or whether the receiving server is permitted to host every listed name.

The correct conclusion is not “authentication is insufficient, so it is unimportant.” It is “authentication supplies provenance, so admission and intent can be judged against a known source.” The controls form a chain rather than a hierarchy in which one strong cryptographic fact erases every organisational question.

Running products expose different blast radii

Current BIND documentation describes catalog changes being put into effect, members being added, removed or reconfigured, versions 1 and 2, label-driven state reset and coo. Its minimum update interval can slow the cadence of changes, but delay is not semantic approval.

Knot DNS documents producer and consumer roles and maps groups to local configuration profiles. It also states that a de-cataloged member is purged immediately, including its zone file, journal, timers and DNSSEC keys, subject to its stated zone-file exception. The same documentation notes that a catalog update reloads configured zones more broadly. Those product facts make a catalog diff a storage and process event, not just a list edit.

PowerDNS documents version-2 producer and consumer support, coo, group and explicit unique values used to signal state reset. Its supported properties and backends differ from other implementations.

No configuration review should therefore end with “all three products support RFC 9432.” A mixed fleet needs a behavior matrix: unsupported property handling, persistence, removal, restart, label reset, migration, reload scope, archive ability and rollback. Running-code primacy means testing each release rather than projecting a standard's abstract model onto every binary.

The authority ledger

For each accepted catalog serial, retain a content hash and normalized diff; authenticated peer and transport; schema verdict; local admission decision and policy version; every member's origin catalog and label; name clash or unsupported-property reason; apply result per consumer; member transfer and load status; and authoritative-answer canaries from outside the fleet.

For a removal, add the state inventory, archive identifier, deletion time and restoration deadline. For coo, add both catalog observations, label continuity, explicit state-transfer decision and the point at which the old catalog relinquished control. Do not place secrets or unrestricted catalog contents in ordinary logs.

The ledger should let an investigator answer six questions without inference: what the producer sent; who authenticated the transfer; what the consumer admitted; which state the catalog owned; what the software executed; and what clients could resolve afterward.

Sources