idnits 2.17.1 draft-licanhuang-dnsop-distributeddns-13.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages -- Found 17 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5. IANA Considerations' ) ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 534: '...ervers before joining P2P network MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 114 has weird spacing: '...ly used in Do...' == Line 141 has weird spacing: '...t layer is th...' == Line 173 has weird spacing: '... Server maint...' == Line 176 has weird spacing: '...dresses of Fo...' == Line 254 has weird spacing: '...r.music with ...' == (14 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'AGENT' is defined on line 702, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNDOP L. Huang 3 Internet-Draft Hangzhou Domain Zones Tech.Co.,Ltd. 4 Intended status: Standards Track 5 Expires: July 27, 2013 January 28,2013 7 Distributed DNS Implementation in IpV6 8 draft-licanhuang-dnsop-distributeddns-13.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on July 27, 2013 . 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (http://trustee.ietf.org/license- 39 info) in effect on the date of publication of this document. Please 40 review these documents carefully, as they describe your rights and 41 restrictions with respect to this document. Code Components extracted 42 from this document must include Simplified BSD License text as 43 described in Section 4.e of the Trust Legal Provisions and are provided 44 without warranty as described in the Simplified BSD License. 46 Abstract 48 This file is a proposal for P2P based Domain Name query strategy in 49 IpV6. The DNS servers construct n-tuple overlay virtual hierarchical 50 overlay network. With cached addresses of DNS servers, the overload of 51 traffic in tree structure can be avoided and more security can be 52 enhanced due to the random lookup paths. This strategy may use for 53 Domain Name query and reverse Domain Name query in IpV6 for a large 54 number of domain names. 56 Table of Contents 58 1. Introduction ................................................3 59 2. Virtual Hierarchical Overlay Network for DNS ................3 60 2.1 DNS Query Strategy ......................................5 61 2.2 Route Table Definitions..................................6 62 2.3 Reverse Resolution.......................................6 63 2.4 Message..................................................7 64 3. Some Notes ..................................................12 65 3.1 Complexity...............................................12 66 3.2 Random trace.............................................12 67 4. Security Considerations......................................13 68 5. IANA Considerations..........................................13 69 6. Acknowledgements.............................................13 70 7. Appendix A: protocols of establishment and lookup ...........14 71 7.1 Primitives and Functions ................................14 72 7.2 Protocol of Network Establishment........................14 73 7.3 lookup protocol..........................................15 74 8. References ..................................................17 75 8.1. Normative References ..................................17 76 8.2. Informative References ................................17 77 Author's Address ...............................................17 79 1. Introduction 81 Because the Webs have large number of Domain name links, DNS 82 becomes a vital component in today's Internetinfrastructure. 83 However, the existing DNS architecture will encounter problems 84 in the future for the growth of the Internet. 86 This file is a proposal for P2P based DNS query stratagy in IpV6. The 87 DNS servers construct n-tuple overlay virtual hierarchical overlay 88 network. With cached addresses of DNS servers, the overload of 89 traffic in tree structure can be avoided and more securtity can be 90 enhanced due to the random lookup paths. This strategy may be used 91 in DNS query in IpV6 for a large number of domain names. 93 There are huge numbers of IP address in IpV6. Moreover, there may be 94 a use case for multi domain names associated with a sigle IP address. 95 Pervasive computing will enlarge the numbers of DNS lookups. DNS 96 implementation currently used may encounter overload traffic in root 97 DNS servers. This document uses VIRGO[VIRGO] overlay network to solve 98 the above problem. VIRGO is a multi-tuple virtual hierarchical 99 overlay network with cached node address. We here change some places 100 to suit the distributed DNS implementation. The lookup protocols of 101 DNS is similar as the protocols in VIRGO[VIRGO], which is 102 illustrated in detail in the paper[P2PSD] titled as A P2P service 103 discovery strategy based on content catalogues. 105 2. Virtual Hierarchical Overlay Network for DNS 106 Virtual Hierarchical Overlay Network for DNS is a hybrid of 107 unstructured P2P and structured P2P technologies. The DNS servers 108 construct multi-tuple Virtual Hierarchical Overlay Network. Some 109 servers are only leaves of the network, others may coexist in 110 different layers. These servers form a duplicated virtual 111 hierarchical tree, with one root layer, several middle layers, and 112 many leaf virtual nodes. Random connections cached in a DNS server's 113 routing table are maintained. The servers in the same domain are 114 fully connected. Unlike query pathes currently used in Domain Name 115 Systems allways go to root servers, Virtual Hierarchical Overlay 116 Network for DNS routes quest message to the server with theoretical 117 least hops from destination server. The route tables of Domain Name 118 servers contains two kinds of route addresses, tree addresses, which 119 are prerequiste, and cached addresses. 121 The following is some terms related to the Virtual Hierarchical 122 Overlay Network for DNS. 124 Domain Name Server is a node which keeps local domain RRs[RFC1035]. 125 All the Domain Name Servers are the same except some Domain Name 126 Servers taking the function of gateways in the meantime. Every Domain 127 Name Server just controls the leaves of the domain. Every Domain Name 128 Server contains route table. Every Domain Name Server uses its 129 controlled domain name by cutting off leaves as its Identification, 130 which is called as Domain Name Server Identification (DNSI). For 131 example, for Grid.network.computer.science, 132 Wireless.network.computer.science, etc., Domain Name Servers have 133 Identifications -- network.computer.science. It keeps RRs for 134 Grid.network.computer.science,Wireless.network.computer.science,etc. 135 The Domain Name Server can be replicated by machines with different 136 IP addresses, but all with same RRs and route tables. 138 Gateway is a nodee which takes part in routing functions in 139 several different layers of virtual groups. 141 Gateway uppermost layer is the uppermost virtual group layer that 142 the gateway is in. The layers can be calculated by the domain 143 lengths of node ID. 145 Virtual group is formed virtually by the gateways nodes. The Group 146 Name is part of the node's domain name, eg. in the above example, 147 science, science.computer, science.computer.network are group names. 149 N-tuple virtual group tree (denoted by NVGT) is a hierarchical tree 150 formed by virtual groups. Among the nodes of the lower layer virtual 151 groups, N-tuple gateway nodes in each group are chosen to form upper- 152 layer groups, and from the nodes of these upper-layer groups to form 153 upper-upper-layer groups in the same way, and this way is repeated 154 until a root-layer group is formed. 156 In the Virtual Hierarchical Overlay Network for DNS, all Domain Name 157 Servers consist of N-tuple virtual group tree. The Virtual 158 Hierarchical Overlay Network can be established by manual or 159 automatedly by establishment protocol which is shown in Appendix A. 161 Domain Name Servers are virtually architectured as Tree Structure. 162 Some Domain Name Servers takes roles of gateways. When a Domain 163 Name Server joins the network, it first finds one of Domain Name 164 Servers which share the maxmium prefixs with the joining Domain Name 165 Server, then the joining server sends the JOINMESSAGE to the 166 latter, the latter will broadcast the message to all Domain Name 167 Servers in the virtual group. The Network establishment is shown at 168 Appendix 4.2. 170 2.1 DNS Query Strategy 172 Every DNS server is the same but some coexist in more than one layer. 173 Every DNS Server maintains a route table and a RR record related to 174 its Domain. Route table includes addresses of Foreign Name Servers 175 which are prerequiste for Virtual Hierarchical Overlay Network and 176 cached addresses of Foreign Name Servers which are refreshed by TTL 177 rule. The query process is shown as the following figure. 179 | Foreign 180 | 181 Local Host | 182 | 183 +-------+ +--------+ | +-------+ +-------+ 184 | | user queries | |queries | | | | | 185 |User |------------->| Local |---------|->|Foreign|-->| Tree +| 186 |Program| | Name | | |Name | | Cache | 187 | |<-------------| Server |<--------|--|Server |<--|(route | 188 | |user responses| |responses| | | | table)| 189 +-------+ +--------+ | +-------+ +-------+ 190 | A A | | 191 Route cache operations | | |___________|____ | 192 | | | | | 193 V | | | V 194 +----------------+ | +--------+ +------+ 195 | Tree + | | |Authori-| | | 196 | Cache | | |tive |-->| RR | 197 | (route table) | | |Name |<--| | 198 +----------------+ | |Server | | | 199 | +--------+ +------+ 201 The query process is as the following: User program sends QUERY 202 MESSAGE to Local Name Server. If Local Name Server is the authoritive 203 Domain Name Server, then the Local Name Server will check its RR to 204 resolve the request Domain name. Otherwise, The Local Name Server 205 will routes to the Foreign Name Server which is closer to the 206 authoritive Domain Name Server by calculating theoretical hops. Then 207 the Foreign Name Server routes to the even closer Foreign Domain Name 208 Server. Repeat this process, until the authoritive Domain Name Server 209 has been found. Finally, the authoritive Domain Name Server resolves 210 request Domain Name by check its RR record, and responses to the 211 Local Name Server. The latter will forward the response to the User 212 Program. The details of the algorithm can be found in Appendix A. 214 2.2 Route Table Definitions 216 All Route Tables have the same top level format shown below, which is 217 also called as Domain Server Node Entity(DSNE): 219 +------------+------------------------------------------------------+ 220 |Section Name| Description | 221 +------------+------------------------------------------------------+ 222 |DNSI |Domain Name Server Indetification of an Domain Server| 223 +------------+------------------------------------------------------+ 224 |TYPE |route TYPE codes (TREE as 0, CHACHE as 1) | 225 +------------+------------------------------------------------------+ 226 |TTL |the time interval that the route record may be cached | 227 | |before the source of the information should again be | 228 | |consulted. | 229 +------------+------------------------------------------------------+ 230 |UTS |Unreachable time stamp.If the route was cached, then | 231 | |reflesh it by TTL rule.If the route is gateway node in| 232 | |virtual tree structure,notice to manager to repair it.| 233 +------------+------------------------------------------------------+ 234 |IPADDRESSes | IP addresses of the replicated Domain Servers | 235 +------------+------------------------------------------------------+ 237 2.3 Reverse Resolution 239 Reverse Resolution uses .IN-ADDR.ARPA domain today. In IPv6, 240 .IP6.ARPA was defined by [RFC3152], and more detail information can 241 be found in [RFC3596]. Because IPv6 has a huge Name Space, it is 242 difficult to keep reverse RRs in today's architecture. Here, an 243 approach with Virtual Hierarchical Overlay Network for DNS can solve 244 the above problem. Domain Name Servers managing local networks is 245 called as the hierarchical address Domain just like Domain Name 246 Resolution. These Domain Name Servers join the Virtual Hierarchical 247 Overlay Network for DNS. The records of route table is the same as 248 the Domain Name Resolution. DNSI(Domain Name Server Indetification 249 of an Domain Server) is like as: 250 fea5.47ff.203.8002.0.200.2001.IP6.INT with Server IP Address 251 2001:200:0:8002:203:47ff:fea5:0010 resolutes the Domain Name from 252 2001:200:0:8002:203:47ff:fea5:0 to 253 2001:200:0:8002:203:47ff:fea5:ffff. Whereas in Domain Name 254 resolution, popular.music with Server IP Address 255 2001:200:0:8002:203:47ff:fea5:0010 solutes www.***.popular.music 256 Domain Names. The servers for popular.music and 257 fea5.47ff.203.8002.0.200.2001.IP6.ARPA can be same or different. 258 Reverse Domain Name Servers joins Virtual Hierarchical Overlay 259 Network for DNS is the same as Domain Name Servers , and also use 260 protocol shown at Appendix 4.2. The query protocol is also the same 261 as Domain Name Resolution, which is shown as Appendix 4.3. The Total 262 address space of IPv6 is huge. But, only the Reserve Domain Name 263 Servers managing used IP addresses will join the Virtual Hierarchical 264 Overlay Network for DNS. And the worst maxium query steps are 32. 265 With route cache the query steps will be less than 32. Therefore, 266 this strategy for Reverse Resolution is feasible. 268 2.4 Message 270 2.4.1 DNS Message format 272 +---------------+-----------+---------------------------------------+ 273 |Section Name |Size(bytes)| Description | 274 +---------------+-----------+---------------------------------------+ 275 |Header | 12 |indicating the type of message and the | 276 | | |number of entries in the other sections| 277 | | |of the message | 278 +---------------+-----------+---------------------------------------+ 279 |Question |variable |querying or joining information | 280 +---------------+-----------+---------------------------------------+ 281 |Answer |variable |resource records matchmaking questions | 282 | | |or confirmation answer | 283 +---------------+-----------+---------------------------------------+ 284 |Additional |variable |Conveys one or more resource records | 285 | | |relative to the query | 286 +---------------+-----------+---------------------------------------+ 287 |Join |variable |Server's joining information | 288 +---------------+-----------+---------------------------------------+ 289 |Confirmation |variable |Confirmation for server's join | 290 +---------------+-----------+---------------------------------------+ 291 2.4.2 Domain Name Node Entity format 293 1 1 1 1 1 1 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 295 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 296 | DSNELen | 297 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 298 | DNSILen | 299 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 300 | | 301 / DNSI / 302 / / 303 | | 304 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 305 | TYPE | 306 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 307 | TTL | 308 | | 309 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 310 | UTS | 311 | | 312 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 313 | NumRDS | 314 | | 315 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 316 | | 317 / IPADDRESS1 / 318 / ... / 319 / IPAddressn / 320 | | 321 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 323 Here, DSNELen is the length of Domain Name Node Entity, and 324 DNSILen is the length of Domain Name Server Identification. NumRDS 325 is the number of replicated Domain Name Server IP Addresses. 327 2.4.3 DNS Message Header Format 329 1 1 1 1 1 1 330 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 331 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 332 | ID | 333 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 334 |QR| Opcode |AA|TC|RD|RA|CA|NF|Z | RCODE | 335 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 336 | QDCOUNT | 337 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 338 | ANCOUNT | 339 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 340 | NSCOUNT | 341 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 342 | ARCOUNT | 343 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 345 where: 347 The items are the same meaning with [RFC1035] except for the 348 following: 350 QR A one bit field that specifies whether this message is 351 a query/join(0), or a response/confirmation(1). 352 OPCODE A four bit field that specifies kind of query in this 353 message. This value is set by the originator of a 354 query and copied into the response. The values are: 355 0 a standard query (QUERY) 356 1 an inverse query (IQUERY) 357 2 a server status request (STATUS) 358 3 Server join 359 4-15 reserved for future use 361 CA Confirmation answer for authoritative server join. 363 NF 0 for RFC 1035, 1 for this specification 365 Z Reserved for future use. Must be zero in all 366 queries and responses. 368 2.4.4 Question section format 370 The question section is used to carry the "question" in most queries, 371 i.e., the parameters that define what is being asked. The section 372 contains QDCOUNT (usually 1) entries, each of the following format: 374 1 1 1 1 1 1 375 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 377 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 378 | | 379 / LocalNSIP / 380 / / 381 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 382 | | 383 / QNAME / 384 / / 385 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 386 | QTYPE | 387 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 388 | QCLASS | 389 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 391 where: 393 The items are the same meaning with [RFC1035] except for the 394 following: 396 LocalNSIP Local Name Server IP address used for sending back the 397 anwser from any zone server. 399 2.4.5 Answer section format 401 1 1 1 1 1 1 402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 404 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 405 | | 406 / RRs / 407 / / 408 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 409 | | 410 / AuthoritiveDSNE / 411 / / 412 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 414 where: 415 The items are the same meaning with [RFC1035] except for the 416 following: 418 AuthoritiveDSNE Node entity of the Authoritive Name Server used for 419 cached 420 routetable 422 2.4.6 Join section format 424 1 1 1 1 1 1 425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 427 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 428 | | 429 / JoinDSNE / 430 / / 431 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 433 where: 435 JoinDSNE Joining Domain Server Node Entity 437 2.4.7 Confirmation section format 439 1 1 1 1 1 1 440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 442 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 443 | | 444 / ConfirmationDSNE / 445 / / 446 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 448 where: 450 ConfirmationDSNE Node Entity of Domain Server 451 confirming joining Domain Serve 453 3. Some Notes 455 This specification is compliant with [RFC1035]. 457 High performance and stable computers are chosen as gateway 458 nodes. Because the gateway node not only manages local RRs,but also 459 routes messages. The virtual tree structure requires gateway node 460 stable. 462 Due to the prerequiste tree, every Domain Name Server can reach 463 other ones. Due to redundant gateway nodes, the virtual tree can be 464 allways maintaned. 466 Due to the random cached nodes in the route table of every Domain 467 Name Server, the route paths are randomly chosen. This may avoid the 468 network trafic in tree-like structure. This may also enhance the 469 security of the DNS. 471 3.1 Complexity 473 The time complexity, space complexity and message-cost of the 474 proposed architecture is O(L), where L is the lengths of Domain Name. 476 Because the DNS server nodes are virtually organized as a tuple 477 virtual tree, every DNS server has a route table which includes 478 prerequisite DNS servers' IP addresses for Tree Paths (TREE portion) 479 and cached DNS servers' IP addresses (CACHED portion). 481 Because the message is routed according to the minimum of 482 theoretical distance from destination node , and the route table 483 contains TREE portion, every hop reduces the distance from 484 destination node by at least one hop, Therefore, 486 hops(a,b) < length(a) + length(b)-1 (1) 488 Where, hops(a,b) is for the hops from node a to node b; 489 length(a),length(b) are for 490 node a domain name lengths and node b domain name lengths 491 respectively. 492 For example, the length of www.nic.fr is 3. So, 494 time complexity = O(L) (2) 496 message_cost = O(L) (3), 497 where L is the length of domain name. 499 Because the route table of the virtual gateway nodes virtually 500 existed from root layer to bottom layer groups has the maximum 502 route items of nodes's information, 503 we have: 505 MaxItems = L*N_tuple*nvg +Max_Cached (4) 507 ,where L is the length of domain name., N_tuple is multiplicity of 508 gateway nodes for virtual tree, 509 nvg is number of virtual groups, Max_Cached is the maximum number 510 of cached records in the route table 512 Therefore, 514 Space Complexity = O(L) (5) 516 Also due to the cached information of DNS servers, the performance of 517 DNS lookups may reach 0(1) due to Zipf's law[VIRGODNS]. 519 3.2 Random trace 521 Every node has a path to any other node. Supposing a-->b. Every route 522 step has passible paths of the number of elements of route table of the 523 node. Thus, the diffrent numbers of paths is about |routetable(a)| at 524 DNS server a. In the same way, the diffrent numbers of paths can be 525 choosed is about |routetable(vi)| at DNS server vi. Therefore, 526 the totoal number of paths is: 528 |routetable(a)| X ...X|routetable(vi)| X...X |routetable(vn)| . 529 vi...vn are intermediate route nodes. 530 Therefore, the communication path would be random. 532 4. Security Considerations 534 For security consideration, the DNS servers before joining P2P network MUST 535 be approved by the upper layer organizations. layer organizations should be 536 controlled by trustful communities. 538 5. IANA Considerations 540 This document consists entirely of DNS IANA Considerations. 542 6. Acknowledgements 544 Thanks for Luke Kenneth Casson Leighton's valuable opinions. 546 7. Appendix A: protocols of establishment and lookup 548 7.1 Primitives and Functions 550 sender.send (message,receiver), sender sends message to receiver 552 sender.send(message,receiver (- Set), sender sends message to 553 all the receivers belong to a Set 555 RouteTableAdd(DSNE,type), add DSNE to route table 557 lookup_location(DomainName),find the destination node's location 559 LengthOfSamePrefix(DomainName,DomainName), length of shared 560 prefixes between two nodes 562 LengthOfDomainName(DomainName), the length of DomainName 564 hopDistance2object(pi,DomainName), the theoretical hops from 565 the node to the destination node 567 selectRouteNodeFromRouteTable(DomainName), choose next hop node 568 from route table 570 checkupRRs(QUERYMESSAGE), retrieve RR record in RR database 572 7.2 Protocol of Network Establishment 574 Here, a new Domain Name Server P_join joins the network. If Header of 575 DNS Message is set to join, the Message is callaed as JOINMESSAGE;if 576 Header of DNS Message is set to confirmation, the Message is callaed 577 as CONFIRMATIONMESSAGE. 579 1. P_join finds one of Domain Name Servers P_groupToJoin(which 580 belongs to virtual group--joinGroup) sharing maximium prefixs with 581 P_join. 583 2. P_join.send(JOINMESSAGE, P_groupToJoin); 585 3. P_groupToJoin.send(JOINMESSAGE, pi (- joinGroup); 587 4. (pi (- joinGroup).send(pi.CONFIRMATIONMESSAGE, P_join); 588 (pi (- joinGroup).RouteTableAdd(P_join.DSNE,TREE); 590 5. P_join.RouteTableAdd((pi (- joinGroup).DSNE,TREE); 591 6. set joinGroup to one upper group; 593 7. set P_groupToJoin = pi (- joinGroup; 595 8. repeat step 2 to 7 until replicated nodes no less 596 than n-tuple in joinGroup or joinGroup is root group. 598 7.3 lookup protocol 600 Here, if Header of DNS message is set to query, the DNS Message is 601 callaed as QUERYMESSAGE; if Header of DNS message is set to response, 602 the DNS Message is callaed as RESULTMESSAGE. 604 Step 1 UserProgram.send (QUERYMESSAGE, LocalNameServer) 606 Step 2 authoritiveDNServer = 607 LocalNameServer.lookup_location(QUERYMESSAGE.DomainName) 609 Step 3 RESULTMESSAGE= 610 authoritiveDNServer.checkupRRs(QUERYMESSAGE); 612 Step 4 authoritiveDNServer=send(RESULTMESSAGE, 613 LocalNameServer); 615 Step 5 LocalNameServer.send(RESULTMESSAGE, UserProgram); 617 Step 6 618 LocalNameServer.RouteTableAdd(authoritiveDNServer.DSNE,CHACHE); 620 Where, function of lookup_location (locates the destination node by 621 the minimum hops) is as following: 623 Function p.lookup_location(QUERYMESSAGE) \{ 625 if LengthOfSamePrefix(p.DNSI,QUERYMESSAGE.DomainName)== 626 LengthOfDomainName(QUERYMESSAGE.DomainName)-1 628 return p; 629 else \{ 631 routeP = 632 p.selectRouteNodeFromRouteTable(QUERYMESSAGE.DomainName); 634 p.send(QUERYMESSAGE,routeP); 635 if (message sending is successful) 636 routeP.lookup_location(QUERYMESSAGE); 638 else \{ 640 Mark routeP as unreachable in p.routetable; 642 p.lookup_location(QUERYMESSAGE); \} 643 \} 644 \} 646 Where, function selectRouteNodeFromRouteTable(select route with 647 theoretical least hops from destination Domain Name Server) is as 648 following: 650 Function p.selectRouteNodeFromRouteTable(requestDomainName) 652 gnSet = 653 Minimum(p.hopDistance2object(pi (- RouteTable,requestDomainName)); 655 return routeP = random(gnSet); 657 Where, function hopDistance2object (calculating theoretical hops 658 from destination Domain Name Server) is as following: 660 Function p.hopDistance2object(pi,requestDomainName) 662 if LengthOfSamePrefix(pi.DNSI, requestDomainName) ==1 664 return LengthOfDomainName(requestDomainName)+pi.length -3; 666 elseif pi.length < LengthOfSamePrefix(pi.DNSI, requestDomainName) 668 return LengthOfDomainName(requestDomainName) - 669 LengthOfSamePrefix(pi.DNSI, requestDomainName)-1; 671 else 673 return LengthOfDomainName(requestDomainName)+pi.length - 674 2*LengthOfSamePrefix(pi.DNSI,requestDomainName)-1 676 8. References 678 8.1. Normative References 680 [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 681 SPECIFICATION",Specification," RFC1035, 682 USC/Information Sciences Institute,November, 1987. 683 [RFC3152] Bush, R., "Delegation of IP6.ARPA," RFC 3152, BCP 49, 684 August 2001. 685 [RFC3596] Thompson, S., C. Huitema, V. Ksinant, M. Souissi, "DNS 686 Extensions to Support IP Version 6," RFC 3596, October 2003. 688 8.2. Informative References 690 [VIRGO] Huang, L., "VIRGO: Virtual Hierarchical Overlay 691 Network for Scalable Grid Computing ",Proc. 692 European Grid Conference(EGC2005), in LNCS 3470, 693 p911-921, 2005. 694 [P2PSD] Huang, L., "A P2P service discovery strategy based on 695 content catalogues", Data Science Journal, Vol(6), 2007, 696 ppS492-S499. 697 http://www.jstage.jst.go.jp/article/dsj/6/0/S492/_pdf 698 [VIRGODNS] Huang, L.,"VIRGO P2P based distributed DNS framework 699 for IPv6 network",Proc. 4th International 700 Conference on Networked Computing and Advanced Information 701 Management(NCM 2008) 702 [AGENT] Huang, L.,"Constructing Large Scale Cooperative Multi-Agent 703 Systems from Semantic P2P Networks", Springer, 704 ISBN:978-3-642-34952-2, Vol(460),2013, pp257-277 706 Authors' Addresses 708 Lican Huang 709 Current Address: 710 Hangzhou Domain Zones Technology Co., Ltd. 711 & 712 Hangzhou Domain Search Network Technology Co., Ltd. 713 & 714 Zhejiang Sci_Tech University, 715 Hangzhou, P.R.China 716 EMail: lican.huang.hz@gmail.com; licanhuang@zstu.edu.cn; 717 huang_lican@yahoo.co.uk