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

Karl Auerbach karl at cavebear.com
Wed Jul 8 07:02:45 EDT 2009


On 07/08/2009 03:10 AM, Roland Perry wrote:
> In message <4A5400E2.2080402 at cavebear.com>, at 19:13:54 on Tue, 7 Jul
> 2009, Karl Auerbach <karl at cavebear.com> writes
>> If the lights were to go out on a big part of DNS, as they did in
>> actuality over the US Northeast, and somebody calls ICANN and says
>> "fix it", ICANN's answer will be "not our job".
>
> So what failed, to cause that DNS outage?

I prefixed my sentence with "If".

So far DNS outages have been relatively minor or local.  But then again, 
from a worldwide point of view, the loss of electrical power to the 
Northeast portion of the US was a local matter.

Systemic flaws tend to creep into our systems and bite us by surprise - 
for example, it was the centralized congestion of Google Adwords and 
Google's "urchin" for web analysis, that tended to drag down intenet web 
performance when Michael Jackson died.

There is no particular reason to believe that DNS, particularly DNS with 
DNSSEC, does not contain similar points that could be tickled by 
accident (or on purpose).

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.

By-the-way, one very under-discussed matter is the degree to which 
DNSSEC might proved to be an obstacle to recovery should DNS ever wobble 
off axis.

> If it was every ISP's connectivity to every DNS root server (or to most
> tld servers), that does indeed sound like something outside ICANN's
> ability to fix.

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.

In addition, many human or natural failures are regional - Katrina 
affected only a small region - but for the people in that region they 
perceive major outages.  ICANN could, but has not, engaged in any effort 
to make it easier for people inside those regions to rebuild services 
locally rather than sitting on their hands waiting for rescuers to carve 
their way in.  (I know the feeling and frustrating of waiting for the 
outsiders to work their way in - here in Santa Cruz the wrath of the 
gods has hit us with fire, flood, earthquake, and some fruitcake who 
thought that blowing up power transmission lines in celebration of 
earth-day [and every day of the following two weeks] was fun.)

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. 
But it got deep sixed.

> I'd be interested to know the exact issue, as some tld operators claim
> 100% historical availability of their DNS servers.

I can believe that claim.  But then again, as they say on securities 
prospectuses - past performance is not necessarily an indicator of 
future performance.   I remember one day when I brought down an entire 
company's network because of a single packet I originated on a 
supposedly isolated test network (we were doing one of the fabled TCP/IP 
bakeoffs) that got propagated and took out every router in the company. 
  Never happened before.  That was the same day that I saw a network 
adaptor with no software driver answer ARP's - turned out that the 
device was wedged and was re-sending its last packet.  After than I 
began to understand the full import of Mr. Murphy and his law (.i.e. If 
anything can go wrong, it will, and at the worst possible time.)

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