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]