Discovery Proxy for Multicast DNS-Based Service Discovery
RFC 8766

Document Type RFC - Proposed Standard (June 2020; No errata)
Author Stuart Cheshire 
Last updated 2020-06-22
Replaces draft-cheshire-dnssd-hybrid
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Tim Chown
Shepherd write-up Show (last changed 2017-09-15)
IESG IESG state RFC 8766 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Éric Vyncke
Send notices to Tim Chown <tim.chown@jisc.ac.uk>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions


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
Show full document text