huntting@boulder.Colorado.EDU (Brad Huntting) (09/09/90)
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
dfk@eu.net (Daniel Karrenberg) (09/10/90)
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