Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On BIND, I have an entry for a domain that is pointing to an old server and IP. This machine doesn't exist any more. When I make the change to point to the new server, the nslookup is still showing the old value for previous server. I changed the www entry last thursday (it's tuesday the next week), and the entry still hasn't cached/propagated through and is still showing the old entry. I have rebuilt the domain, deleting the previous, but I am still seeing the old entry showing up on NSLOOKUP. I am willing to wait awhile to let it cache through. Is there another way to get this to point to the appropriate working address, rather than it still pointing to the old?

share|improve this question

Rather than waiting for DNS caches to flush, you should do your lookups directly from the authoritative server(s).

With dig it is done like this:


With nslookup it is done like this:


As for trying to solve your problem, we can only make wild guesses because all you gave us was "I changed it but it didn't change."

If you add your actual config to the question we might have a chance. If you can't do that, Bind likes to log errors and continue on and attempt to load the rest of the zone files or entries. For instance, removing the ns2 line from a zone file causes this to be logged:

Feb 18 18:47:34 dns01 named[22465]: zone NS '' has no address records (A or AAAA)
Feb 18 18:47:34 dns01 named[22465]: zone not loaded due to errors.

But Bind will still start up and load all the other zone files. I'm not sure exactly how it behaves on bad syntax, whether it ignores that entry or the entire zone file. Look through your logs (that was in daemon.log) for anything related to named.)

Some other guesses:

  1. Did you restart Bind?
  2. Did you forget the trailing . on a CNAME entry?
  3. Did you double check that Bind is actually using the files you edited?
  4. Did you grep through all your zone files for the IP address?
share|improve this answer
I did check for the . on the CNAME. I have not restarted bind but Iwill do so shortly. The dig command brought up the old address as well. BUT it gave me the actual name of the server so I will be investigating that shortly. So more info has been uncovered about the previous web server. – Lnxchik1624 Feb 19 '13 at 14:38
Thank you! It finally loaded the right information. I think the dig was useful for getting more info and i finally restarted it (my bad, sorry). and about 5 minutes later it was loading correctly. Originally I changed it on webmin and did the restart from there but I guess it didn't work?? I did from CLI this time and seemed to work a lot better. Thank you! – Lnxchik1624 Feb 19 '13 at 14:52
Bad serial numbers (i.e., serial number of the zone wasn't increased, or wrapped aound)? – vonbrand Feb 19 '13 at 18:21

The original submitter's problem seems to have gone away at this point, but for the benefit of other people in the same situation who may stumble across this question..

The general order of operations for making a change to your name service and verifying afterwards that everything went as planned looks something like this (note: the list below does not cover zones with dynamic updates enabled, which will additionally require freeze and thaw steps if you are manually editing the zone master file, rather than using nsupdate to make changes)

  1. Back up copies of the old zone files in case something goes wrong.
  2. Make the planned changes to your zone file(s), taking special care to ensure that the serial number in the SOA record is properly updated for each zone that is edited.
  3. Review the changes you have made to the zone file. It doesn't hurt to run named-checkzone at this stage to ensure the edits are free of syntax errors. Also, be on guard for inadvertently omitted trailing periods at the end of FQDNs, this is the most common type of zone edit error and it is legal syntax so named-checkzone and/or the server will not flag it for you.
  4. Cause the zone to reload, using whichever of "rndc reload", "rndc reconfig", or restarting named seems most appropriate to your circumstances.
  5. Check the content served by the master name server by using a targeted dig (i.e. "dig soa") to ensure that the zone is properly loaded and the version being served has the new serial number.
  6. Look in the log files on the master and/or slaves for evidence that notify messages have been sent to the slaves and that the slaves have initiated a transfer of the new zone contents by AXFR or IXFR
  7. Use a targeted dig against the slave servers to check that the slave servers are now serving the proper copy of the zone data (check the SOA, and check the records you added or deleted.)
  8. Wait for the zone data to fully propagate. Slave servers that do not receive notifies may wait up to $refresh seconds before checking the SOA to see if new zone data is available. Other servers beyond your control may be caching the old zone data for a time period of up to the TTL value set for the zone (and nonconforming nameservers may set a floor value on how low of a TTL they will accept that is higher than the TTL you have actually chosen.)
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.