27 Dub
2026
27 Dub
'26
18:16
Hi,
until now I had 3 secondaries running and a hidden primary. This ran perfectly well.
Now, I'd like to add some fallback functionality to deal with a potential longer
downtime of my hidden primary. Thus I added two more hidden primaries such that now every
host (3) has a hidden primary that can serve every secondary at all hosts. But: Only one
should be active! Zone and database data will frequently be rsynced to both inactive
primaries. If there would be a downtime I will have to start one of the others to
continue.
According to my understanding of
https://www.knot-dns.cz/docs/3.5/html/configuration.html#secondary-slave-zo… I have been
in the naive understanding that a configuration like ...
remote:
- id: primaryMWN # MWN hidden primary (running)
address: 10.0.1.203@5333
- id: primaryKBN # KBN hidden primary (not running,
standby)
address: 10.0.2.203@5333
- id: primaryEDN # EDN hidden primary (not running,
standby)
address: 10.0.3.203@5333
template:
- id: default
master: [primaryMWN, primaryKBN, primaryEDN] # queried in that
order
… would work, because of:
"Note that the master option accepts a list of remotes, which are queried for a zone
refresh sequentially in the specified order. When the server receives a zone change
notification from a listed remote, only that remote is used for a subsequent zone
transfer."
But I do get error massages like:
edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryKBN not
usable
edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] refresh, remote primaryEDN, address
10.0.3.203@5333, failed (connection reset)
edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryEDN not
usable
edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] refresh, failed (no usable master),
next retry at 2026-04-27T19:03:03+0200, expires in 1119353 seconds
edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] zone event 'refresh' failed
(no usable master)
If I do use "master: primaryMWN" only, everything runs as expected.
I must have misunderstood something ...
Ok, I will have to modify all remaining secondary's knot.conf files if desaster
strikes and another primary has to take over.
BTW: I wanted to omit a multi primary setup as mentioned in
https://www.knot-dns.cz/docs/3.5/singlehtml/#multi-primary because I do have the feeling
that this is some sort of overkill for hosting 5 domains, only ;-)
Are there other ways to achieve my goal? ;-)
Thanks and regards,
Michael
27 Dub
27 Dub
18:27
Sorry, incomplete error messages:
But I do get error massages like:
edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] zone file loaded, serial 2026042703
edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] loaded, serial 2026042703 ->
2026042703, 8933 bytes, expires in 1119353 seconds
edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] refresh, remote 10.0.1.203@5333 TCP,
remote serial 2026042703, zone is up-to-date, expires in 1119353 seconds
edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] refresh, remote primaryKBN, address
10.0.2.203@5333, failed (connection reset)
edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryKBN not
usable
edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] refresh, remote primaryEDN, address
10.0.3.203@5333, failed (connection reset)
edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryEDN not
usable
edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] refresh, failed (no usable master),
next retry at 2026-04-27T19:03:03+0200, expires in 1119353 seconds
edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] zone event 'refresh' failed
(no usable master)
Regards,
Michael
19:24
On Mon, 27 Apr 2026 18:16:10 +0200
Michael Grimm via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
remote:
- id: primaryMWN # MWN hidden
primary (running) address: 10.0.1.203@5333
- id: primaryKBN # KBN hidden
primary (not running, standby) address:
10.0.2.203@5333
- id: primaryEDN # EDN hidden
primary (not running, standby) address:
10.0.3.203@5333
These three have same ip so you should only have one primary server in
secondary dns configuration. It doesn't matter for secondary server if
there is three possible masters if secondary servers can only see one.
--
Tuomo Soini <tis(a)foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
20:07
Tuomo Soini via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
No, the IPs are 10.0.*1*.203, 10.0.*2*.203, and 10.0.*3*.203 respectively.
Michael Grimm via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
remote:
- id: primaryMWN # MWN hidden
primary (running) address: 10.0.1.203@5333
- id: primaryKBN # KBN hidden
primary (not running, standby) address:
10.0.2.203@5333
- id: primaryEDN # EDN hidden
primary (not running, standby) address:
10.0.3.203@5333
These three have same ip so you should only have one primary server in
secondary dns configuration. It doesn't matter for secondary server if
there is three possible masters if secondary servers can only see one.
I am awfully sorry, but I don't understand this.
Every secondary is configured to receive data from three *different* primaries, but only
one is running. According to my understanding, they should stop requesting data from the
other primaries after receiving data from first primary defined in (see initial post):
master: [primaryMWN, primaryKBN, primaryEDN]
But I might be very well misunderstanding the documentation, though
Regards,
Michael
20:58
On Mon, 27 Apr 2026 20:07:35 +0200
Michael Grimm via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
No, the IPs are 10.0.*1*.203, 10.0.*2*.203, and
10.0.*3*.203
respectively.
Sorry, missed that. If you have three primaries, secondary must contact
all configured primary servers to find out which version of the zone is
available. So if you configure several masters and only one is up, you
get errors in your secondary server log.
Our setup is one hidden primary and one cold standby server with
backups of data synced every hour.
If we need to switch primary server, we restore backups to our
cold-standby server and push replacement templates to secondary
servers so they start to use new master.
You could easily do same with one hot primary and two cold ones.
--
Tuomo Soini <tis(a)foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
28 Dub
28 Dub
14:28
Tuomo Soini via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
Our setup is one hidden primary and one cold standby
server with
backups of data synced every hour.
Ok, I have this running.
If we need to switch primary server, we restore
backups to our
cold-standby server and push replacement templates to secondary
servers so they start to use new master.
Thank for this. I will consider this for my setup.
Thanks and regards,
Michael
14:03
Hi Michael,
What about rewriting your remotes configuration to a single remote with multiple
addresses?
Knot will then try the addresses in the specified order until one of them works:
remote:
- id: primary
address: 10.0.1.203@5333 # running
address: 10.0.2.203@5333 # standby
address: 10.0.3.203@5333 # standby
template:
- id: default
master: primary
Daniel
On 4/27/26 18:16, Michael Grimm via knot-dns-users wrote:
Hi,
until now I had 3 secondaries running and a hidden primary. This ran perfectly well.
Now, I'd like to add some fallback functionality to deal with a potential longer
downtime of my hidden primary. Thus I added two more hidden primaries such that now every
host (3) has a hidden primary that can serve every secondary at all hosts. But: Only one
should be active! Zone and database data will frequently be rsynced to both inactive
primaries. If there would be a downtime I will have to start one of the others to
continue.
According to my understanding of
https://www.knot-dns.cz/docs/3.5/html/configuration.html#secondary-slave-zo… I have been
in the naive understanding that a configuration like ...
remote:
- id: primaryMWN # MWN hidden primary (running)
address: 10.0.1.203@5333
- id: primaryKBN # KBN hidden primary (not running,
standby)
address: 10.0.2.203@5333
- id: primaryEDN # EDN hidden primary (not running,
standby)
address: 10.0.3.203@5333
template:
- id: default
master: [primaryMWN, primaryKBN, primaryEDN] # queried in
that order
… would work, because of:
"Note that the master option accepts a list of remotes, which are queried for a zone
refresh sequentially in the specified order. When the server receives a zone change
notification from a listed remote, only that remote is used for a subsequent zone
transfer."
But I do get error massages like:
edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryKBN not
usable
edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] refresh, remote primaryEDN, address
10.0.3.203@5333, failed (connection reset)
edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryEDN not
usable
edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] refresh, failed (no usable
master), next retry at 2026-04-27T19:03:03+0200, expires in 1119353 seconds
edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] zone event 'refresh'
failed (no usable master)
If I do use "master: primaryMWN" only, everything runs as expected.
I must have misunderstood something ...
Ok, I will have to modify all remaining secondary's knot.conf files if desaster
strikes and another primary has to take over.
BTW: I wanted to omit a multi primary setup as mentioned in
https://www.knot-dns.cz/docs/3.5/singlehtml/#multi-primary because I do have the feeling
that this is some sort of overkill for hosting 5 domains, only ;-)
Are there other ways to achieve my goal? ;-)
Thanks and regards,
Michael
--
14:26
Daniel Salzman via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
What about rewriting your remotes configuration to a
single remote with multiple addresses?
Knot will then try the addresses in the specified order until one of them works:
remote:
- id: primary
address: 10.0.1.203@5333 # running
address: 10.0.2.203@5333 # standby
address: 10.0.3.203@5333 # standby
template:
- id: default
master: primary
Thanks Daniel, that did the trick!
I have to blame me on not even have thought about using 3 addresses instead of IDs.
Thanks again and kind regards,
Michael
3
days inactive
4
days old
7 comments
3 participants
participants (3)
-
Daniel Salzman -
Michael Grimm -
Tuomo Soini