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]
