idnits 2.17.1 draft-ietf-dnsop-ohta-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: ---------------------------------------------------------------------------- ** 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 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: ---------------------------------------------------------------------------- == Line 58 has weird spacing: '...trators have...' -- 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 (July 2001) is 8321 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: 4 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-ohta-shared-root-server-01.txt 3 Tokyo Institute of Technology 4 July 2001 6 Root Name Servers with Inter Domain Anycast Addresses 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This memo describes an operational guideline for root name servers to 32 share unicast (interdomain anycast) addresses. 34 1. Motivation 36 DNS root servers are the essential component of the Internet that all 37 the ISPs in the world want to run several root servers. 39 To satisfy them, we need to have thousands or millions of root 40 servers. 42 However, because of the restriction on DNS message size over UDP, the 43 number of unicast IP addresses of root servers is severely limited. 45 Thus, it is necessary to increase the number of root servers by 46 assigning an IP address to a lot of root servers. 48 Even if DNS were designed to allow a lot of root servers, it is 49 difficult for DNS clients to choose the best (with regard to 50 availability, credibility of zone content, delay, domain policy etc.) 51 root servers among so many root servers. It is not practical to ping 52 millions of servers to find which has the smallest RTT. 54 This memo proposes a mechanism of policy based selection of a root 55 server sharing an IP address (anycast IP address) with other root 56 servers and discusses operational issues related to it. 58 Because the selection is policy based, domain administrators have 59 some control over the selection of the best root server among root 60 servers sharing an IP address. 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 or 70 other global servers but it is outside the scope of this memo. 72 2. Suggested Operation 74 As is demonstrated by proliferated private use addresses, it is easy 75 to set up routers to let unicast addresses have local scopes. It is 76 also easy to let the unicast addresses have nested local scopes. The 77 important difference between the addresses for private use and root 78 servers is in their semantics that the root servers sharing an 79 address also share the globally unique semantics of the address. The 80 root 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. 85 So, the root name servers with the anycast addresses must have 86 additional globally unique unicast address (or addresses), which may 87 be used for global communication such as zone transfer. 89 The other possible problem of such addresses is that the shared 90 addresses are not managed by a single entity that the mapping from 91 the shared address of a root server to some operational entity is 92 impossible. 94 However, if a router adjacent to (or near) the root server has a 95 globally unique address, it is possible to map from the global 96 address to an operational entity, which is expected to be operating 97 the root server. That is, tools like "traceroute" work to uniquely 98 identify the operational entity of the root servers sharing a anycast 99 address. 101 To be compatible with the current practice that a single address 102 belong to a single AS, each anycast address is assigned its own AS 103 number. There will be multiple ASes of the AS number containing the 104 same address ranges. 106 ASes, still, can be identified by adjacent ASes. For example, 107 network operators may choose their favorite root server based on the 108 AS numbers of the next hop ASes with, for example, AS path and BGP 109 policy. 111 It is required that operators of an AS adjacent to the root servers' 112 AS be fully responsible to the operation of the root servers. If a 113 root server's AS is adjacent to multiple ASes, operators of all the 114 ASes must be fully responsible to the operation of the root server. 115 Thus, if there is a routing problem related to a root server, 116 operators of the next hop AS(es) should be contacted. 118 To avoid complex routing tricks, globally unique unicast address(es) 119 of the root name servers must be taken from the AS(es) adjacent to 120 the root server's AS. Then, in a likely simple case that the root 121 server's AS consists of a single host, which acts as a name server 122 and a BGP router, the host should peer with adjacent AS(es) through 123 an interface(s) address(es) of which belongs to the adjacent AS(es). 124 If the root server's AS has more complex structure, special IGP 125 arrangement of globally unique unicast address(es) is necessary in 126 the AS and at the border router(s) of the adjacent AS(es). The border 127 router(s) must accept IGP information advertised from the root 128 server's AS. 130 3. Assignment 132 When a server with an anycast address fails but a route to it is 133 still available, there is no way for clients use other servers with 134 the same anycast address, anycast does not improve availability of 135 servers so much. 137 So, even with anycast addresses, there should be multiple root 138 servers. 140 However, as anycast solves the problem of load concentration, we 141 don't need so many anycast IP addresses, 143 We should have at least 3 and at most 7 anycast addresses for root 144 servers. 146 4. Ongoing Experiment 148 An experiment is ongoing with a block of IP addresses 192.83.230/24 149 in AS 4128 and DNS servers sharing an IP address of 192.83.230.1. 151 Domains served by the DNS servers are not root domain but are: real- 152 internet.org. and psg.com. 154 If one is interested in joining (or just watching) the test, send a 155 mail containing a single line of: 157 subscribe aroot 159 to 161 majordomo@ops.ietf.org 163 the mailing list is located at: 165 aroot@ops.ietf.org 167 Archive of the list is available at 168 ftp://ops.ietf.org:/pub/lists/aroot. 170 If there is something wrong with route information from AS 4128, the 171 author of the memo or the mailing list for the test may be contacted. 173 However, for direct contact to the source of the problem, the contact 174 person of an AS next to AS 4128 in the AS path of problematic route 175 information should be contacted. 177 5. Security Considerations 179 This memo describes just an operational guideline with no protocol 180 change. As such, the guideline does not introduce any security issues 181 of the protocol level. 183 As the route forgery to the root servers can be implemented today 184 without this memo by anyone including local intruders, the guideline 185 does not introduce any security issues of the operational level, 186 either. 188 A guideline to track down and verify valid or forged route or AS path 189 to the root servers is described in section 2. 191 6. Author's Address 193 Masataka Ohta 194 Graduate School of Information Science and Engineering 195 Tokyo Institute of Technology 196 2-12-1, O-okayama, Meguro-ku 197 Tokyo 152-8552, JAPAN 199 Phone: +81-3-5734-3299 200 Fax: +81-3-5734-3299 201 EMail: mohta@necom830.hpcl.titech.ac.jp