INTERNET DRAFT M. Ohta draft-ohta-preconfigured-dns-00.txt Tokyo Institute of Technology July 2003 Preconfigured DNS Server Addresses Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo describes how to make addresses of DNS servers preconfigured in clients. Well known anycast addresses, which are assigned to DNS servers, should be preconfigured to resolvers of clients. 1. Introduction The requirement addressed by this memo is to eliminate configuration effort of DNS clients. This memo defines several IP addresses to be used as a well known anycast IP addresses of DNS servers. The addresses are intended to be preconfigured to client resolvers to reduce (or eliminate) initial configuration effort on clients. This memo also describes sever and client operations. 2. Server Operation To serve stub resolvers, preconfigured DNS servers MUST offer M. Ohta Expires on January 20, 2004 [Page 1] INTERNET DRAFT Preconfigured DNS Server Addresses July 2003 recursive service if requested by their clients. While it should be assumed that the clients have no information to validate their identities to the servers, the servers may still limit their services to valid clients based on some (autoconfigured) property of the clients. For (perhaps the only) example, the servers may reply to requests from clients with certain ranges of IP addresses only. 3. Client Operation Clients SHOULD behave as a stub resolver forwarding queries to any of the preconfigured anycast address. Client resolvers SHOULD NOT have SBELT (root server) information, because root servers and their addresses sometimes changes requiring reconfiguration. Client resolvers MAY be able to perform recursive queries. 4. Assigned Addresses The following three IPv4 addresses are assigned as preconfigured DNS server addresses: route information of which should be propagated with a netmask of The following three IPv6 addresses are assigned as preconfigured DNS server addresses: route information of which should be propagated with a netmask of M. Ohta Expires on January 20, 2004 [Page 2] INTERNET DRAFT Preconfigured DNS Server Addresses July 2003 A client resolver can receive a UDP reply from an IP address different from one used to send a corresponding query, that UDP reply may use source address of non-anycast IP address of server. However, such a behavior is not available with TCP and anycast IP addresses MUST be used as source addresses of reply packets of TCP. 4.1. Scope Considerations The assigned anycast addresses are globally well known and have global scopes. On the other hand, servers with the anycast addresses have local scopes, boundaries between them is determined by a routing system. The boundaries many be dynamically determined with routing metric. In addition, route administrators may configure static boundaries. While there may be static boundaries at site boundaries, always requiring them eliminates useful cases, for example, of ISPs providing DNS servers for customer sites. Within a static boundary, there may be a single server for each anycast address, or there may be multiple servers sharing an anycast address, which may be useful for load distribution. Even if identities of the servers changes dynamically between a query and its reply, a simple exchange of UDP packets is not affected and TCP transactions detect sequence number inconsistencies and should attempt new ones. However, having multiple servers sharing an anycast address within a static boundary does not improve redundancy, because a DNS process on a server may die while a route to the server is still alive. Three anycast addresses are provided for the redundancy. 5. Security Considerations Cryptographic security requires some information securely (at least with authentication, even when public key cryptography is used) shared between servers and clients, which requires manual configuration. Thus, no cryptographic security, which makes the protocol complex with no security improvement, should be used by preconfigured client resolvers. M. Ohta Expires on January 20, 2004 [Page 3] INTERNET DRAFT Preconfigured DNS Server Addresses July 2003 The DNS server with the preconfigured addresses are still reasonably reliable, if local environment is reasonably secure, that is, there is no active attackers receiving queries to the anycast addresses of the servers and reply to them. 6. Author's Address Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on January 20, 2004 [Page 4]