problem after upgrading bind.

[Chris Buxton]

One quick and dirty workaround for an expired zone is to change the  
slave copy's file modification date, and then tell named to reload.  
For example:

touch /path/to/zonefile
rndc reload

This gives you another <expire> period in which to figure out and fix  
the problem, during which the slave is once again loading its cached  
copy. If the cached copy is out of date, then if you can copy over  
the master copy of the zone and put it in place of the current cached  
copy, that should work as well and bring the slave up to date.

Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone:   +354 412 1500
Email:   cbuxton at menandmice.com
www.menandmice.com

Men & Mice
We bring control and flexibility to network management

This e-mail and its attachments may contain confidential and  
privileged information only intended for the person or entity to  
which it is addressed. If the reader of this message is not the  
intended recipient, you are hereby notified that any retention,  
dissemination, distribution or copy of this e-mail is strictly  
prohibited. If you have received this e-mail in error, please notify  
us immediately by reply e-mail and immediately delete this message  
and all its attachment.



On Oct 9, 2007, at 9:03 AM, mark evans wrote:

> Yes, i did run the dig from the slave.  i will try the tcpdump.   
> when i
> restarted the bind 8.4 on the master the slave seems to have pulled  
> the
> zones over because it is no longer showing expired.  So i have to  
> wait for
> another zone to expired.  I will try the tcpdump as soon as i get  
> an expired
> zone.
> Thanks for you assistance
> Mark
>
>
> On 10/9/07, Niall O'Reilly <Niall.oReilly at ucd.ie> wrote:
>>
>>
>> On 9 Oct 2007, at 16:12, mark evans wrote:
>>
>>> The only error i see logged about this domain is the expired
>>> message, which
>>> i get when i start the server.  I tried renaming the zone file  
>>> and and
>>> forcing the transfer but the zone file was not created on the slave.
>>>
>>> we also are not seeing any errors logged on the master.
>>
>>        From what you've explained --
>>
>>          Zone transfer from master works manually using dig;
>>          Zone transfer from maser doesn't work automatically using  
>> named;
>>          Zone trnsfer request from named seems not to reach the  
>> master.
>>
>>        Something is different between the request you generate  
>> manually
>>        and the one which named generates.
>>
>>        Did you run dig on the same system where the slave named is
>> running?
>>        What does your favorite packet-capture utility (tcpdump, for
>> example)
>>        tell you?
>>
>>        /Niall
>>
>>
>>
>
>
>