Re: An alternative to 6to4 and teredo

[Keith Moore <moore@cs.utk.edu>]

On Mon, 20 Jan 2003 10:36:30 -0500
Margaret Wasserman <mrw@windriver.com> wrote:

> 
> 
> >many applications involve more than two parties, even if the
> >interconnections between components of those applications are
> >two-party connections.  a >2 component app often needs to be able to
> >provide referrals from one component to another - e.g. to say "if you
> >need to access this component, contact it at address A port P".
> 
> I've been thinking about this a lot lately, and I wonder...  Why do
> these referrals need to be by IP address?  It would make more sense to
> refer another party to a DNS name and port number.  

No it doesn't.  

First, because DNS is too slow and unreliable for some purposes; 

Second, because a host can have multiple DNS names associated with it at
any given time, but the binding between the DNS name and the host is
subject to change at any time and the host/app typically doesn't know
which DNS names are bound to which things; 

Third, because even if an app does use DNS lookup to get all of the
addresses of its peers it still doesn't mean that it's better to expect
the host/app to be responsible for routing than to expect the network to
do so.

> Then the other party can do its own DNS look-up, and make its own
> address selection decision.

It's the idea that it's reasonable to expect a host or app to make a decision about which address to use that I'm questioning.  Just because it's hard for the network to do routing on a large scale doesn't mean that apps and hosts are in a better position to do so.
 
> >if the network requires address selection in order to allow one
> >component to reach another, then it hinders operation of this kind of
> >application. and for a variety of reasons, DNS is often too
> >ambiguous, too slow, or too unreliable for DNS names to be used as
> >general-purpose names for hosts.
> 
> If DNS is too ambiguous, slow or unreliable for this purpose,
> shouldn't we fix DNS?

You can't fix DNS, at least not beyond a point.  Part of the problem is
that DNS names have long since ceased to be host names, and there's no
going back.  DNS names are now better thought of service names, with "host" just being another kind of service.  Another part of the problem is that DNS is by intent and design heavily federated and distributed, which means that DNS servers typically aren't co-located with, and don't share fate with, the endpoints that use them.

It may be possible to improve DNS, e.g. by building better tools to keep servers in sync and to discourage configuration errors, by using anycast addresses for DNS servers and using routing advertisements to direct queries to nearby servers that happen to be up, by building large distributed DNS server farms and getting sites to outsource their DNS servers to such farms (at least for their public DNS service), etc.  But I don't see this happening soon, and in any event I don't see how DNS can be made as reliable as IP.

DNS is a very useful service, but DNS names are not suitable as a universal replacement for IP addresses as endpoint identifiers.

-- 
I tried enlightenment but it kept crashing.