INTERNET-DRAFT Gunnar Lindberg draft-lindberg-dnsop-isp-root-server-00.txt Chalmers University Expires February 2000 of Technology 17 Aug 1999 ISP Operated Root Name Servers Copyright (C) The Internet Society (1999). All Rights Reserved. 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. 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 memo proposes a way to increase the number of DNS Root Servers (today 13) to assure robustness. This does increase complexity, but the increased complexity is kept entirely within the DNS itself. 1. Introduction. There are 13 Name Servers for the Domain Name System's Root zone, often referred to at "dot" or "."; we will use the term RS or NS(.) for them. They are spread out in a rather uneven way (some people might actually go so far as to call it "unfair") with a majority of them in North America. The list is kept in file ftp://FTP.RS.INTERNIC.NET/domain/named.root which every other Name Server uses as a hint at startup time to know Lindberg ISP Operated Root Name Servers [Page 1] draft-lindberg-dnsop-isp-root-server-00.txt 17 Aug 1999 where to start. The reason there are 13 RS is very pragmatic; the response to a query for NS(.) - the list of Root Servers - should fit into one single UDP packet and should not require TCP. Each Name Server, NS, needs to be able to communicate with at least one RS to operate correctly; first at startup time to get the real NS(.) list (the file mentioned above is only a hint) and later on to get the NS() list for other zones, e.g. the list of NS(com) or NS(se). Since there are only 13 RSs, even a fairly minor network outage may prevent all RS contact, resulting in severe failures. The discussion to date has often focused on countries; each country needs its own RS etc, etc. However, the notion of country has little or no relevance on the Internet. Instead the important entity is the ISP, the Internet Service Provider, who competes on an open market and may operate in several countries (even on several continents). With such open competition it is highly unlikely that a (large) ISP will accept to have its customer depend on a RS operated by another ISP, which would be the case if RSs were distributed based on country. So, in this document focus is to allow each ISP to operate its own set of RSs. There might be independent organizations running RSs, serving a number of ISPs with whom they have good connectivity. However, for this discussion that's only a special case of an ISP and we refer to such an organization as an ISP too. 2. Terminology. In this document we use the following terminology: o NS - Name Server. Generic term. o RS - Root Server. Generic term. o RRS - Real Root Server. The 13 Root Servers we all love and depend on. o IRS - ISP Root Server. A Root Server operated by an ISP. 3. The Proposal. The proposed changes are quite straight forward: Lindberg ISP Operated Root Name Servers [Page 2] draft-lindberg-dnsop-isp-root-server-00.txt 17 Aug 1999 o Modify the software in the RRSs (the 13 Real Root Servers) so that their response may depend on the IP source address of the requestor (best fit IP prefix). This is known as "Split DNS", or "Two Faced DNS". o Allow each ISP to register its own set of RSs (IRSs, ISP Root Servers) and the IP prefixes that should get these IRSs as response to NS(.) queries and/or as additional information. o Default response is "NS(.) = RSS", i.e. the Real Root Servers, like today. Since every NS will query at least one of the RRS at least once to get the NS(.) list (or will get the NS(.) list as additional information in response to other queries) it will get updated with its ISP's IRS list and will send its queries to those host from then. It will then be the ISP's responsibility to create good connectivity from its customers to its IRS and to keep these hosts in good shape. -------------------------------------------------------------------- +-> RRS1 RRS2 RRS3 ... RRS13 <-+ ! ! ! ! Response ! Response ! ! ! NS(.)= ! NS(.)= ! ! ! IRS1.ISP1 ! IRS1.ISP2 ! Query ! ! IRS2.ISP1 ! IRS2.ISP2 ! Query NS(.)?! ! IRS3.ISP1 ! IRS3.ISP2 ! NS(.)? ___________!___ ! ! ____________!__ ! ! ! ! ! ! ! ! ! C1 <-------+ +--------------> C2 ! ! Customer ! ! Customer ! ! ! ! ! ! ! ! ! ! IRS1.ISP1 ! ! IRS1.ISP2 ! ! IRS2.ISP1 ! ! IRS2.ISP2 ! ! IRS3.ISP1 ! ! IRS3.ISP2 ! ! ! ! ! ! ISP1 ! ! ISP2 ! !_______________! !_______________! Fig. 1: NS(.) Query & Response -------------------------------------------------------------------- 4. An Observation. The "Split DNS", or "Two Faced DNS", is actually quite useful in Lindberg ISP Operated Root Name Servers [Page 3] draft-lindberg-dnsop-isp-root-server-00.txt 17 Aug 1999 other situations, e.g. when private IP-addresses, [RFC1597], are used, i.e. there is an "inside" and an "outside" and we need to return private addresses if the requestor is "inside" and globally unambiguous ones otherwise. Therefore this functionality could and should exist in its own right. 3. Pros And Cons. Other proposals exist, [sharedWG], [sharedH], [sharedO], [hadns]. Most of them suggest having several instances of the RSs and let routing decide which of the instances an actual query is sent to. This is often referred to as "anycast". Some of the Pros-Cons discussion here is with that as background. 3.1. Cons. This proposal means changing software on the RRSs, the most important hosts on the Internet, which is not to be taken lightly. Keeping a (potentially) large number of RSs in sync is nontrivial. Some IRS may not be as well maintained as one could wish. Customers of such an ISP would then prefer to use the RRSs or some other ISP's IRSs as NS(.). However, this is not easily done (regardless of whether it's regarded as acceptable). The RRSs use the querier's IP address prefix to determine which IRSs to return as NS(.) and the IP address prefix is associated with a particular ISP. Therefore, the RRS will always respond with that particular ISP's IRSs as NS(.) and the customer has no way to change to some other NS(.) list. 3.2. Pros. Once the initial NS(.) response is received from one of the RRSs, it is clear which IRSs are in use and that information stays stable; it is possible to identify each IRS by a name that reflects the ISP running it, traceroute to it ends up at the same host every time, etc, etc. This proposal puts the DNS complexity with the increased (large) number of RSs entirely in the DNS itself and does not depend on any other Internet subsystem for its operation - e.g. routing and routing paradigms - more than it does today. Since the IRSs appear as themselves - as opposed to several of the other proposals where they mimic identical instances of one single RS host - there is no additional need for synchronization; as always RSs must be in sync but it's no worse then today. Lindberg ISP Operated Root Name Servers [Page 4] draft-lindberg-dnsop-isp-root-server-00.txt 17 Aug 1999 4. Security. Strong authentication is needed for the (non-realtime) communication between the RRS operator(s) and the ISPs to make sure that changes and updates for a particular ISP really come from that ISP. The address prefixes must be validated, to assure they really are allocated to the ISP in question. The relationship between the IRSs and the ISP must also be validated. The increased number of RSs of course increases the risk of some of them being misconfigured. It also increases the risk for undetected spoofing or man-in-the-middle attacks, simply because there are more RS hosts to keep track of. A malicious ISP may alter the NS(.) list, or other responses from its IRS, so that it will block or mis-direct DNS queries about its competitors or non-customers; this is probably illegal and is definitely socially unacceptable. Thus it is not likely to happen frequently. It is still unclear how this proposal combines with DNSSEC; e.g. who should sign the root zone provided by the IRSs. The increased number of RSs makes the overall DNS system less vulnerable to DoS attacks; it may not help a particular ISP under attack, but the global picture improves. 5. References. [RFC1597] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot: "Address Allocation for Private Internets", March 1994. [sharedWG] draft-ietf-dnsop-shared-root-server-01.txt M. Ohta, E. Hardie: "Distributing Root Name Servers via Shared Unicast Addresses", work in progress. [sharedH] draft-hardie-dnsop-shared-root-server-00.txt E.Hardie: "Distributing Root Name Servers via Shared Unicast Addresses", work in progress. [sharedO] draft-ohta-root-servers-01.txt M. Ohta: "Root Name Servers Sharing Administratively Scoped Unicast Addresses", work in progress. Lindberg ISP Operated Root Name Servers [Page 5] draft-lindberg-dnsop-isp-root-server-00.txt 17 Aug 1999 [hadns] draft-catalone-rockell-hadns-00.txt G. Catalone, R. Rockell: "Implementation of a High Availability DNS System", work in progress. Author's Address Gunnar Lindberg Computer Communications Group Chalmers University of Technology S-412 96 Gothenburg, SWEDEN, Phone +46 31 772 5913 FAX +46 31 772 5922 lindberg@cdg.chalmers.se 6. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. 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 assigns. 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. Lindberg ISP Operated Root Name Servers [Page 6]