💾 Archived View for radia.bortzmeyer.org › rfc-mirror › rfc8766.txt captured on 2024-07-09 at 05:19:45.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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 ('