Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!aplcen!jhunix!ecf_hap From: ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain resolver resets needed Summary: There is already a mechanism in place... Keywords: that's what TTL's are for Message-ID: <1206@jhunix.HCF.JHU.EDU> Date: 24 Mar 89 15:28:09 GMT Expires: 23 Apr 89 23:00:00 GMT References: Reply-To: ecf_hap@jhunix.UUCP (Andrew Poling) Followup-To: comp.protocols.tcp-ip Organization: The Johns Hopkins University - HCF Lines: 38 In article w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) writes: >On Monday March 20 a large number of Milnet hosts changed their >network addresses. Simtel20 was one of those. I've been getting a >lot of complaints from users on other hosts who cannot connect to >Simtel20 with FTP. We are also not receiving mail from a number of >hosts which are reporting "connection refused". > >The problem can be solved by restarting your domain resolver so it >will pick up the new address for Simtel20 and the many other hosts >whose addresses changed. This shouldn't be necessary. I mean, while it is necessary, it shouldn't be. If the TTL (time-to-live) on these entries were set to a short period of time (say a coupla hours or something) in advance, then set back to their usual large values afterward, any change in information would be picked up quickly by other name-domain-servers. > >This points out the need for some mechanism to update domain resolver >caches before their expiration so that when address changes occur they >do not result in loss of connectivity. In our case it will be five >days before hosts with domain servers know that we have made the >address change. Meantime they are all trying to connect to >whitesands-mil-tac which now has our old address. The BIND operations guide suggests the use of low TTL's in exactly this sort of situation for exactly this reason. Sure it would mean a *little* more traffic and less efficient use of caching, but only temporarily. Andy -- Andy Poling andy@gollum.hcf.jhu.edu Network Services Group ecf_hap@jhunix.UUCP Homewood Academic Computing ECF_HAP@JHUVMS.BITNET Johns Hopkins University