The draft also uses local cache. Besides of technologies now used, it adds a virtual overlay P2P layer, and cache route informaion. If queries can not find the right data in the local cache, this draft goes to the servers in the upper layer of tree or the servers having the minimun hop distance with authoritative server, instead of going to the root servers. This draft can work well in sub networks when they are disconnected with other outside networks.
>From: Edward Lewis <[EMAIL PROTECTED]> >Reply-To: >To: dnsop@ietf.org >Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt >Date:Wed, 25 Jun 2008 11:30:42 -0400 > >Regarding: >http://www.ietf.org/internet-drafts/draft-licanhuang-dnsop-distributeddns-04.txt > >This document begins with a faulty problem statement, shows an >apparent misunderstanding of how the DNS functions and seems to not >recognize what DNS's great strengths are. Whether the idea is a >"solution looking for a problem"[0] is not an issue for me (as *this* >is the IETF). ;) > >One of the great strengths of the DNS is the lightweight nature of >data lookup. A querier can expect an answer back in a very short >amount of time. This is accomplished by structuring the query in a >way that deterministically identifies where the information should be >and a very constrained algorithm for seeking possible alternate >locations. Adding an hierarchical overlay network to help queries to >find answers would only detract from this strength of DNS. > >Where there seems to be a misunderstanding of the protocol is in the >terminology that name servers mentioned as being in a tree structure. >Perhaps this is from an unclear interpretation of the Introduction. >Nevertheless, in DNS, the data is in a tree structure, the name >servers are not. The significance of this is that some query lookups >can be done by just asking a local cache, or the local cache >consulting maybe one or two other servers, neither being a root >server (in this case I am not being specific to the ICANN root >servers). > >The document appears to assume that the DNS functions without caches. >It is not true that all queries go to the root, nor even a TLD. It >is entirely possible that a recursive, iterating, caching server >already has the records for the root and TLD servers, as well as a a >number of widely popular lower level domains (such as bbc.co.uk or >amazon.com). In this case, a new query could result in just a query >to one server authoritative for the desired data. > >As far as a solution in search of a problem, I really don't see any >applicability to the query-response function of the DNS. However >there may be something more interesting in the zone data replication >problem. E.g., while AXFR, IXFR, and NOTIFY are fully functional >means for passing a zone from one name server to another, the >mechanisms do have their (performance) limitations. > >[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. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >Never confuse activity with progress. Activity pays more. >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
