problem after upgrading bind.

[Chris Buxton]

You weren't supposed to delete the existing file.

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 11:38 AM, mark evans wrote:

> i tried your suggestion.  deleted the zonefile.  touched the file  
> and did a
> rndc reload.
> it deleted the newly created zonefile.  i didn't seen any errors in  
> the
> slave's log.
> Thanks
> Mark
>
>
> On 10/9/07, Chris Buxton <cbuxton at menandmice.com> wrote:
>>
>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>