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

Fred Morris m3047 at m3047.net
Thu Sep 7 21:08:52 UTC 2023


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


More information about the bind-users mailing list