Very strange disk caching of zone file

[Sten Carlsen]

I was thinking if you have set primary as master and secondary as slave
in named.conf?

If that is the case, you will risk mixing of two different update
mechanisms.

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  
>offered.
>
>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  
>success everytime.
>
>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  
>in failure.
>
>Any input on this perplexing problem would be greatly appreciated.
>
>Redux Hostmaster
>Network Redux, LLC
>hostmaster at networkredux.com
>http://www.networkredux.com
>Phone:  800-756-6518
>Facsimile:  800-756-6518
>
>
>
>
>  
>

-- 
Best regards

Sten Carlsen

Let HIM who has an empty INBOX send the first mail.