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

From: "黄理灿" <[email-masked]>
Date: Wed, 25 Jun 2008 16:58:18 +0800

VGhhbmtzLCBEZWFuLA0KDQogICBBbm90aGVyIGRpc2FkdmFudGFnZXMgb2YgY3VycmVudCBJUHY2IFJvb3QgRE5TIGFyY2hpdGVjdHVyZSBpcyBlYXN5IHRvIGF0dGFjaywgYW5kIGV2ZW4gbG9jYWwgZG9tYWluIG5hbWVzIGFyZSB1bnJlYWNoYWJsZSB3aGVuIHJvb3Qgc2VydmVycyBjYW4gbm90IGJlIGFjY2Vzc2VkLiBGb3IgZXhhbXBsZSwgdGhlIGZpYnJlIGNhYmxlcyBjb25uZWN0aW5nIFVTIHdpdGggQ2hpbmEgd2FzIGJyb2tlbiBieSBlYXJ0aHF1YWtlLCB0aGVuIGFsbW9zdCBhbGwgd2ViIHBhZ2VzIHdhcyB1bnJlYWNoYWJsZSBldmVuIHRoZSBtYWNoaW5lIHdhcyBpbiBDaGluYSBiZWNhdXNlIG9mIHJvb3Qgc2VydmVycyBhcmUgbG9jYXRlZCBpbiBVU0EuICAgVGhlIGRyYWZ0ICJkcmFmdC1saWNhbmh1YW5nLWRuc29wLWRpc3RyaWJ1dGVkZG5zLTA0LnR4dCIgY2FuIHNvbHZlIHRoZXNlIHByb2JsZW1zDQoNCkxpY2FuDQoNCtTaxPq1xMC00MXW0NT4vq3M4bW9Og0KPkZyb206IERlYW4gQW5kZXJzb24gPGRlYW5AYXY4LmNvbT4NCj5SZXBseS1UbzogDQo+VG86IFBhdWwgVml4aWUgPHZpeGllQGlzYy5vcmc+DQo+U3ViamVjdDogUmU6IFtETlNPUF0gSS1EIEFDVElPTjpkcmFmdC1saWNhbmh1YW5nLWRuc29wLWRpc3RyaWJ1dGVkZG5zLTA0LnR4dA0KPkRhdGU6VHVlLCAyNCBKdW4gMjAwOCAyMDozOToxMCAtMDQwMCAoRURUKQ0KPg0KPkRyLiBMaWNhbiBIdWFuZw0KPg0KPkl0IGlzIHBlcmZlY3RseSBjbGVhciBub3cgdGhhdCB0aGUgY3VycmVudCBJUHY2IFJvb3QgRE5TIGFyY2hpdGVjdHVyZSBpcw0KPmRlZXBseSBmbGF3ZWQuICBJdCBpcyBzdHJhbmdlIHRoYXQgUGF1bCBWaXhpZSBhc3NlcnRzIHRoYXQgdGhlcmUgYXJlIG5vDQo+ZnV0dXJlIGxvYWQgcHJvYmxlbXMsIHNpbmNlIFBhdWwgVml4aWUgaGFzIHByZXZpb3VzbHkgYXNzZXJ0ZWQgdGhhdCBETlMNCj5BbnljYXN0IGlzIGEgc29sdXRpb24gdG8gdGhlc2UgZnV0dXJlIGxvYWQgcHJvYmxlbXMuIFJGQzE1NDYgc3RhdGVzLCBhbmQNCj5pdCBoYXMgYmVlbiBleHBlcmltZW50YWxseSBkZW1vbnN0cmF0ZWQgdGhhdCBBbnljYXN0IGRvZXNuJ3Qgd29yayBmb3INCj5UQ1AgY29ubmVjdGlvbnMuIFJlY2VudCBkaXNjdXNzaW9uIG9uIE5BTk9HIGhhFrom [email-masked]  Wed Jun 25 02:32:10 2008Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from [127.0.0.1] (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id 234483A6998;	Wed, 25 Jun 2008 02:32:10 -0700 (PDT)X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id 60F323A6998	for <[email-masked]>; Wed, 25 Jun 2008 02:32:09 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 3.784X-Spam-Level: ***X-Spam-Status: No, score=3.784 tagged_above=-999 required=5	tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_103=0.327, 	MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753,	MSGID_FROM_MTA_HEADER=0.803]Received: from mail.ietf.org ([64.170.98.32])	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id KTmdEfgtx-4p for <[email-masked]>;	Wed, 25 Jun 2008 02:32:08 -0700 (PDT)Received: from zstu.edu.cn (mail.zstu.edu.cn [218.108.82.170])	by core3.amsl.com (Postfix) with SMTP id 67F7C3A68D5	for <[email-masked]>; Wed, 25 Jun 2008 02:32:04 -0700 (PDT)Received: (eyou send program); Wed, 25 Jun 2008 16:58:18 +0800Message-ID: <[email-masked]>Received: from 10.11.152.68 by mail.zstu.edu.cn with HTTP;	Wed, 25 Jun 2008 16:58:18 +0800X-WebMAIL-MUA: [10.11.152.68]From: "=?gb2312?B?u8bA7bLT?=" <[email-masked]>To: "Dean Anderson" <[email-masked]>, "Paul Vixie" <[email-masked]>Date: Wed, 25 Jun 2008 16:58:18 +0800X-Priority: 3Cc: [email-masked]: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txtX-BeenThere: [email-masked]: 2.1.9Precedence: listReply-To: =?gb2312?B?u8bA7bLT?= <[email-masked]>List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,	<mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/pipermail/dnsop>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,	<mailto:[email-masked]?subject=subscribe>Content-Type: multipart/mixed; boundary="===============1934805923=="Sender: [email-masked]: [email-masked]

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-masked]>
>Reply-To: 
>To: Paul Vixie <[email-masked]>
>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'26��v�F�B�W&F�'0У�vW&RV�FW"F�R֗7F�V���&W76���F�B��ǒ�e"W6W2D5��BF�@У��&F��'�D�2VW&�W2&R�WfW"W&f�&�VB�fW"D5�W&�2F��0У�W����2v��F�W�F���F�BD�2�67B֖v�B&R7F&�Rv�V�D5У��67B�2��B7F&�S��B6VV�2F�W�F������6�'&V7Fǒ�F�BD�2��ǐУ�W6W2TE�У�У�gW'F�W&��&R���7W�'B�bG"�Ɩ6��V�r&V֗6S�2�cb&V6�&G2&PУ�FFVBF��&VG�Ɩ֗FVB&�֖�r�B�2&W7��6W2BF�RW�V�6R�b�c@У�6W'fW'2��cB7F&�ƗG��2&VGV6VB��&VGV7F�����F�R�V�&W"�b�c@У�6W'fW'2��F�W6R&W7��6W2���6W27F&�ƗG�&�&�V�2��F�R&W7V7F�fPУ�cB&��B�D�B��B�F�W"F����2���F�R�F�W"��B�FF��rfWvW"�c`У���W6W'fW'2���2�B&�֖�r&W7��6W26�֖�&ǒ6��&�֗6W2�cbD�0У�7F&�ƗG��F��2�2��&'6��6���6R�F��26���6R�2��ǒ���6V@У�&V6W6R�bF�R֗���r�cb�B�cB&V6�&G2��F�R6�R6WB�b&��B�@У�D�26W'fW'2�F�W&R�2���VVB�"&WV�&V�V�Bf�"7V6�֗���r�W6��pУ�V�F�&Vǒ6W&FR�cB�B�cb&W6��fW'2f��G2F�R��&'6��6���6PУ�6W6VB'�F�R֗���r�У�У�6���F���F�B6���WFR6WB�b�cb&��B��W6W'fW'26��V�B&PУ�7&VFVB��BF�BF�R66�&�ƗG�6��WF���&��6VB'�G"�Ɩ6��V�pУ�6��V�B&R6W&��W6ǒ6��6�FW&VB26��WF���F�F�R66�&�ƗG�&�&�V�0У��&VG�W�W&�V�6VB���cB�6�F�B�cbD�2�fW"D56�&R��F�V@У�&VƖ&ǒ�У�У�����FV�У�У�У���#B�V�#��V�f���Rw&�FS�У�У��У��F����Rf�"��W"v�&���F��2��f��B��7W�'Bf�"F��276W'F���У��У������G&�GV7F���У��У����F��Vv�D�2&V6��W2f�F�6����V�B��F�F�w2��FW&�W@У�����g&7G'V7GW&R�F�RW��7F��rD�2&6��FV7GW&Rv���V�6�V�FW У���&�&�V�2��F�RgWGW&Rf�"F�Rw&�wF��bF�R��FW&�WB�У������У���D�2���V�V�FF���7W'&V�FǒW6VB��V�6�V�FW"�fW&��BG&ff�0У�����&��BD�26W'fW'2����У��У��F�W&Vf�&Rv���R�f��B��W"&��6VB6��WF���F�&R�b��v�VƗG��F�W&PУ���26�7B���fW&��7�7FV�6���W��G�f�"FF��rf�'GV�&�WF��r��W"F�У��F�RD�2�v��6�v�V�B�fRF�&R�W7F�f�VB'��V6���&R6���WFR&�&�V�У��7FFV�V�B�B��&�V7F�fR�Ǘ6�2�b��&RF����R�FW&�F�fR�У��У�У���У�c���FW&�WB&W&VBF��&V֗V�f�"&WGFW"6W'f�6S�У�wwr�c���WBf7FW"���&R&VƖ&�R�&WGFW"6W'f�6PУ�cr3CB�У�У�У������������������������������������������������У�D�4���Ɩ�rƗ7@У�D�4��WFb��&pУ�GG3���wwr�WFb��&r�������Ɨ7F��f��F�6�У�Р

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jun 2008 08:04:17 -0400

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jun 2008 08:04:17 -0400

Joe

---

From: Joao Damas <[email-masked]>
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  

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

---

From: Joao Damas <[email-masked]>
Date: Wed, 25 Jun 2008 14:17:05 +0200

Joao Damas
ISC

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Jun 2008 15:26:33 +0000

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Jun 2008 15:26:33 +0000

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Jun 2008 17:55:44 +0200

On Wed, Jun 25, 2008 at 04:58:18PM +0800,
 ?????? <[email-masked]> wrote 

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

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Jun 2008 17:55:44 +0200

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 15:29:23 -0400 (EDT)

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

> 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

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 15:29:23 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 16:08:57 -0400 (EDT)

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.

PAO1    Palo Alto, CA, USA      IPv4 and IPv6   Global Node
SFO2    San 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:
> >

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 16:08:57 -0400 (EDT)

--Dean

---

From: David Conrad <[email-masked]>
Date: Wed, 25 Jun 2008 13:23:00 -0700

> if only ICANN
> operators.

You mean like http://www.internic.net/domain/root.zone that has been  
published since, oh, 1996 or so?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 25 Jun 2008 13:23:00 -0700

Regards,
-drc

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 18:20:32 -0400 (EDT)

So why deny AXFR from roots, then?

;File start: 24620
; The use of the Data contained in Verisign Inc.'s aggregated
; .com, and .net top-level domain zone files (including the checksum
; files) is subject to the restrictions described in the access Agreement
; with Verisign Inc.

. IN    SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. (
				  2008062500 ;serial
				  1800 ;refresh every 30 min
				  900 ;retry every 15 min
				  604800 ;expire after a week
				  86400 ;minimum of a day
				  )

BTW, did the root zone actually change today (2008062500)? 

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 18:20:32 -0400 (EDT)

;File start: 24620

		--Dean

---

From: David Conrad <[email-masked]>
Date: Wed, 25 Jun 2008 15:29:34 -0700

> So why deny AXFR from roots, then?

AXFR constitutes a significantly greater load on a name server than  
simply answering normal queries.  As such, independent root server  
operators may decide to restrict zone transfer from their root servers.

> BTW, did the root zone actually change today (2008062500)?

VeriSign regenerates the root zone twice a day regardless of whether  
there are root zone changes.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 25 Jun 2008 15:29:34 -0700

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jun 2008 19:06:10 -0400

> So why deny AXFR from roots, then?

I'll note that this is a matter for individual root operators, so the  
question is better directed at them, individually. However, as a  
trivial refutation of the implication that all root servers deny AXFR,  
see the following:

[calamari:~]% for n in $(jot -w "%c.root-servers.net" 13 a); do
for> echo -n "${n} does "
for> dig @${n} . axfr | grep -q 'Transfer failed' && echo -n "not "
for> echo "leave AXFR wide open, at least for this client"
for> done
a.root-servers.net does not leave AXFR wide open, at least for this  
client
b.root-servers.net does leave AXFR wide open, at least for this client
c.root-servers.net does leave AXFR wide open, at least for this client
d.root-servers.net does not leave AXFR wide open, at least for this  
client
e.root-servers.net does not leave AXFR wide open, at least for this  
client
f.root-servers.net does leave AXFR wide open, at least for this client
g.root-servers.net does leave AXFR wide open, at least for this client
h.root-servers.net does not leave AXFR wide open, atFrom [email-masked]  Wed Jun 25 16:06:17 2008
From: Joe Abley <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 19:06:10 -0400
Cc: [email-masked], David Conrad <[email-masked]>,
	=?UTF-8?B?6buE55CG54G/?= <[email-masked]>
Subject: Re: [DNSOP] Why deny AXFR from root servers?
Sender: [email-masked]

> So why deny AXFR from roots, then?

I'll note that this is a matter for individual root operators, so the  
question is better directed at them, individually. However, as a  
trivial refutation of the implication that all root servers deny AXFR,  
see the following:

[calamari:~]% for n in $(jot -w "%c.root-servers.net" 13 a); do
for> echo -n "${n} does "
for> dig @${n} . axfr | grep -q 'Transfer failed' && echo -n "not "
for> echo "leave AXFR wide open, at least for this client"
for> done
a.root-servers.net does not leave AXFR wide open, at least for this  
client
b.root-servers.net does leave AXFR wide open, at least for this client
c.root-servers.net does leave AXFR wide open, at least for this client
d.root-servers.net does not leave AXFR wide open, at least for this  
client
e.root-servers.net does not leave AXFR wide open, at least for this  
client
f.root-servers.net does leave AXFR wide open, at least for this client
g.root-servers.net does leave AXFR wide open, at least for this client
h.root-servers.net does not leave AXFR wide open,  least for this  
client
i.root-servers.net does not leave AXFR wide open, at least for this  
client
j.root-servers.net does not leave AXFR wide open, at least for this  
client
k.root-servers.net does leave AXFR wide open, at least for this client
l.root-servers.net does not leave AXFR wide open, at least for this  
client
m.root-servers.net does not leave AXFR wide open, at least for this  
client
[calamari:~]%

> BTW, did the root zone actually change today (2008062500)?

Yes. (The SOA RDATA changed, at least). Forming your own deltas by  
doing a zone transfer every day and exercising diff is not rocket  
science, either. The implication that the nature of changes is somehow  
secret seems to fly in the face of common sense.

To all those who are about to mail me privately about feeding trolls,  
no need, I know, I know.

Joe

at least for this  
client
i.root-servers.net does not leave AXFR wide open, at least for this  
client
j.root-servers.net does not leave AXFR wide open, at least for this  
client
k.root-servers.net does leave AXFR wide open, at least for this client
l.root-servers.net does not leave AXFR wide open, at least for this  
client
m.root-servers.net does not leave AXFR wide open, at least for this  
client
[calamari:~]%

> BTW, did the root zone actually change today (2008062500)?

Yes. (The SOA RDATA changed, at least). Forming your own deltas by  
doing a zone transfer every day and exercising diff is not rocket  
science, either. The implication that the nature of changes is somehow  
secret seems to fly in the face of common sense.

To all those who are about to mail me privately about feeding trolls,  
no need, I know, I know.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jun 2008 19:13:35 -0400

> meaning they don't advertise their route outside of the ISP they are

"The ISP" is misleading; both F-root nodes in the PRC are connected to  
popular exchange points in their respective locations, and ISC is  
known to operate open peering policies.

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.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jun 2008 19:13:35 -0400

Joe

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 19:19:30 -0400 (EDT)

> operators may decide to restrict zone transfer from their root servers.

A single AXFR constitutes a greater load than a single query. However, 
it seems unlikely that 30,000 ISPs doing AXFR of the root zone would be 
less than all the root queries from all the nameservers in the world.

> there are root zone changes.

One would think that could be more efficient.

BTW, can you explain what these zones are?

XN--KGBECHTV. NS A.IANA-SERVERS.NET.
XN--KGBECHTV. NS B.IANA-SERVERS.NET.
XN--KGBECHTV. NS C.IANA-SERVERS.NET.
XN--HLCJ6AYA9ESC7A. NS A.IANA-SERVERS.NET.
XN--HLCJ6AYA9ESC7A. NS B.IANA-SERVERS.NET.
XN--HLCJ6AYA9ESC7A. NS C.IANA-SERVERS.NET.
XN--11B5BS3A9AJ6G. NS A.IANA-SERVERS.NET.
XN--11B5BS3A9AJ6G. NS B.IANA-SERVERS.NET.
XN--11B5BS3A9AJ6G. NS C.IANA-SERVERS.NET.
XN--JXALPDLP. NS A.IANA-SERVERS.NET.
XN--JXALPDLP. NS B.IANA-SERVERS.NET.
XN--JXALPDLP. NS C.IANA-SERVERS.NET.
XN--DEBA0AD. NS A.IANA-SERVERS.NET.
XN--DEBA0AD. NS B.IANA-SERVERS.NET.
XN--DEBA0AD. NS C.IANA-SERVERS.NET.

XN--G6W251D. NS A.IANA-SERVERS.NET.
XN--G6W251D. NS B.IANA-SERVERS.NET.
XN--G6W251D. NS C.IANA-SERVERS.NET.
XN--HGBK6AJ7F53BBA. NS A.IANA-SERVERS.NET.
XN--HGBK6AJ7F53BBA. NS B.IANA-SERVERS.NET.
XN--HGBK6AJ7F53BBA. NS C.IANA-SERVERS.NET.
XN--80AKHBYKNJ4F. NS A.IANA-SERVERS.NET.
XN--80AKHBYKNJ4F. NS B.IANA-SERVERS.NET.
XN--80AKHBYKNJ4F. NS C.IANA-SERVERS.NET.
XN--ZCKZAH. NS A.IANA-SERVERS.NET.
XN--ZCKZAH. NS B.IANA-SERVERS.NET.
XN--ZCKZAH. NS C.IANA-SERVERS.NET.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 19:19:30 -0400 (EDT)

---

From: David Conrad <[email-masked]>
Date: Wed, 25 Jun 2008 16:30:28 -0700

> BTW, can you explain what these zones are?

http://idn.icann.org/#The_example.test_names

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 25 Jun 2008 16:30:28 -0700

Regards,
-drc

---

From: Brian Dickson <[email-masked]>
Date: Wed, 25 Jun 2008 19:30:52 -0400

Dean Anderson wrote:
> XN--KGBECHTV. NS A.IANA-SERVERS.NET

Wow, an interesting, operationally pertinent question. It deserves mild 
praise and an answer.

See http://www.iana.org/reports/2007/testetal-report-01aug2007.html

(Things that start with xn-- are punycode. Google or any other search 
engine is your friend.)

Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 25 Jun 2008 19:30:52 -0400

Brian

---

From: "Joe Baptista" <[email-masked]>
Date: Wed, 25 Jun 2008 21:17:00 -0400

On Wed, Jun 25, 2008 at 7:06 PM, Joe Abley <[email-masked]> wrote:

> a.root-servers.net does not leave AXFR wide open, at least for this client
> c.root-serFrom [email-masked]  Wed Jun 25 18:17:09 2008
Date: Wed, 25 Jun 2008 21:17:00 -0400
From: "Joe Baptista" <[email-masked]>
To: "Joe Abley" <[email-masked]>
Cc: =?GB2312?B?u8bA7bLT?= <[email-masked]>, [email-masked],
	David Conrad <[email-masked]>
Subject: Re: [DNSOP] Why deny AXFR from root servers?
Sender: [email-masked]
On Wed, Jun 25, 2008 at 7:06 PM, Joe Abley <[email-masked]> wrote:

> a.root-servers.net does not leave AXFR wide open, at least for this client
> c.root-servevers.net does leave AXFR wide open, at least for this client
> d.root-servers.net does not leave AXFR wide open, at least for this client
> e.root-servers.net does not leave AXFR wide open, at least for this client
> h.root-servers.net does not leave AXFR wide open, at least for this client
> i.root-servers.net does not leave AXFR wide open, at least for this client
> j.root-servers.net does not leave AXFR wide open, at least for this client
> l.root-servers.net does not leave AXFR wide open, at least for this client
> m.root-servers.net does not leave AXFR wide open, at least for this client
>

Thats not bad.  I remember a time when only the f root would AXFR.  5 out of
13 is not bad.

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 21:42:35 -0400 (EDT)

On Wed, 25 Jun 2008, Joe Abley 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.
> 
> 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.

> 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 "nFrom [email-masked]  Wed Jun 25 18:43:09 2008
Date: Wed, 25 Jun 2008 21:42:35 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Joe Abley <[email-masked]>
Cc: [email-masked], =?UTF-8?B?6buE55CG54G/?= <[email-masked]>
Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Sender: [email-masked]

On Wed, 25 Jun 2008, Joe Abley 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.
> 
> 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.

> 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

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jun 2008 21:49:34 -0400

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jun 2008 21:49:34 -0400

Joe

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 26 Jun 2008 06:25:34 +0200

On 25 jun 2008, at 14.17, Joao Damas wrote:

> 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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 26 Jun 2008 06:25:34 +0200

Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Jun 2008 10:18:19 -0400

> 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-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Jun 2008 10:18:19 -0400

A

---

From: Dean Anderson <[email-masked]>
Date: Thu, 26 Jun 2008 13:08:54 -0400 (EDT)

> only technical point it seemed to me that you tried to make.

My point was not based on ISP being singular. My point was based on a
"Local Node" not being universally accessible. The Chinise F-root nodes
are not available to other Chinese ISPs who don't peer with ISC at those
peering points.  So, an earthquake that disrupts communication from
China to the SF Bay Area, deprives users in China of access to F-root,
just as Dr. Huang's hypothesis stated. And I see from today that his
statement isn't so hypothetical, it happened as he said in 2006. There
are a number of very good points in Dr. Huang's proposal, and they
should be considered.

They (e.g. Vixie, DNSOP msg June 25), have also challenged Dr. Huang's
agenda in proposing solutions to known problems.  I note the same
naysayers have previously associated as a group on similar issues, and
that this group advocates Anycast as a solution to the current and
future load problems. They (e.g. Vixie, DNSOP msg. June 24)  have
discredited their opposition to Dr. Huang's proposal, at least, by
asserting that there are no load problems to be solved, while advancing
their own solution.  It should be noted that ISC, Vixie et al have a
financial motive in promoting Anycast as the solution and that Dr.
Huang's proposal competes with their solution. There is an undisclosed
conflict of interest.

		--From [email-masked]  Thu Jun 26 10:09:21 2008
Date: Thu, 26 Jun 2008 13:08:54 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Joe Abley <[email-masked]>
Cc: [email-masked], =?UTF-8?B?6buE55CG54G/?= <[email-masked]>
Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Sender: [email-masked]

> only technical point it seemed to me that you tried to make.

My point was not based on ISP being singular. My point was based on a
"Local Node" not being universally accessible. The Chinise F-root nodes
are not available to other Chinese ISPs who don't peer with ISC at those
peering points.  So, an earthquake that disrupts communication from
China to the SF Bay Area, deprives users in China of access to F-root,
just as Dr. Huang's hypothesis stated. And I see from today that his
statement isn't so hypothetical, it happened as he said in 2006. There
are a number of very good points in Dr. Huang's proposal, and they
should be considered.

They (e.g. Vixie, DNSOP msg June 25), have also challenged Dr. Huang's
agenda in proposing solutions to known problems.  I note the same
naysayers have previously associated as a group on similar issues, and
that this group advocates Anycast as a solution to the current and
future load problems. They (e.g. Vixie, DNSOP msg. June 24)  have
discredited their opposition to Dr. Huang's proposal, at least, by
asserting that there are no load problems to be solved, while advancing
their own solution.  It should be noted that ISC, Vixie et al have a
financial motive in promoting Anycast as the solution and that Dr.
Huang's proposal competes with their solution. There is an undisclosed
conflict of interest.

		Dean

--Dean