Understood, but what I'm asking about is that the slave does not appear to be 
losing contact with the first-listed master.  In fact, from the logs, it 
appears to be flipping back and forth (though not round-robinning).  

Someone else asked, essentially, "why?" ...  The network paths are diverse to 
the different interfaces so, while I'm not protecting against failure of the 
master, I am protecting against network path failure.  

--
Peter Laws / N5UWY
National Weather Center / Network Operations Center / Web
University of Oklahoma Information Technology
[email protected]

________________________________________
From: [email protected] 
[[email protected]] on behalf of Barry Margolin 
[[email protected]]
Sent: Saturday, July 24, 2010 07:09
To: [email protected]
Subject: Re: Multiple masters expected behavior?

In article <[email protected]>,
 Peter Laws <[email protected]> wrote:

> On 07/22/10 19:57, Barry Margolin wrote:
> > In article<[email protected]>,
> >   Peter Laws<[email protected]>  wrote:
> >
> >> I have multiple interfaces on my master and multiple interfaces on most of
> >> my slaves.
> >>
>
>
> >>
> >> Is that expected behavior?
> >
> > Yes.  What if the first server stops getting updates, but the second one
> > does and has a higher serial number?  Don't you want the slaves to check
> > the SOA record on it to pick up these changes?
>
> Except that the 2 "masters" are simply different interfaces on the same
> master ... so the serial number *better* always be the same!

That's true in *your* case.  But BIND was designed to handle the more
general case, where the masters can be different machines.

--
Barry Margolin, [email protected]
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
_______________________________________________
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to