Internet DRAFT - draft-aggarwal-dnssd-optimize-query

draft-aggarwal-dnssd-optimize-query







Internet Engineering Task Force                              A. Aggarwal
Internet-Draft                                            Qualcomm (QCE)
Intended status: Standards Track                           July 01, 2014
Expires: January 2, 2015


               Optimizing DNS-SD query using TXT records
                 draft-aggarwal-dnssd-optimize-query-00

Abstract

   DNS-SD allows a client to find a list of named instances of a service
   name over a particular transport within a domain of interest using
   standard DNS queries.  As the number of potential responders
   increases, DNS-SD based discovery doesn't scale well.  To mitigate
   the scaling issues, schemes to narrow down the search context would
   be needed.  The document proposes to include key/value pairs in the
   form of a DNS TXT record along with the service name in the DNS query
   to assist with the discovery process.  The DNS TXT record can be
   placed in the additional section of the query without requiring any
   changes to the structure of DNS messages.

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 2, 2015.

Copyright Notice

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



Aggarwal                 Expires January 2, 2015                [Page 1]

Internet-Draft  Optimizing DNS-SD query using TXT records      July 2014


   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.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Proposed Changes  . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Realization of the proposal . . . . . . . . . . . . . . . . .   4
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   5
   6.  API Considerations  . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   DNS-SD [RFC6763] in combination with mDNS [RFC6762] provide a
   discovery framework for service names registered with IANA over a
   local link.  The objective of DNS-SD was to discover service
   instances that implement a given service.  The use of mDNS scales
   well when the number of service instances that implement a given
   service are limited in number on the local link.  However, when the
   number of wireless devices (e.g., Wi-Fi) approach hundreds of devices
   in a typical link, several service instances may respond when a DNS-
   SD query is issued for a given service name.  The number of wireless
   devices is slated to grow further as more devices (things) are
   deployed as part of the Internet of Things (IoT) era.

   At the same time, the DNS-SD protocol also enables discovery in
   various operating environments that rely on unicast DNS.  Being able
   to narrow down the search context beyond the service name scope will
   be even more critical for such DNS-SD based discovery schemes to
   scale.

   This contribution proposes one such solution.

   This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values.






Aggarwal                 Expires January 2, 2015                [Page 2]

Internet-Draft  Optimizing DNS-SD query using TXT records      July 2014


1.1.  Sample Use Cases

   Some sample use cases that might experience scaling problems are
   mentioned below:

   o  A client application is looking to find color printers on the
      local network

   o  A lighting application needs to discover lighting fixtures or
      bulbs from a given manufacturer before establishing a session with
      each device to control the fixtures

2.  Background

   There are two potential mechanisms that can help a DNS-SD querier
   narrow down the answers of interest within the scope of DNS-SD
   [RFC6763]:

   o  Placing TXT records in the response: DNS has an efficiency feature
      whereby a DNS server may place additional records in the
      additional section of the DNS message.  These additional records
      are records that the client did not explicitly request, but the
      server has reasonable grounds to expect that the client might
      request them shortly, so including them can save the client from
      having to issue additional queries.  DNS-SD clarifies that the
      intention of DNS-SD TXT records is to convey a small amount of
      useful additional information about a service.  Ideally, it should
      not be necessary for a client to retrieve this additional
      information before it can usefully establish a connection to the
      service.  For a well-designed application protocol, even if there
      is no information at all in the TXT record, it should be possible,
      knowing only the host name, port number, and protocol being used,
      to communicate with that listening process and then perform
      version- or feature-negotiation to determine any further options
      or capabilities of the service instance.

   o  Using subtype as part of the question: DNS-SD allows a querier to
      send a subtype along with the service name.  It does require that
      the subtype be 63 octets or fewer.  DNS-SD RFC further clarifies
      that these should be documented in the protocol specification in
      question and/or in the "notes" field of the registration request
      sent to IANA.

   It can be argued that mechanisms in place to narrow down the search
   beyond the service name are not very flexible.  While nothing
   prevents an application implementing DNS-SD to eventually find the
   service instance of interest, it results in unnecessary traffic and
   delay.  The proposal is to enable a richer search query mechanism by



Aggarwal                 Expires January 2, 2015                [Page 3]

Internet-Draft  Optimizing DNS-SD query using TXT records      July 2014


   explicitly adding key/value pairs in the query to avoid having to
   establish sessions with all services that match the service name in
   the question.  Since DNS-SD allows a responder to include TXT records
   in the additional section with key-value pairs that it thinks the
   client may request, session establishment with the responder can be
   avoided if the desired key/value pairs (from the client's
   perspective) were included in the response.

3.  Proposed Changes

   DNS-SD as defined in [RFC6763]  uses DNS TXT records to store
   arbitrary key/value pairs conveying additional information about the
   named service.  Each key/value pair is encoded as its own constituent
   string within the DNS TXT record, in the form "key=value" (without
   the quotation marks).  The proposal is for the client to be able to
   query for key/value pairs along with the service name.  The DNS TXT
   record in the additional section of the query serves to send this
   additional information.  Since DNS messages are allowed to have an
   additional section, this proposal doesn't require any changes to the
   structure of DNS messages.

   DNS TXT record is allowed to have multiple key/value pairs.  If
   multiple keys are present in a given TXT record, they are AND'ed and
   the responder must match all the keys in the TXT record.  At the same
   time, DNS query could include more than one TXT record analogous to
   multiple TXT records in the response.  If multiple TXT records are
   present in the query, they are logically OR'ed while the keys of each
   TXT record are AND'ed as stated above.

4.  Realization of the proposal

   Actual key/value pairs that can be sent are specified within the
   application protocol specification.  Some examples to aid in the
   understanding of the proposal are mentioned below.  They correspond
   to the use cases introduced earlier e.g.

   o  A client application looking for color printer can add color=true
      in the DNS TXT record as part of the additional section of the
      query

   o  A lighting application looking to discover bulbs by a certain
      manufacturer (such as Philips), can add the DNS TXT record in the
      additional section of the query with manuf=Philips

   o  The discovery scope can be further constrained by defining
      additional keys within the service protocol specification.  By
      augmenting the query with additional context, the spurious traffic




Aggarwal                 Expires January 2, 2015                [Page 4]

Internet-Draft  Optimizing DNS-SD query using TXT records      July 2014


      and additional delay in finding the service instance of interest
      is reduced.

5.  Deployment Considerations

   An important deployment consideration is to analyze the behavior of
   an existing mDNS responder and unicast DNS to the receipt of DNS-SD
   query with a service name in the question section and TXT records in
   the additional section.  If mDNS responder doesn't recognize TXT
   records, no filtering would occur and a response will be sent only if
   there is a match for the service name.

   Regarding the behavior of unicast DNS when the standard query carries
   TXT records in the additional section, the DNS will respond strictly
   based on the service name in the question without any filtering based
   on the TXT records.  DNS will issue a negative response unless there
   is a record matching the question.  In summary, unicast DNS will
   continue to serve DNS queries that include TXT records in the
   additional section.

6.  API Considerations

   Several high level operating systems (Android, iOS) provide service
   discovery APIs.  For the proposed enhancement to be realized, service
   registration should allow for service specific key/value pairs to be
   registered.  This capability should already exist since it is allowed
   as per the current DNS-SD specification.  The additional impact would
   be for the client application to be able to query for specific key/
   value pairs along with the service name over a specific transport.

7.  Security Considerations

   The additional data (key/value pairs signifying the search context)
   beyond the service name in the DNS-SD query inherently reveals more
   information about what the client is searching for.  DNS and mDNS
   today do not provide confidentiality, so observers already have
   access to potentially sensitive information such as what names one is
   requesting; addressing this issue is outside the scope of this
   extension.  Even if confidentiality were to be solved, this extension
   still provides more information to the actual DNS/mDNS responders
   themselves.  A client concerned about such information disclosure can
   simply choose not to use this extension for such queries, and thus
   trade off efficiency for privacy.








Aggarwal                 Expires January 2, 2015                [Page 5]

Internet-Draft  Optimizing DNS-SD query using TXT records      July 2014


8.  IANA Considerations

   This memo includes no request to IANA.

9.  Acknowledgements

   Thanks to Dave Thaler for helping develop this idea and formalizing
   as a contribution for DNS-SD enhancements.

10.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              December 2012.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, December 2012.

Author's Address

   Ashutosh Aggarwal
   Qualcomm (QCE)
   5775 Morehouse Dr
   San Diego , California  92121
   USA

   Phone: +1 858 658 2229
   Email: aggarwal@qce.qualcomm.com


















Aggarwal                 Expires January 2, 2015                [Page 6]