idnits 2.17.1 draft-diao-aip-dns-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of lines with control characters in the document. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 146 has weird spacing: '... |Top edu ...' == Line 149 has weird spacing: '...u yahoo com...' == Line 152 has weird spacing: '... www mail ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 25, 2013) is 3768 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 99, but not defined == Unused Reference: 'RFC 791' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC1706' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 495, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Diao Yuping 3 Internet-Draft Guangdong University of Finance & Economics 4 Intended status: standard Diao Yongping 5 Expires: June 25, 2014 Guangzhou, China 6 Liao Ming 7 Guangzhou, China 8 December 25, 2013 10 DNS Extension for Autonomous Internet(AIP) 11 draft-diao-aip-dns-04.txt 13 Abstract 15 With the reality of Internet, Autonomous Internet technology 16 in this article constructs independent autonomous extensible domain 17 name architecture and domain name hierarchy through current domain 18 name architecture, provides independent root DNS server, inner/outer 19 DNS resolution mechanism for each autonomous internet network system, 20 and provides reformation and transition solution from current 21 Internet to realize autonomy even in unilateral technical action. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 25, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Specification of Requirements . . . . . . . . . . . . . . . 4 59 2. Autonomous Internet DNS Design . . . . . . . . . . . . . . . . 4 60 2.1. AIP DNS Design Goal . . . . . . . . . . . . . . . . . . . . 4 61 2.2. AIP DNS Hierarchy . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. AIP DNS Architecture and Transformation . . . . . . . . . . 6 63 3. AIP DNS Resolution Procedure. . . . . . . . . . . . . . . . . . 7 64 3.1. Domain Name Resolution within AIP Network . . . . . . . . . 7 65 3.2. Domain Name Resolution between AIP Networks . . . . . . . . 8 66 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 Internet Domain Name System (DNS) distributes domain name and IP 78 address for the host on the Internet. DNS automatically translates 79 the domain name into IP address when user accesses Internet using 80 domain name. In current Internet domain name hierarchy, the root 81 DNS server authorizes and distributes all sub-layer DNS servers. 82 And by default it is to request the root DNS server service when any 83 other DNS servers receive a non local domain name resolution request. 84 DNS supports the Internet running normally. But its central control 85 method is not suitable to autonomy and scalability and can't keep up 86 with the fast development of Internet. To national internet network, 87 owning its independent root DNS server and realize autonomy in 88 Internet is a problem not only for the cost but also for the 89 technical difficulty. It is almost impossible in current DNS 90 architecture. 92 1.1. Specification of Requirements 94 In this document, several words are used to signify the requirements 95 of the specification. These words are often capitalized. The key 96 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 97 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 98 are to be interpreted as described in [RFC2119]. 100 2. Autonomous Internet DNS Design 102 2.1. AIP DNS Design Goal 104 Based on Internet practice, autonomous internet (AIP) techinology 105 should even unilaterally transform the Internet into Autonomous 106 Internet (AIP) without protocol change, using mode change, transition 107 period. In the same time, Autonomous Internet system architecture 108 designed should be safe and extensible; the reformation is the least 109 possibly and the transition is smooth and feasible. 111 To achieve the goal of Internet autonomy, AIP technology will 112 construct an independent autonomous extensible domain name system and 113 hierarchy based on current DNS, so that each AIP network has its own 114 independent domain name hierarchy and root DNS servers; It provides 115 the domain name resolution mechanism inner/outer AIP network system, 116 so that the internal domain name resolution is no longer via the DNS 117 outside this AIP network. Thus, the new generation Internet which 118 uses the AIP technology will become a multi-polar system and provide 119 full self-control ability to each AIP network. 121 2.2. AIP DNS Hierarchy 123 The main rules of the Autonomous Internet DNS are defined as 124 following: 126 Rule 1: Each AIP network itself has a complete set of Domain Name 127 System, which support traditional domain name resolution within the 128 AIP. 130 Rule 2: Each AIP network has its own numbered name that is different 131 from the others. The numbered name is taken as the default domain 132 name suffix when the internal domain name of this AIP network is 133 cited by external AIP network. Any IP node's external domain 134 name consists of its internal domain name and its AIP network 135 default domain name suffix. 137 Rule 3: When communicate between AIP networks, the access to IP node 138 of external AIP network must use the IP node's external domain name. 140 AIP Domain name system is autonomous, extensible. 142 +------------------------------+ +------------------------------+ 143 |Root "" | | "" Root | 144 | _________|________ | | _________|________ | 145 | / / | \ \ | | / / | \ \ | 146 |Top edu com org gov ex(i)<+-+>ex(i) com cn Top| 147 | /\ /\ | | /\ | 148 | / \ / \ | | / \ | 149 |Second baidu yahoo com cn | | baidu yahoo Second| 150 | /\ | | /\ | 151 | / \ | | / \ | 152 |Host www mail | | www mail Host| 153 | AIP Network A | | AIP Network B | 154 +------------------------------+ +------------------------------+ 155 Figure 1: Autonomous Internet domain name hierarchy 157 According to the goal and DNS rules of AIP, the AIP domain name 158 hierarchy of AIP can be designed as Fig. 1. In this figure, network 159 A, B and ... are AIP networks; Domain node "www.yahoo.com" in network 160 B is expressed as "www.yahoo.com.B" for its external domain name. 161 At the same time, each AIP network domain name hierarchy tree adds 162 the top-level domain name "ex(i)", so as to map the other external 163 AIP network domain name hierarchy trees accessible from this AIP 164 network. When ex(i)=B, it means the other AIP network B is accessible 165 from this AIP network. 167 2.3. AIP DNS Architecture and Transformation 169 According to the AIP DNS, we can construct AIP DNS architecture show 170 as Fig. 2. Each AIP DNS has its root DNS servers, which are 171 responsible for all the DNS resolution in this AIP network. Other DNS 172 servers of this AIP point to these root DNS servers by default. 173 . 174 +-------------------------------.-------------------------------+ 175 |+---------+ . | 176 ||Root DNS <--------------------+ | 177 || | .\ | 178 |+----^----+ . +-----------------------+ | 179 | | . | | 180 |+----v----+ . +----v----+| 181 || DNS | . | DNS || 182 || (.us) | . | (.cn) || 183 |+----^----+ . +----^----+| 184 | | . | | 185 |+----v----+ . +----v----+| 186 || Host | . | Host || 187 || N1(G1) | . | N2(G2) || 188 |+---------+ . +---------+| 189 | Internet | 190 +-------------------------------.-------------------------------+ 191 \./ 192 V 193 +------------------------------+ +------------------------------+ 194 |+----------+ +----------+| |+----------+ +----------+| 195 || Root DNS <------> AIP DNS <+-+> AIP DNS <------> Root DNS || 196 || (A) | | GW A || || GW B | | (B) || 197 |+----^-----+ +----^-----+| |+----^-----+ +----^-----+| 198 | | | | | | 199 |+----v-----+ | | +----v-----+| 200 || DNS | | | | DNS || 201 ||(.us/.com)| | | |(.cn/.com)|| 202 |+----^-----+ | | +----^-----+| 203 | | | | | | 204 |+----v-----+ | | +----v-----+| 205 || Host | | | | Host || 206 || Na1(Ga1) | | | | Nb2(Gb2) || 207 |+----------+ | | +----------+| 208 | Internet/AIP network A | | AIP network B | 209 +------------------------------+ +------------------------------+ 211 Figure 2: AIP DNS architecture and transformation 213 Each AIP network is almost the same as the current Internet, and the 214 internal domain name resolution and IP node communication have not 215 any change. The only change is that the destination domain name need 216 add domain name suffix of the destination AIP network when IP nodes 217 communicate between different AIP networks. Therefore, each AIP 218 network will add a device called "AIP DNS gateway" (AIP DNS GW) to 219 support domain name resolution between AIP networks. On one hand, it 220 forwards its external DNS resolution request to the destination AIP 221 network, returns the DNS resolution result to internal requester; 222 On the other hand, it receives DNS resolution request from external 223 AIP networks, feedback the DNS resolution result to the external AIP 224 network requester, which at first it would get the internal DNS 225 resolution result according to the traditional way. 227 In order to realize the transition from Internet to Autonomous 228 Internet, each partition of current Internet should first realize 229 possible self-government and gradually reduce its dependence on the 230 foreign domain names, such as COM, NET et al. 232 Then to each AIP network, we can establish a new autonomous DNS, or 233 Upgrade one part of current Internet DNS (core part or non core part) 234 to a new autonomous DNS. 236 Unilateral action: It is not likely the whole Internet can be 237 transformed synchronally in one time. In order not to affect existing 238 domain name resolution before the Internet core part transforms into 239 an AIP network, any country can set up an AIP DNS independently and 240 connect to the Internet through the original link; or any two 241 countries in agreement can set up their AIP networks and connect to 242 each others. There is something different in the unilateral action. 243 On one hand, the upgrade work is including of new added local AIP 244 network root DNS server to construct an independent DNS, and an AIP 245 DNS GW deployment to support domain name resolution between AIP 246 networks. On the other hand, it is necessary to add a pre-transformed 247 AIP DNS GW in each AIP network connecting to the Internet (core part) 248 DNS instead of the original transformation requirement for Internet 249 core part. The pre-transformed AIP DNS GW would initiatively add the 250 domain name suffix to the domain name from the existing Internet 251 (core part), which is the only difference from normal AIP DNS GW. 253 3. AIP DNS Resolution Procedure 255 3.1. Domain Name Resolution within AIP Network 257 Within each AIP network, domain name resolution keeps traditional 258 method. 260 3.2. Domain Name Resolution between AIP Networks 262 Between AIP networks, external domain name of destination IP node 263 should be provided for domain name resolution. Assume that a host in 264 AIP network A has domain name Na1 and global IP address Ga1. Another 265 host in AIP network B has domain name Nb2=www.yahoo.com, whose 266 external domain name is www.yahoo.com.B. Fig. 3 shows the DNS query 267 procedure between AIP network A and B when host Na1 request for the 268 domain name resolution of host Nb2. This domain name resolution 269 procedure between AIP networks is described as following: 271 Host DNS Root DNS AIP DNS :AIP DNS Root DNS DNS 272 Na1 (A) (A) GW A : GW B (B) (B) 273 | | | | : | | | 274 |-Nb2.B->| | | : | | | 275 | |-Nb2.B->| | : | | | 276 | |<.......| | : | | | 277 | | | | : | | | 278 | |------Nb2.B----->| : | | | 279 | | | |-Nb2.B->| | | 280 | | | | : |--Nb2-->| | 281 | | | | : |<.......| | 282 | | | | : | | | 283 | | | | : |-------Nb2------>| 284 | | | | : |<----------------| 285 | | | |<-------| | | 286 | |<----------------| : | | | 287 |<-------| | | : | | | 288 | | | | : | | | 289 Internet/AIP network A : AIP network B 291 Figure 3: DNS query procedure between AIP networks 293 Step 1: Source host Na1 request for the resolution of external 294 domain name "Nb2.B", and send the query to local DNS server through 295 host's resolver. 297 Step 2: When receive the query, Local DNS server inquire its cache 298 and return the result. But if there is no record for the query, local 299 DNS server would send query to root DNS server of local AIP network 300 A. 302 Step 3: Root DNS server of local AIP network A return a primary DNS 303 server IP address of queried domain (sub-domain of AIP network A's 304 root domain name, here is B, which mirrors external DNS hierarchy of 305 another AIP network B) to local DNS server, namely the IP address of 306 AIP DNS GW A in AIP network A. 308 Step 4: Local DNS server send the query to the returned DNS server 309 (AIP DNS GW A) IP address again. 311 1) When receive the query, AIP DNS GW A inquire its cache and 312 return the result. But if there is no record for the query, AIP 313 DNS GW A would send query to AIP DNS GW B in AIP network B. 315 2) When receive the query, AIP DNS GW B inquire its cache and 316 return the result. But if there is no record for the query, AIP 317 DNS GW B would get rid of the local AIP network domain name suffix 318 ".B" from external domain name "Nb2.B", then send query with the 319 internal domain name "Nb2" to root DNS server of local AIP network 320 B. 322 3) Root DNS server of local AIP network B return a primary DNS 323 server IP address of queried domain (sub-domain of root domain 324 name, such as COM) to AIP DNS GW B. 326 4) AIP DNS GW B sends the query to the last step 3) returned DNS 327 server IP address again. After receive the query, this DNS server 328 inquire (its cache) and return the corresponding record or the 329 corresponding lower-level DNS server IP address. 331 5) AIP DNS GW B repeats last step 4) until it finds the correct 332 record, namely the IP address Gb2 of the domain name Nb2. 334 6) AIP DNS GW B turns the internal domain name "Nb2" into external 335 domain name "Nb2.B" in the returned result by adding local AIP 336 network domain name suffix "B", and then caches the result and 337 return the result to AIP DNS GW A. 339 Step 5: AIP DNS GW A caches the returned result and return the result 340 to local DNS server. 342 Step 6: Local DNS server caches the returned result and returns the 343 result to source host Na1. 345 Therefore, host Na1 (Ga1) now can communicate with host Nb2 (Gb2) 346 after it gets the IP address of the destination host Nb2. 348 4. Conclusion 350 Autonomous Internet DNS provides a technology to realize Internet 351 autonomy, which can own independent root DNS server even in 352 unilateral action. And it could be realized in high independence, 353 extensible usage, the least cost and non transition period. It is 354 hopeful to establish future autonomous extensible multi-polar 355 Internet and resolve the autonomous problem of Internet. 357 5. Security Considerations 359 There is no additional security requirement than current domain name 360 system. Security issues are not discussed in this memo. 362 6. IANA Considerations 364 As described by AIP DNS rule 2 in Section 2.2, different AIP network 365 default domain name suffix needs to be assigned by IANA. 367 7. Acknowledgments 369 The authors would like to thank everybody for their valuable opinion 370 and evaluation to this document. 372 Following are some FAQs: 374 1).The I-D does not split the DNS at all. It plays with words by 375 pretending it will allow several roots but this is not true. 376 Instead, it creates a super-root (the one which will allocate 377 the AIPs, the .A and .B in the examples) and therefore just 378 displaces the (real) problems to the super-root. 380 A:Yes, this I-D does not split the DNS at all and just make it more 381 extensible and flexible! It is ridiculous rumor to say that 382 anybody could and wanted to split the Internet too! 384 Here is a super-root in this draft in mathematical sense. 385 It is the way to smoothly transfer to AIP DNS and provides 386 DNS resolution among all these AIP networks. If we provide the 387 domain name suffix, common sense is available globally. It 388 satisfies the two essentail preconditions in RFC 2826: 389 - The existence of a common symbol set, and 390 - The existence of a common semantic interpretation of these 391 symbols. 393 But in practical you can run your own root in each AIP network. 394 It provides automony and extensibility. 396 Technically, it is extensible choice for countries, global 397 operators, and specific internet networks such as Things of 398 Internet. 400 Of course, there are more other applications as you need. 402 2).Has the AIP technology considered the possibility of disruption 403 to Internet communications? 405 A:This would not affect Internet communications in traditional ways. 406 Based on Internet practice, autonomous internet (AIP) techinology 407 can transform the Internet into Autonomous Internet (AIP) without 408 protocol change, using mode change, transition period. 410 It would be more reasonable and efficient that internal domain 411 name resolution is no longer via the DNS outside this AIP network. 413 And as described by AIP DNS rule 2 in Section 2.2, different AIP 414 network's default domain name suffix needs to be assigned by IANA, 415 or other international organization, or it can be negotiated 416 directly by multi-stakeholder organizations like ICANN. 418 3).Does the AIP technology propose to use recursive DNS access 419 between AIPs? It is likely to have serious scaling issues. 421 A:This recursive translation would happen only in local DNS server 422 and AIP DNS GW but not AIP DNS roots. 424 4).If, for example, I am in a Chinese AIP and want to access 425 www.example.com, but I want to get to the one that would be 426 accessible from Brazil, do I access "www.example.com", 427 "www.example.com.ex", www.example.com.br.ex", or something 428 else? Is there any reason to believe that the resource 429 record for www.example.com within the AIP is the same as the 430 one for the same name in some other AIP? I worry about that, 431 as much as anything, because international business and 432 communication depends on a common understanding of resource 433 records; if a vendor in country A wants to make a product or 434 service available to a potential customer in country B (or 435 for that matter in all countries), it gives one URI/URL to 436 all of them and they all have access to it. If there is 437 significant confusion at this level, sending for example 438 requests intended for Google to Baidu, it will have a 439 significant and negative effect on international business 440 and communications. 442 A:AIP just provides more flexiblility and possibility to 443 international business and communications. For Google or Baidu, 444 they can apply different local URL for different country to 445 provide differentiate services as usual(for example www.google.cn, 446 www.google.com.hk...); or they can apply a unified URL for all 447 countries such as www.google.com and just provide a link for 448 different countries. 450 In AIP, The another additional possibility is to apply identical 451 local URL for different country to provide differentiate services. 453 5).Do you agree that the economic importance of international trade 454 far outweighed the value of having an autonomous naming system...? 456 A:I agree thoroughly that new technologies should provide more 457 flexiblility and possibility for people equally but not limit 458 the free and equal international communication right-it is the 459 soul of Internet forever! 461 6).Could you comment on the proposal, explaining in more detail 462 what you have in mind, and how (a) the service remains 463 scalable, and (b) the service supports the international 464 objectives of business interests that use it? 466 A:AIP technology is so simple as it describe in this draft. 467 The prospect of future Internet would be more open and scalable 468 if we can just imagine openly! 470 8. References 472 8.1. Normative References 474 [RFC 791] Postel, J., ed., "Internet Protocol - DARPA Internet 475 Program Protocol Specification", RFC 791, September 1981. 477 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 478 STD 13, RFC 1034, November 1987. 480 [RFC1035] Mockapetris, P., "Domain names - Implementation and 481 Specification", STD 13, RFC 1035, November 1987. 483 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 484 (IPv6) Specification", RFC 2460, December 1998. 486 8.2. Informative References 488 [RFC1706] B. Manning, and R. Colella, "DNS NSAP Resource Records", 489 RFC 1706, October 1994. 491 [RFC3596] S. Thomson, C. Huitema, V. Ksinant, and M. Souissi, "DNS 492 Extensions to Support IP Version 6", RFC 3596, October 493 2003. 495 [RFC2782] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for 496 specifying the location of services (DNS SRV)", RFC 2782, 497 February 2000. 499 Authors' Addresses 501 Diao Yuping 502 Information Institute of Guangdong University of Finance & Economics, 503 21 Luntou Road, Haizhu District, 504 Guangzhou 510320, China. 506 Email: diaoyp73@yahoo.com 508 Diao Yongping 509 China Telecom-Guangzhou Institute, 510 Guangzhou 510630, China. 512 Email: diaoyp@yahoo.com 514 Liao Ming 515 Guangzhou 510631, China. 517 Email: luminous_liao@yahoo.com