w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) (03/23/89)
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 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. --Keith Petersen
tcs@BRL.MIL (Terry Slattery, SECAD) (03/23/89)
> 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. The current refresh entry should satisfy this need if the changes are expected in advance. A week before the change, set the refresh interval to 24 hours. Hosts will begin using the 24 hour interval when their current info expires. One day before the change, set the refresh interval to something smaller, perhaps 2 or 4 hours. When the change is made, hosts will only be using the wrong addresses for at most 2-4 hours. When things are stable, change back to your normal refresh interval. For this to work, you must know at least your current refresh interval in advance of the change date. There will also be a slight increase in network traffic as hosts refresh more frequently. Without significantly more state in the nameserver about who requested host info, there is no easy way to flush remote caches. You already know the alternative - answer phone calls from remote sites who can't contact you and have them do a manual flush. I noticed that wsmr-simtel20.army.mil has a ttl of 24 hours, not one week. All DNS hosts should work properly after this time and only hosts using a static host table should have problems. -tcs
ron@ron.rutgers.edu (Ron Natalie) (03/24/89)
Kieth: There's a simple solution to this. Walk around to the back of your PSN and swap the cables for the TAC and your host. This gratuitous renumbering on the MILNET is one of the silliest things I've seen in years. It was a hold over from the old days (when TIP's were integral with the IMPs) that TAC's occupied port 2. The displacing of every host on the MILNET who occupy port zero is a real pain. I notice that either the NIC didn't get bumped, or their nameserver info is out of date. Of course this is from the people who brought you the quaint phrase "rehomed" as a description of what they did when they kicked most of the universities off the ARPANET last year. This from the same group that wastes more time on the Domain transition issue thinking up what to name the hosts than actually doing anythign about it. Several years ago when I was still in the employ of the Army, and one of the only representives of an actual military site on the Internet Engineering Task Force, we sat down with a subcommittee to figure a way to practically make the domain transition for the military nodes. The recommendation involved things like setting up a first step with a few nameservers that had the authoritative information for the .MIL domain, and would forward domain queries for less adventuresome MILNET sites. I was probably sufficiently cautious because at the time I deplored the domain implementation (is this any way to run a distributed database). All of these recommendations were ignored. The next debacle was the demise of the interim .ARPA domain. People seemed to think that the magical removal of this domain was going to accomplish something. To me it's just another top level domain, nor more or less valid than .GOV or .MIL or anything else. What needed to be done is to convince the military sites to do name resolution, or to at least fake it well. Just renaming the hosts did nothing to help this and we're still in the dark ages where it comes to talking to the guys on the Autodin II side of the universe. -Ron (Blown to hell by BRL) Natalie
almquist@JESSICA.STANFORD.EDU (Philip Almquist) (03/24/89)
Terry, > The current refresh entry should satisfy this need if the changes are > expected in advance. A week before the change, set the refresh > interval to 24 hours. Hosts will begin using the 24 hour interval > when their current info expires. One day before the change, set the > refresh interval to something smaller, perhaps 2 or 4 hours. When the > change is made, hosts will only be using the wrong addresses for at > most 2-4 hours. When things are stable, change back to your normal > refresh interval. The idea is right, but you used the wrong words and therefore might confuse somebody. There is a field in the SOA record called the REFRESH interval, but that is not what you were referring to above. What he does want to decrease is the TTLs associated with the records that are going to change. Since no record may have a TTL smaller than the zone MINIMUM TTL (another phrase from RFC 1035), he may well have to change the zone MINIMUM TTL. Philip
LARSON@KL.SRI.COM (Alan Larson) (03/24/89)
Keith Petersen mentioned the need to update domain resolver caches, noting that it would be 5 days before hosts with domain servers know that they have made an address change. Not quite true. Some hosts will (randomly) have almost expired data in their local cache, this data will expire in less than five days. Other hosts that didn't have the address at all, will work instantly. In any case, this problem need not have occured. I include excerpts from two RFCs on the subject: - - - - From RFC1033, "DOMAIN ADMINISTRATORS OPERATIONS GUIDE" Most host information does not change much over long time periods. A good way to set up your TTLs would be to set them at a high value, and then lower the value if you know a change will be coming soon. You might set most TTLs to anywhere between a day (86400) and a week (604800). Then, if you know some data will be changing in the near future, set the TTL for that RR down to a lower value (an hour to a day) until the change takes place, and then put it back up to its previous value. From RFC1034, "DOMAIN NAMES - CONCEPTS AND FACILITIES" ... If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change. - - - - Alan -------
rick@UUNET.UU.NET (Rick Adams) (03/24/89)
When uunet.uu.net (also a very popular host) changed from 192.12.141.129 to 192.48.96.2 I did exactly as everyone suggested. A week before the expected change, I dropped the TTL to a day. The day before the move, I dropped it to 4 hours. After the move, I of course raised it to 10 days. It worked just like it was supposed to. Domain server sites didnt notice any difference. host.txt sites thrashed for a few days until the updated hosts.txt was available. --rick
ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling) (03/24/89)
In article <KPETERSEN.12480089674.BABYL@WSMR-SIMTEL20.ARMY.MIL> 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
blarson@skat.usc.edu (Bob Larson) (03/26/89)
In article <8903231027.aa08575@SEM.BRL.MIL> tcs@BRL.MIL (Terry Slattery, SECAD) writes: >The current refresh entry should satisfy this need if the changes are >expected in advance. [description of manually changing refresh time ommited.] Wouldn't it be better to give a specific exparation time to the name server, so the name server caches would all expire at the proper time without making the refresh interval to short or needing manual intervention? (Is this just a case of the available software doesn't have this capability?) -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (03/27/89)
Settings for TTL values is out of our hands and handled by the NIC under direction of DCA. Unfortunately, the directions which DCA gave the NIC did not include the TTL transition steps you and others described for this last port address overhaul. I am sure that they are now aware and that future updates will include progressive TTL change instructions. --Frank
ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling) (03/28/89)
In article <16103@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >Wouldn't it be better to give a specific exparation time to the name >server, so the name server caches would all expire at the proper time >without making the refresh interval to short or needing manual >intervention? (Is this just a case of the available software doesn't >have this capability?) Ouch! Can you imagine every caching nameserver in the country assaulting the root servers all at once? I (and I'm sure alot of others do this too) get a full download from the root servers of the top-level domains which see alot of traffic here. I can do this because the host in question hasn't got much else to do. When that TTL runs down, I query the root servers to see if I have to down load again. That would mean that every machine like mine would be requesting a download within ten minutes of each other (five minute ns_maint sleep gives +/-5 minute spread from the target time). I don't think the root server's administrators would like that idea. :-) 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