Service Type Routing for DNS-SD Service Registration Protocol
draft-ma-dnssd-srp-service-routing-00

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,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC9665]  Lemon, T. and S. Cheshire, "Service Registration Protocol
              for DNS-Based Service Discovery", RFC 9665,
              DOI 10.17487/RFC9665, June 2025,
              <https://www.rfc-editor.org/info/rfc9665>.

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]