Service Registration Protocol for DNS-Based Service Discovery

The information below is for an old version of the document
Document Type Active Internet-Draft (candidate for dnssd WG)
Authors Stuart Cheshire  , Ted Lemon 
Last updated 2018-07-03 (latest revision 2018-07-02)
Replaced by draft-ietf-dnssd-srp
Stream IETF
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream WG state Call For Adoption By WG Issued
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                              S. Cheshire
Internet-Draft                                                Apple Inc.
Intended status: Informational                                  T. Lemon
Expires: January 3, 2019                             Nibbhaya Consulting
                                                            July 2, 2018

     Service Registration Protocol for DNS-Based Service Discovery


   The DNS-SD Service Registration Protocol uses the standard DNS Update
   mechanism to enable DNS-Based Service Discovery using only unicast
   packets.  This eliminates the dependency on Multicast DNS as the
   foundation layer, which greatly improves scalability and improves
   performance on networks where multicast service is not an optimal
   choice, particularly 802.11 (WiFi) and 802.15 (IoT) networks.  DNS-SD
   Service registration uses public keys and SIG(0) to allow services to
   defend their registrations against attack.

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 January 3, 2019.

Copyright Notice

   Copyright (c) 2018 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

Cheshire & Lemon         Expires January 3, 2019                [Page 1]
Internet-Draft        Service Registration Protocol            July 2018

   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.

1.  Introduction

   DNS-Based Service Discovery [RFC6763] is a component of Zero
   Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap].

   DNS-Based Service Discovery (DNS-SD) allows services to advertise the
   fact that they provide service, and to provide the information
   required to access that service.  Clients can then discover the set
   of services of a particular type that are available.  They can then
   select a service from among those that are available and obtain the
   information required to use it.

   The DNS-SD Service Registration protocol, described in this document,
   provides a reasonably secure mechanism for publishing this
   information: what services are offered, and how to use them.  Once
   published, these services can be readily discovered by clients using
   standard DNS lookups.

   In the DNS-Based Service Discovery specification [RFC6763] Section 10
   "Populating the DNS with Information" briefly discusses ways that
   services can publish their information in the DNS namespace.  In the
   case of Multicast DNS [RFC6762], allows clients to directly query
   services on the local link for names in the ".local" namespace.

   RFC6763 also allows clients to discover services using the DNS
   protocol [RFC1035]; this is done either by having a system
   administrator manually configure service information in the DNS, or
   by using a Discovery Proxy [I-D.ietf-dnssd-hybrid], which performs
   mDNS queries on behalf clients issuing queries using DNS.  This
   eliminats the "link local" limitation of mDNS, but provides no
   additional security, and still relies on multicast.

   Manual configuration of DNS servers is costly and failure-prone, and
   requires a knowledgable network administrator.  Consequently,
   although all DNS-SD implementations of which we are aware support it,
   it is much less frequently used than mDNS.  This document describes a
   solution: a way to provide DNS-SD using DNS that can be as automatic
   as multicast DNS, but with better performance, scalability and

Cheshire & Lemon         Expires January 3, 2019                [Page 2]
Internet-Draft        Service Registration Protocol            July 2018

2.  Service Registration Protocol

   Services using the DNS-SD Service Registration Protocol use DNS
   Update [RFC2136] [RFC3007] to publish service information in the DNS.
Show full document text