Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!dfk
From: dfk@eu.net (Daniel Karrenberg)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: DNS in Europe : issue 2
Message-ID: <1797@mcsun.eu.net>
Date: 10 Sep 90 07:54:17 GMT
References: <9009081952.AA25986@inria.inria.fr>
Distribution: inet
Organization: European Unix systems User Group
Lines: 55

dupont@INRIA.INRIA.FR (Francis Dupont) writes:
> How do you select sites for secondary name-servers ?

There are basically three reasons for having secondaries:

	1) backup in case the primary machine or local network
	   segment is down

	2) backup in case global network connectivity to the primary
	   is lost

	3) offloading (network connections to) the primary


So we place at least one secondary quite near to the primary but
preferably on another local network segment and power circuit
to satisfy 1 above. 

Then we put some secondaries in different places of the world like US
and Australia to satisfy point 2 above.  In case of a toplevel domain we
also put some secondaries in different parts of Europe because
intra-European connectivity is not what it should be quite yet and links
are quite loaded so that point 3 above becomes more of a concern. 

In case of lower levels of the domain tree we are reluctant to place
secondaries at places administratively remote from us.  This because the
added redundancy does not outweigh the operational problems we can get
from an inconsistent DNS in case our secondary site is not well
maintained.  We are especially weary of arrangements where there is just
one (sometimes extremely) helpful person at the secondary site.  What if
that person gets run down by a truck or changes jobs?  The ideal
situation is one where we have reciprocal agreements with the
administrators of the secondaries which allow us to log into their
systems and manipulate the nameservers if need be. 

For the refreshes we are not so much concerned about the network load
as about the relieability. The most frustrating thing is not being
able to refresh an obsolete zone of which you know it's out there
and for example causing valid mail addresses to bounce. This is also
one of the cases where a close relationship with the maintainers 
of the secondary servers is a must.

The most important lesson we have learned so far is that the rule is
not what you think it is at first: "Get as many secondaries as you can
for maximum redundancy." This can get too complex to manage very quickly.

A rule we did learn: "Be extremely aware of unnecessary glue RRs!"
Obsolete ones can haunt you!

Cheers

-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcsun!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX