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

From: "黄理灿" <[email-masked]>
Date: Tue, 24 Jun 2008 16:16:53 +0800

Hi,

I have updated distributed DNS implementation in Ipv6.

Please give your comments.

Thanks.

Dr. Lican Huang

>From: [email-masked]
>Reply-To: [email-masked]
>To: [email-masked]
>Subject: I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt 
>Date:Mon, 23 Jun 2008 15:45:01 -0700 (PDT)
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>	Title		: Distributed DNS Implementation in IpV6
>	Author(s)	: L. Huang
>	Filename	: draft-licanhuang-dnsop-distributeddns-04.txt
>	Pages		: 17
>	Date		: 2008-6-23
>	
>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. This strategy may use
>   for Domain Name query and reverse Domain Name query in IpV6 for a
>   large number of domain names.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-licanhuang-dnsop-distributeddns-04.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
> 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: 24 Jun 2008 17:30:12 +0000

> Please give your comments.

thank you for your work on this.  i find no support for this assertion:

	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.
	   ...
	   DNS implementation currently used may encounter overload traffic
	   in root DNS servers.  ...

therefore while i find your proposed solution to be of high quality, there
is a cost in overall system complexity for adding a virtual routing layer to
the DNS, which would have to be justified by a much more complete problem
statement and an objective analysis of more than one alternative.
-- 
Paul Vixie
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: 24 Jun 2008 17:30:12 +0000

1. Introduction

---

From: Phil Regnauld <[email-masked]>
Date: Tue, 24 Jun 2008 19:52:50 +0200

> statement and an objective analysis of more than one alternative.

	I would put it much more concisely: this is a solution looking
	for a problem.

	Phil

---

From: Phil Regnauld <[email-masked]>
Date: Tue, 24 Jun 2008 19:52:50 +0200

Phil

---

From: bill fumerola <[email-masked]>
Date: Tue, 24 Jun 2008 14:54:28 -0700

> > statement and an objective analysis of more than one alternative.

like Paul, i'm not commenting on the specific technical value of the
draft. i haven't read the updated version of the draft. however, when i
read the previous version, i remember that to be practical it requires
a greenfield implementation or would have to be represented in a dns
system other than the one common root system used on the internet. almost
as if it could just as easily be an entirely standalone namemapping
system instead of DNS.

also, as i recall when this draft was discussed before:
1) 
> 	I would put it much more concisely: this is a solution looking

2) this draft seemed to be the result of some thesis project in the p2p
   space that aimed to solve the thesis problems by changing dns rather
   than solving the problems by utilizing dns

3) there was much assumption and conclusions that weren't anywhere near
   consensus. at minimum there existed so many empty phrases ("IPv6 is
   large") as to hide value that could be taken away and reorganized
   into a draft that this WG could do something with, if we had a problem
   this draft could address.

i'll try and find time to read the new version to see if anything changed,
but based on the last draft, i don't think this should be a WG priority
or work-item without first a problem statement that we can all agree on.

-- bill

---

From: bill fumerola <[email-masked]>
Date: Tue, 24 Jun 2008 14:54:28 -0700

-- bill

---

From: Dean Anderson <[email-masked]>
Date: Tue, 24 Jun 2008 20:39:10 -0400 (EDT)

Dr. Lican Huang

It is perfectly clear now that the current IPv6 Root DNS architecture is
deeply flawed.  It is strange that Paul Vixie asserts that there are no
future load problems, since Paul Vixie has previously asserted that DNS
Anycast is a solution to these future load problems. RFC1546 states, and
it has been experimentally demonstrated that Anycast doesn't work for
TCP connections. Recent discussion on NANOG has shown that operators
were under the mistaken impression that only AXFR uses TCP, and that
ordinary DNS queries are never performed over TCP.  Perhaps this
explains why they think that DNS Anycast might be stable when TCP
Anycast is not stable; it seems they think (incorrectly) that DNS only
uses UDP.

Furthermore, in support of Dr. Lican Huang premise: As IPv6 records are
added to already limited priming and NS responses at the expense of IPv4
servers, IPv4 stability is reduced.  Any reduction in the number of IPv4
servers in these responses imposes stability problems on the respective
IPv4 root, TLD, and other Domains. On the other hand, adding fewer IPv6
nameservers in NS and priming responses similarly compromises IPv6 DNS
stability.  This is a hobbsian choice. This choice is only imposed
because of the mixing IPv6 and IPv4 records on the same set of root and
DNS servers. There is no need or requirement for such mixing. Using
entirely separate IPv4 and IPv6 resolvers avoids the hobbsian choice
caused by the mixing.

So, I think that a complete set of IPv6 root nameservers should be
created, and that the scalability solution proposed by Dr. Lican Huang
should be seriously consideFrom [email-masked]  Tue Jun 24 17:39:17 2008
Date: Tue, 24 Jun 2008 20:39:10 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Paul Vixie <[email-masked]>
Cc: [email-masked], =?gb2312?b?u8bA7bLT?= <[email-masked]>
Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Sender: [email-masked]

Dr. Lican Huang

It is perfectly clear now that the current IPv6 Root DNS architecture is
deeply flawed.  It is strange that Paul Vixie asserts that there are no
future load problems, since Paul Vixie has previously asserted that DNS
Anycast is a solution to these future load problems. RFC1546 states, and
it has been experimentally demonstrated that Anycast doesn't work for
TCP connections. Recent discussion on NANOG has shown that operators
were under the mistaken impression that only AXFR uses TCP, and that
ordinary DNS queries are never performed over TCP.  Perhaps this
explains why they think that DNS Anycast might be stable when TCP
Anycast is not stable; it seems they think (incorrectly) that DNS only
uses UDP.

Furthermore, in support of Dr. Lican Huang premise: As IPv6 records are
added to already limited priming and NS responses at the expense of IPv4
servers, IPv4 stability is reduced.  Any reduction in the number of IPv4
servers in these responses imposes stability problems on the respective
IPv4 root, TLD, and other Domains. On the other hand, adding fewer IPv6
nameservers in NS and priming responses similarly compromises IPv6 DNS
stability.  This is a hobbsian choice. This choice is only imposed
because of the mixing IPv6 and IPv4 records on the same set of root and
DNS servers. There is no need or requirement for such mixing. Using
entirely separate IPv4 and IPv6 resolvers avoids the hobbsian choice
caused by the mixing.

So, I think that a complete set of IPv6 root nameservers should be
created, and that the scalability solution proposed by Dr. Lican Huang
should be seriously considerered as a solution to the scalability problems
already experienced in IPv4, so that IPv6 DNS over TCP can be handled
reliably.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

d as a solution to the scalability problems
already experienced in IPv4, so that IPv6 DNS over TCP can be handled
reliably.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Jun 2008 11:30:42 -0400

Regarding:

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Jun 2008 11:30:42 -0400

Regarding:

---

From: Phil Regnauld <[email-masked]>
Date: Sat, 28 Jun 2008 17:32:31 +0200

Edward Lewis wrote:
> 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
>    of traffic in tree structure can be avoided.

	Already there, as has already been pointed out, we have a flawed
	and unsupported assertion.

>    large number of domain names.

	Question: Why is this limited to IPv6 ?

>    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

---

From: Phil Regnauld <[email-masked]>
Date: Sat, 28 Jun 2008 17:32:31 +0200

[...]

	And vice versa.

	Question: why ?

	

	Question: Why ?

Conclusion:

	Phil

---

From: Dean Anderson <[email-masked]>
Date: Sat, 28 Jun 2008 17:36:04 -0400 (EDT)

A number of the points you raise have already been addressed.

The IPV6 Reverse resolution question has been discussed at length in
DNSEXT previously. In fact, it was proposed to remove reverse resolution
entirely from IPV6 for just the reason Dr. Huang notes.  A 128 bit IPV6
address is 16 octets. To perform reverse resolution requires traversing
16 levels of DNS tree. Even the delegations impose significantly larger
trees on the registries. It is recognized that this isn't going to be
very scalable, or even possible.  IPV6 proposes to use ICMP Node
Identification query instead.  At present, there is an IPV6 reverse
tree, but it is not guarenteed it will stay. It is for transition--so
that gethostbyaddr() still works on IPv6 during transition.

See for example the discussions here:

http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html

		--Dean

On Sat, 28 Jun 2008, Phil Regnauld wrote:
> 	inFrom [email-masked]  Sat Jun 28 14:37:15 2008
Date: Sat, 28 Jun 2008 17:36:04 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Phil Regnauld <[email-masked]>
Cc: [email-masked], Edward Lewis <[email-masked]>
Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Sender: [email-masked]

A number of the points you raise have already been addressed.

The IPV6 Reverse resolution question has been discussed at length in
DNSEXT previously. In fact, it was proposed to remove reverse resolution
entirely from IPV6 for just the reason Dr. Huang notes.  A 128 bit IPV6
address is 16 octets. To perform reverse resolution requires traversing
16 levels of DNS tree. Even the delegations impose significantly larger
trees on the registries. It is recognized that this isn't going to be
very scalable, or even possible.  IPV6 proposes to use ICMP Node
Identification query instead.  At present, there is an IPV6 reverse
tree, but it is not guarenteed it will stay. It is for transition--so
that gethostbyaddr() still works on IPv6 during transition.

See for example the discussions here:

http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html

		--Dean

On Sat, 28 Jun 2008, Phil Regnauld wrote:
> 	formation as IP6.ARPA grows.
>

---

From: Phil Regnauld <[email-masked]>
Date: Sun, 29 Jun 2008 00:27:11 +0200

> A number of the points you raise have already been addressed.

	Hi Dean,

	Where ?

> entirely from IPV6 for just the reason Dr. Huang notes.

	Which one ?  There's still nothing showing that there effectively
	is going to be a bottleneck of traffic to the root.  Some curve,
	some data points, anything, we could use to extrapolate future
	problems from current trends, or even a *simulation* of load
	based on guesstimages/projections of network host population would
	come in handy.

> A 128 bit IPV6
> 16 levels of DNS tree.

	How is that better than 32 steps for the proposed implementation ?

(from the draft, §2.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.

	Note: I may very well have gotten lost in the logic, and if
	there's something I missed, please point it out...

> Even the delegations impose significantly larger
> very scalable, or even possible.

	Again, where ?  The references you point to below are somewhat old,
	and of course it doesn't make them any less relevant (after all,
	IPv6 is only going to be get used more and more), but still, I fail
	to see any kind of model that really does show that it will be a problem.

	C. Huitema's argument that the "... operational implications are daunting",
	I can easily identify with -- autoconfiguration, if it does get used,
	will mean that everything has to be automatized and most likely dynamic.

	Alain Durand does point out that due to the size of ipv6 space,
	reverse information for large ranges of IP addresses will have to be
	dynamically generated, use wildcard, only record some, or drop.

	But it still doesn't say how this is going to be a problem, that
	Mr. (not a Dr. it seems) is arguing his draft is the solution to.

> IPV6 proposes to use ICMP Node Identification query instead.

	You mean ICMP Node Information ? (RFC4620)

	Yes, it definitely looks like an interesting solution.  It has issues,
	though, for example, the fact that it assumes that every node on
	the internet will be reachable so that they can be queries:

(from RFC4620, §8. Security Considerations)

>   This protocol has the potential of revealing information useful to a
>   would-be attacker.  An implementation of this protocol MUST have a
>   default configuration that refuses to answer queries from global-
>   scope [3] addresses.

	... and the protocol doesn't propose implementing a collector/
	local aggregator which could handle/reverse proxy such queries at the
	edge router or firewall level, so I guess if you've got a firewall,
	you haven't got reverse anyway.

> At present, there is an IPV6 reverse

	That's not the impression I got.  Decisions to phase out ip6.int and
	use ip6.arpa look to me like ip6.arpa is here to stay.  HOW we populate
	it -- or rather: how do we make that namespace return something useful,
	using gethostbyaddr(), is part of the challenge -- for the reasons
	stated by the sources you site.

	But I don't see either of these issues in anyway related to the
	"the overload of traffic in tree structure" that Mr. Huang says
	should be avoided.

> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html

	Cheers,
	Phil

---

From: Phil Regnauld <[email-masked]>
Date: Sun, 29 Jun 2008 00:27:11 +0200

Hi Dean,

	Where ?

(from the draft, §2.3)

	Cheers,
	Phil

---

From: Frederico A C Neves <[email-masked]>
Date: Mon, 30 Jun 2008 11:04:51 -0300

Mr. Anderson,

> address is 16 octets. To perform reverse resolution requires traversing

Not exactly. The reverse delegation is at the 4 bits boundary, so the
correct is 32 possible levels, but this possibility doesn't impose all
these levels. Half of the levels are unlikely to be used and the other
half you'll see normally the average of 3 to 4 as we see it today for
IPv4. The amount of delegations levels are driven by the IP
distributions layers (IANA-RIR-NIR-ISP), not by the address space.

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Mon, 30 Jun 2008 11:04:51 -0300

Mr. Anderson,

Fred