Is this KB example backwards? Re: Multiple master servers for the same zones

Greg Choules greg at isc.org
Fri Sep 8 07:19:10 UTC 2023


Doing this officially.

Firstly @Fred you were right. I skim read it knowing what I ought to see and didn't spot what was actually there.
Thanks for pointing it out, I'll get that fixed.

Secondly @Leroy the config is the thing that will determine what types a zone is.
Please would you do a few things and share results? Do the same on both servers and make it clear which is which. Please also use the same zones on both boxes as examples:
- "named -V" to see what versions each of them is running.
- "named-checkconf -px" Copy/paste just the zone definitions for a couple of zones you are having trouble with, as examples. Not the whole config.
- "rndc zonestatus <name>". Use the same zones you chose from above.

Let’s see what we see.
Cheers, Greg

> On 8 Sep 2023, at 01:24, Leroy Tennison via bind-users <bind-users at lists.isc.org> wrote:
> 
> Just to clarify, the configuration I was referring to was supposed to have a master and slave DNS server for private zones (only two DNS servers) but something happened during/after upgrade and they both showed master (actually rndc -s 127.0.0.1 -r zonestatus <zone - both forward and reverse for all zones>) reported master and the other primary.
> 
> On Thursday, September 7, 2023 at 04:09:04 PM CDT, Fred Morris <m3047 at m3047.net> wrote:
> 
> 
> Hi Greg.
> 
> So somebody referenced this KB article because presumably it was 
> tangentially relevant, but I don't know that the OP is working with 
> standby infrastructure (good question!). All they say is that after an 
> upgrade all servers were masters.
> 
> The amount of direct relevance of the article is questionable. 
> Nonetheless, paragraph two seems factually incorrect on its face: changing 
> type master; to type slave; does not swich a server from secondary to 
> master, last I checked it did the opposite.
> 
> On Thu, 7 Sep 2023, Greg Choules wrote:
> > 
> > Hi Fred.
> > No, the sense is correct.
> > Imagine you have a server with a secondary zone of (say) "example.com",
> > which transfers data for that zone from a primary somewhere.
> 
> The KB article talks about multiple masters. At the outset there is no 
> secondary.
> 
> > The secondary
> > loads data received during a zone transfer straight into memory and uses it.
> > It is optional for the secondary to also write that data to a file on its
> > local storage, if you specify a "file" statement in the zone declaration.
> 
> All examples (barring questions of relevance) of configuration syntax in 
> the article specify a file statement. In one case it's implicit as in 
> masterfile-format raw; and in the other it's quite explicit (but both of 
> the examples are talking about standby primaries, which are not an 
> explicit thing in the software although they are conceptually understood).
> 
> Please re-read the second paragraph and try again.
> 
> > If the server currently being secondary for "example.com" does write that
> > zone to disc then it is easy to switch it to become primary because it
> > already has the zone file stored locally. Just change the "type", leave the
> > "file" statement alone and delete (or comment) the "primaries".
> 
> Agreed.
> 
> > Does that help?
> 
> No. I have personally set up and administered a corosync / pacemaker 
> cluster to do a standby to master promotion (for publishing RPZs with 
> BIND) in a past life.
> 
> Respectfully...
> 
> 
> --
> 
> Fred
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
> https://lists.isc.org/mailman/listinfo/bind-users
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230908/9b869e0a/attachment.htm>


More information about the bind-users mailing list