dnssd D. Ma Internet-Draft ZDNS Intended status: Standards Track 1 August 2026 Expires: 2 February 2027 Service Type Routing for DNS-SD Service Registration Protocol draft-ma-dnssd-srp-service-routing-00 Abstract 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. Status of This Memo 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 Notice 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 Ma Expires 2 February 2027 [Page 1] Internet-Draft SRP service type routing August 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Service Type Routing Label . . . . . . . . . . . . . . . . . 3 3. Service Type Routing Registration . . . . . . . . . . . . . . 4 3.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Informative References . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 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 Ma Expires 2 February 2027 [Page 2] Internet-Draft SRP service type routing August 2026 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. 2. 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 [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. Ma Expires 2 February 2027 [Page 3] Internet-Draft SRP service type routing August 2026 3. Service Type Routing Registration 3.1. 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. 3.2. 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. Ma Expires 2 February 2027 [Page 4] Internet-Draft SRP service type routing August 2026 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. 3.3. Backward Compatibility 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. 4. Security Considerations TBD 5. IANA Considerations 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]. 6. Informative References 7. Normative References [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", RFC 9665, DOI 10.17487/RFC9665, June 2025, . Author's Address Di Ma ZDNS Floor 21, Block B, Greenland Center Ma Expires 2 February 2027 [Page 5] Internet-Draft SRP service type routing August 2026 Chaoyang Beijing, 100102 China Email: madi@zdns.cn Ma Expires 2 February 2027 [Page 6]