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

Karl Auerbach karl at cavebear.com
Wed Jul 8 08:00:04 EDT 2009


On 07/08/2009 04:35 AM, Roland Perry wrote:

> Do you mean the electricity (literally the lights) went out?

More than once.  http://en.wikipedia.org/wiki/Northeast_Blackout_of_2003

> Of course, a tiny proportion of the world's DNS relies entirely upon the
> Northest US.

When the 9-11 catastrophe occurred much of Africa and South America fell 
off the net.  On the net geographic proximity is often quite different 
from net proximity.


>> For example, the fact that most root and many TLD servers have their
>> own names in the .net TLD suggests that there may exist a possibility
>> of some crossover failures should .net have problems.
>
> But the DNS resolvers will typically cache the results for a fortnight.
> Which will give people some time to work around whatever the problem was.

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.

Bad data isn't always immediately detected.  For example, I've had bad 
tertiary MX records that went unnoticed until my primary and secondary 
mail exchanger were down at the same time - an event that happened years 
after the bad data was lodged into the system.

And suppose that an ill .net server decided to issue update 
notifications to induce the pulling of bad data despite a cache and 
uncompleted TTL?

Every point in which something touches something else is a kind of 
marionette string that can be pulled.  Often it does nothing.  But in 
the hands of Mr. Murphy or another actor things sometimes go terribly 
wrong.  From preliminary reports the pilots of AF flight 447 learned 
what happens when systems that can't fail do fail.


>> 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.  ICANN's original goal 
was to assure that DNS query packets are quickly, efficiently, and 
accurately translated into DNS response packets.  Unless ICANN oversees 
and regulates root server operations we are flying only on the good will 
of the root server operators.  (A good group, but they are mortal - and 
in some cases, such as the root servers operated by the US military, 
their higher allegiance is not to the community of internet users.)

> So they should have a role as "firefighters" moving in to re-establish
> connectivity where the current arrangements are too slow?

Not in real time, but they could A) facilitate the creation of recovery 
facilities and B) not stomp on those who try to create recovery facilities.

>> I've proposed to ICANN the creation of a bootable DVD (think
>> KNOPPIX+DNS) that contains enough of a DNS system (root and TLD
>> contents) that can be shoved into an available PC to get a typical
>> community started with at least a bootstrap level of network services.
>
> Anyone could do that. Have you approached other than ICANN with this idea?

Yes, several times.  Don't forget I was on the ICANN board of directors, 
and even with that close degree of access, the idea never got a decent 
hearing.

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.

		--karl--

____________________________________________________________
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



More information about the Governance mailing list