Internet Draft Jaehoon Paul Jeong Jungsoo Park Hyoungjun Kim ETRI Expires: July 2004 9 February 2004 DNS Service for Mobile Ad Hoc Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies an architecture of DNS service system for mobile ad hoc network which might be connected to the Internet. The resolution of DNS names of mobile nodes within mobile ad hoc network is performed by multicast DNS and that of DNS names of nodes in the Internet is performed through DNS autoconfiguration of recursive DNS server. In the former, each mobile node plays a role of DNS name server for the DNS resource records associated with DNS name of which authority it has. The latter allows mobile node to receive the global Internet service, such as web service, by providing global DNS resolution in mobile ad hoc network connected to the Internet. These two kinds of DNS name resolution are processed automatically without the intervention of users in mobile ad hoc network. Also, this Jeong, et al. Expires - July 2004 [Page 1] Internet-Draft MANET DNS Service February 2004 document specifies how to authenticate DNS message as well as how to provide ad hoc users with service discovery based on multicast DNS. Conventions used in this document 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 [2]. Table of Contents 1. Terminology...................................................2 2. Introduction..................................................2 3. Overview......................................................3 4. DNS Operations in ANS System..................................5 4.1 ANS Responder.............................................5 4.2 ANS Resolver..............................................5 4.3 ANS API...................................................7 5. Generation of DNS Zone File...................................7 6. Service Discovery.............................................8 7. Global DNS Service in MANET connected to the Internet.........8 8. IPv6 Considerations...........................................8 9. Configuration Parameters......................................9 10. Security Considerations......................................9 10.1 Message Authentication through TSIG......................9 11. Copyright....................................................9 12. Normative References........................................10 13. Informative References......................................10 14. Authors' Addresses..........................................11 1. Terminology This document uses the terminology described in [3]. In addition, two new terms are defined below: Mobile Ad Hoc Network (MANET) The network where mobile nodes can communicate with one another without preexisting communication infrastructure, such as base station or access point. Ad Hoc Name Service System (ANS) The name service system that provides DNS name resolution and service discovery in MANET connected to the Internet. 2. Introduction Jeong, et al. Expires - July 2004 [Page 2] Internet-Draft MANET DNS Service February 2004 When mobile nodes want to communicate with one another in MANET environments such as battle field and public vehicle (e.g., airplane, bus and boat), they need to construct a temporary and infrastructureless network. Recently, according as the necessity of MANET increases, Ad Hoc routing protocols for multi-hop MANET have been being developed actively. Also, Ad Hoc multicast routing protocols as well as ad hoc unicast routing protocols have been being developed and implemented to provide mobile users in MANET with multicast service such as video conference and computer-supported collaborative work (CSCW). For the deployment of MANET technology, the global connectivity for MANET has been being researched, of which object is to support the communication between the mobile ad hoc node and Internet node [3]. DNS is one of the most popular applications in the Internet. It provides the name-to-address resolution among nodes in the Internet. DNS must also be a necessity of MANET but the current DNS is inappropriate to MANET that has dynamic topology because the current DNS works on the basis of dedicated and fixed DNS name servers. Therefore, a new DNS architecture appropriate to this MANET, where there is no dedicated DNS server and the network is multi-hop, became necessary [4]. This document specifies an architecture of name service system which can provide mobile nodes in MANET with the name-to-address resolution and autoconfiguration technology for easy configuration related to IP address autoconfiguration [5] and name service, such as the generation of zone file for name service. It also describes service discovery performed through the name service system of this document and DNS service resource record (SRV) [6]. This service discovery mechanism provides ad hoc user with the information of a service with the specified transport protocol (TCP or UDP) that is needed for the connection to the service in MANET, such as IP address and port number. The name service system allows mobile node within MANET connected to the Internet via Internet gateway to resolve DNS name of Internet node into global IP address and the mobile node to communicate with the Internet node via Internet gateway. For the authentication of DNS messages, this document specifies a mechanism of DNS authentication based on TSIG resource record [7]. 3. Overview ANS is the name service system that provides the name resolution and service discovery in MANET which is multi-hop. The IP address for the network device of each mobile node is configured by Ad Hoc IP address autoconfiguration or by manual configuration [5]. ANS System consists of ANS Responder that works as DNS name server in MANET and ANS Resolver that performs the role of DNS resolver for name-to- Jeong, et al. Expires - July 2004 [Page 3] Internet-Draft MANET DNS Service February 2004 address translation. Figure 1 shows DNS name resolution through ANS System in MANET, consisting of three mobile nodes; that is, Node A, Node B and Node C. Each mobile node runs ANS Responder and Resolver. An application on mobile node that needs the name resolution can receive the name service through ANS Resolver because ANS provides the applications with the library functions for name resolution, ANS API, through which they can communicate with ANS Resolver. +-------+ +-------+ |Node A | |Node B | +-------+ +-------+ | . DNS Query | | ..........................>| -------------------.------------------ |. |V +-------+ |Node C | +-------+ Figure 1. Multicasting of DNS Query Message for Name Resolution +-------+ +-------+ |Node A | |Node B | +-------+ +-------+ | DNS Response | | <............. | -------------------.------------------ |. |. +-------+ |Node C | +-------+ Figure 2. Unicasting of DNS Response Message for Name Resolution ANS Resolver sends DNS query message for a host DNS name in a multicast address for ANS name service, ANS_MULTICAST_IPV4_ADDRESS, which ANS Responder in each mobile node MUST join for DNS name service [3]. When ANS Responder receives DNS query from ANS Resolver in other mobile nodes, after checking if it is responsible for the query, it decides to respond to the query. When it is responsible for the query, it sends an appropriate response message to ANS Resolver in unicast. In Figure 1 and 2, Node A sends in multicast a DNS Query message for resolving a host DNS name into IP address and Jeong, et al. Expires - July 2004 [Page 4] Internet-Draft MANET DNS Service February 2004 Node C responds to the query with a DNS Response message, which is responsible for the DNS name queried by Node A. 4. DNS Operations in ANS System 4.1 ANS Responder ANS Responder plays the role of DNS name server, operating in eight steps as follows; Step (a) : ANS Responder starts. Step (b) : ANS Responder generates a DNS zone file for name service. Step (c) : ANS Responder loads resource records of the zone file into ANS Zone DB. Step (d) : ANS Responder verifies the uniqueness of the resource records related to each domain name through dynamic update request (DUR) [3]. DUR query message is sent in multicast with destination address set to ANS_MULTICAST_IPV4_ADDRESS. Step (e) : ANS Responder joins ANS multicast group, ANS_MULTICAST_IPV4_ADDRESS in order to receive DNS query messages from other mobile nodes. Step (f) : ANS Responder waits for DNS message. Step (g) : When ANS Responder receives a DNS message, it checks if the message is a DNS query. Step (h) : If the DNS message is a query, ANS Responder processes the query and sends the response to ANS Resolver that sent the query and goes to Step (f). If the DNS message is a response of which the name belongs to this node, ANS Responder performs the dynamic update request to verify the uniqueness of the resource record related to the name like in [3]. If ANS Responder finds the name conflict through the dynamic update request, it invalidates the resource record corresponding to the duplicate name in its ANS Zone DB. After performing the dynamic update request, ANS Responder goes to Step (f). 4.2 ANS Resolver ANS Resolver performs the name resolution request received from user application via ANS API, operating in twelve steps as follows; Jeong, et al. Expires - July 2004 [Page 5] Internet-Draft MANET DNS Service February 2004 Step (a) : ANS Resolver starts. Step (b) : ANS Resolver waits for the request of name resolution from an application via ANS API on the same node. Step (c) : When ANS Resolver receives the resolution request, it checks first if there is the result of the request in ANS Cache. Step (d) : If there is already the result of the request in ANS Cache, ANS Resolver passes the result to the application and goes to Step (b). Unless there is the result of the request in ANS Cache, it goes Step (e). Step (e) : ANS Resolver generates a DNS query message. Step (f) : ANS Resolver sends the DNS query message in multicast with destination address set to ANS_MULTICAST_IPV4_ADDRESS. Step (g) : ANS Resolver starts a query timer. Step (h) : ANS Resolver waits for a DNS response message until the query timer expires. Step (i) : If the query timer expires or a DNS response message arrives, ANS Resolver checks what the event is. If the event is the timer expiration, it goes to Step (j). Otherwise, it goes to Step (k). Step (j) : ANS Resolver checks whether the number of retransmission of query message is less than or equal to the allowed maximum number of retransmission (MAX_RETRANS) and. If the number of retransmission of query message (Num_Retrans) is greater than MAX_RETRANS, ANS Resolver returns the error message to the application via ANS API and goes to Step (b). Otherwise, it goes to Step (f). Step (k) : ANS Resolver checks if the response is valid. If the response is valid, it goes to Step (l). Otherwise, it discards the response and checks Num_Retrans. If Num_Retrans is greater than MAX_RETRANS, ANS Resolver returns the error message to the application via ANS API and goes to Step (b). Otherwise, it goes to Step (h). Step (l) : If ANS Resolver has received multiple valid response messages from other ANS Responders, it sends the first response to every ANS Responder that sent a response except the ANS Responder that has sent the response first. Jeong, et al. Expires - July 2004 [Page 6] Internet-Draft MANET DNS Service February 2004 This triggers dynamic update request at each ANS Responder that receives this response message, allowing each ANS Responder to check the duplication of a DNS resource record. After this, ANS Resolver stores the response in ANS Cache, passes the response to the application via ANS API and goes to Step (b). If ANS Resolver received only one valid response, it stores the response in ANS Cache, passes the response to the application via ANS API and goes to Step (b). 4.3 ANS API ANS API allows a user application to use ANS Resolver for resolving DNS name. A user application calls ANS API function, ans_getaddrinfo() as follow; /* ANS API function */ int ans_getaddrinfo(char* node, u_short family, struct ans_addrinfo** res); //node: contain DNS name //family: indicate IP version //res: store the result of DNS name resolution, i.e., IP address /* structure for name resolution */ struct ans_addrinfo { int ai_flags; //indicate if resolution is from name to address /* 0 : no resolution, 1 : resolution from name to address */ int ai_family; //IP version size_t ai_addrlen; //length of socket address, ai_addr, in bytes struct sockaddr* ai_addr; //IP address char* ai_canonname; //domain name }; 5. Generation of DNS Zone File ANS Responder needs a file for storing host DNS name, Host Name File. Host DNS name consists of user id and MANET_DOMAIN; for example, when user id is "paul", host DNS name is "paul.manet.". When ANS Responder starts for DNS service, it generates its DNS zone file, called ANS Zone File, which contains DNS resource record(s) of A or AAAA type by combining its DNS name and IP address with its Host Name File. The autoconfiguration of DNS zone file allows ad hoc Jeong, et al. Expires - July 2004 [Page 7] Internet-Draft MANET DNS Service February 2004 user easily to configure DNS resource records for its DNS name. That is to say, the user only registers its DNS name with ANS Responder's Host Name File. This autoconfiguration becomes more useful when IP address autoconfiguration is used together [5]. 6. Service Discovery Service discovery allows ad hoc users to discover the service information that is necessary to connect to the service when the service name, transport protocol (e.g., TCP or UDP) and domain where the service is placed are given. With DNS SRV resource record [6], ANS can provide service discovery. It is assumed that mobile node running unicast services should register a DNS SRV resource record for each service with its ANS Zone File. 7. Global DNS Service in MANET connected to the Internet When a mobile node in MANET connects to a web server in the Internet, it needs an Internet gateway that connects the MANET to the Internet [4]. Also, it needs a recursive DNS server, called global DNS server, that translates the DNS name of the web server into the global IP address. Therefore, Internet gateway SHOULD run ANS Responder in order to inform mobile nodes in MANET of the information of recursive DNS server connected to the Internet. The IP address of A global DNS server is resolved with ANS Resolver and SRV resource record. The service name of global DNS server is defined as "_global-dns-server". For example, if the address of global DNS server is "A.B.C.D", the SRV resource record is as follows; $ORIGIN MANET_DOMAIN dns-server A ttl A.B.C.D __global-dns-server._udp SRV ttl priority weight 53 dns-server In another way, the global DNS address MAY be delivered to mobile node that tries to connect to the Internet on piggy-back along with Internet gateway address [8]. The function of the library related to DNS resolver for the DNS resolution, e.g., "getaddrinfo()", SHOULD be modified for the support of DNS name service in MANET. The DNS name for the domain belonging to MANET, of which suffix is MANET_DOMAIN, is resolved through ANS Resolver of ANS System. The other DNS names are resolved through the regular DNS resolver which uses DNS resolver's configuration file, e.g., /etc/resolv.conf in UNIX, including the recursive DNS server(s) informed by Internet gateway. 8. IPv6 Considerations Jeong, et al. Expires - July 2004 [Page 8] Internet-Draft MANET DNS Service February 2004 ANS can provide ad hoc users with DNS name service and service discovery in IPv6 MANET. ANS_MULTICAST_IPV4_ADDRESS is replaced with ANS_MULTICAST_IPV6_ADDRESS for IPv6 ANS. AAAA resource record is used for the purpose of containing IPv6 address associated with host DNS name in ANS zone file. 9. Configuration Parameters This section gives default values for some important parameters associated with MANET DNS operations. Parameter Name Value --------------------------- ----- ANS_MULTICAST_IPV4_ADDRESS 224.0.0.251 ANS_MULTICAST_IPV6_ADDRESS FF05::224.0.0.251 MAX_RETRANS 3 MANET_DOMAIN manet. 10. Security Considerations In order to provide securer name service including service discovery in ANS, it is necessary to authenticate ANS responses. ANS can use IPsec ESP with a null-transform or the secret key transaction authentication for DNS, TSIG [7], which can be easily accomplished through the configuration of a group pre-shared secret key for the trusted nodes [3]. 10.1 Message Authentication through TSIG In ANS, the authentication of DNS message is recommended on the basis of TSIG resource record which provides secret key transaction authentication for DNS. HMAC-MD5 is used as hashing algorithm for authentication [9][10]. All ANS Resolvers and Responders in a trusted group SHOULD share a group secret key for TSIG authentication. Whenever ANS Responder responds to DNS query, it sends DNS response message including TSIG resource record, which has the authentication code generated through hashing the total DNS response message with the group's secret key. 11. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 2001. All Rights Reserved. Jeong, et al. Expires - July 2004 [Page 9] Internet-Draft MANET DNS Service February 2004 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Levon Esibov, Bernard Aboba and Dave Thaler, "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-29.txt, January 2004. 13. Informative References [4] Ryuji Wakikawa et al., "Global connectivity for IPv6 Mobile Ad Hoc Networks", draft-wakikawa-manet-globalv6-01.txt, July 2002. [5] Jaehoon Paul Jeong, Jungsoo Park, Hyoungjun Kim and Dongkyun Kim, "Ad Hoc IP Address Autoconfiguration", draft-jeong-adhoc-ip- addr-autoconf-02.txt, February 2004. [6] A. Gulbrandsen, P. Vixie and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV) ", RFC 2782, February 2000. Jeong, et al. Expires - July 2004 [Page 10] Internet-Draft MANET DNS Service February 2004 [7] P. Vixie, O. Gudmundsson, D. Eastlake and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG) ", RFC 2845, May 2000. [8] Jaehoon Paul Jeong, Soohong Daniel Park, Luc Beloeil and Syam Madanapalli, "IPv6 DNS Discovery based on Router Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-01.txt, February 2004. [9] H. Krawczyk, M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [10] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 14. Authors' Addresses Jaehoon Paul Jeong ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 1664 Fax: +82 42 861 5404 EMail: paul@etri.re.kr Jungsoo Park ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 6514 Fax: +82 42 861 5404 EMail: pjs@etri.re.kr Hyoungjun Kim ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 6576 Fax: +82 42 861 5404 EMail: khj@etri.re.kr Jeong, et al. Expires - July 2004 [Page 11]