Providing DNSSD Service on Infrastructure
draft-tlmk-infra-dnssd-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ted Lemon , Mathieu Kardous | ||
| Last updated | 2025-07-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tlmk-infra-dnssd-00
DNSSD T. Lemon
Internet-Draft Apple Inc
Intended status: Standards Track M. Kardous
Expires: 26 January 2026 Silicon Labs
25 July 2025
Providing DNSSD Service on Infrastructure
draft-tlmk-infra-dnssd-00
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 DNSSD Service Registration Protocol (SRP) or mDNS. This
document describes a way to provide a unified DNSSD proxy service
that allows hosts to advertise services using SRP and discover
services using unicast DNS via a Discovery Proxy rather than using of
mDNS, in scenarios where mDNS is currently the only option.
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/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 & Kardous Expires 26 January 2026 [Page 1]
Internet-Draft DNSSD on Infrastructure July 2025
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 26 January 2026.
Copyright Notice
Copyright (c) 2025 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
1.1. Previous work . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Modes of deployment . . . . . . . . . . . . . . . . . . . . . 4
4. Content of Service Advertisement . . . . . . . . . . . . . . 4
4.1. Service Advertisement on Infrastructure . . . . . . . . . 5
4.2. Ad-Hoc Service Advertisement . . . . . . . . . . . . . . 5
4.3. Content of SRV record . . . . . . . . . . . . . . . . . . 6
4.4. Content of the TXT record . . . . . . . . . . . . . . . . 6
4.4.1. Interface-specific domains . . . . . . . . . . . . . 7
4.4.2. Service Priority . . . . . . . . . . . . . . . . . . 7
5. Discovering the DNSSD service . . . . . . . . . . . . . . . . 8
5.1. Advertising using RAs . . . . . . . . . . . . . . . . . . 8
6. Dual-homed infrastructure DNSSD service . . . . . . . . . . . 8
6.1. Unmanaged networks . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Lemon & Kardous Expires 26 January 2026 [Page 2]
Internet-Draft DNSSD on Infrastructure July 2025
1. Introduction
DNS Service Discovery (DNS-SD) [RFC6763] is a general mechanism for
advertising and discovering services on IP networks. mDNS is a
commonly used transport for DNS-SD. However, it has several
shortcomings: it relies entirely on multicast, which works somewhat
poorly on WiFi networks. Devices publishing services have to always
be available to answer mDNS queries, which can have significant
battery impact. When doing service discovery, such devices may do
WiFi beacon skipping to save power, and in so doing, miss a large
percentage of multicast traffic, making mDNS unreliable.
To address this, this document describes a way of combining several
existing technologies to reduce reliance on multicast. This can be
done in, for example, a CE router [RFC7084], or a SNAC Router
[I-D.ietf-snac-simple]. It can actually be done in any device that
is expected to be continuously operational on a network link and has
sufficient resources to provide the service.
There are four logical parts to the service: - The DNS [RFC1035] zone
in which DNSSD information will be stored - The SRP [RFC9665]
service, which is used to add and update services in the DNS zone -
The Advertising Proxy [I-D.ietf-dnssd-advertising-proxy] service,
which advertises the contents of the zone using mDNS on the
infrastructure link - The Discovery Proxy [RFC8766], which enables
discovery of local services that are advertised using mDNS using the
unicast DNS protocol.
In addition, the service must be advertised so that devices that
would like to make use of it can discover it.
1.1. Previous work
This specification relies on existing technology and makes reference
to that technology assuming that the reader is already familiar with
it. Readers should familiarize themselves with at least the
following documents.
* The DNS specification [RFC1035] which discusses DNS zones
* The SRP specificaiton [RFC9665] which explains how to register
services in the DNS without a pre-shared key
* The Advertising Proxy specification
[I-D.ietf-dnssd-advertising-proxy] which explains how to advertise
the contents of a DNS zone using mDNS
Lemon & Kardous Expires 26 January 2026 [Page 3]
Internet-Draft DNSSD on Infrastructure July 2025
* The Discovery Proxy specification [RFC8766] which describes how to
discover mDNS services on a link using DNS queries
* The DNS Push Specification [RFC8765] which describes how to
efficiently do long-lived DNS queries
* The DNS-SD specification [RFC6763] which describes how to discover
services using the DNS and mDNS protocols
2. Conventions and Definitions
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.
3. Modes of deployment
This service can be deployed either as a centralized service provided
by infrastructure, or as an ad-hoc service that takes advantage of
infrastructure but is not part of infrastructure. An example of the
first would be a Customer Edge router (CE Router) [RFC7084]. CE
routers are typically autonomously operating devices--although they
can be configured by the end user, this is not typical. However,
since they are the basis for the network infrastructure of a home
network, we think of DNSSD service provided by a CE router as network
infrastructure.
An example of a device that provides full DNSSD service on an ad-hoc
basis would be a SNAC router. SNAC routers connect infrastructure
networks to stub networks on an ad-hoc basis and provide all four of
the services required for DNSSD service to the SNAC network, but only
provide Advertising Proxy service to the infrastructure network.
This means that devices on infrastructure can discover devices on the
stub network, but not to register with SRP service nor use the SNAC
advertising proxy. A SNAC router that implements the behavior
described in this document no longer has this limitation.
4. Content of Service Advertisement
The goal of advertising the service is to provide sufficient
information that, having resolved the service advertisement, a user
of the service has all the information needed to use the service.
This includes at least:
* Name of the domain to use for service discovery
Lemon & Kardous Expires 26 January 2026 [Page 4]
Internet-Draft DNSSD on Infrastructure July 2025
* Name of the domain to use for service registration
* Name of the host providing the DNSSD service
* Ports to use for the UDP DNS protocol when communicating with the
service
4.1. Service Advertisement on Infrastructure
Service advertisement on infrastructure is provided using the
'dnssd.service.arpa.' domain. This is a locally-served domain
[RFC6303]. The local DNS resolver on infrastructure MUST answer
authoratively for queries in the dnssd.service.arpa zone. Because
this is an infrastructure-provided service, infrastructure advertises
only one service instance, with the service instance name
"infrastructure." Therefore, an infrastructure-provided DNSSD
service advertises the infrastructure service instance in
dnssd.service.arpa as follows:
infrastructure.'service-name'.dnssd.service.arpa IN SRV 'data'
infrastructure.'service-name'.dnssd.service.arpa IN TXT 'data'
The infrastructure DNSSD service MUST support
[I-D.ietf-dnssd-multi-qtypes]. Therefore, this query can be done as
a single multi-qtype query. Typical DNS servers will, when answering
an SRV query, include additional data containing address [RFC2782] pp
4-5. In such situations, if the DNSSD service is provided by
infrastructure, all of the information required to discover it will
be returned in response to a single query.
4.2. Ad-Hoc Service Advertisement
What we mean by "ad hoc" is something that is not integrated into
infrastructure. Ad hoc servers do not have control of the local DNS
resolver, and therefore cannot be discovered using DNS, and must
instead be discovered using mDNS. Because there is no coordination,
it is possible (and in some cases likely) that there will be more
than one such server, so the service instance name should be handled
normally [RFC6763] section 4.1.1.
Therefore, when advertising with mDNS, the service instance will be
advertised as follows:
'instance-name'.'service-name'.local IN SRV 'data'
'instance-name'.'service-name'.local IN TXT 'data'
Lemon & Kardous Expires 26 January 2026 [Page 5]
Internet-Draft DNSSD on Infrastructure July 2025
4.3. Content of SRV record
mDNS APIs typically do not provide a way of setting the priority and
weight of the SRV record, and the infrastructure service always has
the highest priority. Therefore, these fields SHOULD be set to zero,
and MUST be ignored. The reason they MUST be ignored is that since
they SHOULD be zero, and most devices will not be able to set them to
any other value, treating them as described in [RFC2782] presents an
opportunity for an attack by advertising a service with a weight of
65535.
The port field should be set to the UDP port on which SRP service is
provided.
The target is the hostname of the host providing the service.
4.4. Content of the TXT record
TXT records are made up of a series of name=value pairs. The
following names are defined:
srp-tcp='port': the port number to use for SRP registrations using
the DNS Protocol over TCP. If not present, this service is assumed
to be available on the port provided in the SRV record.
dns-udp='port': the port number to use for DNSSD queries using the
DNS protocol over UDP. If not present, this service is assumed to be
available on the port provided in the SRV record.
dns-tcp='port': the port number to use for DNSSD queries using the
DNS protocol over TCP. If not present, this service is assumed to be
available on the port provided in the SRV record.
srp-tls='port': the port number to use for SRP registrations using
TLS. If not present, port 853 is assumed.
dns-tls='port': the port number to use for DNSSD queries using the
DNS protocol over TLS. If not present, port 853 is assumed.
reg-dn='domain': the domain name to use in SRP registrations. If not
present, default.service.arpa is assumed.
domains='domain-list': a comma-separated list of domains in which
service discovery is available. If not present, dnssd.service.arpa
and local are assumed to be the only domains.
Lemon & Kardous Expires 26 January 2026 [Page 6]
Internet-Draft DNSSD on Infrastructure July 2025
'domain'='ip-subnet-list': a link-specific domain that can be used to
query services on that specific IP link. The link is identified by a
comma-separated list of IPv4 and/or IPv6 prefixes that are present on
that link. See Section 4.4.1.
priority='priority': a priority for this service. See Section 4.4.2
4.4.1. Interface-specific domains
A DNSSD service may support link-specific discovery proxy service.
In such cases, each IP link must have its own unique domain, which is
specific to the individual DNSSD service. Each such domain must have
an name=value entry in the TXT record. This entry has as its name a
domain name. Its value is a comma-separated list of IP prefixes that
are on-link for the IP link identified by the domain.
IP subnets are in the form 'IP address'/'prefix-length'. IP
addresses are represented according to the IP address family. IPv4
addresses are in the dotted-decimal format as defined in [RFC952] in
the section titled GRAMMATICAL HOST TABLE SPECIFICATION, in
subsection A under 'address'. IPv6 addresses are represented as
described in [RFC5952].
As a special (common) case, if the service only provides discovery
proxy for a single link, and that is the link on which the DNSSD
service is advertised, discovery of services on that link can use the
"local" domain. In this case, no domains will be listed in the TXT
record; if "local" discovery is to be supported alongside other
domains, then the "local" domain must be included in the TXT record.
If a service DNSSD service is advertised on more than one link, the
local domain is specific to the link for which the destination
address for the query is on-link. If the destination address is not
on-link for any link, queries in .local are not valid and MUST be
responded to with the REFUSED response code.
4.4.2. Service Priority
Infrastructure service is always the highest priority, and there can
be only one such service. When infrastructure service is discovered,
this is done using infrastructure. Consequently there is no need to
try to discover an ad hoc service, and no need to choose amongst
services. The infrastructure service therefore MUST NOT include a
priority. Ad-hoc servers SHOULD include a priority. If a priority
is not included, the priority of the Ad-Hoc service is assumed to be
65535.
Services should choose a priority based on their capabilities. The
following priorities are defined:
Lemon & Kardous Expires 26 January 2026 [Page 7]
Internet-Draft DNSSD on Infrastructure July 2025
0: Server is not constrained and is connected to a high-speed wired
network link (that is, not WiFi, probably Ethernet or a fiber optic
network).
100: Server is not constrained and is connected to a WiFi link
200: Server is constrained, but otherwise well able to provide
service.
65535: Server can provide service if needed, but should not be
preferred.
5. Discovering the DNSSD service
A host that wishes to use the DNSSD service must first discover it.
Discovery follows a series of steps:
1. Attempt to discover an infrastructure-provided DNSSD service
2. Failing that, browse for a list of Ad-Hoc services.
3. If one or more Ad-Hoc services are returned by the browse, choose
one using the priority specified in the TXT record.
4. If no server is discovered, or if no discovered server appears to
work, fall back to mDNS-based DNSSD service
5.1. Advertising using RAs
DNSSD servers that send RAs MUST include a DNSSD-Service RA option in
RAs that they send when the DNSSD service is active. DNSSD clients
can distinguish infrastructure DNSSD service from ad-hoc service
because infrastructure routers have nonzero lifetimes.
It can be the case that there is more than one infrastructure router.
In some cases these routers will be part of a managed infrastructure,
in which case DNSSD service provided by these routers MUST be a
common service.
6. Dual-homed infrastructure DNSSD service
In a dual-homed network, there is more than one default router and
potentially more than one DNSSD service. In the case of managed
networks, the network operator MUST ensure that there is a single
DNSSD service, even if it is advertised by more than one default
router.
Lemon & Kardous Expires 26 January 2026 [Page 8]
Internet-Draft DNSSD on Infrastructure July 2025
6.1. Unmanaged networks
In an unmanaged network, there is no way for the operator to decide
which default router will provide the DNSSD service when more than
one default router is able to do so. So we have the following
options:
1. One router defers to the other
2. The routers share a common DNS zone either using SRP replication
or DNS zone transfers with secondary failover
3. SRP clients are required to register with both services
Practically speaking option 3 is the only easy option, although it
places a greater burden on the client. With option 1, the SRP client
may take some time to notice that an SRP service has gone away and
then reregister, and this is not ideal. Option 2 requires mechanisms
that are not yet described in a standard. Consequently, when more
than one infrastructure DNSSD service is present, consumers of the
DNSSD service that will register their service using SRP MUST
register with all infrastructure DNSSD servers.
7. Security Considerations
TODO Security
8. IANA Considerations
ALlocate 'service-name', "_dnssd-server" is preferred
9. References
9.1. Normative References
[I-D.ietf-dnssd-advertising-proxy]
Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD
Service Registration Protocol", Work in Progress,
Internet-Draft, draft-ietf-dnssd-advertising-proxy-04, 4
March 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-dnssd-advertising-proxy-04>.
[I-D.ietf-dnssd-multi-qtypes]
Bellis, R., "DNS Multiple QTYPEs", Work in Progress,
Internet-Draft, draft-ietf-dnssd-multi-qtypes-08, 7 July
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
dnssd-multi-qtypes-08>.
Lemon & Kardous Expires 26 January 2026 [Page 9]
Internet-Draft DNSSD on Infrastructure July 2025
[I-D.ietf-snac-simple]
Lemon, T. and J. Hui, "Automatically Connecting Stub
Networks to Unmanaged Infrastructure", Work in Progress,
Internet-Draft, draft-ietf-snac-simple-07, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-snac-
simple-07>.
[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>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/rfc/rfc2782>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/rfc/rfc5952>.
[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>.
[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>.
[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>.
Lemon & Kardous Expires 26 January 2026 [Page 10]
Internet-Draft DNSSD on Infrastructure July 2025
[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, DOI 10.17487/RFC0952,
October 1985, <https://www.rfc-editor.org/rfc/rfc952>.
[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
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<https://www.rfc-editor.org/rfc/rfc6303>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Ted Lemon
Apple Inc
Email: mellon@fugue.com
Mathieu Kardous
Silicon Labs
Email: somebody@example.com
Lemon & Kardous Expires 26 January 2026 [Page 11]