[secdir] [new-work] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[The IESG <[e-mail]>]

The Extensions for Scalable DNS Service Discovery (dnssd) WG in the Internet
Area of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is provided
for informational purposes only. Please send your comments to the IESG
mailing list ([e-mail]) by 2026-09-13.

Extensions for Scalable DNS Service Discovery (dnssd)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Chris Box <[e-mail]>
  Florian Obser <[e-mail]>

Assigned Area Director:
  Éric Vyncke <[e-mail]>

Internet Area Directors:
  Éric Vyncke <[e-mail]>
  Tommy Jensen <[e-mail]>

Mailing list:
  Address: [e-mail]
  To subscribe: https://www.ietf.org/mailman/listinfo/dnssd
  Archive: https://mailarchive.ietf.org/arch/browse/dnssd/

Group page: https://datatracker.ietf.org/group/dnssd/

Charter: https://datatracker.ietf.org/doc/charter-ietf-dnssd/

# Background

Zero-configuration networking protocols are well suited to discover services
within the scope of a single link. In particular, the DNS-SD [RFC 6763] and
mDNS [RFC 6762] protocol suite (sometimes referred to using Apple Computer
Inc.'s trademark, Bonjour) are widely used for DNS-based service discovery
and host name resolution on a single link. But, mDNS and DNS-SD cannot be
used to discover services on remote links.

The Service Registration Protocol (SRP) [RFC 9665] allows servers to register
the services they offer using unicast DNS. A Discovery Proxy [RFC 8766]
enables automatic population of the unicast DNS namespace with services it
learns via mDNS.

With these building blocks it is now possible for clients to discover
services using unicast DNS alone. Service discovery can be extended across a
wide area network, going beyond directly connected links.

The scenarios in which multi-link service discovery is required may be zero
configuration environments, environments where administrative configuration
is supported, or a mixture of the two.

An example is the [Thread Group](https://threadgroup.org/) [Border
Router](https://www.threadgroup.org/Portals/0/documents/support/BorderRouterWhitePaper_657_2.pdf),
which implements a [SNAC
router](https://datatracker.ietf.org/doc/draft-ietf-snac-simple/), enabling
bidirectional service discovery between a low-power Thread mesh network
(using SRP) and Ethernet (using mDNS). This technology is used by
[Matter](https://csa-iot.org/all-solutions/matter/), delivering
interoperability between in-home devices from different manufacturers.

# Working Group Description

The focus of the WG is to develop solutions for extended, scalable service
discovery using DNS-SD and mDNS over single or multi-links. The WG will
consider the tradeoffs between reusing/extending existing protocols and
developing entirely new ones. It is highly desirable that any new solution is
backwardly compatible with existing DNS-SD/mDNS deployments.

To that end, the DNSSD WG will work on:

Standards-track documents

* Define how to publish SRP-registered names in Multicast DNS, so the
services can be discovered by mDNS clients. * Define mechanisms that improve
the efficiency, availability and effectiveness of DNS-SD or mDNS. * Define
how to resolve or avoid conflicts between competing updates for the same name.

Informational or BCP documents

* Describe how the different protocol components can be combined to make a
complete DNS-SD service that is equally accessible by both mDNS and SRP
clients.

While developing these, the working group will consider the privacy and
security requirements described by [RFC8882]. It will collaborate with SNAC
and other DNS-related working groups and external bodies (e.g., The Thread
Group) when applicable.

The following are out of scope:

- Integration or conflict with other zero-configuration service and naming
protocols, such as Universal Plug and Play (UPnP) and Link-Local Multicast
Name Resolution (LLMNR). - Updates to general DNS protocols.

Milestones:

  Nov 2026 - Issue WGLC for draft-ietf-dnssd-tsr

  Mar 2027 - Issue WGLC for draft-ietf-dnssd-advertising-proxy

  Jul 2027 - Issue WGLC for draft-ietf-dnssd-uld

  Mar 2028 - Issue WGLC for draft-ietf-dnssd-srp-replication



_______________________________________________
new-work mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]