secondary lag after NOTIFY

Mark.Andrews at nominum.com Mark.Andrews at nominum.com
Sat Dec 23 04:31:50 UTC 2000


> In article <920ott$6f4 at pub3.rc.vix.com>,  <neggybogger at my-deja.com> wrote:
> >We use BIND version 8.2.2-P7 on primary and secondary.
> >A cron job on the performs an ndc reload at 4am daily.
> >We add a lot of zones and at 5am daily named.conf on the
> >primary is FTPed over to the secondary.  Some "kung fu"
> >then converts the master entries in named.conf into
> >slave syntax. An ndc reload then takes place on the secondary.
> >
> >Following a record and SOA change in a primary zone file,
> >it can take up to a week for it to appear in the secondary
> >copy, in spite of logs on both servers showing the primary
> >sending the NOTIFY promptly and the secondary ACKing it
> >within about 30 mins.
> >
> >Messages of the following format appear in the secondary log,
> >however inspections of the contents of (in this case)
> >/home/named/slave/fred.com days later show that no update has
> >taken place:
> >
> >"notify: NOTIFY(SOA) for zone already xferring (fred.com)"
> 
> We see this as well.  Occasionally, a zone will get "stuck" -- named thinks
> it's in the middle of transferring it, but it's not, so it never starts the
> transfer.  The only fix we've found is "ndc exec" to restart named from
> scratch -- reload doesn't clear this up.

	BIND 8.2.3 fixed some stuck zone problems.
> 
> >Should we be ndc reloading the secondary every morning and is there
> >really a need to ftp named.conf over from the primary every day if
> >it is changing?
> 
> You certainly need to ftp the new named.conf file; how else is the slave
> supposed to know about zones that have been added or deleted?  However, it
> should be sufficient to use "ndc reconfig" rather than "ndc reload" to pick
> up these changes in the named.conf (however, I've noticed that if a zone is
> already in the axfr queue, neither reconfig nor reload will remove it --
> when we removed several thousand zones that were pointing to a nonexistent
> customer primary, we had to restart to cancel all the pending transfers).
> 
> -- 
> Barry Margolin, barmar at genuity.net
> Genuity, Burlington, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the grou
> p.
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com



More information about the bind-users mailing list