[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