Subject: Re: Something better than DNS?

From: Emin Gun Sirer <[email-masked]>
Date: Mon, 27 Nov 2006 12:39:59 -0500

Hi, 

Let me expand on how DNSSEC coupled with a cooperative, p2p architecture
for DNS can help enable competition among TLDs. The short summary is:
  - CoDoNS+DNSSEC enable any server to securely serve any name, 
	which makes it possible, should the community decide to 
	pursue it, to have a TLD be served by any number of registrars.
  - This can be accomplished with a single root and consistent 
	namespace.
  - Such a delegation of a domain to multiple operators is 
	optional. Though CoDoNS is an enabler for it, it is also 
	entirely agnostic on the issue. We could just as well
	preserve the status quo of one registry per TLD; in 
	fact, this is the sensible thing to do initially.

Here is the longer story:

- Current DNS performs delegations physically, by handing the query off
to a set of servers; the name hierarchy and the server hierarchy are
intertwined. This leads to a natural monopoly. Suppose you want a .COM
name, but also want to boycott VeriSign over SiteFinder? Tough. You want
a .AERO name, but want robust, reliable name resolution? Again, tough.
You have no way out, because the servers operated by those entities are
involved in the resolution of the names in their assigned TLDs.

- DNSSEC enables the name delegation to be decoupled from the server
hierarchy. Currently, root says "for .FOO, go further query these
servers" and you have to trust the network that your packets go to the
intended .FOO servers. With DNSSEC, root can say "whoever has the
matching private key for public key K_foo is authoritative for .FOO" and
anyone can provide an answer. The response is self-certifying by virtue
of the crypto signature it carries. Someone without access to the
private key k_foo cannot create false bindings. This is nice, as you all
realize, because the network need no longer be trusted; the bindings can
be independently verified. But it still relies on the old DNS server
hierarchy for lookups of the appropriate delegations.

- CoDoNS enables the query resolution to be decoupled from the server
hierarchy. With CoDoNS, any node can cache and forward an authoritative
response to any query, provided that the response is signed properly.
Instead of a tree-based hierarchy of servers, we instead have a giant
pool of servers, all ready to step in for each other when a node fails,
and self-organizing to provide the level of performance necessary for
DNS. This has nice implications for DoS-resilience. It has one single
root. We do not propose a separate root; fracturing the namespace would
be a dire mistake for all the reasons people have outlined before.
CoDoNS supports all existing DNS names.

- With CoDoNS+DNSSEC, the natural namespace monopoly is gone. We have
the same hierarchical namespace we all have come to love, but without
the natural monopolies associated with serving it. It is possible for
root to delegate .FOO to a public key K_foo, and give out the private
key k_foo to two separate entities, say R1 and R2. Now, both R1 and R2
can issue names with the suffix .FOO. You want the name BAR.FOO, but
don't like the way R1 is treating its customers? Great, buy your name
from R2; it is just as authoritative. Naturally, R1 and R2 will have to
cooperate to not issue conflicting bindings for the same name. There are
lots of protocols (e.g. a secure timestamp from a trusted server is the
cheapest scheme; more elaborate schemes based on consensus protocols are
possible) for achieving this, and it is also possible to contractually
oblige R1 and R2 to cooperate (e.g. root does not give anyone k_foo
unless they sign an agreement to follow a protocol for avoiding
inconsistent bindings). 

A good system architecture should enable many different kinds of
operational deployment. CoDoNS+DNSSEC enables a new kind of deployment
that is not possible currently or with DNSSEC alone. Should we all
decide that it makes sense to delegate parts of the namespace to
multiple operators, we can do so with the matching namesystem
architecture.

As designers of CoDoNS, we don't particularly care if IANA decides to
delegate TLDs to single operators each or to multiple operators, though
we will rightfully point out that our architecture is more flexible than
the legacy DNS. The delegation of a domain to multiple operators, while
possible, is something that will likely take at least 5-10 years to
become operationally feasible. It's the kind of thing academic research
is supposed to enable; politics often dictates what really happens on
the ground. Frankly, I'd be delighted if IANA simply signed the
top-level keys to delegate the top level TLDs to their respective,
single operators. 

So, the delegation of namespaces to multiple operators is a nuanced
twist as far as CoDoNS is concerned. Here is the bigger picture: CoDoNS
recently served www.electoral-vote.com, Andy Tanenbaum's very popular
election tracking site that had previously been the target of DoS
attacks. With CoDoNS, Andy had more servers dedicated to serving his
name than the DoD had dedicated to serving .MIL. His DNS was not
targeted for DoS attacks. This is the kind of material difference a new
architecture can make.  

Gun.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 11:45:56 +0100

On Mon, Nov 27, 2006 at 12:39:59PM -0500,
 Emin Gun Sirer <[email-masked]> wrote 
 a message of 99 lines which said:

> the name hierarchy and the server hierarchy are intertwined. This
> leads to a natural monopoly. Suppose you want a .COM name, but also
> want to boycott VeriSign over SiteFinder?

You are playing with words. CoDoNS separates name service and name
delegation but there is still a monopoly on the name delegation, which
is the important stuff.

> - With CoDoNS+DNSSEC, the natural namespace monopoly is gone. 

False. CoDoNS does not magically allow me to register microsoft.com
and have it distributed to the world.

> Naturally, R1 and R2 will have to cooperate to not issue conflicting
> bindings for the same name.

That's the problem with most "one namespace, several registries"
proposals. There is still a registry to coordinate the so-called
"several registries" so you're back to step 1.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 28 Nov 2006 08:06:22 -0500

On Tue, 28 Nov 2006 11:45:56 +0100

> "several registries" so you're back to step 1.
"Most?"  I'd have said "all".  

The name space is a tree, and (for almost all purposes except web
browsing, and maybe even then) has to be one.  (Reread 2826.)  This
says nothing about how one arbitrates the nodes of the tree at any
level, including quite specifically the root node and the nodes
directly underneath it (i.e., the TLDs) -- it can be the current ICANN,
a replacement body, co-operation, bidding, or the ghost of Jon Postel
-- but the nodes *must* be distinctly named if name resolution is to
work.

For those who like alternate roots, you can either assert that "our TLD
registrars would never compete" (the co-operation model) or you force
people trying to use these resolvers to know which one to use.  In that
case, the pointer to the proper resolver is the real second-level node,
and the real root is whatever designates that name space.  In other
words, you haven't changed the model, you've just added another level
(and created trouble besides).

		--Steve Bellovin, http://www.cs.columbia.edu/~smb