Dear ...,

I think that the time has come to do something about the DNS/ICANN
mess. It seems to me that ICANN is not only implementing the wrong
solution, it is fundamentally devoted to solving the wrong
problem. But it is at least doing harm by distracting lots of good
people from productive work, and may find ways to do worse than
that. The right strategy now is neither to fight ICANN, nor to work
with it, but to make it irrelevant by offering the right sort of
service to devalue DNS and its TLDs.

DNS has suffered from the start from a bundling of two radically
different sorts of service:

1. it provides portable unique identifiers for entities and services,
allowing IP addresses to be assigned for efficient routing.

2. it provides a crappy but better-than-nothing directory of
sort-of-meaningful names for entities and services.

A variety of organizations are already competing on service #2:
Google, Yahoo, etc. They are not covering all of our needs, and we
will be vulnerable to monopolistic bottlenecks at some point, but at
present these services provide better directories than DNS and are
basically stable while improving. It is also still possible for new
competitors to enter this arena, and there is no severe application
of artificial scarcity.

** ACTION ITEM ** We need to create a competing version of service
#1. It should map inherently meaningless, hierarchical, extensible
unique identifiers to descriptors indicating how to contact a
particular entity, request a particular service.

The keys: arbitrarily long sequences of arbitrarily large integers
(e.g., 476.8337942.42.1.83675). The hierarchy is purely
administrative. The administrator of a number at any level can assign
suffixes freely. There is no need to ration the top level, and no
value in capturing multiple top-level numbers, since a single one
gives just as much power as many. Technically the keys are really just
sequences of numbers, not character strings, but we'll use character
strings to bootstrap from the current DNS system.

The values: members of a large, open, union of types. The first type
in the union is just IP address. We can add new types of values on
demand as we figure out what is most useful. Early extensions are
likely to allow sets of tuples of the form

	<IP address, port, application-specific parameters>

creating hunt lists. Later we are likely to get patterns, multicast
specifiers, ... For backwards compatibility, the owner of a name may
associate several types of value, and each query to the system may
specify which level of value it desires. E.g., a complicated multicast 
pattern can go along with a single IP address where a server sets up
the semantics of the multicast for a querier who hasn't yet
implemented its own multicast capability.

Initial implementation: take a domain, and represent keys as
hierarchical subdomains. We don't need a TLD, or even a second-level
domain, for this purpose. 476.8337942.42.1.83675.netids.sponsor.org works
fine. Automate the registration process, sending a top-level numerical
ID to anyone who requests it. Allow (perhaps require: tricky decision)
a cryptographic key to inhibit hostile capture of the entry. Let the
assignee change the entry (initially just an IP number) at will. By
using the current DNS, we get the benefit of all the DNS-cognizant
software that's already out there. Depending on the resource/demand
balance, the we can limit our registry to top-level assignments, and
require each assignee to support the DNS tables for her own
hierarchy. Or, we might offer a modest amount of server-side support
for individual hierarchies at first, to avoid having naive users hoard
top-level numbers to avoid having to implement their own DNS servers.

Future implementation: create a server that works more efficiently
directly on the numerical sequences. Hack the netids.sponsor.org DNS
daemon to chop off its own suffix and pass the remainder to the more
efficient server, while promulgating client software that bypasses the
DNS level. All extensions to the semantics of table entries go into
this native server. Very aggressively promote mirroring servers (which
you get for free in the DNS version). As soon as possible, spin off
distributed servers covering different subranges of top-level keys. At
some point, there should be garbage collection of unused keys. But we
have plenty of time to think about what "unused" really means.

Vulnerabilities: At the beginning, while dependent on the DNS
piggybacking and very simple-minded, there is vulnerability to
hijacking (which directly harms the assignee and her correspondents,
but indirectly the credibility of the system). Because of this, we
*might* want to require, rather than just allow, a cryptographic
key. Perhaps by generating keys for the naive we can avoid making this
a big barrier to entry. Until people are clever enough to use a secure
transmission to determine the key, they are still vulnerable to
sniffing when establishing the key, but in practice that's probably
not a biggie. We are also vulnerable to denial of service by flooding,
both in the assignment of keys and in the querying. But the attacker
doesn't have a lot to gain in such an attack. Simple procedures, such
as imposing a delay between transactions from similar IP numbers,
might defend against the more naive attacks. It will be important to
demonstrate early that acquiring and hoarding lots of numbers gives no
serious advantage. Once I acquire the top-level key n, I can create
hierarchical keys for myself that are only one bit longer than n+1,
n+2, etc. There's some exposure to naive users hoarding top-level keys
to avoid setting up their own DNS, but I doubt that such naive users
will take very many keys apiece, and we can afford a lot of waste. I'm
trying to think of liability problems. The use of meaningless numbers
is supposed to avoid all of the trademark nonsense. There must be
marginal problems with number-letter substitutions, numerologically
significant numbers, etc. Getting beyond the DNS character-string
piggybacking into invisibly traded binary keys will help. Liability
for failing to create a rendezvous, or for allowing a malicious
redirection by an unauthorized attacker is possible. But the
disclaimers on perfect reliability for IP routing seem to have
succeeded, and the provision of cryptographic keys can probably put
the onus of guaranteeing integrity on the assignee.

Perhaps the biggest vulnerability is that someone will think of a way
to use the system that we completely fail to anticipate, leading to a
load that we are unprepared to handle. But that's rather the fun part.

I worked all this out for myself, but I'm pretty sure that most if not 
all of it has been proposed before. I could help hunt up the other
proposers and jawbone them into a meeting.

So, what does it take to just do it? Who would front the thing? How
much funding do we need?

On the one hand, I think that ICANN is trying desperately, and failing
miserably, to allocate a resource that really isn't worth much. Maybe
that's their problem, and I should tend my own garden. On the other
hand, I'm worried that all the fuss will eventually cement DNS and its
worse successors as a bottleneck on use of the net. E.g., the use of
reverse DNS lookup as a sort of netwide *mandatory* identity check
seems possible, and scary. Or, ICANN could just grow into an
undesirably strong center of power, and find that it can do something
completely different from DNS. And anyway, there's something better
than DNS, and we ought to create it.

Cheers,

Mike O'Donnell
http://people.cs.uchicago.edu/~odonnell/