Summary

  • IETF Datatracker approved draft-ietf-dnssd-uld-00 as a DNSSD working-group document on 18 August. It replaces an individual draft whose technical body is unchanged in the new version.
  • Unicast Local Discovery would combine service registration, authoritative DNS and two proxies behind a preferred on-link server. It aims to reduce multicast costs on Wi-Fi, but its Security Considerations section is still empty.

The most important change in the new Unicast Local Discovery draft is not a packet format. It is who now owns the work.

The history of the working-group document records three events at 16:22:50 UTC on 18 August: the DNSSD chair approved the working-group -00, the new revision became available and it was linked as the replacement for draft-tlmk-infra-dnssd. A normalized comparison of the two documents finds no change in the protocol body. The new name therefore marks formal working-group development, not a newly invented mechanism.

That distinction matters because the adoption path was corrected in public. The predecessor's Datatracker history says a chair initially treated a show of hands at IETF 126 as adoption, then released the document after concluding that a mailing-list call should have happened first. A call was issued on 21 July, and the state changed to “Adopted by a WG” on 6 August. The record shows a procedural repair and a later approval; it does not prove that every technical question was settled.

The 17-page working draft addresses a familiar local-network cost. Multicast DNS asks devices advertising services to listen for and answer queries. On Wi-Fi, the draft notes, multicast frames are not acknowledged or retransmitted at the MAC layer, access points do not buffer them for sleeping stations, and they travel at a low mandatory data rate. A battery-powered device must either wake frequently or risk missing queries, while multicast can consume disproportionate airtime.

ULD proposes to put a continuously available server between those endpoints. The server combines an SRP registrar and authoritative DNS server with a Discovery Proxy and an Advertising Proxy. A supporting client registers services with the server and directs .local discovery queries to it over unicast. The server bridges those records to devices that still use multicast, so an application can keep the familiar local namespace.

This is an assembly of existing parts rather than a replacement for all of them. RFC 9665 already defines the Service Registration Protocol used to submit service information and leases. RFC 8766 defines the Discovery Proxy that answers unicast DNS queries using information learned from mDNS links. The draft specifies how those functions are presented as one discoverable local service.

Nor does it abolish multicast DNS. RFC 6762 remains the protocol baseline the draft says it would update if approved. ULD servers still advertise their presence through DNS-SD over mDNS, proxy to multicast-only devices and support fallback. If a client cannot find a working ULD server, it returns to mDNS. The proposal changes which component should carry routine discovery work when a server is available.

The selected component gains operational weight. In a managed network, an operator must explicitly designate the infrastructure ULD server, and no more than one should advertise the new Router Advertisement option on a link. Infrastructure servers receive the highest preference. Ad-hoc servers can operate at lower priorities, and clients must continue looking for a better choice, re-register their services when they move and restart discovery when DNS queries, lease refreshes or push sessions persistently fail.

That convergence rule is not cosmetic. If clients register the same name with different independent servers, both registrations may be accepted before the conflict appears at the multicast layer. The draft chooses deterministic client convergence on one preferred server instead of requiring registration replication among servers. It trades a distributed conflict problem for a selection, availability and migration problem that operators and implementers can observe more directly.

The Router Advertisement path makes the control boundary sharper. IPv6 clients are expected to discover an infrastructure server through a ULD RA option, or use that option to verify an infrastructure claim learned through DNS-SD. The text points to RA Guard as the protection for that designation. IPv4-only clients have no such path and discover all servers through mDNS; the server must verify that an IPv4 request comes from a directly connected subnet before processing .local traffic.

The work is not ready to be described as a standard. Its status notice calls it an Internet-Draft that may change or disappear, and it expires in February 2027. The Security Considerations section contains only TODO. The SNAC-router section is also unfinished, and the IANA service name remains unassigned in the text. There is no published ULD implementation report, interoperability result or measurement of airtime, battery life, query loss or failover.

The broader DNSSD working-group charter explains why the subject belongs in the IETF: mDNS works well on a local link but does not by itself provide scalable discovery across routed, multi-link networks, and wider discovery raises security and privacy questions. ULD narrows its first step to an on-link service. Even at that scope, the missing security analysis is central because a preferred discovery server can influence which local services a client sees.

Working-group adoption is therefore a meaningful beginning, not an operational verdict. It creates a public place to finish the trust model, option allocation, failure behavior and implementation evidence. Until those pieces arrive, the defensible claim is limited: the IETF has formalised work on moving routine local discovery toward unicast, while the cost and safety of that move remain to be demonstrated.

Sources