Slave Refresh Rates

Mark Damrose mdamrose at elgin.cc.il.us
Fri Jan 11 04:24:04 UTC 2002


"chris" <cherbst at hotpop.com> wrote in message
news:a1l93f$nl2 at pub3.rc.vix.com...
>
> On Thu, 10 Jan 2002 15:09:33 -0500, Mark Damrose wrote:
>
> > "chris" <cherbst at hotpop.com> wrote in message
> > news:a1kp04$l4q at pub3.rc.vix.com...
> >
> >
> >> dig @ns1.my.domain my.domain axfr > my.domain.db
> >
> > Don't do this in any automated way.  If ns1.my.domain is down, you've
> > just wiped out your other server too.
>
> OK, then how about:
>
> dig @ns1.my.domain my.domain axfr > my.domain.db||exit 1
> named-checkzone my.domain my.domain.db&&rndc reload
>

Just tested this, and named-checkzone doesn't seem to care that there are 2
SOA records.  I'm not curious enough to find out if named would actually
load a zone with 2 SOA records.

However - by the time you test to see that the transfer failed, you've
already wiped out your working zone.  You would have to transfer to a temp
file, check that and then move it into place and restart named.

But why?  What is wrong with using the build in function of named to
transfer the zone?  Did it break and nobody told me?  The only time I could
think that you would ever want to do something else is if your slave server
could not communicate directly with the master, and this wouldn't help that.




More information about the bind-users mailing list