RFC 7558

Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions

📅 published July 2015, from ietf

RFC 7558: Requirements for Scalable DNS-SD / mDNS Extensions 🎀

okay bestie, let's get into this one. ✨ It's an Informational doc from the IETF, published July 2015, with ISSN 2070-1721. It's not a Standards Track spec, so it's basically a "here's the problem and what we need" write-up 💅. The authors are K. Lynn from Verizon Labs, S. Cheshire from Apple, Inc., M. Blanchet from Viagenie, and D. Migault from Ericsson. The title is Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions 🦋. The title block doesn't list anything it obsoletes or updates, so there's nothing to report on that front 🌸.

Abstract ✨

DNS-SD over mDNS is super popular right now for finding services and names on a local link 🔥. But people want service discovery to work beyond the local link too, and this doc lays out the problem and a list of requirements for scalable DNS-SD 💜.

Status of This Memo 📜

This doc is not an Internet Standards Track spec. It's published just for info 🧚.

It's a product of the IETF, and it reflects the consensus of the IETF community 🫶. It went through public review and got approved for publication by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, though. See Section 2 of RFC 5741 for that 💅.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7558 🍓.

Copyright (c) 2015 IETF Trust and the people listed as document authors. All rights reserved 🌈.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info (as in effect on the publication date). Please actually read these, bestie, because they spell out your rights and restrictions for this doc 🙈. Any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💖.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
3.  Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . .   6
4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7
5.  Namespace Considerations  . . . . . . . . . . . . . . . . . .   9
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . . .  13
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction ✨

okay so DNS-SD ([DNS-SD]) plus its buddy Multicast DNS ([mDNS]) is everywhere for finding services and names on a local link 🦋. The problem is that as people move to multi-link home or campus networks, mDNS (by design) doesn't work across routers 😭. DNS-SD can also be paired with regular unicast DNS for wide-area service discovery, but that's not widely deployed yet 🙈. This gap between what customers need and what's actually done has led to calls for improvement, like the Educause petition [EP] 💅.

Because of this and similar market demand, a bunch of products now do service discovery beyond the local link using different ad hoc techniques 🔥. Still, no consensus has come together on which approach is the best long-term direction for DNS-based Service Discovery protocol development 🌸.

Multicast DNS as it stands also isn't optimized for network tech where multicast is relatively expensive 💀. Wi-Fi ([IEEE.802.11]) can get hurt by too much mDNS traffic, since multicast carries higher network overhead. Wireless mesh networks like IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ([RFC4944]) are basically multi-link subnets ([RFC4903]), where intermediate nodes have to forward multicasts 🧚.

It's in everyone's best interest (end users, network admins, and vendors alike) to work together within the IETF and build an efficient, scalable, and interoperable standards-based solution 🫶.

So this doc defines the problem statement and gathers requirements for scalable DNS-SD/mDNS extensions ✨.

1.1. Terminology and Acronyms 📖

  • Service: a listening endpoint (host and port) for a given application protocol. Services are identified by Service Instance Names 💖.
  • DNS-SD: DNS-based Service Discovery ([DNS-SD]) is a regular application of DNS resource records and messages to help with naming, discovery, and location of services. When used on its own, the term usually refers to the wide-area unicast protocol 🌈.
  • mDNS: Multicast DNS ([mDNS]) is a mechanism that gives you distributed DNS-like capabilities (including DNS-SD) on a local link, without needing traditional DNS infrastructure 🦋.
  • SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future extension of DNS-SD (and maybe mDNS) that meets the requirements in this doc 👑.
  • Scope of Discovery: a subset of a local or global namespace (for example, a DNS subdomain) that's the target of a given SSD query 🎀.
  • Zero Configuration: a deployment of SSD that needs no administration, although some administration may be optional 🍓.
  • Incremental Deployment: an orderly transition, as a network installation evolves, from DNS-SD/mDNS to SSD 🌸.

2. Problem Statement 🔥

Service discovery beyond the local link is probably the biggest thing missing from the DNS-SD-over-mDNS framework (you'll also see it written as "DNS-SD over mDNS" or "DNS-SD/mDNS") 😭. The other issues and requirements are summarized below 💅.

Network admins in the research and education community sent in a list of DNS-SD/mDNS improvements they wanted, in the form of the Educause petition [EP]. Here's the summary of their technical issues 💜:

  • Enterprises and institutions often use wireless links for client access and wired links for server infrastructure. Usually those are on different subnets 🌐. So products that advertise services like printing and multimedia streaming via DNS-SD over mDNS can't be found by client devices on other links 😩. DNS-SD with conventional unicast DNS does work when servers and clients are on different links, but the resource records describing the services have to somehow get entered into the unicast DNS namespace 🙈.
  • DNS-SD resource records can be entered by hand into a unicast DNS zone file [STATIC], but a DNS admin has to do it. That's labor intensive and brittle when device IP addresses change dynamically, which is super common with DHCP 💀.
  • Adding DNS-SD records automatically with DNS Update does work, but the DNS server has to be configured to allow DNS Updates, and devices need DNS Update credentials to be allowed to make those updates. That's proven to be onerous 😤.

So there's a need for a mechanism that fills the DNS namespace with the right DNS-SD records, with less manual admin than a conventional unicast DNS server typically needs ✨.

Here's the summary of technical requirements 📋:

  • It must scale to a range of hundreds to thousands of DNS-SD/mDNS-enabled devices in a given environment 🌸.
  • It must work across a variety of network link technologies at the same time, such as wired and wireless networks 🦋.
  • It must not significantly increase network traffic (wired or wireless) 🫶.
  • It must be cost-effective to manage at up to enterprise scale 💖.

2.2. IEEE 802.11 Wireless LANs 📶

Multicast DNS was originally designed to run on Ethernet, which was the dominant link layer back then 🕰️. On shared-medium Ethernet, multicast frames don't add much extra demand on the shared medium compared to unicast frames 🌿. On IEEE 802.11 networks, though, multicast frames go out at a low data rate that every receiver supports 🐢. In practice that low rate means a bigger chunk of airtime goes to multicast transmission 😬. Some network admins block multicast traffic, or use access points that send multicast frames as a series of link-layer unicast frames 🙈.

Wireless links can be orders of magnitude less reliable than their wired counterparts 📉. To make transmissions more reliable, the IEEE 802.11 Medium Access Control (MAC) requires positive acknowledgement of unicast frames 🔒. It does not, however, support positive acknowledgement of multicast frames 💀. So it's common to see higher loss rates for multicast frames on wireless than on wired 😭.

So if you want service discovery on IEEE 802.11 networks, the number of multicast frames has to be kept at a suitably low value, or swapped out for unicast frames so you can use the MAC's reliability features 💅.

2.3. Low-Power and Lossy Networks (LLNs) 🔋

Emerging wireless mesh networking tech like the Routing Protocol for LLNs (RPL) [RFC6550] and 6LoWPAN throws a few challenges at the current DNS-SD/mDNS design 🧚. First up, link-local multicast scope [RFC4291] is defined as a single-hop neighborhood 📡. A wireless mesh network that's one logical subnet can often stretch across multiple hops [RFC4903], so you need a bigger multicast scope to span it [RFC7346] 🌐. Multicast DNS was intentionally not specified for anything bigger than link-local scope, because of the extra off-link multicast traffic it would generate 🙈.

On top of that, low-power nodes may be offline for long stretches, either because they're "sleeping" or because of connectivity problems 😴. In those cases, LLN nodes might fail to respond to queries or defend their names using the current design 💀.

3. Basic Use Cases ✨

okay so these use cases exist to help us picture, tell apart, and sort the target requirements 🎀. They go from simple to wildly complicated, showing how deployment and admin stuff gets harder as things grow 💅.

  • (A) Personal Area Networks (PANs): The simplest network is one client and one server on a shared link, like one laptop and one printer 🖨️. PANs with no router can use Zero Configuration Networking [ZC] to self-assign link-local addresses [RFC3927] [RFC4862] and Multicast DNS [mDNS] for naming and service discovery. This is already implemented and deployed in Mac OS X, iOS, Windows [B4W], and Android [NSD] 🦋.
  • (B) Classic home or 'hotspot' networks, with these properties 🏠:
    • Single exit router: The network may have one or more upstream providers or networks, but all outgoing and incoming traffic goes through a single router.
    • One-level depth: A single physical link, or multiple physical links bridged to form a single logical link, connects to the default router. That single logical link gives you one broadcast domain, which makes link-local Multicast DNS easy to use. ARP also works here, so the home or 'hotspot' network can be just one IPv4 subnet 🌸.
    • Single administrative domain: All nodes fall under the same administrative authority. This doesn't necessarily mean there's a network administrator 🙈.
  • (C) Advanced home and small business networks [RFC7368]: This is like B, but it has multiple wired and/or wireless links connected by routers, usually behind a single exit router. The forwarding nodes are mostly self-configuring and don't need routing protocol administration. These networks also shouldn't need DNS administration ✨.
  • (D) Enterprise networks: These have an arbitrary network diameter under a single administrative authority. Most of the forwarding and security devices are configured, and multiple exit routers are more common. Big conference-style networks, which are mostly wireless access (like the ones at IETF meetings), also count here 💼.
  • (E) Higher-Education networks: This is like D, except the core network may sit under a central administrative authority while the leaf networks have their own local administrative authorities 🎓.
  • (F) Mesh networks such as RPL/6LoWPAN: These are multi-link subnets with prefixes defined by one or more border routers. They may make up any part of networks C, D, or E 🕸️.

4. Requirements 💜

Any successful SSD solution(s) will have to find the right balance between competing goals like scalability, deployability, and usability ⚖️. With that in mind, none of the requirements below should be considered in isolation, bestie 🫶.

REQ1: For use cases A, B, and C, there should be a Zero Configuration mode of operation. This means servers and clients should be able to automatically work out a default scope of discovery for advertising and discovering services, respectively 🪄.

REQ2: For use cases C, D, and E, there should be a way to configure scopes of discovery that support a range of topologically independent zones (e.g., from department to campus wide). This capability must exist in the protocol. Individual operators are not required to use it in all cases. In particular, use case C should support Zero Configuration operation where that's wanted. If multiple scopes are available, there must be a way to list the choices so one can be selected. In use case C, either Zero Configuration (one flat list of resources) or configured (e.g., resources sorted by room) modes of operation should be available 📋.

REQ3: As stated in REQ2 above, the discovery scope doesn't need to line up with network topology. For example, it may instead be aligned to physical proximity (e.g., building) or organizational structure (e.g., "Sales" vs. "Engineering") 🏢.

REQ4: For use cases C, D, and E, there should be an incremental way to deploy the solution 🪜.

REQ5: SSD should leverage and build upon current link scope DNS-SD/mDNS protocols and deployments 🧱.

REQ6: SSD must not adversely affect or break any other current protocols or deployments. No breaking the group chat 🙅‍♀️.

REQ7: SSD must be capable of operating across networks that are not limited to a single link or network technology, including clients and services on non-adjacent links 🌐.

REQ8: It is desirable that a user or device be able to discover services within the sites or networks to which the user or device is connected 📡.

REQ9: SSD should operate efficiently on common link layers and link types 🔗.

REQ10: SSD should be considerate of networks where power consumption is a critical factor. For example, nodes may be in a low-power or sleeping state 😴.

REQ11: SSD must be scalable to thousands of nodes with minimal configuration and without degrading network performance. A possible figure of merit is that, as the number of services increases, the amount of traffic due to SSD on a given link remains relatively constant 📈.

REQ12: SSD should enable a way to provide a consistent user experience whether local or remote services are being discovered 🎀.

REQ13: The information presented by SSD should closely reflect the current state of discoverable services on the network. That is, new information should be available within a few seconds, and stale information should not persist indefinitely. In networking, all information is necessarily somewhat out of date by the time it reaches the receiver, even if only by a few microseconds or less. So timeliness is always an engineering trade-off against efficiency. The engineering decisions for SSD should balance timeliness against network efficiency in a sensible way ⏱️.

REQ14: SSD should operate over existing networks (as described by use cases A through F above) without requiring changes to the network at the physical, link, or internetworking layers 🙌.

REQ15: The administrator of an advertised service should be able to control whether the service is advertised beyond the local link 🔒.

5. Namespace Considerations 🗂️

The traditional unicast DNS namespace mostly holds globally unique names. Multicast DNS gives every link its own separate link-local namespace, where names are only unique within that link. Clients discovering services may need to tell local names apart from global ones, and may need to figure out when names in different namespaces point to the same service 🧐.

Devices on different links may have the same mDNS name (maybe because of vendor defaults), since link-local mDNS names are only guaranteed to be unique per link. This can cause a local label disambiguation problem when results get aggregated (e.g., for presentation) 😬.

SSD should support rich internationalized labels within Service Instance Names, the same way DNS-SD/mDNS does today 🌍. SSD must not negatively impact the global DNS namespace or infrastructure 🛡️.

Publishing local services in the global DNS namespace can mostly be seen as exporting local resource records and their associated labels into some DNS zone. The issues around defining labels that work across both local and global namespaces are discussed in a separate document [INTEROP-LABELS] 📚.

6. Security Considerations 🚨

⚠️ Okay bestie, this section is serious. Read it all, no skipping 🙏.

Insofar as SSD may automatically gather DNS-SD resource records and publish them over a wide area, the security issues are likely to include the union of those discussed in the Multicast DNS [mDNS] and DNS-based Service Discovery [DNS-SD] specifications. The following sections highlight potential threats posed by deploying DNS-SD over multiple links or by automating DNS-SD administration 🕵️‍♀️.

6.1. Scope of Discovery

In some scenarios, the owner of the advertised service may not have a clear idea of the scope of its advertisement 👀.

For example, since mDNS is currently restricted to a single link, the scope of the advertisement is limited, by design, to the shared link between client and server. If the advertisement propagates to a larger set of links than expected, this may result in unauthorized clients (from the owner's perspective) discovering the service and then potentially trying to connect to it. It also discloses information (about the host and service) to a larger set of potential attackers 😱.

Note that discovering a service does not necessarily mean the service is reachable by, can be connected to, or can be used by a given client. Specific access-control mechanisms are out of scope of this document 🔐.

If the scope of discovery is not properly set up or constrained, information leaks will happen outside the appropriate network 💀.

6.2. Multiple Namespaces

There is a possibility of conflicts between the local and global DNS namespaces. Without adequate feedback, a discovering client may not know if the advertised service is the correct one, which enables potential attacks 🎭.

6.3. Authorization

DNSSEC can assert the validity but not the accuracy of records in a zone file. The trust model of the global DNS relies on the fact that human administrators either (a) manually enter resource records into a zone file or (b) configure the DNS server to authenticate a trusted device (e.g., a DHCP server) that can automatically maintain such records 🗝️.

An impostor may register on the local link and appear as a legitimate service. Such "rogue" services may then be automatically registered in unicast DNS-SD 👿.

6.4. Authentication

Up to now, the "plug-and-play" nature of mDNS devices has relied only on physical connectivity. If a device is visible via mDNS, it's assumed to be trusted. That's not likely to be the case in foreign networks 🚩.

If there's a risk that clients may be fooled by rogue services, then application-layer authentication should be considered as part of any security solution. Authentication of any particular service is outside the scope of this document 🪪.

6.5. Access Control 🔐

Okay, so access control is all about who gets to use a service that's advertised via DNS-SD. And "use" is NOT the same as "discover" or "reach" a service, bestie. Finding a service and being allowed to actually use it are two totally different vibes 💅

Controlling access to an advertised service is outside the scope of DNS-SD, so DNS-SD isn't the one handling it. Access control today usually comes from existing site infrastructure (things like router access-control lists and firewalls) and/or from service-specific mechanisms (like user authentication to the service itself). Networked printers are a great example: they can lock things down with a user ID and password 🖨️ Apple's software supports this kind of access control for USB printers shared via Mac OS X Printer Sharing, and so do a lot of networked printers themselves. So leaning on existing service-specific security mechanisms (aka stuff outside the scope of DNS-SD) does not create new security considerations. Iconic, honestly 🙌

6.6. Privacy Considerations 🫣

Okay, this part is kind of a big deal. Mobile devices like smart phones or laptops can expose the location of their owners by registering services in arbitrary zones, and that's a real privacy risk 😭 Devices of this kind must not register their services in arbitrary zones without the approval ("opt-in") of their users. That's the main rule, and it's not up for debate.

BUT (and this is the plot twist 🎀) it should be possible to configure one or more "safe" zones where mobile devices may automatically register their services. So you get the convenience without the oversharing. Main character privacy energy 🦋

7. References 📚

7.1. Normative References

[DNS-SD]   Cheshire, S. and M. Krochmal, "DNS-Based Service
           Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
           <http://www.rfc-editor.org/info/rfc6763>.

[mDNS]     Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
           DOI 10.17487/RFC6762, February 2013,
           <http://www.rfc-editor.org/info/rfc6762>.

[RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
           Configuration of IPv4 Link-Local Addresses", RFC 3927,
           DOI 10.17487/RFC3927, May 2005,
           <http://www.rfc-editor.org/info/rfc3927>.

[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 4291, DOI 10.17487/RFC4291, February
           2006, <http://www.rfc-editor.org/info/rfc4291>.

[RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
           Address Autoconfiguration", RFC 4862,
           DOI 10.17487/RFC4862, September 2007,
           <http://www.rfc-editor.org/info/rfc4862>.

[RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
           DOI 10.17487/RFC4903, June 2007,
           <http://www.rfc-editor.org/info/rfc4903>.

[RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
           "Transmission of IPv6 Packets over IEEE 802.15.4
           Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
           <http://www.rfc-editor.org/info/rfc4944>.

[RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
           Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
           JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
           Low-Power and Lossy Networks", RFC 6550,
           DOI 10.17487/RFC6550, March 2012,
           <http://www.rfc-editor.org/info/rfc6550>.

[RFC7346]  Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
           DOI 10.17487/RFC7346, August 2014,
           <http://www.rfc-editor.org/info/rfc7346>.

[RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
           Weil, "IPv6 Home Networking Architecture Principles", RFC
           7368, DOI 10.17487/RFC7368, October 2014,
           <http://www.rfc-editor.org/info/rfc7368>.

7.2. Informative References 💡

[B4W]      "Bonjour (software)",
           <http://en.wikipedia.org/wiki/Bonjour_(software)>.

[EP]       Badman, L., "Petitioning Apple: From Educause Higher Ed
           Wireless Networking Admin Group", July 2012,
           <https://www.change.org/p/from-educause-higher-ed-
           wireless-networking-admin-group>.

[IEEE.802.11]
           IEEE Computer Society, "IEEE Standard for Information
           technology - Telecommunications and information exchange
           between systems Local and metropolitan area networks -
           Specific requirements Part 11: Wireless LAN Medium Access
           Control (MAC) and Physical Layer (PHY) Specifications",
           IEEE Std 802.11,
           <http://standards.ieee.org/about/get/802/802.11.html>.

[INTEROP-LABELS]
           Sullivan, A., "On Interoperation of Labels Between mDNS
           and DNS", Work in Progress,
           draft-sullivan-dnssd-mdns-dns-interop-01, October 2014.

[NSD]      Android, "NsdManager",
           <http://developer.android.com/reference/android/net/nsd/
           NsdManager.html>.

[STATIC]   "Manually Adding DNS-SD Service Discovery Records to an
           Existing Name Server", July 2013,
           <http://www.dns-sd.org/ServerStaticSetup.html>.

[ZC]       Cheshire, S. and D. Steinberg, "Zero Configuration
           Networking: The Definitive Guide", O'Reilly Media, Inc.,
           ISBN 0-596-10100-7, December 2005.

Acknowedgements 🫶

We gratefully acknowledge contributions and review comments made by RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and Peter Van Der Stok. The whole squad showed up for this one 💜

Authors' Addresses ✍️

Kerry Lynn
Verizon Labs
50 Sylvan Road
Waltham, MA  95014
United States

Phone: +1 781 296 9722
Email: kerry.lynn@verizon.com


Stuart Cheshire
Apple, Inc.
1 Infinite Loop
Cupertino, CA  95014
United States

Phone: +1 408 974 3207
Email: cheshire@apple.com


Marc Blanchet
Viagenie
246 Aberdeen
Quebec, QC  G1R 2E1
Canada

Email: Marc.Blanchet@viagenie.ca
URI:   http://viagenie.ca


Daniel Migault
Ericsson
8400 Boulevard Decarie
Montreal, QC  H4P 2N2
Canada

Phone: +1 514 452 2160
Email: daniel.migault@ericsson.com
📦 where this page comes from