Service Registration Protocol for DNS-Based Service Discovery
Extracted elements (30)
KEY records use a much longer lease (typically 14 days) than service records (typically 2 hours) so that a temporarily offline device retains its name claim while not continuing to advertise unavailable services. This prevents name squatting during brief outages.
SRP restricts registrable record types (PTR, SRV, TXT, KEY, A, AAAA only) because SIG(0) authentication does not establish trust—it only proves continuity of identity from the initial claim. Allowing arbitrary records (SOA, MX, CNAME) would require a full trust model that is deferred to future work.
SRP Updates omit DNS Update prerequisites to allow a complete registration in a single transaction. The registrar applies implicit predicates (FCFS key checks, structural validation) rather than requiring the requester to probe current state across multiple round-trips.
SRP uses two protocol variants because low-power CNN devices have severe battery constraints; the series of DNS lookups needed for full registrar discovery would waste energy. CNN devices receive registrar addresses during network join, avoiding these lookups.
An SRP registrar is not required to implement general DNS Update prerequisite processing. When it receives a DNS Update message that is not an SRP Update, it MAY process it as a normal RFC 2136 update or MUST reject it with Refused RCODE. Operators must carefully consider the intersection of SRP Update rules and other update authorization rules to prevent one type of requester from overriding another's registrations.
Recursive resolvers MUST NOT forward queries for 'service.arpa.' or its subdomains to upstream caches or to the '.arpa.' authoritative servers, per RFC 6303 locally-served zones rules. The one exception is DS record queries with the DO bit set, which MUST be answered with correct DNSSEC authority information.
An SRP Update MUST contain exactly one Host Description Instruction, MUST include an EDNS(0) Update Lease option, and the LEASE time MUST be less than or equal to KEY-LEASE. Any DNS Update message containing prerequisites or unrecognized add/delete records is not an SRP Update.
Full-featured hosts MUST support registration domain discovery as described in Section 11 of RFC 6763 and discover the SRP registrar via the '_dnssd-srp._tcp.<zone>' (or '_dnssd-srp-tls._tcp.<zone>' for TLS) SRV record.
SRP registrars MUST support compression of SRV RR targets in incoming SRP Updates, since requesters MAY compress these targets to save space. However, authoritative DNS servers (including those that are also SRP registrars) MUST NOT compress SRV record targets in DNS responses.
SRP registrars MUST treat updates for a service type and all its subtypes as atomic: if a subtype appeared in a previous update but is absent from the current update, the registrar MUST remove that subtype. There is no mechanism to delete a single subtype individually.
The flags field in the KEY RR used for SIG(0) in SRP Updates MUST be set to all zeroes by SRP requesters. SRP registrars MUST accept and store the flags field as received, without checking or modifying it.
The SRP registrar MUST include an EDNS(0) Update Lease option in its response. The requester MUST check for this option and MUST use the granted lease times from the response (which may be shorter or longer than requested) when scheduling renewals.
The SRP requester's public/private key pair MUST be stored in stable storage and MUST be unique to the device. A device with rewritable storage SHOULD retain the key indefinitely and SHOULD provide a mechanism to erase and regenerate it (e.g., on factory reset).
To remove all services for a hostname, the SRP requester sends an SRP Update with LEASE=0 containing exactly one Host Description Instruction with a 'Delete All RRsets From A Name' for the hostname. The registrar MUST then remove all associated service instances and Service Discovery PTR records.
TTLs for all RRs within each RRset in an SRP Update MUST be consistent. SRP registrars MUST check TTL consistency within RRsets and MUST reject updates with inconsistent TTLs using a Refused RCODE.
When a hostname lease expires, the SRP registrar MUST simultaneously remove the hostname and all service instances and Service Discovery PTR records referencing it. If KEY-LEASE is nonzero, KEY records for those service instances MUST be retained.
When an SRP requester must send multiple SRP Updates, it SHOULD combine them into a single message. If they cannot fit, subsequent updates MUST be sent sequentially: the requester MUST NOT send a new update until the previous one is acknowledged.
SRP registrar implementations MUST offer TLS support. SRP requesters using TCP SHOULD use DNS-over-TLS (RFC 7858) for opportunistic privacy and SHOULD NOT fall back to plain TCP. Public keys in SRP registrations can be used as host tracking identifiers; registrars MAY suppress KEY records from query responses.
An SRP Update is a single DNS Update message (RFC 2136) containing three instruction types: Service Discovery Instructions (PTR RRs), Service Description Instructions (SRV, TXT, KEY RRs per service instance), and exactly one Host Description Instruction (A/AAAA and KEY RRs for the hostname). All three instruction types may be combined in one atomic transaction.
Constrained hosts use the special-use domain name 'default.service.arpa.' for registration and rely on out-of-band network configuration (e.g., from the CNN join process) to discover registrar addresses and ports. The SRP registrar may rewrite 'default.service.arpa.' names to a domain with broader visibility.
Every SRP Update MUST include an EDNS(0) Update Lease option (RFC 9664) carrying a LEASE time (typically 2 hours) for all DNS-SD records and a KEY-LEASE time (typically 14 days) for KEY records. The LEASE MUST be less than or equal to KEY-LEASE. Registrars MUST reject updates lacking this option.
First Come, First Served (FCFS) Naming uses SIG(0) (RFC 2931) to let a requester claim and defend a name. A KEY RR containing the public key is included in every Host Description and Service Description Instruction; the update is signed with the corresponding private key. No other requester can update a name unless it possesses the same private key.
SRP Update response codes are limited to: NoError (success), ServFail (server error), Refused (malformed or unauthorized update), and YXDomain (name conflict with different key). The SRP requester MUST NOT attempt to validate any RRs included in non-NoError responses.
IANA added two service name entries to the Service Name and Transport Protocol Port Number Registry: 'dnssd-srp' (TCP, no assigned port) for plaintext SRP and 'dnssd-srp-tls' (TCP, no assigned port) for TLS-secured SRP. Both reference RFC 9665.
IANA allocated IPv6 anycast address 2001:1::3/128 from the IANA IPv6 Special-Purpose Address Registry for the DNS-SD Service Registration Protocol, providing a fixed destination for SRP Updates when no registrar is explicitly configured.
IANA registered 'service.arpa.' in the Special-Use Domain Names registry and added it to the Transport-Independent Locally-Served Zones Registry. IANA also created the 'service.arpa. Subdomain' registry (grouped with Locally-Served DNS Zones), with 'default.service.arpa.' as its initial entry for SRP Updates.
SRP registrars MUST implement the ECDSAP256SHA256 signature algorithm for SIG(0) validation. They SHOULD also implement algorithms numbered 13 or higher from RFC 8624 that have MUST/RECOMMENDED/MAY in the validation column. SRP requesters MUST NOT assume availability of algorithms numbered below 13.
SRP Updates have only FCFS authorization semantics; any requester knowing the registrar's IP can send valid updates. Registrars SHOULD reject updates from addresses outside the administrative domain. For TCP, three-way handshake prevents off-path spoofing, but registrars relying on this MUST NOT accept TCP Fast Open payloads. For UDP on CNNs, source-address filtering at routers (RFC 2827) is required.
Using SRP for a zone also used for non-DNS-SD records risks name squatting ('www', 'mail') and offensive name registration. Recommended mitigations: use subdomains (e.g., 'dnssd.example.com.') rather than organizational zones for SRP, and configure a prohibited-name dictionary that returns Refused (not a number-suffix-retry-able error).
Name conflict handling: when an SRP requester receives a YXDomain RCODE, the registrar has found a conflicting existing name owned by a different SIG(0) key. The requester MUST choose a new name (typically by appending or incrementing a number) or give up. There is no normative requirement on the exact name-selection strategy.