Re: A new spin on multihoming: multihoming classes.

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Sun, 9 Sep 2001, Iljitsch van Beijnum wrote:

> In the DNS, the information for each zone is replicated over two or more
> servers. Rather than making sure you can always get at a certain server,
> the DNS makes sure you can always get at the information by trying servers
> until a live one is found. If all TCP/IP applications (well, the DNS is
> not really an "application") did this, there would be no need for
> multihoming support.
> 

My other message addresses this. I'd like to add that I'm not sure I agree with
you that this is adequate.  Also, because I believe that DNS is agnostic
towards routing, in practice if I assume you would MH SOA & NS entries, you
might find DNS lookups slow down if random NS entries were used to locate DNS
information if one MH path was less optimal than another.  You might not get
black holed, but DNS resolution for the site would end up being degraded in the
presence of multihoming.

Can you see my reasoning?  For DNS to be efficient or even work at all, it has
to be MH aware to do its job.  It's circular and hence I believe there is a
problem.

There is a circular issue in the current DNS system, but we resolve it through
the use of geographically distinct secondary servers and gluing in the
delegation via a fixed IP address. This works because the routing system always
provides a path to the backup server in the instance that the primary DNS is
down.  I'm not so sure it will be so simple in a multi prefix environment.

Peter

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210