Service Registration Protocol for DNS-Based Service Discovery
draft-sctl-service-registration-00

Document Type Active Internet-Draft (individual)
Last updated 2017-07-03
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
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, 2018                                   Nominum, Inc.
                                                            July 2, 2017

     Service Registration Protocol for DNS-Based Service Discovery
                   draft-sctl-service-registration-00

Abstract

   The DNS-SD Service Registration Protocol provides a way to perform
   DNS-Based Service Discovery using only unicast packets.  This
   eliminates the dependency on Multicast DNS as the foundation layer,
   which has worked well in some environments, like the simplest of home
   networks, but not in others, like large enterprise networks (where
   multicast does not scale well to thousands of devices) and mesh
   networks (where multicast and broadcast are supported poorly, if at
   all).  Broadly speaking, the DNS-SD Service Registration Protocol is
   DNS Update, with a few additions.

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 http://datatracker.ietf.org/drafts/current/.

   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, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

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

   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.

1.  Introduction

   DNS-Based Service Discovery [RFC6763] is a component of Zero
   Configuration Networking [RFC6760] [ZC] [Roadmap].

   There are two facets of DNS-Based Service Discovery to consider:
   how relevant information makes its way into the DNS namespace
   (how a server offers its services to interested clients) and how
   clients access that information (how an interested client discovers
   and uses a service instance).

   This document is concerned with the first of those two facets:
   how relevant information makes its way into the DNS namespace.

   In the DNS-Based Service Discovery specification [RFC6763] Section 10
   "Populating the DNS with Information" briefly discusses ways that
   relevant information can make its way into the DNS namespace.  In the
   case of Multicast DNS [RFC6762], the relevant information trivially
   becomes visible in the ".local" namespace by virtue of devices
   answering for themselves.  For unicast DNS names, ways that
   information makes its way into the DNS namespace include manual
   configuration of DNS zone files, possibly assisted using tools such
   as the "dns-sd -Z" command, automated tools such as a Discovery Proxy
   [DisProx], or explicit registration by the services themselves.  It
   is the last option -- explicit registration by the services
   themselves -- that is the subject of this document.

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

2.  Service Registration Protocol

   The DNS-SD Service Registration Protocol is largely built on DNS
   Update [RFC2136] [RFC3007], with some additions.

   When a device advertises services using Multicast DNS, the parent
   domain is implicitly ".local".

   When a device advertises services in the traditional unicast DNS
   namespace, it needs to know the parent domain name for its services.
   This parent domain can be manually configured by a human operator, or
   learned from the network.  In the DNS-SD specification [RFC6763]
Show full document text