idnits 2.17.1 draft-ietf-dnsop-shared-root-server-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9082 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. Ohta 2 draft-ietf-dnsop-shared-root-server-01.txt Tokyo Institute of Technology 3 June 1999 5 Distributing Root Name Servers via Shared Unicast Addresses 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This memo describes an operational guideline for root name servers to 31 share unicast addresses. 33 1. Motivation 35 For the stability of the Internet, it is critical that there are 36 sufficiently many DNS root servers operating at various places of the 37 Internet. 39 For the stability of the domestic Internet, it is critical for each 40 country that there are sufficiently many DNS root servers operating 41 at various places of the Internet in the country. 43 However, the number of unicast IP addresses of root servers is 44 limited. Thus, for the internationally fair operation of DNS, the 45 number of root servers in each country (including US) must be equal 46 to the number of unicast IP addresses of root servers divided by the 47 number of countries (some weight may be given according to the number 48 of Internet hosts in each country). 50 Given the current number of countries and IP addresses of root 51 servers, each country (again, including US) will be able to have 1/20 52 root servers, which definitely is not sufficiently many. 54 Thus, it is necessary to somehow increase the number of root servers. 55 This memo proposes administrative scoping of the routing ranges of 56 unicast addresses of root servers. 58 With administratively scoped unicast addresses, any entity, including 59 a country, can use the addresses for its local root servers and set 60 the scope of the routing ranges of the addresses appropriately. 62 Note that operations similar to that described in this memo are 63 possible today locally without global coordination by any operator 64 who may be irritated by the lack of his control on (sufficiently 65 many) root servers, which may be a source of some operational 66 problems. This memo is an attempt to document the way to solve the 67 problem in a least harmful manner. 69 Similar operation described in this memo may be applicable to gTLD 70 servers but it is outside the scope of this memo. 72 2. Suggested Operation 74 As is demonstrated by the proliferated private use addresses, it is 75 easy to set up routers to let unicast addresses have local scopes. It 76 is also easy to let the unicast addresses have nested local scopes. 77 The important difference between the addresses for privae use and 78 root servers is in their semantics that the root servers sharing an 79 address share the globally unique semantics of the address. The root 80 servers may share a globally unique DNS host name, too. 82 A possible problem of such addresses is that the shared addresses can 83 not be used for global communication. So, it is suggested that the 84 root name servers with the administratively scoped shared unicast 85 addresses have additional globally unique unicast addresses, which 86 may be used for global communication such as zone transfer. 88 The other possible problem of such addresses is that the shared 89 addresses are not managed by a single entity that the mapping from 90 the shared address of a root server to some operational entity is 91 impossible. However, if the routers near the root server has a global 92 addresses, it is possible to map from the global address to an 93 operational entity, which is expected to be operating the root 94 server. That is, tools like traceroute works to find the operational 95 entity of the root servers. 97 To be compatible with the current practice that a single address 98 belong to a single AS, each administratively scoped shared unicast 99 address is assigned its own AS number. There will be multiple ASes of 100 the AS number containing the same address ranges. 102 ASes, still, can be identified by adjacent ASes. For example, 103 network operators may choose their favorite root server based on the 104 AS numbers of the next hop ASes with, for example, AS path and BGP 105 policy. 107 It is required that operators of an AS adjacent to the root servers' 108 AS be fully responsible to the operation of the root servers. If a 109 root server's AS is adjacent to multiple ASes, operators of all the 110 ASes must be fully responsible to the operation of the root server. 111 Thus, if there is a routing problem related a root server, operators 112 of the next hop AS(es) should be contacted. 114 3. Assignment 116 Considering that each country is likely to need a considerable number 117 of root servers, it is reasonable to make most, if not all, of the IP 118 addresses of the root servers administratively scoped and shared. 120 Note that given the large number of root servers in the Internet, it 121 is impossible that all the servers use a single server as the primary 122 source of zone transfer. That is, the name and the IP address of the 123 current primary server may also be shared. 125 Considering the huge effort to change the file containing the IP 126 addresses of the root servers all around the Internet, the IP 127 addresses of the root servers should better stay same as that of 128 today. Organizations running the current root servers are requested 129 to release the current class B or C address blocks containing the 130 current IP addresses of the root server for the public use. 132 The AS numbers assigned to root server addresses are: 134 Name IP Address/Mask AS Number 136 A.ROOT-SERVERS.NET 198.41.0.4/8 (to be assigned by IANA) 137 B.ROOT-SERVERS.NET 128.9.0.107/16 (to be assigned by IANA) 138 C.ROOT-SERVERS.NET 192.33.4.12/8 (to be assigned by IANA) 139 D.ROOT-SERVERS.NET 128.8.10.90/16 (to be assigned by IANA) 140 E.ROOT-SERVERS.NET 192.203.230.10/8 (to be assigned by IANA) 141 F.ROOT-SERVERS.NET 192.5.5.241/8 (to be assigned by IANA) 142 G.ROOT-SERVERS.NET 192.112.36.4/8 (to be assigned by IANA) 143 H.ROOT-SERVERS.NET 128.63.2.53/16 (to be assigned by IANA) 144 I.ROOT-SERVERS.NET 192.36.148.17/8 (to be assigned by IANA) 145 J.ROOT-SERVERS.NET 198.41.0.10/24 (to be assigned by IANA) 146 K.ROOT-SERVERS.NET 193.0.14.129/24 (to be assigned by IANA) 147 L.ROOT-SERVERS.NET 198.32.64.12/24 (to be assigned by IANA) 148 M.ROOT-SERVERS.NET 202.12.27.33/24 (to be assigned by IANA) 150 4. Security Considerations 152 This memo describes just an operational guideline with no protocol 153 change. As such, the guideline does not introduce any security issues 154 of the protocol level. 156 As the route forgery to the root servers can be implemented today 157 without this memo by anyone including local intruders, the guideline 158 does not introduce any security issues of the operational level, 159 either. 161 A guideline to track down and verify valid or forged route or AS path 162 to the root servers is described in section 2. 164 5. Authors' Addresses 166 Masataka Ohta 167 Computer Center 168 Tokyo Institute of Technology 169 2-12-1, O-okayama, Meguro-ku 170 Tokyo 152-8550, JAPAN 172 Phone: +81-3-5734-3299 173 Fax: +81-3-5734-3415 174 EMail: mohta@necom830.hpcl.titech.ac.jp