Summary

  • RFC 9526 keeps Public Homenet Zone creation and DNSSEC private keys with the Homenet Naming Authority, while a Distribution Manager and public authoritative servers provide Internet-facing publication.
  • Mutual TLS authenticates control and transfer peers. It does not prove domain ownership, parent DS installation, distribution of the latest zone serial or successful validation by an outside resolver.
  • Outsourced authority needs a linked custody record: entitlement, signed generation, transfer, public serving, parent delegation, external validation and verified withdrawal must remain distinct.

A signed zone that the world cannot yet trust

Begin at the moment when almost every local indicator is green. The home router has selected the names it wants to publish. Its Homenet Naming Authority, or HNA, has assembled a zone, incremented the serial and signed the result. A mutually authenticated TLS session has completed. The Distribution Manager has transferred the zone without error.

An external validating resolver still returns failure.

Nothing in that sequence is contradictory. The HNA can be the cryptographic author while another organisation controls public serving. The Distribution Manager can hold the newest signed version while one public authoritative instance still serves the previous serial. Every authoritative server can serve the new DNSKEY while the parent zone still contains the old DS. A resolver can reach a validly signed child whose chain no longer joins the parent.

RFC 9526 is valuable because it does not hide this division of labour. “Simple provisioning” does not mean one event creates public authority. The architecture separates the party that selects and signs the statement, the infrastructure that distributes it, the parent that connects it to the chain of trust and the resolver that observes the result.

The public zone is not the home's private namespace

The protocol concerns a Public Homenet Zone beneath a registered domain. It is not a mechanism for publishing the special-use home.arpa namespace. The Homenet Zone remains local, and the RFC places it outside the public workflow.

That distinction is operational, not cosmetic. A home may learn names through DHCP, mDNS, UPnP, PCP or manual configuration, but the HNA applies policy before placing any name or address in the public zone. Link-local addresses should not be published. Unique-local or private addresses may have meaning behind a VPN, while public names may still reveal services even when packets cannot reach them.

The home therefore begins with a selection decision: which internal facts deserve a stable public name? A complete audit should retain that decision, including excluded records and the policy version. If the final zone is the only surviving artifact, the organisation cannot later explain whether an exposed printer name was intentional, inherited from discovery or left behind after a device disappeared.

Cryptographic authorship remains in the home

RFC 9526 gives the HNA the work of constructing all zone content. The HNA signs the Public Homenet Zone with DNSSEC and handles the associated private keying material. The architecture provides no mechanism for transferring private DNSSEC keys to the Distribution Manager.

This is a strong custody choice. The outsourcer receives a signed statement; it does not need the power to create a different signed statement. A compromised distribution tier can suppress a new version or continue presenting an older version within its validity window, but it cannot silently mint an authentic replacement without the HNA's key.

Yet key possession is not public control. The HNA is a hidden primary. Its address should not be listed in the public NS set unless additional protection exists, and it is not expected to answer ordinary Internet queries. Public reach belongs to the DNS Outsourcing Infrastructure, or DOI. The home can own the pen while the outsourcer owns the printing press and the delivery route.

That separation should appear in dashboards. “Zone signed” means a named generation was produced under a named key. “Zone public” means the intended authoritative instances serve that generation. The first state cannot be promoted to the second by inference.

One service boundary, two authenticated channels

The HNA and the DOI communicate through a Distribution Manager, but RFC 9526 separates control from synchronization. On the Control Channel, the HNA initiates a protected exchange to obtain or provide delegation parameters, parent-DS information and the address used for transfer. Both sides are mutually authenticated over TLS.

The Synchronization Channel reverses the connection roles. The DM acts as TLS client; the HNA acts as server and hidden primary. AXFR or IXFR carries the zone. DNS NOTIFY can prompt an immediate check, while SOA timers let the secondary discover changes without a notification. The same pair of addresses can participate in both channels, yet the channels remain distinct because their roles and claims differ.

Mutual TLS supplies channel evidence: these peers completed a protected session according to this trust configuration. It does not prove that the HNA owns the registered domain. It does not prove that an AXFR contained the expected serial unless the transfer is bound to a digest or readback. It does not prove that the DM sent that version through its internal distribution system. And it says nothing about what an external resolver later received.

This is a recurring automation error. Authentication is treated as authorization; authorization is treated as execution; execution at one boundary is treated as an end-to-end outcome. RFC 9526 supplies enough structure to refuse those substitutions.

The least specified channel carries public reach

The Distribution Manager behaves like a hidden secondary. From there, the DOI sends the zone to its public authoritative servers. RFC 9526 names this the Distribution Channel but does not normatively define its implementation. It might use zone transfer, database copying, a REST interface or another established mechanism.

The omission is reasonable for an experimental architecture that must accommodate existing DNS platforms. It is also the point where assurance must become provider-specific. A successful HNA-to-DM transfer is not a receipt from every edge that answers queries. If the DOI uses several regions or software stacks, each can lag, reject or partially apply a generation.

Operators should record the serial and content hash accepted by the DM, then query every intended public authoritative instance—or a declared quorum whose limits are explicit. A single anycast address can conceal heterogeneous backends. Repeating the same query from several networks is observation, not proof of complete fleet state, but it is stronger than assuming the internal distribution channel succeeded.

The missing evidence is not a reason to reject outsourcing. It is a reason to name the promise precisely: the DM accepted generation 42; these authoritative instances served generation 42 during this interval; these instances did not answer or still served generation 41.

A DS acknowledgement is a promise, not the parent zone

DNSSEC makes the next authority boundary unusually visible. The HNA supplies the hash of its Key Signing Key through a DS RRset. A DOI that has the necessary registrar or registry relationship can arrange for that DS to appear in the parent zone. When the Distribution Manager accepts the update, it returns NOERROR as a commitment to update the parent.

Commitment is the correct word. The response is evidence that the DM accepted responsibility. It is not an observation that the parent now publishes the intended DS. Registry processing can fail, another account can hold the domain, a previous DS can coexist unexpectedly, or caches can continue to expose old state.

Secure delegation exists only when the child is signed, the correct DS is in the parent and a validator can build the chain. RFC 9526 even requires the HNA to sign in situations where it cannot arrange secure delegation. A signature can therefore be structurally correct and publicly orphaned.

The receipt chain should retain the submitted DS, the DM response, the parent readback and an independent validation result. Combining those into one “DNSSEC enabled” flag destroys the ability to locate a break during rollover or provider migration.

Domain ownership is a prerequisite the protocol cannot prove

The RFC says the DOI must not serve a Public Homenet Zone unless it is confident that the HNA owns the Registered Homenet Domain. It then places proof of ownership outside scope. This is not a flaw; it is a warning that another authority system precedes the DNS exchange.

When the DOI is also the registrar, an account and provisioning relationship may establish the necessary entitlement. When the DNS provider is independent, the home owner needs another proof path. In either case, the control-channel certificate, domain entitlement and DNSSEC signing key can have different owners, renewal schedules and recovery procedures.

A resilient migration record maps all three. Which account can change the parent? Which HNA credential can command the DM? Which key signed the current child? Which old provider must stop answering? If one employee, device reset or expired credential can sever the mapping, the architecture is operationally fragile even if every protocol exchange is individually secure.

Deletion reveals whether control was ever real

Creation makes automation look powerful. Deletion tests whether that power was bounded. RFC 9526 requires the HNA to be able to request deletion of a delegation at a specific DM. After receiving the instruction, the DM must stop serving the Public Homenet Zone and can return NOERROR to indicate deletion.

That response still belongs to one boundary. Public authoritative servers may need time to withdraw the zone. Parent NS or DS data may remain. Recursive caches may retain answers until TTL expiry. During a provider change, the new service may already be active while the old one remains reachable.

A complete deletion receipt therefore observes absence as carefully as creation observes presence. It names the old DM, all authoritative endpoints, relevant parent records, signature validity and cache horizon. It records whether the operation is retirement or migration. It proves that control over the public name moved or ended without leaving two uncoordinated authorities.

The commercial agreement matters too. RFC 9526 leaves deletion of an inactive HNA to that agreement. A provider's right to retire an abandoned customer zone is not the same as the HNA's protocol right to request withdrawal. Leadership should know which clock and appeal path governs each.

Renumbering turns one zone into several timelines

Residential prefixes change. During renumbering, the HNA updates public addresses, notifies the DM and causes another transfer. In a make-before-break transition, old and new prefixes can coexist for a period. In a flash renumbering, the old prefix can become unusable before the new one is ready.

The HNA is advised to update its synchronization location on boot because it may not know how long it was offline or whether the signed zone expired. That single detail reveals the distributed timeline: desired addresses, HNA serial, transferred serial, served serial, parent state and recursive cache contents do not change atomically.

Monitoring should compare them rather than flatten them. An old address can be correctly cached but no longer reachable. A new address can be served without corresponding access policy. A locally functioning name can hide a stale public answer. The right question is not “is DNS up?” but “which generation is authoritative at each boundary, and until when?”

Sources

Sources