Very strange disk caching of zone file
ccc2716 at vip.cybercity.dk
Sat Nov 19 16:00:02 UTC 2005
I was thinking if you have set primary as master and secondary as slave
If that is the case, you will risk mixing of two different update
Also be careful to update the serial number in each zone, it may play
some tricks if you don't at least if set as master and slave.
Redux Hostmaster wrote:
>I've tried numerous searches on this, and it has baffled all of us
>here, so I will post the scenario and look forward to any feedback
>DNS setup is as follows...
>Primary and secondary nameservers, both holding master records,
>synced and zones reloaded whenever an update is made to a zone file.
>Problem is noted on secondary nameserver, when any modifications made
>to /var/named/[our-reverse-zone].db do not take hold.
>Here's how it was tested:
>- PTR record added to zone file in question.
>- Zone file reloaded, named also restarted for posterity
>- /var/log/messages indicate zone is successfully loaded (serial is
>updated just to make sure it is grabbing the new zone on disk)
>- dig @localhost -x [new IP in PTR] returns NXDOMAIN
>The exact same testing behavior on the primary server results in
>The only solution we have been able to come up with, is renaming the
>zone file in /etc/named.conf -- and then copying the existing zone
>out of /var/named to the new name in /var/named.
>Upon reloading the zone, a dig returns the appropriate results.
>Any attempt to switch the zone file back to the original name results
>Any input on this perplexing problem would be greatly appreciated.
>Network Redux, LLC
>hostmaster at networkredux.com
Let HIM who has an empty INBOX send the first mail.
More information about the bind-users