Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!CS.UCLA.EDU!wales From: wales@CS.UCLA.EDU (Rich Wales) Newsgroups: comp.protocols.tcp-ip.domains Subject: Pros and cons of secondary name servers off site Message-ID: <910306.205519z.05578.wales@valeria.cs.ucla.edu> Date: 6 Mar 91 20:55:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 32 What is the current policy/philosophy on having a copy of a domain's data stored on at least one "off-site" server (e.g., a secondary name server for UCLA data that is located somewhere other than UCLA)? When the domain system first came out, it was either a requirement or a strong recommendation that this should always be done. However, when I looked through RFC 1123 (host software requirements) the other day, I was unable to find any comments on the issue of off-site name service. When I suggested to a colleague around here that we ought to arrange for an off-site secondary server for our domain info, he countered that doing this would be pointless. He reasoned that, if his department's machines were all down, no one would be able to send him mail (or TELNET or FTP to him) anyway -- and anyone trying to send mail to his depart- ment would get temporary "name server failure" errors and try again later. So (he reasoned), why bother with off-site backup name service? My gut reaction to the above was that it's probably better to have the name server info available anyway, even if the hosts in question aren't reachable. But I can't think of any convincing reason why this =must= be so. Is the idea of off-site backup name service just one of those concepts that seemed to make sense in the original design of the system, but which turned out to be impractical and has since been quietly dropped? Comments? If possible, I'd prefer an explanation of =why= off-site backup name service is (or is not) a good idea, rather than simple com- ments of the form "thou shalt do it because such-and-so RFC demands it". Rich Wales // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683