Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ub!boulder!huntting
From: huntting@boulder.Colorado.EDU (Brad Huntting)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: DNS in Europe : issue 2
Message-ID: <25908@boulder.Colorado.EDU>
Date: 9 Sep 90 16:44:02 GMT
References: <9009081952.AA25986@inria.inria.fr>
Sender: news@boulder.Colorado.EDU
Reply-To: huntting@boulder.Colorado.EDU (Brad Huntting)
Distribution: inet
Organization: University of Colorado, Boulder
Lines: 28

In article <9009081952.AA25986@inria.inria.fr> dupont@INRIA.INRIA.FR (Francis Dupont) writes:
>
> How do you select sites for secondary name-servers ?
>The issue is not simple : load sharing is more effective if secondaries
>are far from the primary, but refreshs can become expensive ...
>I'd like to know if there are some works or heuristics about this matter.
>
>Francis.Dupont@inria.fr

As I see it, there are really two kinds of secondary nameservers.

The near ones and the far ones.  The near ones you strategically
place to insulate yourself from network/host failures on your
own network.  For example we try to place a nameserver at every
subnet gateway, and we run them as secondaries so they never
forget the names of the hosts on the local subnet.  It would be
better if we could tell them to only down load the portion of the
zone dealing with that subnet, but this is not really possable
without creating secondary domains.

The far ones should (in my opinion) be placed very far away.  I
don't think you should worry about refreshes too much.  Bind
versions 4.8.2(?) and later will not transfer the zone unless the
serial number in the SOA record changes.  We have a very dynamic
zone, and so to keep down the network trafic we only allow zone
changes every other day of the week.  Our refresh rate is 12h.

brad