Providing Local Unicast DNS-SD Service on Infrastructure
draft-tlmk-infra-dnssd-03
| Document | Type | Active Internet-Draft (dnssd WG) | |
|---|---|---|---|
| Authors | Ted Lemon , Karsten Sperling | ||
| Last updated | 2026-08-06 (Latest revision 2026-07-27) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Adopted by a WG | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tlmk-infra-dnssd-03
DNSSD T. Lemon
Internet-Draft K. Sperling
Updates: 6762 (if approved) Apple Inc
Intended status: Standards Track 27 July 2026
Expires: 28 January 2027
Providing Local Unicast DNS-SD Service on Infrastructure
draft-tlmk-infra-dnssd-03
Abstract
DNS Service Discovery provides several mechanisms whereby hosts can
discover and advertise services on an IP network. Such discovery can
be done using Multicast DNS (mDNS) or DNS, and advertising can be
done with DNS-SD Service Registration Protocol (SRP) or mDNS. This
document defines Unicast Local Discovery (ULD), a service that
combines an SRP registrar, a Discovery Proxy, and an Advertising
Proxy. Hosts can use a ULD server to advertise and discover services
on the local link entirely via unicast SRP and DNS while remaining
interoperable with hosts that use mDNS.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-tlmk-infra-dnssd/.
Discussion of this document takes place on the DNSSD Working Group
mailing list (mailto:dnssd@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/dnssd/. Subscribe at
https://www.ietf.org/mailman/listinfo/dnssd/.
Source for this draft and an issue tracker can be found at
https://github.com/Abhayakara/draft-tlmk-infra-dnssd.
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/.
Lemon & Sperling Expires 28 January 2027 [Page 1]
Internet-Draft Unicast Local Discovery July 2026
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 28 January 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Unicast Local Discovery . . . . . . . . . . . . . . . . . . . 4
3.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Protocol Operations . . . . . . . . . . . . . . . . . . . 6
3.2.1. Registering Services . . . . . . . . . . . . . . . . 6
3.2.2. Discovering Services . . . . . . . . . . . . . . . . 7
3.2.3. Discovery Proxy . . . . . . . . . . . . . . . . . . . 8
3.2.4. Advertising Proxy . . . . . . . . . . . . . . . . . . 8
3.2.5. Administrative Records . . . . . . . . . . . . . . . 9
3.3. Server Discovery and Monitoring . . . . . . . . . . . . . 9
3.3.1. Server Advertisement . . . . . . . . . . . . . . . . 9
3.3.2. Infrastructure RA Option . . . . . . . . . . . . . . 10
3.3.3. Client Behavior . . . . . . . . . . . . . . . . . . . 11
3.4. IPv4 and Dual-Stack Operation . . . . . . . . . . . . . . 12
4. Operational Considerations . . . . . . . . . . . . . . . . . 12
5. SNAC Router Considerations . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Domain Name Reservation Considerations . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Choice of Local Domain . . . . . . . . . . . . . . . 15
Appendix B. Rationale for Supporting Ad-Hoc Servers . . . . . . 16
Lemon & Sperling Expires 28 January 2027 [Page 2]
Internet-Draft Unicast Local Discovery July 2026
Appendix C. Convergence on a Preferred Server . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
DNS Service Discovery (DNS-SD) [RFC6763] is a general mechanism for
advertising and discovering services on IP networks. While DNS-SD
can operate over either unicast DNS or Multicast DNS (mDNS)
[RFC6762], in practice mDNS is the prevalent method for local service
discovery in home networks and other unmanaged environments, because
unicast DNS-SD requires infrastructure support (managed DNS zones,
service registration mechanisms) that is not typically present on
such networks.
However, mDNS relies entirely on multicast, and places the
responsibility for answering queries on each device that is
publishing a service. This interacts poorly with Wi-Fi in several
compounding ways: Multicast frames are not acknowledged or
retransmitted at the MAC layer, making them inherently less reliable.
Unlike unicast frames, they are also not buffered by the access point
when a station is sleeping. This creates a problematic tradeoff
especially for battery-powered devices: either wake at every DTIM
beacon (usually multiple times per second) at a significant power
cost, or extend sleep intervals and miss a large proportion of
queries, making mDNS unreliable. Finally, multicast frames are
transmitted at the lowest mandatory data rate, consuming many times
more airtime than equivalent unicast frames. This means that even
moderate amounts of mDNS traffic can consume a disproportionate share
of available airtime.
To address this, this document defines a way of combining several
existing technologies into a Unicast Local Discovery (ULD) service:
an SRP registrar [RFC9665] with its Authoritative DNS Server
[RFC1034] [RFC1035] to handle registration and discovery over
unicast, and an Advertising Proxy [I-D.ietf-dnssd-advertising-proxy]
and Discovery Proxy [RFC8766] to provide interoperability with mDNS.
While each of these components can be deployed today, only when they
are integrated in a standardized way into a discoverable service can
a client rely entirely on unicast discovery and cease participating
in mDNS itself. From a client's perspective, ULD is a drop-in
replacement for mDNS: If a ULD server is available on a particular
link, the client uses it for all local advertisement and discovery on
that link; otherwise it falls back to mDNS. Note that because SRP is
used for registration, advertisement via ULD is limited to the record
patterns defined by DNS-SD.
Lemon & Sperling Expires 28 January 2027 [Page 3]
Internet-Draft Unicast Local Discovery July 2026
A ULD server can be deployed as part of the network infrastructure,
for example on a CE router [RFC7084], or on an ad-hoc basis on
devices such as SNAC Routers [I-D.ietf-snac-simple] that already have
the required capabilities. It can be implemented in any device that
is expected to be continuously operational on a network link and has
sufficient resources to provide the service.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the terms "infrastructure" and "ad-hoc" to refer
to the two different ways a ULD server can be deployed:
Infrastructure server: The ULD server is a router on the link that
has been intentionally deployed as part of the network
infrastructure. At most one infrastructure server is expected per
link.
Ad-hoc server: The ULD server is a device on the link that is not
part of the network infrastructure but has the required
capabilities, such as a SNAC router. Multiple ad-hoc servers may
be present on the same link.
This document uses the terms "shared" and "unique" when referring to
resource record sets in the sense of Section 2 of [RFC6762]: A unique
record set is conceptually under the sole control of a single owning
device, whereas a shared record set may contain records contributed
by multiple devices.
3. Unicast Local Discovery
ULD provides service registration and discovery within the ".local."
domain, the same domain used by mDNS [RFC6762]. This ensures that
ULD is a transparent replacement for mDNS from the perspective of
applications and resolver libraries (see Appendix A for further
discussion of this design choice). Unlike mDNS, where the separate
IPv4 and IPv6 multicast addresses effectively result in two
independent .local namespaces (Section 20 of [RFC6762]), ULD
maintains a single unified .local zone per link.
Lemon & Sperling Expires 28 January 2027 [Page 4]
Internet-Draft Unicast Local Discovery July 2026
This document updates [RFC6762] to allow .local queries to be
directed to a ULD server as an alternative to mDNS multicast: Any DNS
query for a name ending with ".local." MUST be sent to the ULD
server for the link, or to the mDNS IPv4 link-local multicast address
224.0.0.251 or its IPv6 equivalent FF02::FB.
The following sections describe the architecture and operation of a
ULD server on a single link. There are five logical parts to a ULD
server:
* The DNS [RFC1035] zone in which DNS-SD information will be stored
* The SRP [RFC9665] service, which is used to add and update
services in the DNS zone
* The Authoritative DNS Server [RFC1035] which authoritatively
answers unicast DNS queries, drawing on both the zone and the
Discovery Proxy
* The Discovery Proxy [RFC8766], which enables unicast discovery of
local services that are advertised via mDNS but have not been
registered via SRP
* The Advertising Proxy [I-D.ietf-dnssd-advertising-proxy] service,
which advertises the contents of the zone using mDNS, ensuring
SRP-registered services are discoverable via mDNS
+-----------------------------------+ +----+
| Unicast DNS over | | |
| UDP, TCP, or TLS | | |
+-----------------------------------+ | |
| ^ | |
v | | |
+-------------+ +-------------------+ | |
| SRP | | Authoritative | | |
| Registrar | | Server | | |
+-------------+ +-------------------+ |mDNS|
| ^ ^ | |
v / \ | |
+-------------------+ +-----------+ | |
| | | Discovery |<------| |
| .local | | Proxy | | |
| zone | +-----------+ | |
| |-->|Advertising|------>| |
| | | Proxy | | |
+-------------------+ +-----------+ +----+
Figure 1: ULD Server Architecture
Lemon & Sperling Expires 28 January 2027 [Page 5]
Internet-Draft Unicast Local Discovery July 2026
A device serving multiple links (e.g. a CE router with multiple VLAN
interfaces) conceptually maintains a separate ULD instance per link,
each with its own .local zone; the server's link-local address on
each interface inherently scopes queries to the correct zone.
Selection of the preferred server is also per link: a client
operating on multiple links performs discovery separately for each,
and may use ULD on some links while falling back to mDNS on others.
3.1. Transports
A ULD server MUST support DNS over UDP, DNS over TCP, and DNS over
TLS [RFC7858]. DNS over TLS support is required by the SRP
specification [RFC9665] and is also the basis for DNS Push
Notifications. All services (DNS queries, SRP registration, and DNS
Push) operate on the standard ports: port 53 for UDP and TCP, port
853 for TLS. A ULD server MUST support IPv6; dual-stack requirements
are addressed in Section 3.4.
On IPv6, clients MUST address ULD traffic to the server's link-local
address, and a ULD server MUST refuse requests for ".local." that are
not received on a link-local address, responding with RCODE 5
(REFUSED).
ULD clients MAY use TLS, however clients that do support TLS SHOULD
NOT fall back to plain TCP or UDP. TLS in ULD provides opportunistic
encryption as described in Section 4.1 of [RFC7858]. Servers MUST
NOT require client certificates and MAY use self-signed server
certificates. Clients SHOULD NOT reject a server's TLS certificate,
as server authentication is not a goal in this context.
3.2. Protocol Operations
3.2.1. Registering Services
A ULD server MUST accept service registrations via the Service
Registration Protocol (SRP) [RFC9665]. Registrations MUST use
".local." as the registration domain, matching the names that would
be used if the service were advertised via mDNS. The use of any
other registration domain, including default.service.arpa, is out of
scope for this specification.
Because the .local zone is link-scoped, clients MUST only include
address records (A, AAAA) in their SRP registrations that are valid
on the link, following the same rules as for mDNS responses in
Section 6.2 of [RFC6762].
Lemon & Sperling Expires 28 January 2027 [Page 6]
Internet-Draft Unicast Local Discovery July 2026
3.2.2. Discovering Services
A ULD server MUST answer authoritatively for queries in ".local." and
MUST support both standard DNS queries (over UDP, TCP, or TLS) and
DNS Push Notifications [RFC8765] (over TLS using DSO [RFC8490]).
The server draws on two sources: its authoritative zone (containing
SRP-registered services) and the Discovery Proxy (reflecting services
advertised via mDNS). Because ULD uses .local for both its zone and
mDNS interactions, the Discovery Proxy operates without name
rewriting or text-encoding translation — mDNS records are served to
unicast clients with names unchanged. This is in contrast to
deployments where a Discovery Proxy rewrites names between a
delegated subdomain and .local as described in Section 5.5 of
[RFC8766].
Since records matching a query could be shared, by default the server
MUST answer from the union of both sources: for a given query it
returns the matching records from the zone together with the matching
records from the Discovery Proxy; a DNS Push subscription MUST
likewise reflect changes from both sources, even when initial results
came from only one.
As an important optimization, when the query matches a unique record
set in the .local zone, the server SHOULD treat the zone data as
complete and not consult the Discovery Proxy. A record set
registered via SRP is considered unique if it was part of a Host
Description or Service Description Instruction (Section 3.3.1 of
[RFC9665]). Because unique records have a single owner, the zone can
be assumed to hold the entire set.
Because the Advertising Proxy publishes zone contents via mDNS on the
same link that the Discovery Proxy monitors, it is conceivable for
the server to see records from its own .local zone reflected back via
the Discovery Proxy; the server MUST ensure that such duplicate
records are not returned to clients.
The server SHOULD include additional records as defined in Section 12
of [RFC6763] (e.g., SRV, TXT, and address records alongside PTR
answers), except where doing so would cause the response to be
excessively large.
Lemon & Sperling Expires 28 January 2027 [Page 7]
Internet-Draft Unicast Local Discovery July 2026
3.2.3. Discovery Proxy
The Discovery Proxy's contributions to ULD queries generally follow
the answer-aggregation behavior of Section 5.6 of [RFC8766],
answering from its mDNS cache when populated and otherwise issuing
mDNS queries on the link. However, the behavior described there for
standard DNS queries assumes that such queries are used only for one-
shot operations expected to return unique records, while long-lived
subscriptions are used when browsing for shared record sets. This is
a reasonable assumption in the context of a generic Discovery Proxy,
since off-link clients performing wide-area DNS-SD discovery will
generally have the resources needed to implement DNS Push [RFC8765]
over TLS. In the context of ULD, DNS Push subscriptions remain
RECOMMENDED when querying for shared records, but it is desirable to
support constrained clients that cannot use them: Such clients MAY
implement time-bounded browse operations using repeated standard DNS
queries. The interval between repeated queries MUST be at least 9
seconds (90% of the 10-second TTL cap imposed by the Discovery Proxy,
Section 5.5.1 of [RFC8766]).
To support such clients, the ULD server MUST continue to issue mDNS
queries for the requested records for at least 20 seconds after the
most recent matching standard DNS query, as it would for records in
which a local client has an active interest (Section 5.2 of
[RFC6762]). Where the requested records are unique (indicated by the
cache-flush bit), whether received from the link or already held in
the cache, the server need issue no further mDNS queries other than
to refresh them as they approach expiry. Where the records may be
shared, the server responds to each query immediately from its cache,
while the continued querying surfaces any additional records on the
link and keeps the cache current, so that the client's successive
point-in-time snapshots converge on the complete set. This
effectively matches the treatment that Section 5.6 of [RFC8766]
describes for subscriptions.
3.2.4. Advertising Proxy
A ULD server MUST publish the contents of its ".local." zone into
mDNS using an Advertising Proxy, ensuring that services registered
via SRP are discoverable via mDNS. As with the Discovery Proxy, the
Advertising Proxy in ULD effectively operates without name rewriting:
Because the records are already in the .local domain, the rewriting
operation mandated by Section 2.1.2 of
[I-D.ietf-dnssd-advertising-proxy] is a no-op.
Lemon & Sperling Expires 28 January 2027 [Page 8]
Internet-Draft Unicast Local Discovery July 2026
A ULD server MUST implement TSR [I-D.ietf-dnssd-tsr] to correctly
resolve conflicts that arise when the same records reach mDNS via
different paths, for example when a client transitions from direct
mDNS participation to using ULD.
3.2.5. Administrative Records
The ".local." zone MUST contain a number of administrative records.
These records have no meaning in the mDNS namespace and MUST NOT be
published by the Advertising Proxy.
As described in Section 6 of [RFC8766], the zone MUST contain:
* A SOA record for the zone
* Exactly one NS record for the zone, referencing the ULD server's
own hostname in .local
* AAAA record(s) for that hostname, and A record(s) if applicable
For compatibility with client libraries that perform standard DNS
Push or SRP service endpoint discovery, the zone MUST also contain
the following SRV records, each pointing to the server's hostname in
.local and the relevant well-known port:
* _dns-push-tls._tcp.local. — port 853 (DNS Push Notifications)
* _dnssd-srp-tls._tcp.local. — port 853 (SRP registration over TLS)
* _dnssd-srp._tcp.local. — port 53 (SRP registration over UDP/TCP)
The ULD server MUST ensure its own hostname is unique on the link.
This can be achieved either by using a randomly generated name that
is statistically guaranteed to be unique, or by claiming the name via
mDNS probing as defined in Section 8 of [RFC6762]. In either case,
the server's hostname is owned and defended directly by the server as
an mDNS participant, not published on behalf of a client via the
Advertising Proxy.
3.3. Server Discovery and Monitoring
3.3.1. Server Advertisement
All active ULD servers MUST advertise their presence using mDNS, as a
DNS-SD service instance of type <uld-service-name>._tcp. The service
advertisement consists of:
Lemon & Sperling Expires 28 January 2027 [Page 9]
Internet-Draft Unicast Local Discovery July 2026
* A PTR record at <uld-service-name>._tcp.local. pointing to the
service instance name
* An SRV record for the service instance, pointing to the server's
hostname and port 53
* A TXT record for the service instance, containing a pri key
indicating the server's priority as defined below
The SRV priority and weight fields SHOULD be set to zero and MUST be
ignored by clients. Per Section 5 of [RFC6763], these fields are
used for selecting among multiple SRV records for a single service
instance, which does not apply here; additionally, mDNS APIs do not
typically expose them to applications.
Selection among ULD servers is based on the numeric value of the pri
TXT key (lower priority values are preferred). If there are multiple
servers with the same priority, the one with the numerically lowest
IPv6 link-local address MUST be preferred. Services MUST advertise a
priority based on their deployment mode and capabilities:
* 0: Infrastructure server
* 100: Non-constrained ad-hoc server on a wired network link
* 200: Non-constrained ad-hoc server on a Wi-Fi link
* 1000: Constrained ad-hoc server, but otherwise well able to
provide service
* 65535: Ad-hoc server that can provide service if needed, but
should not be preferred
3.3.2. Infrastructure RA Option
An infrastructure ULD server MUST additionally advertise its presence
by including the ULD RA option in its IPv6 Router Advertisements.
The presence of the RA option signals that the sender of the RA is a
ULD server, and the server's link-local source address in the RA is
the address clients use to reach it.
This additional advertisement mechanism serves a dual purpose: It
provides IPv6 clients with a faster discovery path that does not rely
on mDNS, and it enables the designation of the infrastructure ULD
server to be protected by RA Guard [RFC6105]. In order for this
protection to be effective, IPv6-capable clients MUST use the RA
option for infrastructure server discovery, either exclusively or to
verify the infrastructure designation of a server discovered via DNS-
Lemon & Sperling Expires 28 January 2027 [Page 10]
Internet-Draft Unicast Local Discovery July 2026
SD. The DNS-SD advertisement remains necessary to enable clients
already using an ad-hoc server to discover a new infrastructure
server via their existing ULD connection (avoiding the need to wake
for multicast RA reception), and to support IPv4-only clients.
3.3.3. Client Behavior
A client that wishes to use ULD on a particular link must first
discover the preferred ULD server. Discovery follows a series of
steps:
1. Attempt to discover an infrastructure server.
2. Failing that, browse for a list of ad-hoc servers, and determine
the preferred one using the priority specified in the TXT record
(see Section 3.3.1). Since all ULD servers MUST support IPv6, an
IPv6 client need only query the IPv6 mDNS multicast address
(FF02::FB) for this.
3. If no server is discovered, or if no discovered server appears to
work, fall back to mDNS for .local service registration and
discovery.
Once a client has started to use a ULD server, it SHOULD cease its
own mDNS participation on that link, and rely on the ULD server for
all .local operations. The client MUST also monitor the availability
of the service. If the client detects that the service is no longer
available, it MUST restart the discovery process.
The client MUST consider its ULD server unavailable when operations
directed at the server persistently fail (DNS queries time out, SRP
lease refresh fails, or a DNS Push session is lost). When a client
currently using an infrastructure server is awake and processing
Router Advertisements, it MUST check for the continued presence of
the ULD RA option. However, clients are not required to wake
specifically for RA reception.
As motivated in Appendix C, clients of an ad-hoc server MUST
additionally keep looking for the appearance of a more-preferred
server; this could be an infrastructure server or another ad-hoc
server that is preferable to the current server according to the
rules defined in Section 3.3.1. Clients SHOULD utilize a DNS Push
subscription with the current server for this purpose. When a client
migrates to a new server (whether due to server failure or the
appearance of a more-preferred server), it MUST re-register all its
services with the new server.
Lemon & Sperling Expires 28 January 2027 [Page 11]
Internet-Draft Unicast Local Discovery July 2026
3.4. IPv4 and Dual-Stack Operation
ULD is designed primarily for IPv6 operation: Infrastructure server
discovery uses IPv6 Router Advertisements, and clients connect to the
server's IPv6 link-local address, which provides inherent link-
scoping. However, dual-stack mDNS interoperability is required to
ensure that services on IPv4-only devices remain discoverable through
the Discovery Proxy, and services on dual-stack ULD clients can be
discovered over IPv4.
A ULD server MUST therefore participate in mDNS on both the IPv6
multicast address (FF02::FB) and the IPv4 multicast address
(224.0.0.251), unless deployed in an IPv6-only environment. The
server SHOULD also accept ULD client connections over IPv4.
Clients MAY connect to the ULD server over IPv4 using an on-link
address. When a server receives ULD traffic over IPv4, it MUST
verify that the source address falls within a directly-connected
subnet of the receiving interface before processing a ".local."
request. Even when connecting over IPv4, clients MUST use the
server's IPv6 link-local address for the tiebreaker comparison
defined in Section 3.3.1; this ensures all clients converge on the
same server regardless of transport. If the preferred server is not
reachable over IPv4, an IPv4-only client MUST fall back to mDNS. As
the RA-based discovery mechanism is IPv6-only, an IPv4-only client
discovers all servers, including the infrastructure server, via mDNS.
4. Operational Considerations
The ideal deployment state for ULD is a single infrastructure server
on each link, providing streamlined discovery for all clients.
A device that implements ULD MAY provide ULD service by default.
Unless it qualifies as an infrastructure server (see below), it MUST
advertise as an ad-hoc server with a priority reflecting its
capabilities.
In managed networks, the infrastructure ULD server designation MUST
be enabled via explicit configuration by the network operator. Where
multiple managed routers are present on a link, the operator MUST
ensure that at most one advertises the ULD RA option.
In unmanaged networks such as home networks, CE routers [RFC7084] are
typically autonomously operating devices that form the basis for the
network infrastructure. A CE router that provides ULD SHOULD claim
infrastructure status by default, since it is already the de facto
infrastructure for the link. Indications that a device is serving in
this role include being the default router (sending RAs with nonzero
Lemon & Sperling Expires 28 January 2027 [Page 12]
Internet-Draft Unicast Local Discovery July 2026
Router Lifetime) and providing services such as DHCPv4 that are
inherently singleton on the link. A device that is not clearly the
primary gateway for the link MUST NOT claim infrastructure status
without explicit configuration.
Note that Homenet [RFC7788] does not define a "primary router"
designation — it uses a distributed model with no single designated
device. ULD's "one infrastructure server" assumption does not align
well with this architecture. In Homenet networks, ULD servers may
need to operate in ad-hoc mode, or Homenet could be extended to elect
a ULD infrastructure server.
5. SNAC Router Considerations
TODO: The AdProxy and DiscProxy components of the SNAC router could
use ULD, and the device itself can host a ULD server.
6. Security Considerations
TODO
7. Domain Name Reservation Considerations
The considerations set out in [RFC6762] for handling of names within
the ".local." domain continue to apply. Name resolution APIs and
libraries SHOULD continue to recognize .local names as special and
SHOULD NOT send queries for these names to their configured (unicast)
caching DNS server, unless that server is also the ULD server for the
link in question.
8. IANA Considerations
Allocate <uld-service-name>, "_uld" is preferred
9. References
9.1. Normative References
[I-D.ietf-dnssd-advertising-proxy]
Cheshire, S., Lemon, T., and E. Dijk, "Advertising Proxy
for DNS-SD Service Registration Protocol", Work in
Progress, Internet-Draft, draft-ietf-dnssd-advertising-
proxy-06, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
advertising-proxy-06>.
Lemon & Sperling Expires 28 January 2027 [Page 13]
Internet-Draft Unicast Local Discovery July 2026
[I-D.ietf-dnssd-tsr]
Lemon, T. and E. Dijk, "Multicast DNS conflict resolution
using the Time Since Received (TSR) EDNS option", Work in
Progress, Internet-Draft, draft-ietf-dnssd-tsr-03, 6 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
dnssd-tsr-03>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/rfc/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/rfc/rfc7084>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/rfc/rfc8490>.
Lemon & Sperling Expires 28 January 2027 [Page 14]
Internet-Draft Unicast Local Discovery July 2026
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
RFC 8765, DOI 10.17487/RFC8765, June 2020,
<https://www.rfc-editor.org/rfc/rfc8765>.
[RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
2020, <https://www.rfc-editor.org/rfc/rfc8766>.
[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/rfc/rfc9665>.
9.2. Informative References
[I-D.ietf-dnssd-srp-replication]
Lemon, T., Keshavarzian, A., and J. Hui, "Automatic
Replication of DNS-SD Service Registration Protocol
Zones", Work in Progress, Internet-Draft, draft-ietf-
dnssd-srp-replication-02, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
srp-replication-02>.
[I-D.ietf-snac-simple]
Lemon, T., Hui, J., and E. Dijk, "Automatically Connecting
Stub Networks to Unmanaged Infrastructure", Work in
Progress, Internet-Draft, draft-ietf-snac-simple-10, 6 May
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
snac-simple-10>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/rfc/rfc6105>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/rfc/rfc7788>.
Appendix A. Choice of Local Domain
To make ULD a drop-in replacement for mDNS, a client querying a ULD
server must see the same records it would have seen via mDNS, and a
device advertising services via the ULD server must be discoverable
as if it was advertising those services via mDNS. In other words,
the ULD zone must have the same semantics as the ".local." namespace
for that link.
Lemon & Sperling Expires 28 January 2027 [Page 15]
Internet-Draft Unicast Local Discovery July 2026
Indeed, when users or applications reference names in .local, their
intent is generally semantic: to find or resolve services on the
local link, not to trigger the use of the Multicast DNS protocol
specifically. Because of this, the intended adoption path for ULD is
for resolver libraries to use it transparently as the resolution
mechanism for .local when a ULD server is available, requiring no
changes to most applications.
So while a new locally-served special-use domain could be defined for
ULD on the wire, this would create two namespaces with identical
content and semantics, and would require implementations and
libraries to map between them. It would also contradict the insight
that .local is about semantics rather than implementation, further
discouraging the intended adoption path. Instead, ULD directly uses
the .local zone defined by mDNS.
Appendix B. Rationale for Supporting Ad-Hoc Servers
From the point of view of a ULD client, the simplest deployment would
be one where the network's DNS resolver also provides ULD. The
client already sends all DNS queries to this resolver, so queries for
names in .local could simply be handled alongside all other queries
at the same endpoint. Many real-world networks are in fact
structured in a way that would support this: In home networks, the CE
Router [RFC7084] typically acts as a DNS forwarder, DHCP server, and
IPv6 router for the local link. The same architecture extends to
many small and medium enterprise networks, where a single site
gateway commonly provides these services across multiple network
segments (VLANs), making it a natural deployment point for ULD across
the entire site.
However, adding ULD support to existing network infrastructure
requires firmware updates to devices such as CE routers and site
gateways, which may not happen quickly across the installed base.
Meanwhile, SNAC routers [I-D.ietf-snac-simple] and similar devices
already implement all the components needed for ULD (SRP registrar,
Advertising Proxy, Discovery Proxy) and are typically updated more
frequently. To enable ULD deployment in the near term, it is
therefore important to support a mode of operation where such devices
can offer ULD service on an ad-hoc basis.
Supporting ad-hoc ULD servers means that clients must be able to
discover and select among them, directing .local queries to the ULD
server while sending other DNS queries to the configured resolver.
This adds complexity, but also enables deployment in networks where
the DNS resolver is an off-link service that cannot provide ULD; this
is a common configuration in more complex enterprise networks.
Lemon & Sperling Expires 28 January 2027 [Page 16]
Internet-Draft Unicast Local Discovery July 2026
Appendix C. Convergence on a Preferred Server
At first glance, multiple ULD servers on a link would seem to provide
workable service through their mDNS proxies: Services registered on
one server would become visible through others via the Advertising
Proxy and Discovery Proxy. However, name conflict resolution breaks
down in this configuration. If two clients were to register the same
name on different servers, both SRP servers would accept the
registration, and the resulting conflict would only manifest at the
mDNS layer, where it may persist unresolved or be resolved silently
and incorrectly, but in both cases without feedback to either client.
This can be addressed either through server-to-server replication of
registrations [I-D.ietf-dnssd-srp-replication], or by having all
clients converge on the same server — that is, all clients
independently select the same server using a deterministic priority
mechanism. ULD takes the latter approach: since its target
deployment state is a stable infrastructure server per link, the
added complexity of replication is not warranted.
Convergence also needs to be maintained over time: Ad-hoc servers in
particular can appear and disappear at any time, and an
infrastructure server may become available after clients have already
begun using an ad-hoc server. If discovery were a one-time process,
clients performing it at different times could observe different sets
of available servers and make different server choices, breaking
convergence. Therefore, discovery of ULD servers must be an ongoing
process: Clients need to monitor the availability of their chosen
server, discover newly available servers, and migrate to a higher-
priority server when one appears.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Ted Lemon
Apple Inc
Email: mellon@fugue.com
Karsten Sperling
Apple Inc
Email: ksperling@apple.com
Lemon & Sperling Expires 28 January 2027 [Page 17]