[homenet] are FQDNs sufficient and if so for what?

[Curtis Villamizar <[e-mail]>]

The following is an excerpt from section "4.2.  FQDNs are not
sufficient" in Brian's draft-carpenter-referral-ps-02.txt

>    o  In large networks, it is now quite common that the DNS
>       administrator is out of touch with the applications user or
>       administrator, and as a result, that the DNS is out of sync with
>       reality.
>    o  DNS was never designed to accommodate mobile or roaming hosts,
>       whose locator may change rapidly.
>    o  DNS has never been satisfactorily adapted to isolated,
>       transiently-connected, or ad hoc networks.
>    o  It is no longer reasonable to assume that all addresses associated
>       with a DNS name are bound to a single host.  One result is that
>       the DNS name might suffice for an initial connection, but a
>       specific address is needed to rebind to the same peer, say, to
>       recover from a broken connection.
>    o  It is no longer reasonable to assume that a DNS query will return
>       all usable addresses for a host.
>    o  Hosts may be identified by a different URI per service: no unique
>       URI scheme, meaning no single FQDN, will apply.

The bottom line is I really don't see any serious problem with DNS.
It doesn't solve everything but wasn't intended to and replacing it
with a new mapping of names to address and other stuff won't change
anything.

The following is comments on each point individually.

>    o  In large networks, it is now quite common that the DNS
>       administrator is out of touch with the applications user or
>       administrator, and as a result, that the DNS is out of sync with
>       reality.

This is not a technical problem with DNS.  Large DNS domains can be
split into multiple subdomains.  For example, universities have always
delegated subdomains to departments that wanted them.

It may be that a lot of enterprises that run Microsoft junk that maps
into DNS are loath to use subdomains because it relinquishes control
(turf issue) or because the Microsoft junk gets harder to administer
when subdomains are in use.  [That's the excuse I heard at the last
corporation I was at - not sure if it is valid].

>    o  DNS was never designed to accommodate mobile or roaming hosts,
>       whose locator may change rapidly.

A highly dynamic name resolution is not the answer to mobility.  If
so, then getting rid of the 15 minute minimal TTL would do it.

But that would not solve the problem.  The name would have to be
updated exactly simultaneously to the new address being acquired if
the old address is lost at the same time.

The only reliable means of supporting unlimited mobility so far
involves using a fixed address, and a fixed base station and a means
of updating a tunnel from the base to the mobile device.

>    o  DNS has never been satisfactorily adapted to isolated,
>       transiently-connected, or ad hoc networks.

The suggestion to delegate to the home and provide secondary addresses
the transiently-connected domain which wants to be primary.

The same solutions to mobility apply to ad-hoc networks.  The
infrastructure is unnamed, but the nodes within it can be handled as
mobile nodes, including any routers that are mobile.

>    o  It is no longer reasonable to assume that all addresses associated
>       with a DNS name are bound to a single host.  One result is that
>       the DNS name might suffice for an initial connection, but a
>       specific address is needed to rebind to the same peer, say, to
>       recover from a broken connection.

In the cases where this is true, the FQDN (www.content-provider.com)
is intentionally mapped to a set of servers.  Using HTTP 1.1 for
example, there is no need to get the remaining chunks of a broken
connection from the same server.  Any of them should return the same
result.  In cases such as queries where results could vary, a redirect
is done on initial query.  Often this redirect is done anyway to point
to a topologically closer server or a server with lower utilization.

>    o  It is no longer reasonable to assume that a DNS query will return
>       all usable addresses for a host.

Nor does it matter.  Only one always reachable address is needed.  It
is about time that more than just routers started assigning a GUA to
the loopback and putting that in the DNS such that no matter which
interfaces were down or unreachable, the host was always reachable if
at least one interface was up and reachable.

>    o  Hosts may be identified by a different URI per service: no unique
>       URI scheme, meaning no single FQDN, will apply.

CNAMEs are very helpful.  I like keeping certain services as CNAME,
such as www, krb, cvs, svn.  Mail has its own redirection built in as
MX records.  If I want to ssh into the kerberos kdc I can use the
CNAME kdc.  It doesn't matter that this host may have other names.  I
can easily find out the FQDN that the CNAME points to.

Curtis