DNDOP L. Huang
Internet-Draft Hangzhou Domain Zones Tech.Co.,Ltd.
Intended status: Standards Track
Expires: July 27, 2013 January 28,2013
Distributed DNS Implementation in IpV6
draft-licanhuang-dnsop-distributeddns-13.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on July 27, 2013 .
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/license-
info) in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components extracted
from this document must include Simplified BSD License text as
described in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Huang, Lican Expires July 27,2013 FORMFEED[Page 1]
Internet Draft DNS Impl in IPv6 January 28,2013
Abstract
This file is a proposal for P2P based Domain Name query strategy in
IpV6. The DNS servers construct n-tuple overlay virtual hierarchical
overlay network. With cached addresses of DNS servers, the overload of
traffic in tree structure can be avoided and more security can be
enhanced due to the random lookup paths. This strategy may use for
Domain Name query and reverse Domain Name query in IpV6 for a large
number of domain names.
Huang, Lican Expires July 27,2013 FORMFEED[Page 2]
Internet Draft DNS Impl in IPv6 January 28,2013
Table of Contents
1. Introduction ................................................3
2. Virtual Hierarchical Overlay Network for DNS ................3
2.1 DNS Query Strategy ......................................5
2.2 Route Table Definitions..................................6
2.3 Reverse Resolution.......................................6
2.4 Message..................................................7
3. Some Notes ..................................................12
3.1 Complexity...............................................12
3.2 Random trace.............................................12
4. Security Considerations......................................13
5. IANA Considerations..........................................13
6. Acknowledgements.............................................13
7. Appendix A: protocols of establishment and lookup ...........14
7.1 Primitives and Functions ................................14
7.2 Protocol of Network Establishment........................14
7.3 lookup protocol..........................................15
8. References ..................................................17
8.1. Normative References ..................................17
8.2. Informative References ................................17
Author's Address ...............................................17
1. Introduction
Because the Webs have large number of Domain name links, DNS
becomes a vital component in today's Internetinfrastructure.
However, the existing DNS architecture will encounter problems
in the future for the growth of the Internet.
This file is a proposal for P2P based DNS query stratagy in IpV6. The
DNS servers construct n-tuple overlay virtual hierarchical overlay
network. With cached addresses of DNS servers, the overload of
traffic in tree structure can be avoided and more securtity can be
enhanced due to the random lookup paths. This strategy may be used
in DNS query in IpV6 for a large number of domain names.
There are huge numbers of IP address in IpV6. Moreover, there may be
a use case for multi domain names associated with a sigle IP address.
Pervasive computing will enlarge the numbers of DNS lookups. DNS
implementation currently used may encounter overload traffic in root
DNS servers. This document uses VIRGO[VIRGO] overlay network to solve
the above problem. VIRGO is a multi-tuple virtual hierarchical
overlay network with cached node address. We here change some places
to suit the distributed DNS implementation. The lookup protocols of
DNS is similar as the protocols in VIRGO[VIRGO], which is
illustrated in detail in the paper[P2PSD] titled as A P2P service
discovery strategy based on content catalogues.
2. Virtual Hierarchical Overlay Network for DNS
Huang, Lican Expires July 27,2013 FORMFEED[Page 3]
Internet Draft DNS Impl in IPv6 January 28,2013
Virtual Hierarchical Overlay Network for DNS is a hybrid of
unstructured P2P and structured P2P technologies. The DNS servers
construct multi-tuple Virtual Hierarchical Overlay Network. Some
servers are only leaves of the network, others may coexist in
different layers. These servers form a duplicated virtual
hierarchical tree, with one root layer, several middle layers, and
many leaf virtual nodes. Random connections cached in a DNS server's
routing table are maintained. The servers in the same domain are
fully connected. Unlike query pathes currently used in Domain Name
Systems allways go to root servers, Virtual Hierarchical Overlay
Network for DNS routes quest message to the server with theoretical
least hops from destination server. The route tables of Domain Name
servers contains two kinds of route addresses, tree addresses, which
are prerequiste, and cached addresses.
The following is some terms related to the Virtual Hierarchical
Overlay Network for DNS.
Domain Name Server is a node which keeps local domain RRs[RFC1035].
All the Domain Name Servers are the same except some Domain Name
Servers taking the function of gateways in the meantime. Every Domain
Name Server just controls the leaves of the domain. Every Domain Name
Server contains route table. Every Domain Name Server uses its
controlled domain name by cutting off leaves as its Identification,
which is called as Domain Name Server Identification (DNSI). For
example, for Grid.network.computer.science,
Wireless.network.computer.science, etc., Domain Name Servers have
Identifications -- network.computer.science. It keeps RRs for
Grid.network.computer.science,Wireless.network.computer.science,etc.
The Domain Name Server can be replicated by machines with different
IP addresses, but all with same RRs and route tables.
Gateway is a nodee which takes part in routing functions in
several different layers of virtual groups.
Gateway uppermost layer is the uppermost virtual group layer that
the gateway is in. The layers can be calculated by the domain
lengths of node ID.
Virtual group is formed virtually by the gateways nodes. The Group
Name is part of the node's domain name, eg. in the above example,
science, science.computer, science.computer.network are group names.
N-tuple virtual group tree (denoted by NVGT) is a hierarchical tree
formed by virtual groups. Among the nodes of the lower layer virtual
groups, N-tuple gateway nodes in each group are chosen to form upper-
layer groups, and from the nodes of these upper-layer groups to form
upper-upper-layer groups in the same way, and this way is repeated
Huang, Lican Expires July 27,2013 FORMFEED[Page 4]
Internet Draft DNS Impl in IPv6 January 28,2013
until a root-layer group is formed.
In the Virtual Hierarchical Overlay Network for DNS, all Domain Name
Servers consist of N-tuple virtual group tree. The Virtual
Hierarchical Overlay Network can be established by manual or
automatedly by establishment protocol which is shown in Appendix A.
Domain Name Servers are virtually architectured as Tree Structure.
Some Domain Name Servers takes roles of gateways. When a Domain
Name Server joins the network, it first finds one of Domain Name
Servers which share the maxmium prefixs with the joining Domain Name
Server, then the joining server sends the JOINMESSAGE to the
latter, the latter will broadcast the message to all Domain Name
Servers in the virtual group. The Network establishment is shown at
Appendix 4.2.
2.1 DNS Query Strategy
Every DNS server is the same but some coexist in more than one layer.
Every DNS Server maintains a route table and a RR record related to
its Domain. Route table includes addresses of Foreign Name Servers
which are prerequiste for Virtual Hierarchical Overlay Network and
cached addresses of Foreign Name Servers which are refreshed by TTL
rule. The query process is shown as the following figure.
| Foreign
|
Local Host |
|
+-------+ +--------+ | +-------+ +-------+
| | user queries | |queries | | | | |
|User |------------->| Local |---------|->|Foreign|-->| Tree +|
|Program| | Name | | |Name | | Cache |
| |<-------------| Server |<--------|--|Server |<--|(route |
| |user responses| |responses| | | | table)|
+-------+ +--------+ | +-------+ +-------+
| A A | |
Route cache operations | | |___________|____ |
| | | | |
V | | | V
+----------------+ | +--------+ +------+
| Tree + | | |Authori-| | |
| Cache | | |tive |-->| RR |
| (route table) | | |Name |<--| |
+----------------+ | |Server | | |
| +--------+ +------+
Huang, Lican Expires July 27,2013 FORMFEED[Page 5]
Internet Draft DNS Impl in IPv6 January 28,2013
The query process is as the following: User program sends QUERY
MESSAGE to Local Name Server. If Local Name Server is the authoritive
Domain Name Server, then the Local Name Server will check its RR to
resolve the request Domain name. Otherwise, The Local Name Server
will routes to the Foreign Name Server which is closer to the
authoritive Domain Name Server by calculating theoretical hops. Then
the Foreign Name Server routes to the even closer Foreign Domain Name
Server. Repeat this process, until the authoritive Domain Name Server
has been found. Finally, the authoritive Domain Name Server resolves
request Domain Name by check its RR record, and responses to the
Local Name Server. The latter will forward the response to the User
Program. The details of the algorithm can be found in Appendix A.
2.2 Route Table Definitions
All Route Tables have the same top level format shown below, which is
also called as Domain Server Node Entity(DSNE):
+------------+------------------------------------------------------+
|Section Name| Description |
+------------+------------------------------------------------------+
|DNSI |Domain Name Server Indetification of an Domain Server|
+------------+------------------------------------------------------+
|TYPE |route TYPE codes (TREE as 0, CHACHE as 1) |
+------------+------------------------------------------------------+
|TTL |the time interval that the route record may be cached |
| |before the source of the information should again be |
| |consulted. |
+------------+------------------------------------------------------+
|UTS |Unreachable time stamp.If the route was cached, then |
| |reflesh it by TTL rule.If the route is gateway node in|
| |virtual tree structure,notice to manager to repair it.|
+------------+------------------------------------------------------+
|IPADDRESSes | IP addresses of the replicated Domain Servers |
+------------+------------------------------------------------------+
2.3 Reverse Resolution
Reverse Resolution uses .IN-ADDR.ARPA domain today. In IPv6,
.IP6.ARPA was defined by [RFC3152], and more detail information can
be found in [RFC3596]. Because IPv6 has a huge Name Space, it is
difficult to keep reverse RRs in today's architecture. Here, an
approach with Virtual Hierarchical Overlay Network for DNS can solve
the above problem. Domain Name Servers managing local networks is
Huang, Lican Expires July 27,2013 FORMFEED[Page 6]
Internet Draft DNS Impl in IPv6 January 28,2013
called as the hierarchical address Domain just like Domain Name
Resolution. These Domain Name Servers join the Virtual Hierarchical
Overlay Network for DNS. The records of route table is the same as
the Domain Name Resolution. DNSI(Domain Name Server Indetification
of an Domain Server) is like as:
fea5.47ff.203.8002.0.200.2001.IP6.INT with Server IP Address
2001:200:0:8002:203:47ff:fea5:0010 resolutes the Domain Name from
2001:200:0:8002:203:47ff:fea5:0 to
2001:200:0:8002:203:47ff:fea5:ffff. Whereas in Domain Name
resolution, popular.music with Server IP Address
2001:200:0:8002:203:47ff:fea5:0010 solutes www.***.popular.music
Domain Names. The servers for popular.music and
fea5.47ff.203.8002.0.200.2001.IP6.ARPA can be same or different.
Reverse Domain Name Servers joins Virtual Hierarchical Overlay
Network for DNS is the same as Domain Name Servers , and also use
protocol shown at Appendix 4.2. The query protocol is also the same
as Domain Name Resolution, which is shown as Appendix 4.3. The Total
address space of IPv6 is huge. But, only the Reserve Domain Name
Servers managing used IP addresses will join the Virtual Hierarchical
Overlay Network for DNS. And the worst maxium query steps are 32.
With route cache the query steps will be less than 32. Therefore,
this strategy for Reverse Resolution is feasible.
2.4 Message
2.4.1 DNS Message format
+---------------+-----------+---------------------------------------+
|Section Name |Size(bytes)| Description |
+---------------+-----------+---------------------------------------+
|Header | 12 |indicating the type of message and the |
| | |number of entries in the other sections|
| | |of the message |
+---------------+-----------+---------------------------------------+
|Question |variable |querying or joining information |
+---------------+-----------+---------------------------------------+
|Answer |variable |resource records matchmaking questions |
| | |or confirmation answer |
+---------------+-----------+---------------------------------------+
|Additional |variable |Conveys one or more resource records |
| | |relative to the query |
+---------------+-----------+---------------------------------------+
|Join |variable |Server's joining information |
+---------------+-----------+---------------------------------------+
|Confirmation |variable |Confirmation for server's join |
+---------------+-----------+---------------------------------------+
Huang, Lican Expires January 25,2013 FORMFEED[Page 7]
Internet Draft DNS Impl in IPv6 January 28,2013
2.4.2 Domain Name Node Entity format
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSNELen |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DNSILen |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ DNSI /
/ /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| UTS |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NumRDS |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ IPADDRESS1 /
/ ... /
/ IPAddressn /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Here, DSNELen is the length of Domain Name Node Entity, and
DNSILen is the length of Domain Name Server Identification. NumRDS
is the number of replicated Domain Name Server IP Addresses.
Huang, Lican Expires July 27,2013 FORMFEED[Page 8]
Internet Draft DNS Impl in IPv6 January 28,2013
2.4.3 DNS Message Header Format
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA|CA|NF|Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
The items are the same meaning with [RFC1035] except for the
following:
QR A one bit field that specifies whether this message is
a query/join(0), or a response/confirmation(1).
OPCODE A four bit field that specifies kind of query in this
message. This value is set by the originator of a
query and copied into the response. The values are:
0 a standard query (QUERY)
1 an inverse query (IQUERY)
2 a server status request (STATUS)
3 Server join
4-15 reserved for future use
CA Confirmation answer for authoritative server join.
NF 0 for RFC 1035, 1 for this specification
Z Reserved for future use. Must be zero in all
queries and responses.
Huang, Lican Expires July 27,2013 FORMFEED[Page 9]
Internet Draft DNS Impl in IPv6 January 28,2013
2.4.4 Question section format
The question section is used to carry the "question" in most queries,
i.e., the parameters that define what is being asked. The section
contains QDCOUNT (usually 1) entries, each of the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ LocalNSIP /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
The items are the same meaning with [RFC1035] except for the
following:
LocalNSIP Local Name Server IP address used for sending back the
anwser from any zone server.
2.4.5 Answer section format
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ RRs /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ AuthoritiveDSNE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Huang, Lican Expires July 28,2011 FORMFEED[Page 10]
Internet Draft DNS Impl in IPv6 January 28,2013
where:
The items are the same meaning with [RFC1035] except for the
following:
AuthoritiveDSNE Node entity of the Authoritive Name Server used for
cached
routetable
2.4.6 Join section format
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ JoinDSNE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
JoinDSNE Joining Domain Server Node Entity
2.4.7 Confirmation section format
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ConfirmationDSNE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ConfirmationDSNE Node Entity of Domain Server
confirming joining Domain Serve
Huang, Lican Expires July 27,2013 FORMFEED[Page 11]
Internet Draft DNS Impl in IPv6 January 28,2013
3. Some Notes
This specification is compliant with [RFC1035].
High performance and stable computers are chosen as gateway
nodes. Because the gateway node not only manages local RRs,but also
routes messages. The virtual tree structure requires gateway node
stable.
Due to the prerequiste tree, every Domain Name Server can reach
other ones. Due to redundant gateway nodes, the virtual tree can be
allways maintaned.
Due to the random cached nodes in the route table of every Domain
Name Server, the route paths are randomly chosen. This may avoid the
network trafic in tree-like structure. This may also enhance the
security of the DNS.
3.1 Complexity
The time complexity, space complexity and message-cost of the
proposed architecture is O(L), where L is the lengths of Domain Name.
Because the DNS server nodes are virtually organized as a tuple
virtual tree, every DNS server has a route table which includes
prerequisite DNS servers' IP addresses for Tree Paths (TREE portion)
and cached DNS servers' IP addresses (CACHED portion).
Because the message is routed according to the minimum of
theoretical distance from destination node , and the route table
contains TREE portion, every hop reduces the distance from
destination node by at least one hop, Therefore,
hops(a,b) < length(a) + length(b)-1 (1)
Where, hops(a,b) is for the hops from node a to node b;
length(a),length(b) are for
node a domain name lengths and node b domain name lengths
respectively.
For example, the length of www.nic.fr is 3. So,
time complexity = O(L) (2)
message_cost = O(L) (3),
where L is the length of domain name.
Because the route table of the virtual gateway nodes virtually
existed from root layer to bottom layer groups has the maximum
Huang, Lican Expires July 27,2013 FORMFEED[Page 12]
Internet Draft DNS Impl in IPv6 January 28,2013
route items of nodes's information,
we have:
MaxItems = L*N_tuple*nvg +Max_Cached (4)
,where L is the length of domain name., N_tuple is multiplicity of
gateway nodes for virtual tree,
nvg is number of virtual groups, Max_Cached is the maximum number
of cached records in the route table
Therefore,
Space Complexity = O(L) (5)
Also due to the cached information of DNS servers, the performance of
DNS lookups may reach 0(1) due to Zipf's law[VIRGODNS].
3.2 Random trace
Every node has a path to any other node. Supposing a-->b. Every route
step has passible paths of the number of elements of route table of the
node. Thus, the diffrent numbers of paths is about |routetable(a)| at
DNS server a. In the same way, the diffrent numbers of paths can be
choosed is about |routetable(vi)| at DNS server vi. Therefore,
the totoal number of paths is:
|routetable(a)| X ...X|routetable(vi)| X...X |routetable(vn)| .
vi...vn are intermediate route nodes.
Therefore, the communication path would be random.
4. Security Considerations
For security consideration, the DNS servers before joining P2P network MUST
be approved by the upper layer organizations. layer organizations should be
controlled by trustful communities.
5. IANA Considerations
This document consists entirely of DNS IANA Considerations.
6. Acknowledgements
Thanks for Luke Kenneth Casson Leighton's valuable opinions.
Huang, Lican Expires July 27,2013 FORMFEED[Page 13]
Internet Draft DNS Impl in IPv6 January 28,2013
7. Appendix A: protocols of establishment and lookup
7.1 Primitives and Functions
sender.send (message,receiver), sender sends message to receiver
sender.send(message,receiver (- Set), sender sends message to
all the receivers belong to a Set
RouteTableAdd(DSNE,type), add DSNE to route table
lookup_location(DomainName),find the destination node's location
LengthOfSamePrefix(DomainName,DomainName), length of shared
prefixes between two nodes
LengthOfDomainName(DomainName), the length of DomainName
hopDistance2object(pi,DomainName), the theoretical hops from
the node to the destination node
selectRouteNodeFromRouteTable(DomainName), choose next hop node
from route table
checkupRRs(QUERYMESSAGE), retrieve RR record in RR database
7.2 Protocol of Network Establishment
Here, a new Domain Name Server P_join joins the network. If Header of
DNS Message is set to join, the Message is callaed as JOINMESSAGE;if
Header of DNS Message is set to confirmation, the Message is callaed
as CONFIRMATIONMESSAGE.
1. P_join finds one of Domain Name Servers P_groupToJoin(which
belongs to virtual group--joinGroup) sharing maximium prefixs with
P_join.
2. P_join.send(JOINMESSAGE, P_groupToJoin);
3. P_groupToJoin.send(JOINMESSAGE, pi (- joinGroup);
4. (pi (- joinGroup).send(pi.CONFIRMATIONMESSAGE, P_join);
(pi (- joinGroup).RouteTableAdd(P_join.DSNE,TREE);
5. P_join.RouteTableAdd((pi (- joinGroup).DSNE,TREE);
Huang, Lican Expires July 27,2013 FORMFEED[Page 14]
Internet Draft DNS Impl in IPv6 January 28,2013
6. set joinGroup to one upper group;
7. set P_groupToJoin = pi (- joinGroup;
8. repeat step 2 to 7 until replicated nodes no less
than n-tuple in joinGroup or joinGroup is root group.
7.3 lookup protocol
Here, if Header of DNS message is set to query, the DNS Message is
callaed as QUERYMESSAGE; if Header of DNS message is set to response,
the DNS Message is callaed as RESULTMESSAGE.
Step 1 UserProgram.send (QUERYMESSAGE, LocalNameServer)
Step 2 authoritiveDNServer =
LocalNameServer.lookup_location(QUERYMESSAGE.DomainName)
Step 3 RESULTMESSAGE=
authoritiveDNServer.checkupRRs(QUERYMESSAGE);
Step 4 authoritiveDNServer=send(RESULTMESSAGE,
LocalNameServer);
Step 5 LocalNameServer.send(RESULTMESSAGE, UserProgram);
Step 6
LocalNameServer.RouteTableAdd(authoritiveDNServer.DSNE,CHACHE);
Where, function of lookup_location (locates the destination node by
the minimum hops) is as following:
Function p.lookup_location(QUERYMESSAGE) \{
if LengthOfSamePrefix(p.DNSI,QUERYMESSAGE.DomainName)==
LengthOfDomainName(QUERYMESSAGE.DomainName)-1
return p;
else \{
routeP =
p.selectRouteNodeFromRouteTable(QUERYMESSAGE.DomainName);
p.send(QUERYMESSAGE,routeP);
Huang, Lican Expires July 27,2013 FORMFEED[Page 15]
Internet Draft DNS Impl in IPv6 January 28,2013
if (message sending is successful)
routeP.lookup_location(QUERYMESSAGE);
else \{
Mark routeP as unreachable in p.routetable;
p.lookup_location(QUERYMESSAGE); \}
\}
\}
Where, function selectRouteNodeFromRouteTable(select route with
theoretical least hops from destination Domain Name Server) is as
following:
Function p.selectRouteNodeFromRouteTable(requestDomainName)
gnSet =
Minimum(p.hopDistance2object(pi (- RouteTable,requestDomainName));
return routeP = random(gnSet);
Where, function hopDistance2object (calculating theoretical hops
from destination Domain Name Server) is as following:
Function p.hopDistance2object(pi,requestDomainName)
if LengthOfSamePrefix(pi.DNSI, requestDomainName) ==1
return LengthOfDomainName(requestDomainName)+pi.length -3;
elseif pi.length < LengthOfSamePrefix(pi.DNSI, requestDomainName)
return LengthOfDomainName(requestDomainName) -
LengthOfSamePrefix(pi.DNSI, requestDomainName)-1;
else
return LengthOfDomainName(requestDomainName)+pi.length -
2*LengthOfSamePrefix(pi.DNSI,requestDomainName)-1
Huang, Lican Expires July 27,2013 FORMFEED[Page 16]
Internet Draft DNS Impl in IPv6 January 28,2013
8. References
8.1. Normative References
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION",Specification," RFC1035,
USC/Information Sciences Institute,November, 1987.
[RFC3152] Bush, R., "Delegation of IP6.ARPA," RFC 3152, BCP 49,
August 2001.
[RFC3596] Thompson, S., C. Huitema, V. Ksinant, M. Souissi, "DNS
Extensions to Support IP Version 6," RFC 3596, October 2003.
8.2. Informative References
[VIRGO] Huang, L., "VIRGO: Virtual Hierarchical Overlay
Network for Scalable Grid Computing ",Proc.
European Grid Conference(EGC2005), in LNCS 3470,
p911-921, 2005.
[P2PSD] Huang, L., "A P2P service discovery strategy based on
content catalogues", Data Science Journal, Vol(6), 2007,
ppS492-S499.
http://www.jstage.jst.go.jp/article/dsj/6/0/S492/_pdf
[VIRGODNS] Huang, L.,"VIRGO P2P based distributed DNS framework
for IPv6 network",Proc. 4th International
Conference on Networked Computing and Advanced Information
Management(NCM 2008)
[AGENT] Huang, L.,"Constructing Large Scale Cooperative Multi-Agent
Systems from Semantic P2P Networks", Springer,
ISBN:978-3-642-34952-2, Vol(460),2013, pp257-277
Authors' Addresses
Lican Huang
Current Address:
Hangzhou Domain Zones Technology Co., Ltd.
&
Hangzhou Domain Search Network Technology Co., Ltd.
&
Zhejiang Sci_Tech University,
Hangzhou, P.R.China
EMail: lican.huang.hz@gmail.com; licanhuang@zstu.edu.cn;
huang_lican@yahoo.co.uk
Huang, Lican Expires July 27,2013 FORMFEED[Page 17]