problem after upgrading bind.

[mark evans]

ok, i tried it. i touched another domain that was showing expired last
night.  it modified the time. i did an reload.  The log did not show the
domain was expired and the slave can still resolve the name.
Thanks
Mark


On 10/9/07, Chris Buxton <cbuxton at menandmice.com> wrote:
>
> 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
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>
>