Summary

  • RFC 9665 binds an unused service or host name to the first accepted SIG(0) key; it proves continuity with that key, not the identity or authority of a person, company or safe application.
  • A complete operating receipt must follow the update beyond NoError: through registrar discovery, granted leases, hidden-primary replication, authoritative answers, resolver observation, endpoint authentication and an application transaction.

A managed printer is reset before it changes hands. It generates a new key pair, tries to register its familiar name and receives YXDomain: the old key's lease still owns the label. An operator sees two apparently contradictory facts. The printer in front of them is real, yet it cannot prove that it is the printer that first claimed the name.

That is not a defect in RFC 9665. It is the boundary the protocol deliberately draws. Service Registration Protocol, or SRP, removes the need to provision a shared DNS Update secret into every automatic device. The first successful claimant places a KEY record into the registration and signs the transaction with SIG(0). Later updates must demonstrate possession of the corresponding private key. While the KEY lease survives, another key cannot take the host or service-instance name.

The mechanism answers one precise question: is this update continuous with the key that obtained the name? It does not answer who bought the printer, whether the factory reset was authorized, which department now controls it, whether the registrar is the intended registrar, or whether the advertised service is safe and reachable.

One transaction, several judgments

An SRP Update is a constrained form of RFC 2136 DNS Update. It carries exactly one Host Description and may carry several Service Description and Service Discovery instructions. The host, its addresses, service instances, ports, text attributes and public key can therefore be presented in one atomic transaction. Explicit DNS Update prerequisites are absent; the registrar applies RFC 9665's validation rules implicitly.

Those rules matter. The record graph must be internally consistent. Host and service descriptions use the same key. The SIG(0) signature must validate. An EDNS(0) Update Lease option must be present. A name already attached to another active key yields a conflict. An update either satisfies the SRP shape as a whole or it does not.

But atomic acceptance is still only an intake decision. The registrar may be a hidden primary that never answers a client query itself. Its accepted data must reach signers, journals, secondaries or advertising components before users can discover it. A NoError response does not name the serving authority, show what that authority returned, authenticate the endpoint or prove an application exchange.

The name can outlive the service

RFC 9665 intentionally separates the service lease from the key lease. PTR, SRV, A, AAAA and TXT records commonly receive an ordinary lease around two hours. KEY records may retain a name claim for roughly fourteen days. The short clock allows a disconnected service to disappear from discovery; the long clock stops another device from taking the name during a temporary outage.

That design creates a legitimate state in which no service is advertised but the name remains reserved. Dashboards that reduce both clocks to “registered” obscure the reason for the separation. Operations should preserve the requested and granted LEASE and KEY-LEASE, their start times, renewal attempts and the key fingerprint. A missing service RR with a live KEY is not necessarily deletion failure. A live service RR with an expired or replaced ownership key is a different and more serious inconsistency.

Factory reset turns this timing model into a governance event. RFC 9665 says a device key should be unique, kept in stable storage and retained indefinitely when possible. It also permits a reset or ownership transfer to erase it. Once replaced, the device normally needs a new name until the previous KEY lease ends. Product teams therefore cannot specify “reset credentials” without also specifying name continuity, waiting periods, inventory reconciliation and support behavior.

The registrar is not authenticated by the signature it checks

SIG(0) authenticates the requester's transaction. The base SRP specification does not define a mechanism by which the requester validates the registrar's response. Registrars must offer DNS-over-TLS, and capable requesters should use it, but the document describes that use as opportunistic privacy because no practical automatic key-validation mechanism is supplied.

That is an important reality layer. “TLS used” may mean the update was encrypted against passive observation. It does not automatically mean the device authenticated the organization operating the registrar. The evidence record should say whether the registrar was discovered, configured or delivered during network attachment; whether TLS was attempted; whether a certificate or pinned key was actually validated; and whether fallback occurred.

Source validation is likewise local. Registrars should reject updates from outside their administrative domain. TCP can rely on a completed handshake for off-path spoofing resistance only if Fast Open payloads are not accepted without equivalent path validation. UDP on constrained networks depends on ingress and on-link source filtering. The signed key proves message continuity, while network controls decide who may reach the admission surface.

Do not put first-come ownership on the corporate front door

FCFS has no claim to organizational authority. If an operator enables SRP directly on an organizational zone, automatic clients could claim labels such as www, mail or smtp. RFC 9665 recommends a separate discovery subdomain and a prohibited-name dictionary. That is not cosmetic hygiene; it limits what an unaffiliated first claimant can own.

The boundary extends to mixed update paths. A conventional DNS Update credential may be able to rewrite data originally accepted under SRP, silently breaking the registrar's promise to the first key. The two authorization systems should not overlap on the same records unless precedence and audit behavior are explicit.

Nor is service.arpa. a trust mark. It is locally served. A device using a non-local resolver may fail to resolve it or receive an answer that is wrong for the administrative domain. Applications must not treat the suffix as more trustworthy merely because it is special-use. Its names cannot supply a globally unique PKI identity. Endpoint authentication remains an application decision.

What the operating receipt must prove

The useful record begins before the signature: network attachment, source interface, configured or discovered registration domain, selected registrar and transport. It then captures the exact update, host/service instruction graph, KEY fingerprint, signature algorithm, validation result, conflict result, granted leases and response bytes.

After intake it follows the state into the serving system: hidden-primary serial or journal event, signer output, each authoritative instance's answer, recursive observation and remaining TTL. Finally it performs an endpoint handshake and a harmless application transaction. These receipts should share a registration identifier and time window without pretending that one stage inherits the authority of the next.

RFC 9665's achievement is a minimum viable coordination mechanism for devices that cannot arrive with a prearranged enterprise secret. Leadership weakens it by inflating that minimum into an identity system. The stronger operating posture is to keep its claim narrow and then measure the rest.

Sources