[governance] How do ICANN's actions hurt the average Internet

[Roland Perry]

In message <4A548A44.8040108 at cavebear.com>, at 05:00:04 on Wed, 8 Jul 
2009, Karl Auerbach <karl at cavebear.com> writes

>When the 9-11 catastrophe occurred much of Africa and South America 
>fell off the net.

(Although some not until a fortnight later). My impression at the time 
was that this was due to those countries having non-redundant cctld DNS 
served from New York, rather than them no longer being able see the root 
servers and other gtld servers from their country.

Elsewhere you have advocated for a wider range of tlds in the root (eg 
dot-ewe) but are you also advocating that all tlds must first pass a 
test of global resilience and redundancy? Surely different operators 
will have different ideas about this, and differentiating between them 
is part of the process of deciding where to buy your names.

Meanwhile, I hope that lessons have been learnt about the DNS for 
cctlds.

>Caching is its own source of risks - if bad data does get in, sometimes 
>you have to wait a cache timeout (about 48 hours for most TLD data) 
>else you have to engage in manual intervention.

I would guess that avoiding bad data would be a priority (just like 
avoiding getting water in your brake fluid is). Brakes are still a good 
idea!

>Bad data isn't always immediately detected.

If all of an ISP's customers could no longer see .com (because of bad 
data in their DNS resolver), they'd probably hear about it fairly 
quickly.

And I don't expect tlds like .com to allow bad data into their records 
in the first place.

>From preliminary reports the pilots of AF flight 447 learned what 
>happens when systems that can't fail do fail.

Almost every major airline accident is a result of two (or more likely 
three) unlikely things happening at the same time. Happily, if your DNS 
sever crashes, you can reboot it.

>>> There are several things that ICANN can do. Many are already being
>>> done by root server operators, but nothing requires them to continue
>>> to do so. Take a look at the latter part of this:
>>> http://www.cavebear.com/cbblog-archives/000192.html In it you will see
>>> a list of things that ICANN could contractually require.
>>
>> So you'd like ICANN to have a role in centralising the funding and
>> control of the currently independent distributed root servers?
>
>That was and is part of ICANN's explicit mandate.

The root server project you imply, was explicitly in their mandate? Or 
just the kind of thing you personally would have expected a more 
generally worded mandate to include? (A genuine question).

>Don't forget I was on the ICANN board of directors,

Sorry, I didn't know that to start with. At that time in my life people 
warned me against getting involved with ICANN.

>It's not necessarily something that "anyone" could do.  To build a 
>usable subset of DNS it would be useful to have query densities so as 
>to know what to prune - a DVD isn't enough to hold all of DNS.  Some 
>TLD operators would consider that kind of data to be rather 
>proprietary. ICANN has more leverage to pry out that data than a mere 
>mortal.

There seem to be plenty of sites that claim to list the "top 100 
websites" or whatever. Were you wanting to include every domain's DNS 
data, or just the zone files from each tld?
-- 
Roland Perry
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance