[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