Skip to main content

Requirements for Scalable DNS-SD/mDNS Extensions

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7558.
Authors Kerry Lynn , Stuart Cheshire , Marc Blanchet , Daniel Migault
Last updated 2015-03-12 (Latest revision 2015-03-04)
Replaces draft-lynn-dnssd-requirements
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Tim Chown
Shepherd write-up Show Last changed 2014-11-13
IESG IESG state Became RFC 7558 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES.
Responsible AD Ted Lemon
Send notices to,,,
IANA IANA review state IANA OK - No Actions Needed
DNS-SD/mDNS Extensions                                           K. Lynn
Internet-Draft                                                   Verizon
Intended status: Informational                               S. Cheshire
Expires: September 5, 2015                                   Apple, Inc.
                                                             M. Blanchet
                                                              D. Migault
                                                           March 4, 2015

            Requirements for Scalable DNS-SD/mDNS Extensions


   DNS-SD over mDNS is widely used today for discovery and resolution of
   services and names on a local link, but there are use cases to extend
   DNS-SD/mDNS to enable service discovery beyond the local link.  This
   document provides a problem statement and a list of requirements.

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

   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 September 5, 2015.

Copyright Notice

   Copyright (c) 2015 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
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Lynn, et al.            Expires September 5, 2015               [Page 1]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   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
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Namespace Considerations  . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   DNS-Based Service Discovery [DNS-SD] in combination with its
   companion technology Multicast DNS [mDNS] is widely used today for
   discovery and resolution of services and names on a local link.
   However, as users move to multi-link home or campus networks they
   find that mDNS (by design) does not work across routers.  DNS-SD can
   also be used in conjunction with conventional unicast DNS to enable
   wide-area service discovery, but this capability is not yet widely
   deployed.  This disconnect between customer needs and current
   practice has led to calls for improvement, such as the Educause
   petition [EP].

   In response to this and similar evidence of market demand, several
   products now enable service discovery beyond the local link using
   different ad hoc techniques.  As yet, no consensus has emerged
   regarding which approach represents the best long-term direction for
   DNS-based service discovery protocol development.

   Multicast DNS in its present form is also not optimized for network
   technologies where multicast transmissions are relatively expensive.
   Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely
   affected by excessive mDNS traffic due to the higher network overhead
   of multicast transmissions.  Wireless mesh networks such as 6LoWPAN
   [RFC4944] are effectively multi-link subnets [RFC4903] where
   multicasts must be forwarded by intermediate nodes.

   It is in the best interests of end users, network administrators, and
   vendors for all interested parties to cooperate within the context of

Lynn, et al.            Expires September 5, 2015               [Page 2]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   the IETF to develop an efficient, scalable, and interoperable
   standards-based solution.

   This document 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 conventional
   application of DNS Resource Records and messages to facilitate the
   naming, discovery, and location of services.  When used alone, it
   generally refers to the wide-area unicast protocol.

   mDNS: Multicast DNS [mDNS] is a mechanism that facilitates
   distributed DNS-like capabilities (including DNS-SD) on a local link
   without need of traditional DNS infrastructure.

   SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future
   extension of DNS-SD (and perhaps mDNS) that meets the requirements
   set forth in this document.

   Scope of Discovery: A subset of a local or global namespace, e.g., a
   DNS subdomain, that is the target of a given SSD query.

   Zero Configuration: A deployment of SSD that requires 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 perhaps the most important
   feature currently missing from the DNS-SD-over-mDNS framework (also
   written as "DNS-SD over mDNS" or "DNS-SD/mDNS").  Other issues and
   requirements are summarized below.

2.1.  Multi-link Naming and Discovery

   A list of desired DNS-SD/mDNS improvements from network
   administrators in the research and education community was issued in
   the form of the Educause petition [EP].  The following is a summary
   of their technical issues:

Lynn, et al.            Expires September 5, 2015               [Page 3]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   o  Products that advertise services such as printing and multimedia
      streaming via DNS-SD over mDNS are not currently discoverable by
      devices on other links.  It is common practice for enterprises and
      institutions to use wireless links for client access and wired
      networks for server infrastructure, typically on different
      subnets.  DNS-SD used with conventional unicast DNS does work when
      devices are on different links, but the resource records that
      describe the service must somehow be entered into the unicast DNS

   o  DNS-SD resource records may be entered manually into a unicast DNS
      zone file [STATIC], but this task must be performed by a DNS
      administrator.  It is labor-intensive and brittle when IP
      addresses of devices change dynamically, as is common when DHCP is

   o  Automatically adding DNS-SD records using DNS Update works, but
      requires that the DNS server be configured to allow DNS Updates,
      and requires that devices be configured with the DNS Update
      credentials to permit such updates, which has proven to be

   Therefore, a mechanism is desired that populates the DNS namespace
   with the appropriate DNS-SD records with less manual administration
   than typically needed for a unicast DNS server.

   The following is a summary of their technical requirements:

   o  It must scale to a range of hundreds to thousands of DNS-SD/mDNS-
      enabled devices in a given environment.

   o  It must simultaneously operate over a variety of network link
      technologies, such as wired and wireless networks.

   o  It must not significantly increase network traffic (wired or

   o  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 - the
   dominant link-layer at the time.  In shared Ethernet networks,
   multicast frames place little additional demand on the shared network
   medium compared to unicast frames.  In IEEE 802.11 networks however,
   multicast frames are transmitted at a low data rate supported by all
   receivers.  In practice, this data rate leads to a larger fraction of
   airtime being devoted to multicast transmission.  Some network

Lynn, et al.            Expires September 5, 2015               [Page 4]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   administrators block multicast traffic, or use access points that
   transmit multicast frames using a series of link-layer unicast

   Wireless links may be orders of magnitude less reliable than their
   wired counterparts.  To improve transmission reliability, the IEEE
   802.11 MAC requires positive acknowledgement of unicast frames.  It
   does not, however, support positive acknowledgement of multicast
   frames.  As a result, it is common to observe much higher loss of
   multicast frames on wireless as compared to wired network

   Enabling service discovery on IEEE 802.11 networks requires that the
   number of multicast frames be restricted to a suitably low value, or
   replaced with unicast frames to use the MAC's reliability features.

2.3.  Low Power and Lossy Networks (LLNs)

   Emerging wireless mesh networking technologies such as RPL [RFC6550]
   and 6LoWPAN present several challenges for the current DNS-SD/mDNS
   design.  First, Link-Local multicast scope [RFC4291] is defined as a
   single-hop neighborhood.  A wireless mesh network representing a
   single logical subnet may often extend to multiple hops [RFC4903],
   therefore a larger multicast scope is required to span it [RFC7346].
   Multicast DNS was intentionally not specified for greater than Link-
   Local scope, because of the additional off-link multicast traffic
   that would generate.

   Additionally, low-power nodes may be offline for significant periods
   either because they are "sleeping" or due to connectivity problems.
   In such cases LLN nodes might fail to respond to queries or defend
   their names using the current design.

3.  Basic Use Cases

   The following use cases are defined with different characteristics to
   help motivate, distinguish, and classify the target requirements.
   They cover a spectrum of increasing deployment and administrative

      (A) Personal Area networks (PANs): the simplest example of a
      network may consist of a single client and server, e.g., one
      laptop and one printer, on a common link.  PANs that do not
      contain a router may use Zero Configuration Networking [ZC] to
      self-assign link-local addresses [RFC3927] [RFC4862], and
      Multicast DNS [mDNS] to provide naming and service discovery, as
      currently implemented and deployed in Mac OS X, iOS, Windows [B4W]
      and Android [NSD].

Lynn, et al.            Expires September 5, 2015               [Page 5]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

      (B) Classic home or 'hotspot' networks, with the following

      *  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, that is connected
         to the default router.  The single logical link provides a
         single broadcast domain, facilitating use of link-local
         Multicast DNS, and also ARP, which enables the home or
         'hotspot' network to consist of just a single IPv4 subnet.

      *  Single administrative domain: all nodes under the same
         administrative authority.  (However, this does not necessarily
         imply a network administrator.)

      (C) Advanced home and small business networks [RFC7368]:

      Like B, but consist of multiple wired and/or wireless links,
      connected by routers, generally behind a single exit router.
      However, the forwarding nodes are largely self-configuring and do
      not require routing protocol administration.  Such networks should
      also not require DNS administration.

      (D) Enterprise networks:

      Consist of arbitrary network diameter under a single
      administrative authority.  A large majority of the forwarding and
      security devices are configured and multiple exit routers are more
      common.  Large-scale conference-style networks, which are
      predominantly wireless access, e.g., as available at IETF
      meetings, also fall within this category.

      (E) Higher Education networks:

      Like D but the core network may be under a central administrative
      domain while leaf networks are under local administrative domains.

      (F) Mesh networks such as RPL/6LoWPAN:

      Multi-link subnets with prefixes defined by one or more border
      routers.  May comprise any part of networks C, D, or E.

Lynn, et al.            Expires September 5, 2015               [Page 6]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

4.  Requirements

   Any successful SSD solution(s) will have to strike the proper balance
   between competing goals such as scalability, deployability, and
   usability.  With that in mind, none of the requirements listed below
   should be considered in isolation.

   REQ1:   For use cases A, B, and C, there should be a Zero
           Configuration mode of operation.  This implies that servers
           and clients should be able to automatically determine a
           default Scope of Discovery in which to advertise and discover
           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 this capability in all
           cases -- in particular, use case C should support Zero
           Configuration operation where that is desired.  If multiple
           scopes are available, there must be a way to enumerate the
           choices from which a selection can be made.  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 need not be
           aligned to 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.

   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.

Lynn, et al.            Expires September 5, 2015               [Page 7]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   REQ9:   SSD should operate efficiently on common link layers and link

   REQ10:  SSD should be considerate of networks where power consumption
           is a critical factor and, 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

   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.  Thus timeliness is always an
           engineering trade-off against efficiency.  The engineering
           decisions for SSD should appropriately balance timeliness
           against network efficiency.

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

5.  Namespace Considerations

   The traditional unicast DNS namespace contains, for the most part,
   globally unique names.  Multicast DNS provides every link with its
   own separate link-local namespace, where names are unique only within
   the context of that link.  Clients discovering services may need to
   differentiate between local and global names, and may need to
   determine when names in different namespaces identify the same

   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis.  Also, even devices that
   are on the same link may have similar-looking names, such as one
   device with the name "Bill" and another device using the similar-
   looking name "Bi11" (using the digit "1" in place of the letter "l").

Lynn, et al.            Expires September 5, 2015               [Page 8]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   This may lead to a local label disambiguation problem between
   presented results.

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

   The problem of publishing local services in the global DNS namespace
   may be generally viewed as exporting local resource records and their
   associated labels into some DNS zone.  The issues related to defining
   labels that are interoperable between local and global namespaces are
   discussed in a separate document

6.  Security Considerations

   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 that are 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 indication 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 perspective of the owner) discovering and then
   potentially attempting to connect to the advertised service.  It also
   discloses information (about the host and service) to a larger set of
   potential attackers.

   Note that discovery of a service does not necessarily imply that the
   service is reachable by, or 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 the discovery is not properly set up or constrained,
   then information leaks will happen outside the appropriate network.

Lynn, et al.            Expires September 5, 2015               [Page 9]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

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, therefore enabling
   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 then it is
   assumed to be trusted.  This is not likely to be the case in foreign

   If there is a risk that clients may be fooled by the deployment of
   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

   Access Control refers to the ability to restrict which users are able
   to use a particular service that might be advertised via DNS-SD.  In
   this case, "use" of a service is different from the ability to
   "discover" or "reach" a service.

   While controlling access to an advertised service is outside the
   scope of DNS-SD, we note that access control today often is provided
   by existing site infrastructure (e.g., router access control lists,
   firewalls) and/or by service-specific mechanisms (e.g., user
   authentication to the service).  For example, networked printers can
   control access via a user-id and password.  Apple's software supports
   such access control for USB printers shared via Mac OS X Printer
   Sharing, as do many networked printers themselves.  So the reliance

Lynn, et al.            Expires September 5, 2015              [Page 10]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   on existing service-specific security mechanisms (i.e. outside the
   scope of DNS-SD) does not create new security considerations.

6.6.  Privacy Considerations

   Mobile devices such as smart phones or laptops that can expose the
   location of their owners by registering services in arbitrary zones
   pose a risk to privacy.  Such devices must not register their
   services in arbitrary zones without the approval ("opt-in") of their
   users.  However, it should be possible to configure one or more
   "safe" zones in which mobile devices may automatically register their

7.  IANA Considerations

   This document makes no request of IANA.

8.  Acknowledgments

   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.

9.  References

9.1.  Normative References

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927, May

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

Lynn, et al.            Expires September 5, 2015              [Page 11]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

   [RFC6550]  Winter, T., Thubert, P., 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, March 2012.

   [RFC7346]  Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
              August 2014.

   [RFC7368]  Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
              "IPv6 Home Networking Architecture Principles", RFC 7368,
              October 2014.

   [mDNS]     Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              February 2013.

   [DNS-SD]   Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

9.2.  Informative References

   [B4W]      "Bonjour for Windows",

              Sullivan, A., "On Interoperation of Labels Between mDNS
              and DNS", draft-sullivan-dnssd-mdns-dns-interop-01 (work
              in progress), October 2014.

   [EP]       "Educause Petition",
              July 2012.

              "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-2012, 2012,

   [NSD]      "NsdManager | Android Developer", June 2012,

   [STATIC]   "Manually Adding DNS-SD Service Discovery Records to an
              Existing Name Server", July 2013,

Lynn, et al.            Expires September 5, 2015              [Page 12]
Internet-Draft        Scalable DNS-SD Requirements            March 2015

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

Authors' Addresses

   Kerry Lynn
   50 Sylvan Road
   Waltham , MA   95014

   Phone: +1 781 296 9722

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

   Phone: +1 408 974 3207

   Marc Blanchet
   246 Aberdeen
   Quebec , QC   G1R 2E1


   Daniel Migault
   8400 boulevard Decarie
   Montreal , QC   H4P 2N2

   Phone: +1 514 452 2160

Lynn, et al.            Expires September 5, 2015              [Page 13]