I wish I could do that for you. Unfortunately, a decision was made to upgrade
the second system and the issue was fixed (not magically, on purpose) during
the process.
On Friday, September 8, 2023 at 02:19:25 AM CDT, Greg Choules
<g...@isc.org> wrote:
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@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
<m3...@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@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
