Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt

From: "黄理灿" <[email-masked]>
Date: Thu, 26 Jun 2008 13:13:57 +0800

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-masked]>
>Reply-To: 
>To: [email-masked]
>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 stFrom [email-masked]  Wed Jun 25 22:47:14 2008
From: "=?gb2312?B?u8bA7bLT?=" <[email-masked]>
To: "Edward Lewis" <[email-masked]>, [email-masked]
Date: Thu, 26 Jun 2008 13:13:57 +0800
Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Reply-To: =?gb2312?B?u8bA7bLT?= <[email-masked]>
Sender: [email-masked]

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-masked]>
>Reply-To: 
>To: [email-masked]
>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 struructure. 
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop
> 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

cture. 
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop
> 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 26 Jun 2008 11:09:21 +0100

On 26 Jun 2008, at 06:13, 黄理灿 wrote:

> 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.

	You seem to be assuming that whenever the "right data" is missing  
from the cache,
	no useful intermediate data is available locally either, so that the  
resolver
	will have to re-trace the path from the root, visiting an  
authoritative server
	for each zone cut along the way.  That's not how a caching resolver  
works, unless
	someone has perversely "prepared" it by flushing the cache.

	The suggested advantage of the overlay P2P layer which you propose  
seems to be
	based on comparison with a highly unrealistic "straw man" model of  
your own
	invention.  This doesn't help your argument.

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 26 Jun 2008 11:09:21 +0100

Best regards,

	Niall O'Reilly