Summary

  • An IESG decision on October 8 approved a revised charter for the DNS-SD Extensions working group, turning a broad discovery objective into named protocol and documentation tasks.
  • The charter supports work across single and multiple links but excludes changes to general DNS and integration with other zero-configuration naming protocols.

The new DNS-SD charter does two things at once: it widens the working group’s stated setting to include both single-link and multi-link service discovery, and makes the work it can take on more explicit. The Internet Engineering Steering Group approved revision 02 on October 8. That approval authorizes a programme of standards and guidance work. It does not approve a new protocol or show that devices can already discover services reliably across different networks.

The change is visible in the contrast with the previous approved charter. The earlier text described a goal of developing “a solution for extended, scalable DNS-SD,” then asked the group to document problems where local zero-configuration naming meets the global DNS without solving those problems itself. The new text instead names individual tasks: publish names registered through the Service Registration Protocol (SRP) into Multicast DNS (mDNS); improve the efficiency, availability or effectiveness of DNS-SD and mDNS; and define how to resolve or avoid competing updates for the same name.

The technical setting explains why those tasks are separated. DNS-Based Service Discovery and mDNS are widely used on a single link, such as inside a home or office network, but mDNS does not discover services on remote links. SRP lets servers register services in unicast DNS. A discovery proxy can add services learned through mDNS to that unicast namespace. Those pieces make broader discovery possible, but combining them raises questions about names, updates, reachability and who can see a service.

The charter assigns different weight to different outputs. Standards-track documents may specify how SRP-registered names are published in mDNS and how discovery mechanisms handle efficiency, availability and name conflicts. Informational or Best Current Practice documents may explain how protocol components fit together so that mDNS and SRP clients can access the same DNS-SD service. The charter also directs the group to consider the privacy and security requirements in RFC 8882 and to coordinate with SNAC, other DNS groups and outside bodies when needed.

The exclusions matter as much as the task list. The working group is not chartered to integrate DNS-SD with other zero-configuration naming systems such as Universal Plug and Play or Link-Local Multicast Name Resolution. Updates to general DNS protocols are also out of scope. A charter can make a work programme accountable by showing which questions belong in the group and which require a different venue; it cannot settle those questions by itself.

For operators and device makers, this is an early governance signal rather than a deployment milestone. The charter favours compatibility with existing DNS-SD and mDNS deployments, but describes that as highly desirable, not a guarantee. The useful next evidence will be drafts, review records and eventual standards that map back to the approved tasks. Until then, the new mandate should not be read as proof of complete cross-link interoperability, a change to general DNS, or a security decision about any particular deployment.

Sources