💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc8766.txt captured on 2022-03-01 at 15:39:54.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 8766 Apple Inc.
Category: Standards Track June 2020
ISSN: 2070-1721
Discovery Proxy for Multicast DNS-Based Service Discovery
Abstract
This document specifies a network proxy that uses Multicast DNS to
automatically populate the wide-area unicast Domain Name System
namespace with records describing devices and services found on the
local link.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8766.
Copyright Notice
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Operational Analogy
3. Conventions and Terminology Used in This Document
4. Compatibility Considerations
5. Discovery Proxy Operation
5.1. Delegated Subdomain for DNS-based Service Discovery Records
5.2. Domain Enumeration
5.2.1. Domain Enumeration via Unicast Queries
5.2.2. Domain Enumeration via Multicast Queries
5.3. Delegated Subdomain for LDH Host Names
5.4. Delegated Subdomain for Reverse Mapping
5.5. Data Translation
5.5.1. DNS TTL Limiting
5.5.2. Suppressing Unusable Records
5.5.3. NSEC and NSEC3 Queries
5.5.4. No Text-Encoding Translation
5.5.5. Application-Specific Data Translation
5.6. Answer Aggregation
6. Administrative DNS Records
6.1. DNS SOA (Start of Authority) Record
6.2. DNS NS Records
6.3. DNS Delegation Records
6.4. DNS SRV Records
6.5. Domain Enumeration Records
7. DNSSEC Considerations
7.1. Online Signing Only
7.2. NSEC and NSEC3 Records
8. IPv6 Considerations
9. Security Considerations
9.1. Authenticity
9.2. Privacy
9.3. Denial of Service
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Implementation Status
A.1. Already Implemented and Deployed
A.2. Already Implemented
A.3. Partially Implemented
Acknowledgments
Author's Address
1. Introduction
Multicast DNS [RFC6762] and its companion technology DNS-based
Service Discovery [RFC6763] were created to provide IP networking
with the ease of use and autoconfiguration for which AppleTalk was
well known [RFC6760] [ZC] [ROADMAP].
For a small home network consisting of just a single link (or a few
physical links bridged together to appear as a single logical link
from the point of view of IP), Multicast DNS [RFC6762] is sufficient
for client devices to look up the ".local" host names of peers on the
same home network, and to use Multicast DNS-based Service Discovery
(DNS-SD) [RFC6763] to discover services offered on that home network.
For a larger network consisting of multiple links that are
interconnected using IP-layer routing instead of link-layer bridging,
link-local Multicast DNS alone is insufficient because link-local
Multicast DNS packets, by design, are not propagated onto other
links.
Using link-local multicast packets for Multicast DNS was a conscious
design choice [RFC6762]. Even when limited to a single link,
multicast traffic is still generally considered to be more expensive
than unicast, because multicast traffic impacts many devices instead
of just a single recipient. In addition, with some technologies like
Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and
less reliable than unicast, because Wi-Fi multicast traffic is sent
at lower data rates, and is not acknowledged [MCAST]. Increasing the
amount of expensive multicast traffic by flooding it across multiple
links would make the traffic load even worse.
Partitioning the network into many small links curtails the spread of
expensive multicast traffic but limits the discoverability of
services. At the opposite end of the spectrum, using a very large
local link with thousands of hosts enables better service discovery
but at the cost of larger amounts of multicast traffic.
Performing DNS-based Service Discovery using purely Unicast DNS is
more efficient and doesn't require large multicast domains but does
require that the relevant data be available in the Unicast DNS
namespace. The Unicast DNS namespace in question could fall within a
traditionally assigned globally unique domain name, or it could be
within a private local unicast domain name such as ".home.arpa"
[RFC8375].
In the DNS-SD specification [RFC6763], Section 10 ("Populating the
DNS with Information") discusses various possible ways that a
service's PTR, SRV, TXT, and address records can make their way into
the Unicast DNS namespace, including manual zone file configuration
[RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007], and proxies of
various kinds.
One option is to make the relevant data available in the Unicast DNS
namespace by manual DNS configuration. This option has been used for
many years at IETF meetings to advertise the IETF terminal room
printer. Details of this example are given in Appendix A of the
Roadmap document [ROADMAP]. However, this manual DNS configuration
is labor intensive, error prone, and requires a reasonable degree of
DNS expertise.
Another option is to populate the Unicast DNS namespace by having the
devices offering the services do that themselves, using DNS Update
[REG-PROT] [DNS-UL]. However, this requires configuration of DNS
Update keys on those devices, which has proven onerous and
impractical for simple devices like printers and network cameras.
Hence, to facilitate efficient and reliable DNS-based Service
Discovery, a hybrid is needed that combines the ease of use of
Multicast DNS with the efficiency and scalability of Unicast DNS.
This document specifies a type of proxy called a "Discovery Proxy"
that uses Multicast DNS [RFC6762] to discover Multicast DNS records
on its local link on demand, and makes corresponding DNS records
visible in the Unicast DNS namespace.
In principle, similar mechanisms could be defined for other local
discovery protocols, by creating a proxy that (i) uses the protocol
in question to discover local information on demand, and then (ii)
makes corresponding DNS records visible in the Unicast DNS namespace.
Such mechanisms for other local discovery protocols could be
addressed in future documents.
The design of the Discovery Proxy is guided by the previously
published DNS-based Service Discovery requirements document
[RFC7558].
In simple terms, a descriptive DNS name is chosen for each link in an
organization. Using a DNS NS record, responsibility for that DNS
name is delegated to a Discovery Proxy physically attached to that
link. When a remote client issues a unicast query for a name falling
within the delegated subdomain, the normal DNS delegation mechanism
results in the unicast query arriving at the Discovery Proxy, since
it has been declared authoritative for those names. Now, instead of
consulting a textual zone file on disk to discover the answer to the
query as a traditional authoritative DNS server would, a Discovery
Proxy consults its local link, using Multicast DNS, to find the
answer to the question.
For fault tolerance reasons, there may be more than one Discovery
Proxy serving a given link.
Note that the Discovery Proxy uses a "pull" model. Until some remote
client has requested data, the local link is not queried using
Multicast DNS. In the idle state, in the absence of client requests,
the Discovery Proxy sends no packets and imposes no burden on the
network. It operates purely "on demand".
An alternative proposal that has been discussed is a proxy that
performs DNS updates to a remote DNS server on behalf of the
Multicast DNS devices on the local network. The difficulty with this
is that Multicast DNS devices do not routinely announce their records
on the network. Generally, they remain silent until queried. This
means that the complete set of Multicast DNS records in use on a link
can only be discovered by active querying, not by passive listening.
Because of this, a proxy can only know what names exist on a link by
issuing queries for them, and since it would be impractical to issue
queries for every possible name just to find out which names exist
and which do not, there is no reasonable way for a proxy to
programmatically learn all the answers it would need to push up to
the remote DNS server using DNS Update. Even if such a mechanism
were possible, it would risk generating high load on the network
continuously, even when there are no clients with any interest in
that data.
Hence, having a model where the query comes to the Discovery Proxy is
much more efficient than a model where the Discovery Proxy pushes the
answers out to some other remote DNS server.
A client seeking to discover services and other information performs
this by sending traditional DNS queries to the Discovery Proxy or by
sending DNS Push Notification subscription requests [RFC8765].
How a client discovers what domain name(s) to use for its DNS-based
Service Discovery queries (and, consequently, what Discovery Proxy or
Proxies to use) is described in Section 5.2.
The diagram below illustrates a network topology using a Discovery
Proxy to provide discovery service to a remote client.
+--------+ Unicast +-----------+ +---------+ +---------+
| Remote | Communication | Discovery | | Network | | Network |
| Client |---- . . . ----| Proxy | | Printer | | Camera |
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
Multicast-capable LAN segment (e.g., Ethernet)
Figure 1: Example Deployment
Note that there need not be any Discovery Proxy on the link to which
the remote client is directly attached. The remote client
communicates directly with the Discovery Proxy using normal unicast
TCP/IP communication mechanisms, potentially spanning multiple IP
hops, possibly including VPN tunnels and other similar long-distance
communication channels.
2. Operational Analogy
A Discovery Proxy does not operate as a multicast relay or multicast
forwarder. There is no danger of multicast forwarding loops that
result in traffic storms, because no multicast packets are forwarded.
A Discovery Proxy operates as a _proxy_ for remote clients,
performing queries on their behalf and reporting the results back.
A reasonable analogy is making a telephone call to a colleague at
your workplace and saying, "I'm out of the office right now. Would
you mind bringing up a printer browser window and telling me the
names of the printers you see?" That entails no risk of a forwarding
loop causing a traffic storm, because no multicast packets are sent
over the telephone call.
A similar analogy, instead of enlisting another human being to
initiate the service discovery operation on your behalf, is to log in
to your own desktop work computer using screen sharing and then run
the printer browser yourself to see the list of printers. Or, log in
using Secure Shell (ssh) and type "dns-sd -B _ipp._tcp" and observe
the list of discovered printer names. In neither case is there any
risk of a forwarding loop causing a traffic storm, because no
multicast packets are being sent over the screen-sharing or ssh
connection.
The Discovery Proxy provides another way of performing remote
queries, which uses a different protocol instead of screen sharing or
ssh. The Discovery Proxy mechanism can be thought of as a custom
Remote Procedure Call (RPC) protocol that allows a remote client to
exercise the Multicast DNS APIs on the Discovery Proxy device, just
as a local client running on the Discovery Proxy device would use
those APIs.
When the Discovery Proxy software performs Multicast DNS operations,
the exact same Multicast DNS caching mechanisms are applied as when
any other client software on that Discovery Proxy device performs
Multicast DNS operations, regardless of whether that be running a
printer browser client locally, a remote user running the printer
browser client via a screen-sharing connection, a remote user logged
in via ssh running a command-line tool like "dns-sd", or a remote
user sending DNS requests that cause a Discovery Proxy to perform
discovery operations on its behalf.
3. Conventions and Terminology Used in This Document
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.
The Discovery Proxy builds on Multicast DNS, which works between
hosts on the same link. For the purposes of this document, a set of
hosts is considered to be "on the same link" if:
* when any host from that set sends a packet to any other host in
that set, using unicast, multicast, or broadcast, the entire link-
layer packet payload arrives unmodified, and
* a broadcast sent over that link, by any host from that set of
hosts, can be received by every other host in that set.
The link-layer _header_ may be modified, such as in Token Ring Source
Routing [IEEE-5], but not the link-layer _payload_. In particular,
if any device forwarding a packet modifies any part of the IP header
or IP payload, then the packet is no longer considered to be on the
same link. This means that the packet may pass through devices such
as repeaters, bridges, hubs, or switches and still be considered to
be on the same link for the purpose of this document, but not through
a device such as an IP router that decrements the IP TTL or otherwise
modifies the IP header.
4. Compatibility Considerations
No changes to existing devices are required to work with a Discovery
Proxy.
Existing devices that advertise services using Multicast DNS work
with a Discovery Proxy.
Existing clients that support DNS-based Service Discovery over
Unicast DNS work with a Discovery Proxy. DNS-based Service Discovery
over Unicast DNS was introduced in Mac OS X 10.4 Tiger in April 2005
and has been included in Apple products introduced since then,
including the iPhone and iPad. It has also been included in products
from other vendors, such as Microsoft Windows 10.
An overview of the larger collection of associated DNS-based Service
Discovery technologies, and how the Discovery Proxy technology
relates to those, is given in the Service Discovery Road Map document
[ROADMAP].
5. Discovery Proxy Operation
In a typical configuration, a Discovery Proxy is configured to be
authoritative [RFC1034] [RFC1035] for four or more DNS subdomains,
listed below. Authority for these subdomains is delegated from the
parent domain to the Discovery Proxy in the usual way for DNS
delegation, via NS records.
A DNS subdomain for DNS-based Service Discovery records.
This subdomain name may contain rich text, including spaces and
other punctuation. This is because this subdomain name is used
only in graphical user interfaces, where rich text is appropriate.
A DNS subdomain for host name records.
This subdomain name SHOULD be limited to letters, digits, and
hyphens in order to facilitate the convenient use of host names in
command-line interfaces.
One or more DNS subdomains for IPv4 Reverse Mapping records.
These subdomains will have names that end in "in-addr.arpa".
One or more DNS subdomains for IPv6 Reverse Mapping records.
These subdomains will have names that end in "ip6.arpa".
In an enterprise network, the naming and delegation of these
subdomains is typically performed by conscious action of the network
administrator. In a home network, naming and delegation would
typically be performed using some automatic configuration mechanism
such as Home Networking Control Protocol (HNCP) [RFC7788].
These three varieties of delegated subdomains (service discovery,
host names, and reverse mapping) are described below in Sections 5.1,
5.3, and 5.4.
How a client discovers where to issue its DNS-based Service Discovery
queries is described in Section 5.2.
5.1. Delegated Subdomain for DNS-based Service Discovery Records
In its simplest form, each link in an organization is assigned a
unique Unicast DNS domain name such as "Building 1.example.com" or
"2nd Floor.Building 3.example.com". Grouping multiple links under a
single Unicast DNS domain name is to be specified in a future
companion document, but for the purposes of this document, assume
that each link has its own unique Unicast DNS domain name. In a
graphical user interface these names are not displayed as strings
with dots as shown above, but something more akin to a typical file
browser graphical user interface (which is harder to illustrate in a
text-only document) showing folders, subfolders, and files in a file
system.
+---------------+--------------+-------------+-------------------+
| *example.com* | Building 1 | 1st Floor | Alice's printer |
| | Building 2 | *2nd Floor* | Bob's printer |
| | *Building 3* | 3rd Floor | Charlie's printer |
| | Building 4 | 4th Floor | |
| | Building 5 | | |
| | Building 6 | | |
+---------------+--------------+-------------+-------------------+
Figure 2: Illustrative GUI
Each named link in an organization has one or more Discovery Proxies
that serve it. This Discovery Proxy function could be performed by a
device like a router or switch that is physically attached to that
link. In the parent domain, NS records are used to delegate
ownership of each defined link name (e.g., "Building 1.example.com")
to one or more Discovery Proxies that serve the named link. In other
words, the Discovery Proxies are the authoritative name servers for
that subdomain. As in the rest of DNS-based Service Discovery, all
names are represented as-is using plain UTF-8 encoding and, as
described in Section 5.5.4, no text-encoding translations are
performed.
With appropriate VLAN configuration [IEEE-1Q], a single Discovery
Proxy device could have a logical presence on many links and serve as
the Discovery Proxy for all those links. In such a configuration,
the Discovery Proxy device would have a single physical Ethernet
[IEEE-3] port, configured as a VLAN trunk port, which would appear to
software on that device as multiple virtual Ethernet interfaces, one
connected to each of the VLAN links.
As an alternative to using VLAN technology, using a Multicast DNS
Discovery Relay [RELAY] is another way that a Discovery Proxy can
have a "virtual" presence on a remote link.
When a DNS-SD client issues a Unicast DNS query to discover services
in a particular Unicast DNS subdomain
(e.g., "_ipp._tcp.Building 1.example.com. PTR ?"), the normal DNS
delegation mechanism results in that query being forwarded until it
reaches the delegated authoritative name server for that subdomain,
namely, the Discovery Proxy on the link in question. Like a
conventional Unicast DNS server, a Discovery Proxy implements the
usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP.
However, unlike a conventional Unicast DNS server that generates
answers from the data in its manually configured zone file, a
Discovery Proxy learns answers using Multicast DNS. A Discovery
Proxy does this by consulting its Multicast DNS cache and/or issuing
Multicast DNS queries, as appropriate according to the usual protocol
rules of Multicast DNS [RFC6762], for the corresponding Multicast DNS
name, type, and class, with the delegated zone part of the name
replaced with ".local" (e.g., in this case,
"_ipp._tcp.local. PTR ?"). Then, from the received Multicast DNS
data, the Discovery Proxy synthesizes the appropriate Unicast DNS
response, with the ".local" top-level label of the owner name
replaced with the name of the delegated zone. Further details of the
name translation rules are described in Section 5.5. Rules
specifying how long the Discovery Proxy should wait to accumulate
Multicast DNS responses before sending its unicast reply are
described in Section 5.6.
The existing Multicast DNS caching mechanism is used to minimize
unnecessary Multicast DNS queries on the wire. The Discovery Proxy
is acting as a client of the underlying Multicast DNS subsystem and
benefits from the same caching and efficiency measures as any other
client using that subsystem.
Note that the contents of the delegated zone, generated as it is by
performing ".local" Multicast DNS queries, mirrors the records
available on the local link via Multicast DNS very closely, but not
precisely. There is not a full bidirectional equivalence between the
two. Certain records that are available via Multicast DNS may not
have equivalents in the delegated zone possibly because they are
invalid or not relevant in the delegated zone or because they are
being suppressed because they are unusable outside the local link
(see Section 5.5.2). Conversely, certain records that appear in the
delegated zone may not have corresponding records available on the
local link via Multicast DNS. In particular, there are certain
administrative SRV records (see Section 6) that logically fall within
the delegated zone but semantically represent metadata _about_ the
zone rather than records _within_ the zone. Consequently, these
administrative records in the delegated zone do not have any
corresponding counterparts in the Multicast DNS namespace of the
local link.
5.2. Domain Enumeration
A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR
queries, using both unicast and multicast.
If a DNS-SD client receives a Domain Name configuration via DHCP then
it issues unicast queries derived from this domain name. It also
issues unicast queries using names derived from its IPv4 subnet
address(es) and IPv6 prefix(es). These unicast Domain Enumeration
queries are described in Section 5.2.1. A DNS-SD client also issues
multicast Domain Enumeration queries in the "local" domain [RFC6762],
as described in Section 5.2.2. The results of all the Domain
Enumeration queries are combined for DNS-based Service Discovery
purposes.
5.2.1. Domain Enumeration via Unicast Queries
The (human or automated) administrator creates Unicast DNS Domain
Enumeration PTR records [RFC6763] to inform clients of available
service discovery domains. Two varieties of such Unicast DNS Domain
Enumeration PTR records exist: those with names derived from the
domain name communicated to the clients via DHCP option 15 [RFC2132],
and those with names derived from either IPv4 subnet address(es) or
IPv6 prefix(es) in use by the clients. Below is an example showing
the name-based variety, where the DHCP server configured the client
with the domain name "example.com":
b._dns-sd._udp.example.com. PTR Building 1.example.com.
PTR Building 2.example.com.
PTR Building 3.example.com.
PTR Building 4.example.com.
db._dns-sd._udp.example.com. PTR Building 1.example.com.
lb._dns-sd._udp.example.com. PTR Building 1.example.com.
The meaning of these records is defined in the DNS-based Service
Discovery specification [RFC6763] but, for convenience, is repeated
here. The "b" ("browse") records tell the client device the list of
browsing domains to display for the user to select from. The "db"
("default browse") record tells the client device which domain in
that list should be selected by default. The "db" domain MUST be one
of the domains in the "b" list; if not, then no domain is selected by
default. The "lb" ("legacy browse") record tells the client device
which domain to automatically browse on behalf of applications that
don't implement user interface for multi-domain browsing (which is
most of them at the time of writing). The "lb" domain is often the
same as the "db" domain, or sometimes the "db" domain plus one or
more others that should be included in the list of automatic browsing
domains for legacy clients.
Note that in the example above, for clarity, space characters in
names are shown as actual spaces. If this data is manually entered
into a textual zone file for authoritative server software such as
BIND, care must be taken because the space character is used as a
field separator, and other characters like dot ('.'), semicolon
(';'), dollar ('