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]