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

Karl Auerbach karl at cavebear.com
Wed Jul 8 16:51:06 EDT 2009


On 07/08/2009 06:29 AM, Roland Perry wrote:
> 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).

You should read the NANOG reports on what happened.  It was not DNS 
related.  It was more a matter that at that time Africa and S. America 
were net-topologically dependencies of a few buildings in NYC.  When the 
power went out, or emergency generators ran dry, or air filters got so 
clogged that machines just died, then the NYC end of the data links went 
down (or the switches/routers went down) and Africa and S. America felt 
the brunt.

The point of this is that on the net seemingly distant events can have 
nearby effects for good or ill.

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

If you read more deeply I say that that is a choice for the operator of 
the root zone that accepts a given TLD.  If a sloppy root system wants 
to accept TLDs with weak procedures, then, assuming users can know about 
this, then that would be OK.  But for root zone operator such ICANN 
which promotes high quality TLD products, their standards ought to be 
rather higher.

(Note I'm distinguishing "root zone operator" from "root server 
operator".  ICANN operates a root zone.  There are other root zones, 
albeit they have a history of being rather weakly run.)

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

You bet!  Just yesterday afternoon I had the "lovely" experience of 
flying sideways at 120+kph down the highway with the antilock brakes and 
stability control mechanisms in full play -

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

Perhaps.  Suppose the net becomes further cross-coupled with other 
infrastructures.  How might a VoIP phone establish a call to an ISP to 
report the problem when the SIP phone number is under .com?  Or what if 
the directory that lists the ISP's phone number is under .com?

I've watched so-called network repair people.  Often they don't really 
know what they are doing and couldn't analyze a DNS issue from a 
connectivity issue.

(Apropos the degree of diagnostic clue in some network diagnostic 
people: My father and grandfather repaired TV sets back in the days when 
they could be repaired rather than discarded.  It was easy to tell which 
TV repairman were competent from those who were dummies.  The competent 
people had a small mirror that they could prop-up so that they could see 
the screen while they worked at the back of the TV.  The dummies ran 
back and forth from front to back to front to back ...)

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

That's what SUN thought when their entire software repository was wiped 
out because of "can't happen" error happened to un-checksumed UDP (gee, 
isn't the Ethernet CRC adequate?) as they flowed over the bus between 
the NIC card and memory and thence to the disk.

I've recently observed some issues in which large TCP based data 
transfers were being corrupted because at high flow rates certain error 
checking did not occur deep down at the device driver level.

Errors do creep into data.



>> That was and is part of ICANN's explicit mandate.  [To assure technical stability.]
>
> 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).

ICANN is a trade guild that runs a particular marketplace around its 
root zone file.

Other root zone file operators would run a marketplace around their root 
zone files.

Those other operators ought, in my opinion, to be able to establish 
their own rules based on what they feel customers want to buy.

Most of us feel that reliable DNS is worth buying. That's because we 
view domain names as some sort of rock of eternal use.  But for some 
short lived purposes reliability might not be worth paying for.  If one 
only needs a domain name to be stable for a few minutes or days then 
there might be large cost savings possible if a provider can avoid 
building things like data escrow and backups.

The point is that ICANN is imposed a very top-down view of what the 
internet should be onto the DNS.  It is a very unimaginative view and 
ICANN is very xenophobic about new ideas.

Had ICANN's mentality held sway in 1972 it is likely that the internet 
would never have been born.


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

Website data is easier to obtain than DNS data.  Websites are often 
filled with web bugs ranging from one-bit-pixels as used by 
www.whitehouse.gov (in utter violation of their published privacy 
policy) to things like Google's "urchin".  (And there is also website 
tracking via Adobe Flash cookies.)

So website data can be bought.  DNS query data may be for sale, but its 
not quite as open a marketplace.

(Although I'd bet money that my (US) government is paying or coercing 
companies such as Verisign to let the government monitor domain name 
query activity for "national security" purposes."  And I don't doubt 
that the root servers operated by the US government and US military 
establishment are being data mined.)

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