Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
* Joe Abley: 9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. ... such a PTR record would most likely be obtained by following four (root - ip6.arpa - RIR sever - LIR server - assignee server) or three (root - ip6.arpa - RIR server - assignee server) delegations. I doubt this is substantially different, in aggregate, from IPv4. It's actually better with IPv6 than with IPv4 because the LIR aggregate is at a multiple-of-4 boundary, so there's no need to delegate multiple zones for one address block, and it's also more likely that the RIR - LIR delegation has been cached by the resolver. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
If total number of PTR records is smail, that is right. But if most of IPv6 address space is used, one zone can not keep many PTR records. This will leads to many hierarchical zones. From: Florian Weimer [EMAIL PROTECTED] Reply-To: To: Joe Abley [EMAIL PROTECTED] Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt Date:Tue, 08 Jul 2008 10:09:11 +0200 * Joe Abley: 9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. ... such a PTR record would most likely be obtained by following four (root - ip6.arpa - RIR sever - LIR server - assignee server) or three (root - ip6.arpa - RIR server - assignee server) delegations. I doubt this is substantially different, in aggregate, from IPv4. It's actually better with IPv6 than with IPv4 because the LIR aggregate is at a multiple-of-4 boundary, so there's no need to delegate multiple zones for one address block, and it's also more likely that the RIR - LIR delegation has been cached by the resolver. ___ 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
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
* 黄理灿: If total number of PTR records is smail, that is right. But if most of IPv6 address space is used, one zone can not keep many PTR records. This will leads to many hierarchical zones. I don't think this is true. Even standard DNS servers scale to millions of records in a single zone, on affordable hardware. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
If total number of PTR records is smail, that is right. But if most of IPv 6 address space is used, one zone can not keep many PTR records. This will l eads to many hierarchical zones. Do you really see LAN densities been significantly larger than they are today? You are lucky to see more than several thousand machines on even the largest LANs. IPv4 can easily support millions of machines on a LAN but we don't get millions of machines on LANs. The fact that IPv6 can support trillions of devices on a LAN in no way means that the underlying physical layer can support that many devices. What won't happen is ISP's pre-populating reverse namespace. Instead they will populate on use or will have specialised servers that compute responses on request. Neither case will introduce extra levels of delegation. Mark From: Florian Weimer [EMAIL PROTECTED] Reply-To: To: Joe Abley [EMAIL PROTECTED] Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt Date:Tue, 08 Jul 2008 10:09:11 +0200 * Joe Abley: 9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. ... such a PTR record would most likely be obtained by following four (root - ip6.arpa - RIR sever - LIR server - assignee server) or three (root - ip6.arpa - RIR server - assignee server) delegations. I doubt this is substantially different, in aggregate, from IPv4. It's actually better with IPv6 than with IPv4 because the LIR aggregate is at a multiple-of-4 boundary, so there's no need to delegate multiple zones for one address block, and it's also more likely that the RIR - LIR delegation has been cached by the resolver. ___ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
I'm not confusing zone boundardies with label boundaries. 32 levels is the worst case. In practice, it'll probably be much more than 3 or 4 levels, but probably in most cases fewer than 32. But it is widely expected to be very problematic to maintain, and has always been problematic to maintain, even in IPv4. Hence the efforts on RFC1788(IPv4) and RFC4620(IPv6) --Dean On Sun, 6 Jul 2008, Joe Abley wrote: On 6 Jul 2008, at 18:16, Dean Anderson wrote: Oh yeah--That's right. 32 levels--Much worse than I said. No. To reiterate the point that I saw Fred making... I wrote up many of the issues with reverse dns about 1.5 years ago. I submitted it to the IETF, but there was no interest in publishing this information. http://www.av8.net/draft-anderson-reverse-dns-status-01.txt The following example was taken from RFC3596: 4321:0:1:2:3:4:567:89ab would be b.a. 9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. ... such a PTR record would most likely be obtained by following four (root - ip6.arpa - RIR sever - LIR server - assignee server) or three (root - ip6.arpa - RIR server - assignee server) delegations. I doubt this is substantially different, in aggregate, from IPv4. You seem to be confusing label boundaries with zone cuts in your analysis. Joe -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Oh yeah--That's right. 32 levels--Much worse than I said. I wrote up many of the issues with reverse dns about 1.5 years ago. I submitted it to the IETF, but there was no interest in publishing this information. http://www.av8.net/draft-anderson-reverse-dns-status-01.txt The following example was taken from RFC3596: 4321:0:1:2:3:4:567:89ab would be b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. On Mon, 30 Jun 2008, Frederico A C Neves wrote: Mr. Anderson, On Sat, Jun 28, 2008 at 05:36:04PM -0400, Dean Anderson wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On 6 Jul 2008, at 18:16, Dean Anderson wrote: Oh yeah--That's right. 32 levels--Much worse than I said. No. To reiterate the point that I saw Fred making... I wrote up many of the issues with reverse dns about 1.5 years ago. I submitted it to the IETF, but there was no interest in publishing this information. http://www.av8.net/draft-anderson-reverse-dns-status-01.txt The following example was taken from RFC3596: 4321:0:1:2:3:4:567:89ab would be b.a. 9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. ... such a PTR record would most likely be obtained by following four (root - ip6.arpa - RIR sever - LIR server - assignee server) or three (root - ip6.arpa - RIR server - assignee server) delegations. I doubt this is substantially different, in aggregate, from IPv4. You seem to be confusing label boundaries with zone cuts in your analysis. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Mr. Anderson, On Sat, Jun 28, 2008 at 05:36:04PM -0400, Dean Anderson wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
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: 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 ? -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Dean Anderson (dean) writes: A number of the points you raise have already been addressed. Hi Dean, Where ? 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. 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 address is 16 octets. To perform reverse resolution requires traversing 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 trees on the registries. It is recognized that this isn't going to be 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 tree, but it is not guarenteed it will stay. It is for transition--so that gethostbyaddr() still works on IPv6 during transition. 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. 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 Cheers, Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
I have just kicked off the open source project VIRGO-DNS. I will lead my students and other colleagues to implement the draft. I got my Ph.d from 2003, and was senior research assocate in Cardiff University. The cache route information by applying Zipf's law will make average hops much less than worst hops. By theretical calculation, in the case of total numbers of DNS servers with 1 million, alpha parameter 0.91 cache size is 1000, L is 32, then p is 0.537; and average hops is less than 3. From: Phil Regnauld [EMAIL PROTECTED] Reply-To: To: Dean Anderson [EMAIL PROTECTED] Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt Date:Sun, 29 Jun 2008 00:27:11 +0200 Dean Anderson (dean) writes: A number of the points you raise have already been addressed. Hi Dean, Where ? 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. 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 address is 16 octets. To perform reverse resolution requires traversing 16 levels of DNS tree. How is that better than 32 steps for the proposed implementation ? (from the draft, ?.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 trees on the registries. It is recognized that this isn't going to be 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, ?. 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 tree, but it is not guarenteed it will stay. It is for transition--so that gethostbyaddr() still works on IPv6 during transition. 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. 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 Cheers, Phil ___ DNSOP mailing
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On Thu, Jun 26, 2008 at 05:28:48PM +0800, ?? [EMAIL PROTECTED] wrote a message of 39 lines which said: If ISP located at China with domain name with www.*.com, then probably unreachable because of its RR stored in the DN Server located at USA. We (the .fr registry) always use this marketing argument to convince people to buy .fr and not .com :-) More seriously, if there is no .com name server in China, it is indeed a problem (but I do not know if it is true or not) but just a .com deployment problem, not a DNS problem. I assume .cn does not have this issue. This was true when Taiwan earthquaked on Dec.26, 2006. http://www.theregister.co.uk/2006/12/27/boxing_day_earthquake_taiwan/ This is not a serious report, just a small summary, not even mentioning DNS. Nothing suggest it was a DNS problem. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
If ISP located at China with domain name with www.*.com, then probably unreachable because of its RR stored in the DN Server located at USA. This was true when Taiwan earthquaked on Dec.26, 2006. http://www.theregister.co.uk/2006/12/27/boxing_day_earthquake_taiwan/ That is why the draft uses P2P technology. From: Joao Damas [EMAIL PROTECTED] Reply-To: To: é»çç?[EMAIL PROTECTED] Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt Date:Wed, 25 Jun 2008 14:17:05 +0200 On Jun 25, 2008, at 10:58 AM, é»çç?wrote: For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Not so. Have a look at http://www.isc.org/ops/f-root/ for the part that refers to f.root-servers.net There are at least 2 other Internet root server instances in mainland China, and additional ones in the Hong Kong area. Lack of access to root servers was definitely not at the source of any unreachability. Joao Damas ISC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
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 PGP.sig Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On Wed, Jun 25, 2008 at 09:42:35PM -0400, Dean Anderson wrote: And furthermore, these two China servers don't benefit any ISP in China that doesn't peer with ISC, so Dr. Huang's hypothetical scenario is true, as previously demonstrated, despite Mr. Abley's humorous assertions about their non-imaginary existance. It strikes me that, even if the hypothetical scenario is true, replace the DNS isn't the most obvious solution to the problem. For instance, increase the penetration of root copies in PRC-based ISPs would be an obvious answer, and that's something open to every PRC-based ISP today from what we're hearing in this thread. So even if the hypothetical scenario is true, it's not a very strong premise for the conclusion under discussion. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Thanks, Dean, Another disadvantages of current IPv6 Root DNS architecture is easy to attack, and even local domain names are unreachable when root servers can not be accessed. For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. The draft draft-licanhuang-dnsop-distributeddns-04.txt can solve these problems Lican ÔÚÄúµÄÀ´ÐÅÖÐÔø¾Ìáµ½: From: Dean Anderson [EMAIL PROTECTED] Reply-To: To: Paul Vixie [EMAIL PROTECTED] Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt 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 considered as a solution to the scalability problems already experienced in IPv4, so that IPv6 DNS over TCP can be handled reliably. --Dean On 24 Jun 2008, Paul Vixie wrote: 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. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ 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
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On 25 Jun 2008, at 04:58, 黄理灿 wrote: For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Note that this isn't even close to being true, and hasn't been for quite some time, now. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
From: 黄理灿 [EMAIL PROTECTED] ... almost all web pages was unreachable even the machine was in China because of root servers are located in USA. ... according to http://f.root-servers.org/, there are two f-root servers in china. if you have local contacts within china, please help us add more root name servers there, and please help us achieve better peering at the two sites we have (beijing and hong kong). according to http://root-servers.org/, MOST root name servers are outside the united states. i know from living through the transition that this has been true for several years now. i also know that there have been SOME root name servers outside the united states for more than a decade. you are not helping your case by making assertions widely known to be false. what's your actual agenda? is it just that you need to show utility for your academic work in order to finish your PhD? if so, i can offer several suggestions as to real problems that actually do need solutions. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On Wed, Jun 25, 2008 at 04:58:18PM +0800, ?? [EMAIL PROTECTED] wrote a message of 85 lines which said: Thanks, Dean, Lican, I must tell you that associating with a known troll like D. A. is not a good idea to spread your ideas. Almost everything in his message is completely wrong (for instance, in the Nanog discussion he talked about, *one* network operator made the mistake to identify DNS+TCP with AXFR and he was promptly corrected by everyone else). For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Like in your Internet-Draft, this sentence shows a big lack of knowledge about the DNS you pretend to fix. There are root servers instance in China for many years. Anyway, a few seconds after it starts, any DNS resolver in China has certainly the names and addresses of .cn name servers in its cache and can lose connectivity with the root without big problems. Do you have a detailed technical report of these break-ups? IT is certainly interesting to know why access to these sites fail but blaming the root looks like a provider explanation http://pages.cs.wisc.edu/~ballard/bofh/excuses. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On Wed, 25 Jun 2008, Stephane Bortzmeyer wrote: On Wed, Jun 25, 2008 at 04:58:18PM +0800, ?? [EMAIL PROTECTED] wrote a message of 85 lines which said: Thanks, Dean, Lican, I must tell you that associating with a known troll like D. A. is not a good idea to spread your ideas. Almost everything in his message is completely wrong (for instance, in the Nanog discussion he talked about, *one* network operator made the mistake to identify DNS+TCP with AXFR and he was promptly corrected by everyone else). Since my credibility is challenged, let me respond to that challenge: In the recent NANOG discussion, there were several 22 people involved and 33 messages on the subject over 3 days from June 13 to June 16. At least 2 were asserting that DNS doesn't use TCP for anything but AXFR and would be very concerned to find TCP queries. Many more seemed to feel that TCP was only a fallback when UDP failed, which is also incorrect. So Mr. Bortzmeyer can't even accurately report a discussion. By contrast, my reports are consistently reliable and correct. I've been vindicated on many controversial issues. Mr. Bortzmeyer's reports have not been so reliable, and he has not been so vindicated. For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Like in your Internet-Draft, this sentence shows a big lack of knowledge about the DNS you pretend to fix. There are root servers instance in China for many years. Anyway, a few seconds after it starts, any DNS resolver in China has certainly the names and addresses of .cn name servers in its cache and can lose connectivity with the root without big problems. I can think of no reason why anyone outside of ISC should know what ISC doesn't report to ICANN. So Mr. Bortzmeyer's criticism of Dr. Huang's lack of knowledge of ISC customers seems to be baseless. It is indeed rumored, and I've seen several people from ISC report that there are indeed copies of F-root in China. However, this is a commercial operation of ISC, not a decision of IANA. ISC could remove those Anycast servers at any time. ISC is not obligated or regulated in any way regarding the location of these servers. As far as I know, ISC only reports the number, not the locations of the servers or the ISC customers to the ICANN RSSAC. Indeed, it is my understanding that in some cases, the ISC customer only allows the Anycast route inside its network. In those cases, those ISPs have a root copy for their own use, benefiting them and no one else, except of course, ISC. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
According to this page, both F-root servers in China are local nodes, meaning they don't advertise their route outside of the ISP they are connected to. In fact, all copies of F-root except 2 (below) are local nodes, and the two that aren't, are quite close geographically. ISC doesn't publish the customers or sites of these two servers, either. PAO1Palo Alto, CA, USA IPv4 and IPv6 Global Node SFO2San Francisco, CA, USA IPv4 and IPv6 Global Node And we don't know if the two servers in China are in the same ISP in different physical locations, or if they have different ISPs. What Hierachical Anycast (the scheme variant used by ISC) in this case means, is that a user in China may see either 3 or 4 F-root servers (depending on how the two China F-root copies are deployed--a fact that ISC does not report). Indeed, it is possible that some users in China may only see the 2 global copies, both of which are located in the SF Bay area. Any disruption between or involving China and the SF Bay area would isolate many users in China from F-root, so Dr. Huang's hypothetical scenario is indeed possible. Anycasting F-root would not help *nearly* as much as is asserted by ISC. They seem to be talking out their backside, as it were. BTW, the two China ISPs that purchased copies of F-root could alternatively run their own copies of F-root privately, if only ICANN were to publish the root zone publicly instead of only to root server operators. Indeed, if this information were public, all ISPs could run their own private copies of root servers this way, and we could dispense entirely with global root servers, and the threat on global root servers. One wonders why ICANN/IANA doesn't publish this root DNS information for public consumption. --Dean On Wed, 25 Jun 2008, Joao Damas wrote: On Jun 25, 2008, at 10:58 AM, é»çç¿ wrote: For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Not so. Have a look at http://www.isc.org/ops/f-root/ for the part that refers to f.root-servers.net There are at least 2 other Internet root server instances in mainland China, and additional ones in the Hong Kong area. Lack of access to root servers was definitely not at the source of any unreachability. Joao Damas ISC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
if only ICANN were to publish the root zone publicly instead of only to root server operators. You mean like http://www.internic.net/domain/root.zone that has been published since, oh, 1996 or so? Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On Wed, 25 Jun 2008, Joe Abley wrote: On 25 Jun 2008, at 16:08, Dean Anderson wrote: According to this page, both F-root servers in China are local nodes, meaning they don't advertise their route outside of the ISP they are connected to. The ISP is misleading; both F-root nodes in the PRC are connected to popular exchange points in their respective locations, Peering points in this case just gives ISC access to more ISPs at (presumably) less cost. There is nothing misleading in The ISP. The number of many ISPs is unimportant, so long as it is not universal. The key factor is that these are Local Nodes that but only offer services to a specific ISP (or ISPs) rather then all of China and Asia. and ISC is known to operate open peering policies. I was under the impression that you charge for operating these servers. How does that charging work? Do you charge the peering facility and offer services to ISPs at that peering point for free? Do you charge for peering? I'm very curious about that. As to whether the F-root nodes in Hong Kong and Beijing actually exist, I can vouch for them being decidedly non-imaginary since in both cases I was part of the team that installed them. I fully expect this to do nothing to enhance their credibility in your eyes, however, and there's no need to point that out. Gee, I thought you left ISC, yet you can still speak for ISC... So, what does it cost to peer with ISC root servers? I've heard some speculations, but no figures. Of course, Mr. Abley's non-imaginary existance proposition is entirely frivolous. I guess Joe is just trying to get a laugh, somehow. My point is that given these Anycast servers are located in PRC today, there is no guarantee that they will be there next week or next month or next year---That's because ISC doesn't have to ask anyone's permission to remove them, nor does ISC even have to notify anyone (except perhaps the peering ISPs) when it removes these servers. We do not know ISC's contract status on these servers, and we have no influence over those contracts, if any. And furthermore, these two China servers don't benefit any ISP in China that doesn't peer with ISC, so Dr. Huang's hypothetical scenario is true, as previously demonstrated, despite Mr. Abley's humorous assertions about their non-imaginary existance. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On 25 Jun 2008, at 21:42, Dean Anderson wrote: There is nothing misleading in The ISP. Apart from the fact that it's singular, which was the basis of the only technical point it seemed to me that you tried to make. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On 25 jun 2008, at 14.17, Joao Damas wrote: On Jun 25, 2008, at 10:58 AM, 黄理灿 wrote: For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Not so. Have a look at http://www.isc.org/ops/f-root/ for the part that refers to f.root-servers.net There are at least 2 other Internet root server instances in mainland China, and additional ones in the Hong Kong area. Lack of access to root servers was definitely not at the source of any unreachability. I agree with Joao and many others. One can look at many places, also look at a map that I try to keep updated. http://stupid.domain.name/node/407 Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
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
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Hi, I have updated distributed DNS implementation in Ipv6. Please give your comments. Thanks. Dr. Lican Huang From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
[EMAIL PROTECTED] (黄理灿) writes: Hi, I have updated distributed DNS implementation in Ipv6. Please give your comments. Thanks. Dr. Lican Huang 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Paul Vixie (vixie) writes: 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. I would put it much more concisely: this is a solution looking for a problem. Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Paul Vixie (vixie) writes: 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. 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) On Tue, Jun 24, 2008 at 07:52:50PM +0200, Phil Regnauld wrote: I would put it much more concisely: this is a solution looking for a problem. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
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 considered as a solution to the scalability problems already experienced in IPv4, so that IPv6 DNS over TCP can be handled reliably. --Dean On 24 Jun 2008, Paul Vixie wrote: 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. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
