[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                                 T. Lemon
Internet-Draft                                         邓 乔宇 (J. Deng)
Intended status: Standards Track                              Apple Inc.
Expires: 27 January 2022                                    26 July 2021


 Permissionless Advertising and Discovery of DNS-SD Authoritative Zones
                   draft-tljd-dnssd-zone-discover-00

Abstract

   This document describes how to make DNS-SD browsing domains available
   for browsing and discovery without requiring special cooperation from
   the network infrastructure.  Zones made available in this way are
   browsed using DNS or DNS Push.  The mechanism for advertising them is
   Multicast DNS (mDNS).  This allows DNS-SD browsers to benefit from
   the permissionless aspects of mDNS without relying on mDNS for all
   queries, which improves scalability and reliability in applications
   where many services may be advertised.

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 https://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 27 January 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Lemon & Deng             Expires 27 January 2022                [Page 1]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


   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
   2.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Data Model  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Authority Datasets  . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Multicast DNS . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  Authoritative DNS . . . . . . . . . . . . . . . . . .   4
       3.1.3.  SRP Replication . . . . . . . . . . . . . . . . . . .   5
     3.2.  DNSSD Browsing Domains  . . . . . . . . . . . . . . . . .   5
   4.  Advertising an Authority Dataset to be Used for Service
           Discovery . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Choosing a Domain to Advertise  . . . . . . . . . . . . .   6
     4.2.  Advertising DNS Authoritative Service for a Domain using
           multicast DNS . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Advertising Address information for an Authority  . . . .   8
     4.4.  Advertising the Availability of Service Discovery for a
           Domain  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Discovering Authority Datasets  . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   DNS-SD currently provides permissionless advertising and discovery
   using multicast DNS [RFC6762].  Unfortunately, multicast DNS has some
   limitations.  In addition to the obvious limitation that it only
   works between services and users that are connected to a single
   multicast domain (generally a single link), in many situations
   excessive use of multicast is unreliable, which can cause discovery
   to fail when a service is actually present.










Lemon & Deng             Expires 27 January 2022                [Page 2]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


   By contrast, DNS service discovery using unicast traffic is not
   limited by the scope of reachability of link-local multicast.  On
   networks where multicast is less reliable, or more costly, unicast
   DNS-SD is clearly advantageous.  However, because of the hierarchical
   nature of DNS, existing solutions for providing unicast DNS rely on
   coordination with the network infrastructure.  In many settings,
   particularly on home networks, this coordination is not available,
   and so we must fall back on multicast DNS, despite its limitations.

   This document defines a new mechanism for discovering the
   availability of unicast DNS service discovery using multicast DNS.
   Although somewhat limited in the sense that this mechanism still
   relies on multicast DNS as a means of discovering the unicast
   service, this mechanism can substantially reduce reliance on
   multicast DNS, so that its limitations are minimized.  Additionally,
   it makes it possible for devices that provide discovery to adjacent
   networks, such as stub networks, to overcome the limitations of link-
   local multicast for this application.

   This document describes how to advertise and discover authoritative
   service for a DNS domain, and how to advertise the availability of
   service discovery for a DNS domain, using multicast DNS.

2.  Glossary

   Advertiser  a service that is advertising its availability through
      some authority

   Authority  a device, connected to an infrastructure link, that is
      advertising service discovery for an authority dataset using mDNS.

   Authority Dataset  a collection of authoritative data to be
      advertised, and which can be treated as a single coherent set.
      More than one authority may advertise the same dataset; what makes
      it "the same dataset" is the expectation that whichever authority
      is asked for an answer to a particular question will generally
      give the same answer as any other authority.

   DNSSD Browser  a device, connected to an infrastructure link, that
      discovers authorities and uses them to discover services
      advertised by advertisers.










Lemon & Deng             Expires 27 January 2022                [Page 3]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


3.  Data Model

   The goal of the mechanism described in this document is to enable
   permissionless advertising and discovery of authoritative DNS servers
   that can be used for service discovery.  From the perspective of a
   consumer of such a service on a particular IP link, there may be more
   than one such service.  Each such service can be thought of as
   providing an authority dataset.

3.1.  Authority Datasets

3.1.1.  Multicast DNS

   One example of an authority dataset is the set of services that can
   be discovered by a DNSSD Discovery Proxy [RFCxxx].  A discovery proxy
   acts as an authoritative DNS server mapping information advertised
   using multicast DNS on a particular link to a DNS zone.

   There may be more than one discovery proxy for a particular multicast
   DNS link.  If so, both discovery proxies can be expected to return
   the same answers to any questions asked by a DNS-SD client that is
   browsing for services within that zone.  This is what is meant by an
   "authority dataset": the data returned by one authoritative server
   that answers for that dataset should be the same as the data returned
   by the other server.

   Because of the dynamic nature of mDNS, there is no enforcement
   mechanism to ensure that two discovery proxies would answer the same
   DNS question in exactly the same way, but each server is functionally
   equivalent: there is no reason to prefer one server over the other,
   nor to query both servers to avoid missing data known to one but not
   the other.

3.1.2.  Authoritative DNS

   Another example of an authority dataset is an authoritative DNS
   server that maintains a DNS zone for DNS Service Discovery using the
   DNS-SD Service Registration Protocol.  In this case, there is one
   primary authoritative server and, potentially, more than one
   secondary authoritative server.  The secondary server databases are
   all dependent on the primary server's database, and are maintained
   using DNS zone transfers or some other hierarchical replication
   mechanism.

   In this case, the primary and the secondary servers are all serving
   an authoritative zone, which is another example of an authority
   dataset.  The authoritative zone may have different versions, which
   can be known using the zone serial number, but in principle each



Lemon & Deng             Expires 27 January 2022                [Page 4]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


   authoritative server is equivalently valid: there is no reason to
   prefer one over the other.  This is another example of an authority
   dataset.

3.1.3.  SRP Replication

   A third example of an authority dataset would be a set of one or more
   SRP servers that cooperate to maintain a common database using the
   SRP replication protocol [SRP Replication].  These servers are each
   authoritative DNS servers, in the sense that they answer
   authoritatively for questions within the DNS zone that they manage,
   but unlike a typical DNS authoritative service configuration, there
   is no hierarchy-no server is primary-and there are no discrete
   versions of the zone database, so there is no way to generate a
   meaningful serial number that could be used to manage zone transfers.

   As with Discovery Proxies, although it's quite possible at any given
   moment in time that the same query to two different SRP replication
   peers will yield different answers, the dataset being managed by
   these servers is the same dataset, and therefore is also an authority
   dataset.

3.2.  DNSSD Browsing Domains

   Service discovery on a local link always implicitly includes one
   authority dataset: the set of all mDNS services advertised on that
   link.  DNSSD browsers always search for services within this dataset.
   Additional datasets are made available by advertising additional
   legacy browsing domains locally.  So each authority dataset other
   than the link-local authority dataset must be explicitly advertised
   using mDNS; when the DNSSD browser is asked to browse for local
   services without explicitly specifying a domain in which to browse,
   it attempts to discover that service in each of the authority
   datasets advertised locally for discovery, and also in the link-local
   dataset provided by mDNS.

   Note that DNSSD [RFC6763] also provides for discovering browsing
   domains using DNS, either using the domain name search list or using
   the DNS reverse domain query [RFC6763 section ???].  DNS browsing
   domains are provided by the network infrastructure, and complement
   browsing domains that may be provided permissionlessly using mDNS.

4.  Advertising an Authority Dataset to be Used for Service Discovery

   There are four steps an authority must follow to advertise the
   availability of an authority dataset for service discovery:

   *  Choose a domain to represent that authority dataset



Lemon & Deng             Expires 27 January 2022                [Page 5]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


   *  Advertise itself as an authority that provides name service for
      that domain (and hence that dataset)

   *  Advertise its address information

   *  Advertise the availability of service discovery for that domain

4.1.  Choosing a Domain to Advertise

   When advertising a domain for discovery, it must be the case that all
   authorities servers that advertise that domain are advertising the
   same information.  Thus, the domain being advertised can be treated
   as an identifier for a particular authority dataset.  How this is
   accomplished is out of scope for this document; one solution is
   described in [SRP Replication].

   Because the domain is being advertised using multicast DNS, we assume
   that there is no delegation in the global DNS; if there were, there
   would be no reason to advertise the domain using mDNS.  Furthermore,
   in order to prevent domain spoofing using the technique described
   here, the DNS resolver that is discovering this domain is required to
   prove that no delegation for the domain being advertised using mDNS
   exists in the global DNS hierarchy.

   Given that most stub resolvers at present do not support DNSSEC, the
   domain being advertised will have to be a subdomain of some domain
   that is known to be a locally-served domain [RFC6761?].  In this case
   the client can be sure that this domain never appears in the DNS by
   definition, rather than by validating the non-existence of the
   delegation.

   Two domains that are ideal for this purpose are 'home.arpa' [Dot
   Home] and 'service.arpa' [SRP].  The 'home.arpa' domain is generally
   intended for use in home networks, so this is appropriate for use in
   cases where the device advertising the domain is expected to be
   installed in a home network; for devices that are not expected to be
   installed in a home network, 'service.arpa' is preferable.

   Given that there is no way for a particular device to know for
   certain that the network setting in which it is installed is in fact
   'a home' or 'not a home,' this advice is merely a suggestion: a
   consumer product should probably use 'home.arpa' and a commercial
   product should probably use 'service.arpa', and perhaps either device
   should be configurable, but in practice it is not crucial to get this
   perfectly correct.






Lemon & Deng             Expires 27 January 2022                [Page 6]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


   Bearing in mind that there may be multiple authorities and multiple
   authority datasets being provided on the same infrastructure link, it
   is important to choose a domain that is not ambiguous.  Therefore,
   devices advertising domains for discovery MUST NOT use 'home.arpa' or
   'service.arpa' directly: when using these domains, a unique subdomain
   must be chosen below that domain, rather than using the root domain.

   It may be useful to identify the subdomain in terms of some visible
   network identifier.  For instance, if the authority dataset contains
   the set of services for a particular WiFi link, it might make sense
   to use the name 'SSID.wifi.home.arpa'.  This shows the SSID of the
   WiFi link, and differentiates between WiFi and other technologies
   (e.g.  Thread) that use something like an SSID.  For Thread networks,
   the domain 'thread.home.arpa' is used for this purpose, for example,
   and the thread network name is used as the leftmost label (e.g., 'my-
   home.thread.home.arpa.').

   We have stated that the domain must be provably nonexistent, which is
   a slight simplification.  For completeness, we will point out that if
   the delegation is secure, and the server being advertised is able to
   sign records such that they validate, this is also permissible.  But
   in this case, there's likely no utility to using mDNS to advertise
   the authoritative server and, furthermore, this solution requires the
   stub resolver to do DNSSEC validation, which is not commonly
   supported at present.

   Although '.local' is a locally-served domain, it is by definition
   served using multicast DNS.  For this reason, authorities MUST NOT
   use '.local' to advertise their authority dataset.

4.2.  Advertising DNS Authoritative Service for a Domain using multicast
      DNS

   To advertise DNS authoritative service for a domain, the
   authoritative server publishes an NS record for that domain using
   multicast DNS.  For example, to publish DNS service for
   example.thread.home.arpa., the NS record published with mDNS would
   be:

   example.thread.home.arpa.  IN NS thread-server-1.local

   Note that the DNS server for example.com has a .local suffix, meaning
   that its address can be discovered using mDNS.  This is not required.
   If the DNS server is in a domain that can be looked up using ordinary
   DNS service, multicast DNS service is not required.  This solution is
   preferred, but requires coordination with infrastructure, so doesn't
   address the core use case of this document.




Lemon & Deng             Expires 27 January 2022                [Page 7]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


   Before publishing its chosen domain, the authority MUST validate that
   no other authority is advertising that domain for a different
   authority dataset.  The mechanism for this validation is out of scope
   for this document, and is specific to the replication mechanism being
   used.  If no replication mechanism is being used, the authority MUST
   publish its NS record as a unique record.

4.3.  Advertising Address information for an Authority

   Address information for an authority may be advertised using DNS or
   mDNS.  If the authority happens to have a name published in the DNS,
   it SHOULD use that name, since it reduces reliance on multicast.  In
   most cases, this will not be possible, in which case the authority
   MUST advertise addresses that can be used to reach it using mDNS.

4.4.  Advertising the Availability of Service Discovery for a Domain

   In order for services within an authority dataset to be discovered by
   DNSSD browsers, the domain that identifies that authority dataset
   must be advertised as a domain in which discovery should be done.
   This is accomplished by advertising a PTR record in .local for the
   legacy browsing domain [RFC6763].  For example, if the domain being
   used is 'example.wifi.home.arpa.', then the PTR record would be as
   follows:

   lb._dns-sd._udp.local IN PTR example.wifi.home.arpa.

   When more than one authority is advertising discoverability for a
   particular authority dataset, there will be more than one of these
   records advertised, but this isn't a problem since they are not
   required to be unique.  This record should not be advertised until
   the authority has successfully generated or discovered a domain that
   is unique to the authority dataset being advertised.

5.  Discovering Authority Datasets

   A DNSSD browser discovers the set of datasets available locally by
   issuing an mDNS query for lb._dns-sd._udp.local.  This query will
   return zero or more PTR records.  As each PTR record is returned, it
   is compared against the existing set of legacy browsing domains that
   the DNSSD browser maintains.  If the target of the PTR record is not
   in this set, then it is checked for validity and, if valid, added to
   the set, and any ongoing browse operations begin to try to browse the
   new domain.

   A browsing domain discovered using mDNS can only be valid if one of
   the following is true:




Lemon & Deng             Expires 27 January 2022                [Page 8]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


   *  It is a subdomain of a domain that is defined to be a locally
      served domain [???]

   *  The DNSSD browser has found a secure denial of existence for the
      domain and validated it using DNSSEC

   *  The DNSSD browser has found a secure delegation for the domain (in
      which case it MUST validate answers in that domain using DNSSEC).

   In addition, a host on which a DNSSD browser is running may have
   discovered domains that would be considered valid because it is a
   locally-served domain, or because it can be proven not to exist in
   the DNS hierarchy, but for which authoritative service is already
   provided by the network infrastructure.  In this case, the DNSSD
   browser MUST consider the information provided in multicast DNS to be
   invalid, and MUST only use the service information provided by the
   network infrastructure for that domain.

   Examples of this would be a domain like 'home.arpa' that is served by
   the local infrastructure.  In this case, if for example the local
   infrastructure answers with NXDOMAIN for 'example.wifi.home.arpa.'
   then even if the browser is not able to validate this answer, is MUST
   treat the mDNS advertisement for this domain as valid, since
   otherwise the presence of the locally served domain would prevent
   discovery in mDNS-advertised subdomains even though there is no
   conflict.

   There are three types of browsing domains that might exist in the set
   of browsing domains maintained by the DNSSD browser.

   *  Link-Local: one for each network link to which the DNSSD browser
      is directly connected

   *  Infrastructure: browsing domains provided by the infrastructure

   *  Permissionless: browsing domains discovered using mDNS on local
      links

   [RFC6763] and [DNS Push] already describe how to manage link-local
   and infrastructure browsing domains.  Permissionless browsing domains
   are managed similarly.  Each such domain will have one or more name
   servers.  Each name server will, or will not, provide DNS Push
   service.  If one or more servers provide DNS Push service, then the
   DNSSD browser will, when browsing, attempt to connect to one of the
   DNS Push servers for that browsing domain, until a successful
   connection is established or failure is detected.  If failure is
   detected, or if there are no DNS Push servers, the DNSSD browser will
   use DNS datagrams [RFC1034] to browse that domain.



Lemon & Deng             Expires 27 January 2022                [Page 9]


Internet-Draft         DNS-SD Auth Zone Discovery              July 2021


6.  Security Considerations

   Multicast DNS provides no mechanism for trust establishment other
   than the common connection to a shared link.  DNSSD browsers are
   required to treat information about local authority datasets that are
   advertised using mDNS skeptically.  The requirement in section [???]
   to validate

7.  Informative References

Authors' Addresses

   Ted Lemon
   Apple Inc.
   One Apple Park Way
   Cupertino, California 95014
   United States of America

   Email: mellon@fugue.com


   Joey Deng
   Apple Inc.
   One Apple Park Way
   Cupertino, California 95014
   United States of America

   Email: deng.qiaoyu@gmail.com

   Additional contact information:

      邓乔宇
      Apple Inc.
      One Apple Park Way
      Cupertino, California 95014
      United States of America















Lemon & Deng             Expires 27 January 2022               [Page 10]