<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-lemon-stateful-dnssd-00" ipr="trust200902"
     obsoletes="" updates="">
  <front>
    <title abbrev="Special-Use Names Problem">Stateful Multi-Link DNS Service Discovery</title>

    <author fullname="Ted Lemon" initials="T" surname="Lemon">
      <organization>Nominum, Inc.</organization>

      <address>
        <postal>
          <street>800 Bridge Parkway</street>

          <city>Redwood City</city>

          <region>California</region>

          <country>United States of America</country>

          <code>94065</code>
        </postal>

        <phone>+1 650 381 6000</phone>

        <email>ted.lemon@nominum.com</email>
      </address>
    </author>

    <date day="31" month="October" year="2016"/>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes a way of doing DNS service discovery using DNS updates <xref
      target="RFC2136"/> rather than Multicast DNS<xref target="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 <xref target="RFC2931"/> when issuing DNS updates, using the published
      key.</t>

      <t>
	Advantages of this proposal over the Multicast DNS Hybrid proposal <xref
	target="I-D.ietf-dnssd-hybrid"/> are:
	<list style="symbols">
	  <t>Service advertisement does not require multicast.</t>
	  <t>Names are stored in DNS zone databases, and therefore can be published using
	  standard DNS protocol features such as zone transfers.</t>
	  <t>Names can be defended by services that register them, so that it is difficult for
	  an attacker to spoof an existing service.</t>
	</list>
      </t>

      <t>
	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 new update mechanism.  Because this approach maintains state, and
	that state must include existing services that only support advertising via Multicast DNS,
	additional complexity is required to avoid retaining stale information; this complexity is
	not required for the stateless model proposed in the mDNS hybrid specification.
      </t>

      <t>
	Another disadvantage of this approach is that it requires a stable naming infrastructure,
	and requires forwarders on each local link.
      </t>

      <t>
	Some sites may find it preferable to rely on the stateless model for this reason.
	However, the stateful model provides sufficient advantages that it will make sense for
	some sites to implement it, even in the legacy mode that still supports service
	discovery using Multicast DNS.
      </t>
    </section>
    
    <section title="Terminology">
      <t>For the sake of brevity this document uses a number of abbreviations.
      These are expanded here: <list style="hanging">
          <t hangText="mDNS">Multicast DNS</t>
          <t hangText="ML-DNSSD">Multi-Link DNS Service Discovery</t>
        </list></t>
    </section>

    <section title="Overview">
      <t>Stateful Multi-Link DNS service discovery attempts to provide stateful service that is
      otherwise equivalent to Hybrid Unicast/Multicast DNS-Based Service Discovery, except that
      where possible multicast is avoided, and DNS zones are maintained such that full interoperation
      with the DNS is possible.</t>

      <t>In order to accomplish this, service providers detect whether the local network supports
      stateful operation.   If not, they simply provide service using mDNS as before.   If so, they
      advertise services solely using DNS updates.</t>

      <t>The DNS infrastructure is prepared to take DNS updates from devices on served networks;
      each unique link has a DNS forwarder that can detect that a packet originated locally and
      was not forwarded; this serves as validation that the service can be advertised.</t>

      <t>Legacy services are supported using the same query process used in the hybrid model.
      Unlike with the hybrid model, however, discovered services are added to DNS zones.</t>

      <t>As with the Hybrid model, services are discovered using unicast DNS.  Multicast DNS
      service discovery is not usable on networks offering stateful multi-link DNS service
      discovery.</t>
    </section>

    <section title="Service Behavior">
      <t>Hosts offering services using DNS service discovery must advertise these services.
      When a host offering services is connected to a network that does not offer stateful
      ML-DNSSD, it offers service discovery using Multicast DNS.   When stateful ML-DNSSD is offered,
      the host does not offer service discovery using Multicast DNS.</t>
      <section title="Detecting Stateful ML-DNSSD">
	<t>In order to detect the presence of stateful ML-DNSSD, the host first performs
	registration domain discovery as in section 11 of <xref target="RFC6763"/> to
	acquire the name of the recommended default domain for registering services.
	If this process fails, Stateful ML-DNSSD is not present.   If the process succeeds,
	the host looks for a PTR record using the well-known name "_mldnssd.&lt;domain&gt;".
	If a PTR record is present, stateful ML-DNSSD is present.</t>
	
	<t>Whenever a host detects a change to the link, a change to the IP addresses of
	the DNS resolvers provided on the link, or a change to the set of prefixes available
	on the link, the host re-tries the ML-DNSSD detection process.</t>
      </section>

      <section title="Publishing Services when Stateful ML-DNSSD is present">
	<t>When stateful ML-DNSSD is present, a host adds its own information into the
	DNS.   This information is added into three separate domains, as described in
	<xref target="I-D.ietf-dnssd-hybrid"/>, section 4.   The subdomain for
	services and the subdomain for names are a single subdomain, the recommended
	default domain for registering services.   The IPv4 and IPv6 reverse-mapping zones
	are discovered by querying the well-known names "_inaddr_zone.&lt;domain&gt;" and
	"_ipv6_zone.&lt;domain&gt;" for PTR records.   Each PTR record points to a specific
	zone to which updates are sent for IPv4 and IPv6 PTR records.</t>

	<t>When a host that offers service first starts, it generates a key that is used
	to authenticate its DNS updates.   This key is included whenever updating the
	service's name.</t>

	<t>There are four domain names that are updated when a service advertises itself:
	the human-readable name, the machine-readable name, the service entry or entries, and
	the resverse-mapping pointers.  The update proceeds by first adding or updating the
	machine-readable name, then adding a PTR record from the human-readable name to the
	machine-readable name, then adding the reverse-mapping pointers, then adding the
	service.   All updates are signed using SIG(0), authenticated with the private half
	of the host's key.</t>
	
	<t>To add the machine-readable name, the host creates a DNS update that adds its
	name.   The update is predicated on the nonexistence of the name.   The update includes
	A and AAAA records for all of the hosts IP addresses except its link-local addresses.
	If this update succeeds, the machine-readable name has been added.</t>

	<t>The update can fail for one of two reasons: either the signature was invalid, or
	the name already exists.   In the former case, there is a bug, and the host should
	revert to providing service using mDNS.</t>
	
	<t>Otherwise, if the update fails, the name already exists.  The host creates a new
	update that deletes any A and AAAA RRsets and adds A and AAAA as before.  There is no
	predicate for this update because the server should reject it if the name belongs to
	some other host (that is, has a different key).   If this update fails, the host
	chooses a new machine-readable name and restarts the process.</t>

	<t>The host then creates a PTR record under "Human Readable Name.&lt;domain&gt;" pointing
	to the machine-readable name.   If this fails, the host must choose a different name
	and attempt to add it, until successful.</t>

	<t>The host now creates updates for the reverse-mapping name of every IPv4 address it
	has that is not a link-local address, and adds a PTR record for each, pointing back at
	the machine-readable name.  These adds should not fail.   The process is repeated for
	every IPv6 address that is not link-local.</t>

	<t>Finally, the host updates the well-known name for its service or services, adding an
	entry for each one.   These names may already have SRV RRtypes, so this update must
	add records.</t>

	<t>TODO: consider whether this is really the right way to do this--it's really complicated,
	and might be better done as a single HTTP request.</t>

      </section>
      <section title="Maintenance">
	<t>Whenever the host adds its service to the DNS, it queries the machine-readable name
	to see what the TTL is.   When 80% of that TTL has expired, the host refreshes all of its
	records.   This prevents the records from being cleaned up by the DNS server as stale.</t>

	<t>If the host is being shut down cleanly, it may remove all names and SRV records that it
	has added, or may remove all SRV records, leaving everything else intact in order to reserve
	the name.   In most cases, it is better to leave the name.</t>
      </section>
    </section>

    <section title="Discovery">
      <t>Service Discovery is done as per RFC 6763.   Service discovery defaults to '.local',
      which is resolved using mDNS.   If ML-DNSSD is present in any form, hosts doing service
      discovery should successfully discover this following the method described in RFC 6763.
      The service appears to the host doing service discovery the same way whether the hybrid
      model or the stateful model is being used.   Hosts do not do mDNS if ML-DNSSD is present.</t>

      <t>In order to support progressive queries in situations where legacy service discovery
      is in operation, hosts should use DNS push <xref target="I-D.ietf-dnssd-push"/>.</t>
    </section>

    <section title="DNS Service Infrastructure">
      <t>
	Updates are sent to a forwarder on the local link.   The forwarder uses neighbor discovery
	or ARP to validate each of the IP addresses presented in an A or AAAA record.   Updates
	that do not come from local hosts are silently discarded.   Other updates are forwarded
	to the primary name server without changes.
      </t>
      <t>
	The primary server validates all updates by using the key stored on the machine-readable
	name to which the update points.  If the update is an update of the machine-readable
	name, the update is validated based on the key stored at that name, if any, or else
	using the key contained in the update.
      </t>
      <t>
	Any number of secondaries may be configured.   Secondaries may also serve as forwarders
	if appropriate.
      </t>
    </section>

    <section title="Legacy Service Discovery">
      <t>
	Service discovery done as in mdns-hybrid, except that state is retained.  State is
	periodically probed; stale state is discarded.  Discovery service listens for initial
	service announcements.
      </t>
    </section>

    <section title="Security Considerations">
      <t>
	Any host on a network on which service discovery is supported can advertise services,
	which might be spoofed so as to capture private information.   One solution to this is
	to only accept updates from designated infrastructure networks, so that networks to which
	regular users connect are not permitted to advertise services.   This will, however, limit
	the usefulness of various services which may be present on user devices.
      </t>
      <t>
	It may be possible to only allow anonymous pairing <xref
	target="I-D.ietf-dnssd-pairing"/> on public-facing networks, so that infrastructure
	services cannot be advertised, but users can still rendezvous.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2136" ?>
      <?rfc include="reference.RFC.2931" ?>

      <?rfc include="reference.RFC.6762" ?>

      <?rfc include="reference.RFC.6763" ?>

      <?rfc include="reference.I-D.ietf-dnssd-pairing" ?>
      <?rfc include="reference.I-D.ietf-dnssd-hybrid" ?>
      <?rfc include="reference.I-D.ietf-dnssd-push" ?>
    </references>
  </back>
</rfc>
