[governance] It's Time to Stop ICANN's Top-Level Domain (TLD)

[Karl Auerbach]

On 11/05/2010 01:05 PM, Rafik Dammak wrote:

> you mentioned many times resource discovery, can you please clarify what
> you mean by it? I am not sure that everybody here share the same definition.

I also wonder at that claim.

For a few years a lot of people believed that DNS was some sort of 
authoritative directory system.

DNS is no such thing.

It is at best a hinting system - which means that one has to take the 
DNS records with a bit of skepticism.  Unfortunately there is a gap in 
the internet architecture; we don't have a clear layer for 
identification/authentication that can be used to turn those DNS hints 
into something more concrete.

Few of us would call 411 (directory services here in the US), tell the 
operator (usually an electronic person) "connect me to my doctor", and 
then once connected blurt out to the person who answers "I have X, Y, 
and Z diseases".  No, we'd listen to the person who answers and interact 
with him/her to get a sense that we've actually connected with the 
intended person.

But on the internet we do the dumb thing - we trust DNS to give us some 
sort of "authoritative" pointer and then engage in the most sensitive of 
communications without further adieu (or no more than a SSL [that could 
be spoofed by a man-in-the-middle] connection that we don't even bother 
to validate beyond very well.)

As for resource discover - that is a hard thing.

Consider a simple example "print this on the nearest printer".  We did 
that once - and it often turned out that the nearest printer was on the 
floor above or below - which in our building in San Francisco required a 
trip through the security gates between floors to fetch a printout.  The 
"correct" answer in that case of resource discovery would have to 
accommodate something other than raw physical distance.

I did a lot of work on resource proximity when I was part of the 
Advanced Internet Architectures Group at Cisco.  I developed the 
skeletons of a protocol to measure resource proximity taking into 
account the traffic burdens and requirements that would be engendered by 
use of a resource.  (The problem I was trying to solve at that time was 
the binding of video clients to video servers.)  Anyway, Cisco has given 
me permission to publish that internal partial work:  See 
http://www.cavebear.com/cbblog-archives/000151.html (which contains 
pointers to more details.)

(I've also worked a bit on an idea that maps the biological mechanism of 
pheromones onto somewhat randomly wafted packets, but that's for another 
day.)

Getting back to DNS - even if wrapped with DNSSEC and other kinds of 
security, DNS can never be considered perfectly correct - there is too 
much internal caching going on (with cache timeouts of sometimes several 
weeks) and we have expiring names being snapped up and reused, often 
intentionally to grab the lingering traffic.

There are more interesting approaches - like IF-MAP - that make more 
sense for resource discovery.

This hardly means that DNS is moribund.  Rather, DNS is an amazing 
system and ought to survive a very long time as long as its limitations 
are recognized.

My own sense is that DNS will eventually be submerged under a 
multiplicity of discovery and search systems and thus become an internal 
mechanism rarely seen by users.

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

Translate this email: http://translate.google.com/translate_t