Edward Lewis wrote:
> [0] - I cringe when I see a response to a new idea that contains that
> phrase. It can be so, um, anti-innovative and un-motivating plus
> antagonistic. Sometimes the application of a tool to a problem may be
> wrong though sometimes it can spark another idea.
I promised I would reread this, and try to be constructive
about it. The idea of P2P DNS intrigues me, so I thought I'd
give it a shot.
> <draft-licanhuang-dnsop-distributeddns-04.txt> ZST University
[...]
> Abstract
>
> This file is a proposal for P2P based Domain Name 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.
Already there, as has already been pointed out, we have a flawed
and unsupported assertion.
> for Domain Name query and reverse Domain Name query in IpV6 for a
> large number of domain names.
Question: Why is this limited to IPv6 ?
> 1. Introduction
>
> Although DNS becomes a vital component in today's Internet
> infrastructure, the existing DNS architecture will encounter problems
> in the future for the growth of the Internet.
Comment: DNS has already become a vital component in today's Internet
infrastructure.
Also, "will encounter problems" needs to be supported. The rest
of the document does not provide examples, or refer to external
document that may support this assertion.
> 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.
Question: What overload ?
> There are huge numbers of IP address in IpV6. Moreover, there may be
> use case for multi domain names associated with a sigle IP address.
And vice versa.
> DNS implementation currently used may encounter overload traffic in
> root DNS servers.
Question: why ?
> This document uses VIRGO[VIRGO] overlay network to solve the above
> problem.
The problem area is stated, but never fully developed or supported
in the rest of the document.
> Unlike query pathes currently used in Domain Name
> Systems allways go to root servers,
Comment: only initial queries go to the root, they are (often)
subsequently cached. Ed Lewis pointed out the two great strengths
of DNS, there are in fact three: distribution/replication, hierarchy,
and caching.
> Virtual Hierarchical Overlay
> Network for DNS routes quest message to the server with theoretical
> least hops from destination server.
Question: Based on which metric ? How would this be different from
say anycasting the addresses and relying on the routing protocol
to solve the least hops question ?
> 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 node role which takes part in routing functions in
> several different layers of virtual groups.
Question: what impact on the operational requirements of existing
DNS installations would this have ?
> 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.
Question: In 4.2, it is specified:
> 1. P_join finds one of Domain Name Servers P_groupToJoin(which
> belongs to virtual group--joinGroup) sharing maximium prefixs
with
> P_join.
Above, it is mentioned "broadcast the message to all Domain Name
Servers" in the virtual group.
1. What communication type is used to find "one of the Domain Name
Servers
which shares the maximum prefixes" ?
2. I imagine that the broadcast mentioned is some kind of P2P discovery/
flooding mechanism ?
... there are other implementation questions which remain to be
discussed, but I fail to see the point for the time, until more
critical issues like whether this draft addresses any real problems
have been resolved.
> 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.
Question: Why ?
Yes, IPv6 space is immense, but for the foreseeable future, only a
very small part of it will be populated. Same goes for IP6.ARPA.
But there are no data, either by you or others, supporting the
claim that it will be more difficult to accomodate reverse
information as IP6.ARPA grows.
Do you have some simulation, model or other data-based prediction
that can be used to illustrate this problem ?
> 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.
Comment: there is therefore a significant impact on operations ?
(this is to be expected, in a P2P model, as the burden of resolution
is moved away from a single root, if I understand this document
correctly)
> 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.
Question: How so ? (enhance security, that is).
Conclusion:
I find the idea interesting of using a P2P layer for DNS
resolution, even if it's only partial. I can also see that
a bit of thinking has gone into the design, but I still don't
see the postulate of the initial problem statement demonstrated.
Phil
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
