Stateful Multi-Link DNS Service Discovery
draft-lemon-stateful-dnssd-00

Document Type Active Internet-Draft (individual)
Last updated 2016-10-31
Stream (None)
Intended RFC status (None)
Formats plain text xml 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)
Network Working Group                                           T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Informational                          October 31, 2016
Expires: May 4, 2017

               Stateful Multi-Link DNS Service Discovery
                     draft-lemon-stateful-dnssd-00

Abstract

   This document proposes a stateful model for automating Multi-Link DNS
   Service Discovery, as an extension to the existing solution, which
   relies entirely on multicast DNS for discovering services, and does
   not formally maintain DNS zone state.  When fully deployed this will
   confer several advantages: the ability to do DNS zone transfers,
   integrating with existing DNS infrastructure; the elimination of the
   need for regular multicast queries; and the ability for services to
   securely register and defend their names, preventing malicious
   spoofing of services on the network.

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 May 4, 2017.

Copyright Notice

   Copyright (c) 2016 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
   carefully, as they describe your rights and restrictions with respect

Lemon                      Expires May 4, 2017                  [Page 1]
Internet-Draft          Special-Use Names Problem           October 2016

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Service Behavior  . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Detecting Stateful ML-DNSSD . . . . . . . . . . . . . . .   4
     4.2.  Publishing Services when Stateful ML-DNSSD is present . .   4
     4.3.  Maintenance . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  DNS Service Infrastructure  . . . . . . . . . . . . . . . . .   6
   7.  Legacy Service Discovery  . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   This document describes a way of doing DNS service discovery using
   DNS updates [RFC2136] rather than Multicast DNS[RFC6762].  Update
   validation is done on the same basis as Multicast DNS validation: the
   assumption is that a device connected to a local link is permitted to
   advertise services.  However, in contrast to mDNS, which provides no
   mechanism for defending claims made by services, we propose that
   services should publish keys when initially registering names, and
   use SIG(0) authentication [RFC2931] when issuing DNS updates, using
   the published key.

   Advantages of this proposal over the Multicast DNS Hybrid proposal
   [I-D.ietf-dnssd-hybrid] are:

   o  Service advertisement does not require multicast.

   o  Names are stored in DNS zone databases, and therefore can be
      published using standard DNS protocol features such as zone
      transfers.

   o  Names can be defended by services that register them, so that it
      is difficult for an attacker to spoof an existing service.

   There are, however, disadvantages to this approach.  The first
   disadvantage is that this proposal does not actually eliminate
   multicast except in the case that all local services implement the

Lemon                      Expires May 4, 2017                  [Page 2]
Show full document text