Service Type Routing for DNS-SD Service Registration Protocol

Introduction The Service Registration Protocol (SRP) enables network endpoints to securely publish DNS-SD service records via unicast DNS updates. The original design of DNS-SD and SRP primarily targets service discovery and publication within bounded local network environments. As specified in Section 3.1.1 of , an SRP requester can discover multiple candidate registration domains using the r._dns-sd._udp metadata query. Nevertheless, the SRP requester selects one single registration domain, either automatically via dr._dns-sd._udp or manually from the candidate list returned by r._dns-sd._udp. This single-domain publication model creates several architectural and operational limitations when SRP is deployed across large-scale networks and the public Internet. There is no standardized, interoperable mechanism with SRP to route different service types to independent registration domains. All services on a host — regardless of their functional category, traffic patterns, update frequency, or security requirements — must share the same registration zone and its associated SRP registrar infrastructure. Co-locating heterogeneous workloads on a single registrar instance prevents operators from deploying workload-specific tuning strategies, such as differentiated lease lifetimes, fine-grained update rate limits and targeted load-balancing policies. This document defines _str._dns-sd._udp (Service Type Routing), a new registration-focused DNS-SD metadata label. This extension relaxes the original single-registration-domain constraint of SRP in a fully backward-compatible manner. It introduces standardized rules allowing an SRP client to resolve a distinct target registration domain for each advertised service type. With this mechanism, network operators can define routing policies such that different service types are published to separate DNS zones and independent SRP registrar instances. The extension applies only to SRP service registration workflows and leaves DNS-SD service browsing semantics unchanged. It preserves all existing SRP wire format, authentication, record leasing, and zone discovery procedures.

Service Type Routing Label To map different service types to independent registration zones, the SRP requester MUST construct the fully qualified lookup name for service type routing queries in the following format: [ServiceType]._str._dns-sd._udp.[DiscoveryDomain]. The returned resource record is a PTR record pointing to the target service registration domain.

Discovery Domain: The domain used to resolve DNS-SD metadata records, typically obtained via DHCP or static configuration.
Service Type: Standard DNS-SD service identifier (e.g., _agent-control._tcp, _sensor-data._udp).
Service Registration Domain: The target domain where an SRP requester publishes service records including PTR, SRV, and TXT records, determined by service type routing rules.

The _str._dns-sd._udp label follows the established naming pattern for SRP registration metadata. The service-type prefix is mandatory. SRP requesters MUST NOT query the bare _str._dns-sd._udp name without a service type, as such queries have no defined semantics. Consistent with Section 11, all reserved *._dns-sd._udp metadata names use PTR records. Operators MUST deploy at most one PTR record per lookup name. Clients MUST treat empty responses, NXDOMAIN, timeouts, or multiple PTR records as a lookup failure.A valid _str._dns-sd._udp PTR response overrides the dr._dns-sd._udp default domain for the corresponding service type only. All other service types continue using the default registration domain and associated registrar infrastructure. This extension implements service type routing only for SRP registration and never affects service discovery or browsing operations.

Service Type Routing Registration

Workflow For each unique service type the client intends to register via SRP, the client executes the following sequential workflow:

1) Construct routing query name: build the fully qualified domain name: [ServiceType]._str._dns-sd._udp.[DiscoveryDomain].
2) Issue DNS PTR lookup: send a PTR query for the constructed name to discover service type routing information.
3) Find SRP registrar: If the response contains exactly one valid PTR RR, the client uses the returned FQDN as the target Service Registration Domain and proceed to the zone probing step, by resolving SRP registrar (_dnssd-srp._tcp, _dnssd-srp-tls._tcp) as specified in RFC9665. If the response returns NXDOMAIN, timeout, empty answer, or multiple PTR records, the client treats the routing lookup as failed and fall back to default domain discovery.

Note that this workflow preserves all existing SRP authentication, record leasing and update semantics. No modifications to the SRP wire protocol are required.

Example In this example, the network discovery domain is obtained via DHCP or static configuration: example.net. The operator deploys service type routing records to decouple service registration targets by routing distinct service types to independent DNS zones and dedicated SRP registrar infrastructures.

_agent-control._tcp._str._dns-sd._udp.example.net. 300 IN PTR reg.example.org.
_sensor-data._udp._str._dns-sd._udp.example.net. 300 IN PTR reg.example.com.
dr._dns-sd._udp.example.net. 300 IN PTR "reg.example.net."

The _agent-control._tcp service type retrieves routing rules via _str._dns-sd._udp and publishes service records to the zone reg.example.org, utilizing a dedicated registrar optimized for agent service workloads. The _sensor-data._udp service type follows the published routing policy and registers IoT service records to the isolated zone reg.example.com, served by an independent registrar instance for periodic sensor workloads. All service types without explicit service type routing entries fall back to the local default registration domain reg.example.net and the corresponding default registrar.

Backward Compatibility Legacy SRP clients that do not support the _str._dns-sd._udp label ignore this extension and operate strictly per , relying entirely on the dr._dns-sd._udp default domain mechanism. Updated clients gracefully fall back to the default registration domain when no service-type-specific routing record exists. This extension introduces no changes to SRP wire format, record leasing, or DNS-SD browsing semantics, ensuring full backward compatibility with existing standards and deployed devices.

Security Considerations TBD

IANA Considerations This document requests IANA register the _str well-known metadata label within the _dns-sd._udp namespace defined in , dedicated to service type routing for SRP .