Internet DRAFT - draft-cao-lwig-dns-serv-simp
draft-cao-lwig-dns-serv-simp
Internet Engineering Task Force Z. Cao
Internet-Draft F. Cao
Intended status: Informational China Mobile
Expires: September 6, 2012 YC. Ma
Hitachi (China) Research and
Development Corporation
H. Tian
China Academy of
Telecommunications Research
March 5, 2012
Lightweight Service Simplification via DNS
draft-cao-lwig-dns-serv-simp-00
Abstract
This memo discusses a lightweight service simplification method via
DNS. Instead of storing the information on the Web infrastructure,
the service provider can store them on the DNS servers. By
expressing these information in the DNS Resource Records, the
requester can get these information directly during the DNS name
resolution, without the need of accessing any web resource. This way
eliminates the overhead caused by TCP handshake and HTTP get/
response, and can be served as a lightweight information provisioning
method.
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 September 6, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cao, et al. Expires September 6, 2012 [Page 1]
Internet-Draft Lightweight DNS March 2012
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Cao, et al. Expires September 6, 2012 [Page 2]
Internet-Draft Lightweight DNS March 2012
1. Introduction
It is normal to provide information service via Web. But in some
scenarios where light-weight services are provided, information
provisioning via Web is not economic. Before accessing the first
HTTP request , the client needs to inquiry the DNS, and finish TCP
3-way handshake. If the client only needs to know some simple
information, e.g., the temperature or humidity, the overhead of
getting these information is considerable higher.
This memo discusses a lightweight information provision method via
DNS. Instead of storing the information on the Web infrastructure,
the service provider can store them on the DNS servers. By
expressing these information in the DNS Resource Records, the
requester can get these information directly during the DNS name
resolution, without the need to accessing any web resource. This way
eliminates the overhead caused by TCP handshake and HTTP get/
response, and can be served as a lightweight information provisioning
method.
Note: this draft contains the initial idea of light-weight service
simplification. The authors would improve the description and design
considerations in later revisions.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Solution Overview
We give a simple example in this section. As shown in Figure 1, the
user would like to know the temperature of a certain location,
denoted by its FQDN "_temp.locA.example.com". It sends a DNS query
request to the local DNS server, the local DNS does not have the
cached information, and will contact the authorized DNS server which
is actually maintained by the information providers.
There are some considerations in this mechanism.
1. Information expression. How to organize the name space? The
provider should organize the content in a way that is compatible
with the DNS name space. That is, the specific information
semantic is encoded into the FQDN. In the example the
temperature is denoted as _temp.*. And the hierarchical name
space also contains the parent domain information which is
Cao, et al. Expires September 6, 2012 [Page 3]
Internet-Draft Lightweight DNS March 2012
organized in a way that the provider organized its content on the
server.
2. Information storage. How to store the information on the DNS
server? DNS TXT RR [RFC1035] can be used to store the
information. The DNS TXT RR can be organized as TLV so that
different types of information can be stored in the DNS servers.
3. Information request and response. How the user access the
information. The user can use the DNS SRV [RFC2782] query to
access the stored information on the server. And the TXT RR will
be returned in the response message.
4. Information Update. The user could also send DNS update requests
to the authority DNS servers. The DNS dynamic updates [RFC2136]
can be used for information update.
User Local DNS Authority DNS Server
| SRV Query | |
| _temp.locA.example.com | recursive resolution |
|--------------------------->|-------------------------->|
| Query Result | Query Result |
|<---------------------------|<--------------------------|
| | |
Figure 1: An Example of Information Retrieval
If the user is a sensor and would update some resource records on the
DNS server, it should send DNS update messages per [RFC2136] to the
authority DNS server to update the corresponding resource records.
This process is depicted in Figure 2.
User Local DNS Authority DNS Server
| SRV Update | |
| _temp.locA.example.com | recursive resolution |
|--------------------------->|-------------------------->|
| Update Result | Update Result |
|<---------------------------|<--------------------------|
| | |
Figure 2: An Exmaple of Information Update
Note: All the above figures assumes that the local DNS has cached the
address of the authority DNS server. If that's not the case, the
local DNS resolver will consult the root servers for reference. This
also indicates that the cache behavior the upper layer domain names
will influence the information retrieval efficiency.
Cao, et al. Expires September 6, 2012 [Page 4]
Internet-Draft Lightweight DNS March 2012
The CoAP can also be used by the sensors to update the resource
records on the DNS server. In such case, the DNS server should
implement CoAP agent. The CoAP agent should have the rights to
update the DNS record with some specific FQDN, for example, FQDNs
with "_temp" prefix.
3. DNS Considerations
In order to use the DNS resolution process for service
simplification, many aspects such as TTL, cache, authorized server
placement should be considered.
1. The TTL of DNS resource records. The TTL value of the DNS RR
stands for its lifetime, and hence influences the cache behavior
of the local DNS resolver. For high real-time requirement
applications, the TTL should be set to minimal value zero. For
time tolerant applications, the TTL could be set to values
greater than zero. For non-zero TTL values, the local DNS
funtionally acts as the information cache.
2. The placement of the authority DNS server. The authority DNS
server for a certain sub-domain should be controlled by the
information provider, such as the scenario mentioned in
[I-D.vanderstok-core-bc]. The granularity of the sub-domain
separation ought to be determined by the provider. Either it
could be an authority server controlling the *.example.com sub-
domain, or in a denser deployement, an authority server
controlling the *.locA.example.com.
4. IANA Considerations
None.
5. Security Considerations
The proposal in this document should be compatible with DNSSEC.
6. References
6.1. Normative References
[I-D.ietf-core-coap]
Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
"Constrained Application Protocol (CoAP)",
Cao, et al. Expires September 6, 2012 [Page 5]
Internet-Draft Lightweight DNS March 2012
draft-ietf-core-coap-08 (work in progress), October 2011.
[I-D.vanderstok-core-bc]
Stok, P. and K. Lynn, "CoAP Utilization for Building
Control", draft-vanderstok-core-bc-05 (work in progress),
October 2011.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Zhen Cao
China Mobile
Xuanwumenxi Ave. No.32
China, Beijing 100053
China
Phone:
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Feng Cao
China Mobile
CA
USA
Phone:
Fax:
Email: fengcao@chinamobile.com
URI:
Cao, et al. Expires September 6, 2012 [Page 6]
Internet-Draft Lightweight DNS March 2012
Yuanchen Ma
Hitachi (China) Research and Development Corporation
301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District
China, Beijing 100190
China
Phone:
Email: ycma@hitachi.cn
Hui Tian
China Academy of Telecommunications Research
Huayuanbeilu No.52
Beijing, 100191
China
Phone:
Fax:
Email: tianhui@mail.ritt.com.cn
URI:
Cao, et al. Expires September 6, 2012 [Page 7]
