| Internet-Draft | SRP service type routing | August 2026 |
| Ma | Expires 2 February 2027 | [Page] |
This document defines the _str._dns-sd._udp (Service Type Routing) metadata label, a backward-compatible extension for SRP registration. This mechanism relaxes the original single-registration-domain constraint, enabling clients to publish distinct service types to independent target DNS zones and dedicated SRP registrar instances. It supports fine-grained operational tuning, administrative isolation of heterogeneous services. This extension only modifies SRP registration domain selection logic, fully preserves existing SRP wire format, authentication, leasing and discovery behaviors, and introduces no impact on DNS-SD service browsing operations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Service Registration Protocol (SRP) [RFC9665] enables network endpoints to securely publish DNS-SD [RFC6763] 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 [RFC9665], 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.¶
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.¶
The _str._dns-sd._udp label follows the established [RFC6763] 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 [RFC6763] 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.¶
For each unique service type the client intends to register via SRP, the client executes the following sequential workflow:¶
Note that this workflow preserves all existing SRP authentication, record leasing and update semantics. No modifications to the SRP wire protocol are required.¶
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.¶
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.¶
Legacy SRP clients that do not support the _str._dns-sd._udp label ignore this extension and operate strictly per [RFC9665], 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.¶
TBD¶
This document requests IANA register the _str well-known metadata label within the _dns-sd._udp namespace defined in [RFC6763], dedicated to service type routing for SRP [RFC9665].¶