16 Úno
2024
16 Úno
'24
15:26
Hi,
after successful migration of my hidden primary NSD and OpenDNSSEC signer to Knot DNS, I
started to migrate my secondary NSDs to Knot DNS as well.
Thanks to excellent documentation this migration went more or less flawless as well.
BUT: I am somehow irritated about the following error messages at my hidden primary like:
2024-02-16T10:54:08+0100 debug: [ellael.org.] ACL, allowed, action transfer, remote
10.1.1.201@27919, key primary-secondary.
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP,
started, serial 2024021331
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP,
finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:09+0100 debug: [ellael.org.] ACL, allowed, action notify, remote
10.1.1.201@40884, key primary-secondary.
2024-02-16T10:54:09+0100 info: [ellael.org.] notify, incoming, remote 10.1.1.201@40884
TCP, serial 2024021331
>>! 2024-02-16T10:54:09+0100 error:
[ellael.org.] zone event 'refresh' failed (operation not supported)
The log files at both secondary are identical, here one example:
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, incoming, remote 10.2.2.203@5333 TCP,
finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:08+0100 info: [ellael.org.] refresh, remote 10.2.2.203@5333, zone
updated, 0.03 seconds, serial none -> 2024021331,\
expires in 1209600 seconds
2024-02-16T10:54:08+0100 info: [ellael.org.] zone file updated, serial 2024021331
>>! 2024-02-16T10:54:09+0100 info: [ellael.org.]
notify, outgoing, remote 10.2.2.203@5333 TCP, serial 2024021331
FYI: Those errors are only logged when a zone gets updated or using "knotc
zone-notify" at the secondary site.
Here are my essential config excerpts:
Primary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: secondaryKBN
key: primary-secondary
address: 10.1.1.201 # KBN secondary
via: 10.2.2.203 # outgoing interface
Secondary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
block-notify-after-transfer: on
FYI: Only adding "block-notify-after-transfer: on" at secondary sites stopped
those error messages.
I found https://www.mail-archive.com/knot-dns-users@lists.nic.cz/msg01812.html :
"I recommend not using this option unless you really know what you're doing
and why this option is essential for you."
Questions:
#) I do have to admit, I don't understand what is going on without
"block-notify-after-transfer: on"?
#) Am I save in using "block-notify-after-transfer: on"?
#) Or is the another config option?
Thanks in advance and regards,
Michael
16 Úno
16 Úno
15:48
Hi Michael,
Is there another primary above the hidden master?
Daniel
On 2/16/24 15:26, Michael Grimm wrote:
Hi,
after successful migration of my hidden primary NSD and OpenDNSSEC signer to Knot DNS, I
started to migrate my secondary NSDs to Knot DNS as well.
Thanks to excellent documentation this migration went more or less flawless as well.
BUT: I am somehow irritated about the following error messages at my hidden primary
like:
2024-02-16T10:54:08+0100 debug: [ellael.org.] ACL, allowed, action transfer, remote
10.1.1.201@27919, key primary-secondary.
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919
TCP, started, serial 2024021331
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919
TCP, finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:09+0100 debug: [ellael.org.] ACL, allowed, action notify, remote
10.1.1.201@40884, key primary-secondary.
2024-02-16T10:54:09+0100 info: [ellael.org.] notify, incoming, remote 10.1.1.201@40884
TCP, serial 2024021331
>> ! 2024-02-16T10:54:09+0100 error:
[ellael.org.] zone event 'refresh' failed (operation not supported)
The log files at both secondary are identical, here one example:
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, incoming, remote 10.2.2.203@5333 TCP,
finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:08+0100 info: [ellael.org.] refresh, remote 10.2.2.203@5333, zone
updated, 0.03 seconds, serial none -> 2024021331,\
expires in 1209600 seconds
2024-02-16T10:54:08+0100 info: [ellael.org.] zone file updated, serial 2024021331
>>! 2024-02-16T10:54:09+0100 info:
[ellael.org.] notify, outgoing, remote 10.2.2.203@5333 TCP, serial 2024021331
FYI: Those errors are only logged when a zone gets updated or using "knotc
zone-notify" at the secondary site.
Here are my essential config excerpts:
Primary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: secondaryKBN
key: primary-secondary
address: 10.1.1.201 # KBN secondary
via: 10.2.2.203 # outgoing interface
Secondary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
block-notify-after-transfer: on
FYI: Only adding "block-notify-after-transfer: on" at secondary sites stopped
those error messages.
I found https://www.mail-archive.com/knot-dns-users@lists.nic.cz/msg01812.html :
"I recommend not using this option unless you really know what you're doing
and why this option is essential for you."
Questions:
#) I do have to admit, I don't understand what is going on without
"block-notify-after-transfer: on"?
#) Am I save in using "block-notify-after-transfer: on"?
#) Or is the another config option?
Thanks in advance and regards,
Michael
--
15:57
Note that `knotc zone-notify` works on a primary. If you want an explicit refresh on a
secondary, call `knotc zone-refresh`.
On 2/16/24 15:55, Michael Grimm wrote:
Daniel Salzman <daniel.salzman(a)nic.cz> wrote
Is there another primary above the hidden master?
I am not sure if I do understand your question correctly.
Here is my setup:
Hidden Primary —> Secondary (2x)
Feel free to ask for more info. Complete configs?
Thanks,
Michael
16:03
Yes, I understand that, now ;-)
But my main concern is this: "Those errors are only logged when a zone gets
updated"
Regards,
Michael
On 16. Feb 2024, at 15:57, Daniel Salzman
<daniel.salzman(a)nic.cz> wrote:
Note that `knotc zone-notify` works on a primary. If you want an explicit refresh on a
secondary, call `knotc zone-refresh`.
On 2/16/24 15:55, Michael Grimm wrote:
Daniel Salzman <daniel.salzman(a)nic.cz>
wrote
-- Is there another primary above the hidden master?
I am not sure if I do understand your question correctly.
Here is my setup:
Hidden Primary —> Secondary (2x)
Feel free to ask for more info. Complete configs?
Thanks,
Michael
16:05
Okay. Please show me the configuration of the zone (template).
On 2/16/24 16:03, Michael Grimm wrote:
Yes, I understand that, now ;-)
But my main concern is this: "Those errors are only logged when a zone gets
updated"
Regards,
Michael
On 16. Feb 2024, at 15:57, Daniel Salzman
<daniel.salzman(a)nic.cz> wrote:
Note that `knotc zone-notify` works on a primary. If you want an explicit refresh on a
secondary, call `knotc zone-refresh`.
On 2/16/24 15:55, Michael Grimm wrote:
Daniel Salzman <daniel.salzman(a)nic.cz>
wrote
-- Is there another primary above the hidden master?
I am not sure if I do understand your question correctly.
Here is my setup:
Hidden Primary —> Secondary (2x)
Feel free to ask for more info. Complete configs?
Thanks,
Michael
16:14
Thank you for your help. I will send complete configs.
Primary hidden:
###############
# server specifics
#
server:
listen: 10.2.2.203@5333
user: knot:knot
rundir: "/var/run/knot"
tcp-workers: 1
udp-workers: 1
identity: ""
# logging
#
log:
- target: syslog
any: info
- target: "/var/log/knot.log"
any: debug
# database managment
#
database:
storage: "/var/db/knot"
kasp-db: "/var/db/knot/kasp"
# key used for acl transactions
#
key:
- id: primary-secondary
algorithm: hmac-sha256
secret: <hidden>
# acl transactions (primary, secondary)
#
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
# remote secondary and authoritative nameservers (KBN, MWN)
#
remote:
- id: secondaryKBN
key: primary-secondary
address: 10.1.1.201 # KBN secondary
via: 10.2.2.203 # outgoing interface
- id: secondaryMWN
key: primary-secondary
address: 10.2.2.201 # MWN secondary
via: 10.2.2.203 # outgoing interface
- id: secondaryOVH
address: 213.251.188.141 # OVH's sdns2.ovh.net (notify,
submission)
via: 10.2.2.203 # outgoing interface
# all remote secondary servers that get notified
#
remotes:
- id: remoteSERVERS
remote: [secondaryKBN, secondaryMWN, secondaryOVH]
# KSK submission checks (only active during ksk rollovers)
#
submission:
- id: kskCHECKER
check-interval: 15m
parent: secondaryOVH
# dnssec policy
#
policy:
- id: ecdsa
algorithm: ecdsap256sha256
ksk-lifetime: 0 # no KSK rollover
zsk-lifetime: 365d
propagation-delay: 6h
nsec3: on
cds-cdnskey-publish: always
ksk-submission: kskCHECKER
# default template used for all zonefiles
#
template:
- id: default
storage: "/usr/local/etc/knot/zones"
file: "%s"
semantic-checks: on
dnssec-policy: ecdsa
dnssec-signing: on
acl: aclTRANSACTIONS
notify: remoteSERVERS
zonefile-sync: -1
zonefile-load: difference
journal-content: changes
# primary zones hosted
#
zone:
- domain: ellael.org
[others snipped]
Secondary (both identical configs):
###################################
# server specifics
#
server:
listen: 10.1.1.201@53
listen: fd00:a:a:a::201@53
user: knot:knot
rundir: "/var/run/knot"
tcp-workers: 1
udp-workers: 1
identity: ""
version: ""
# logging
#
log:
- target: syslog
any: info
- target: "/var/log/knot.log"
any: debug
# database managment
#
database:
storage: "/var/db/knot"
kasp-db: "/var/db/knot/kasp"
# key used for acl transactions
#
key:
- id: primary-secondary
algorithm: hmac-sha256
secret: <hidden>
# acl transactions (primary, secondary)
#
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
# remote hidden primary and secondary nameservers (MWN, OVH)
#
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.1.1.201 # outgoing interface
block-notify-after-transfer: on
remotes:
- id: remoteSERVERS
remote: [primaryMWN]
# default template used for all zonefiles
#
template:
- id: default
storage: "/usr/local/etc/knot/zones"
file: "%s"
master: primaryMWN
notify: remoteSERVERS
acl: aclTRANSACTIONS
semantic-checks: on
# primary zones hosted
#
zone:
- domain: ellael.org
[others snipped]
Thanks in advance,
Michael
On 16. Feb 2024, at 16:05, Daniel Salzman
<daniel.salzman(a)nic.cz> wrote:
Okay. Please show me the configuration of the zone (template).
On 2/16/24 16:03, Michael Grimm wrote:
Yes, I understand that, now ;-)
But my main concern is this: "Those errors are only logged when a zone gets
updated"
Regards,
Michael
> On 16. Feb 2024, at 15:57, Daniel Salzman <daniel.salzman(a)nic.cz> wrote:
>
> Note that `knotc zone-notify` works on a primary. If you want an explicit refresh on
a secondary, call `knotc zone-refresh`.
>
> On 2/16/24 15:55, Michael Grimm wrote:
>> Daniel Salzman <daniel.salzman(a)nic.cz> wrote
>>> Is there another primary above the hidden master?
>> I am not sure if I do understand your question correctly.
>> Here is my setup:
>> Hidden Primary —> Secondary (2x)
>> Feel free to ask for more info. Complete configs?
>> Thanks,
>> Michael
> --
-- 
17:11
Hi,
do I understand it right, that your secondaries are configured to send
NOTIFY back to the primary?
That is obviously wrong. Just remove the 'notify' lines in the
secondaries' config files.
If you want to achieve some multi-master topology (such that zone
transfers do not happen only from the primary down to each secondary,
but "sideways" from each server to each other), it is generally
difficult to achieve, and one must first make clear about the reason
(for example desired redundance in case of one server outage...).
Libor
Dne 16. 02. 24 v 15:26 Michael Grimm napsal(a):
Hi,
after successful migration of my hidden primary NSD and OpenDNSSEC signer to Knot DNS, I
started to migrate my secondary NSDs to Knot DNS as well.
Thanks to excellent documentation this migration went more or less flawless as well.
BUT: I am somehow irritated about the following error messages at my hidden primary
like:
2024-02-16T10:54:08+0100 debug: [ellael.org.] ACL, allowed, action transfer, remote
10.1.1.201@27919, key primary-secondary.
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919
TCP, started, serial 2024021331
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919
TCP, finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:09+0100 debug: [ellael.org.] ACL, allowed, action notify, remote
10.1.1.201@40884, key primary-secondary.
2024-02-16T10:54:09+0100 info: [ellael.org.] notify, incoming, remote 10.1.1.201@40884
TCP, serial 2024021331
>> ! 2024-02-16T10:54:09+0100 error:
[ellael.org.] zone event 'refresh' failed (operation not supported)
The log
files at both secondary are identical, here one example:
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, incoming, remote 10.2.2.203@5333 TCP,
finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:08+0100 info: [ellael.org.] refresh, remote 10.2.2.203@5333, zone
updated, 0.03 seconds, serial none -> 2024021331,\
expires in 1209600 seconds
2024-02-16T10:54:08+0100 info: [ellael.org.] zone file updated, serial 2024021331
>>! 2024-02-16T10:54:09+0100 info:
[ellael.org.] notify, outgoing, remote 10.2.2.203@5333 TCP, serial 2024021331
FYI: Those errors are only logged when a zone gets updated or using "knotc
zone-notify" at the secondary site.
Here are my essential config excerpts:
Primary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: secondaryKBN
key: primary-secondary
address: 10.1.1.201 # KBN secondary
via: 10.2.2.203 # outgoing interface
Secondary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
block-notify-after-transfer: on
FYI: Only adding "block-notify-after-transfer: on" at secondary sites stopped
those error messages.
I found https://www.mail-archive.com/knot-dns-users@lists.nic.cz/msg01812.html :
"I recommend not using this option unless you really know what you're doing
and why this option is essential for you."
Questions:
#) I do have to admit, I don't understand what is going on without
"block-notify-after-transfer: on"?
#) Am I save in using "block-notify-after-transfer: on"?
#) Or is the another config option?
Thanks in advance and regards,
Michael
--
18:26
Hi,
This is very irritating for me. I tried a lot of combinations of "action:
notify" and/or "action: transfer" at my secondary instances.
Primary has: "action: [notify, transfer]" set.
The latter works with NSD secondaries like a charm with:
name: "notify-knot"
allow-notify: 10.2.2.203 primary-secondary
request-xfr: 10.2.2.203@5333 primary-secondary
In this mail I will only refer to my settings on one of my secondary (10.1.1.201). Primary
listens at 10.2.2.203@5333
@MWN = logfile at hidden primary, @KBN = logfile at secondary
1) acl:
action: [notify, transfer]
@KBN: info: [ellael.org.] notify, outgoing, remote 10.2.2.203@5333 TCP, serial
2024021331
@MWN info: [ellael.org.] notify, incoming, remote 10.1.1.201@40884 TCP, serial
2024021331
@MWN error: [ellael.org.] zone event 'refresh' failed (operation not
supported)
Immediate SOA serial updates NOT working without manual "knotc
zone-refresh"!
2) acl:
action: [notify, transfer]
remote:
block-notify-after-transfer: on
@KBN: info: [ellael.org.] refresh, remote 10.2.2.203@5333, zone updated, 0.03 seconds,
serial none -> 2024021331, expires in 1209600 seconds
info: [ellael.org.] zone file updated, serial 2024021331
@MWN: debug: [ellael.org.] ACL, allowed, action transfer, remote 10.1.1.201@29719, key
primary-secondary.
info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@29719 TCP, started, serial
2024021331
info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@29719 TCP, finished, 0.00
seconds, 1 messages, 7774 bytes
Immediate SOA serial updates working
3) acl:
action: transfer
@KBN: info: [ellael.org.] notify, outgoing, remote 10.2.2.203@5333 TCP, serial
2024021331
debug: [ellael.org.] ACL, denied, action notify, remote 10.2.2.203@16964, key
primary-secondary.
@MWN: debug: [ellael.org.] ACL, allowed, action notify, remote 10.1.1.201@28784, key
primary-secondary.
info: [ellael.org.] notify, incoming, remote 10.1.1.201@28784 TCP, serial
2024021331
warning: [ellael.org.] notify, outgoing, remote 10.1.1.201@53 TCP, server
responded with error 'NOTAUTH'
Immediate SOA serial updates NOT working without manual "knotc
zone-refresh"!
I really don't understand that! Your understandable statement "That is obviously
wrong" and recommendation "Just remove the 'notify' lines in the
secondaries' config files" works, but the zones are not (immediately) updated.
Having 'notify' set, I do need "block-notify-after-transfer: on" for the
remote, and then, everything works as expected … weird.
You can have a look at my complete configs in my other mail. Perhaps, you may find
something else.
If you want to achieve some multi-master topology
(such that zone transfers do not happen only from the primary down to each secondary, but
"sideways" from each server to each other), it is generally difficult to
achieve, and one must first make clear about the reason (for example desired redundance in
case of one server outage…).
No, that's not what I do try to setup. The only "weird" setup might be, that
I do use one of the secondary servers as xfr for my third secondary running under
OVH's responsibility. As my primary has no access to the internet, I did use this
setup for many years, now.
Thanks for your help and regards,
Michael
On 16. Feb 2024, at 17:11, libor.peltan
<libor.peltan(a)nic.cz> wrote:
Hi,
do I understand it right, that your secondaries are configured to send NOTIFY back to the
primary?
That is obviously wrong. Just remove the 'notify' lines in the secondaries'
config files.
If you want to achieve some multi-master topology (such that zone transfers do not happen
only from the primary down to each secondary, but "sideways" from each server to
each other), it is generally difficult to achieve, and one must first make clear about the
reason (for example desired redundance in case of one server outage...).
Libor
Dne 16. 02. 24 v 15:26 Michael Grimm napsal(a):
Hi,
after successful migration of my hidden primary NSD and OpenDNSSEC signer to Knot DNS, I
started to migrate my secondary NSDs to Knot DNS as well.
Thanks to excellent documentation this migration went more or less flawless as well.
BUT: I am somehow irritated about the following error messages at my hidden primary
like:
2024-02-16T10:54:08+0100 debug: [ellael.org.] ACL, allowed, action transfer, remote
10.1.1.201@27919, key primary-secondary.
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP,
started, serial 2024021331
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP,
finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:09+0100 debug: [ellael.org.] ACL, allowed, action notify, remote
10.1.1.201@40884, key primary-secondary.
2024-02-16T10:54:09+0100 info: [ellael.org.] notify, incoming, remote 10.1.1.201@40884
TCP, serial 2024021331
-- >> ! 2024-02-16T10:54:09+0100 error:
[ellael.org.] zone event 'refresh' failed (operation not supported)
The log
files at both secondary are identical, here one example:
2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, incoming, remote 10.2.2.203@5333 TCP,
finished, 0.00 seconds, 1 messages, 7774 bytes
2024-02-16T10:54:08+0100 info: [ellael.org.] refresh, remote 10.2.2.203@5333, zone
updated, 0.03 seconds, serial none -> 2024021331,\
expires in 1209600 seconds
2024-02-16T10:54:08+0100 info: [ellael.org.] zone file updated, serial 2024021331
>>! 2024-02-16T10:54:09+0100 info:
[ellael.org.] notify, outgoing, remote 10.2.2.203@5333 TCP, serial 2024021331
FYI: Those errors are only logged when a zone gets updated or using "knotc
zone-notify" at the secondary site.
Here are my essential config excerpts:
Primary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: secondaryKBN
key: primary-secondary
address: 10.1.1.201 # KBN secondary
via: 10.2.2.203 # outgoing interface
Secondary:
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
block-notify-after-transfer: on
FYI: Only adding "block-notify-after-transfer: on" at secondary sites stopped
those error messages.
I found https://www.mail-archive.com/knot-dns-users@lists.nic.cz/msg01812.html :
"I recommend not using this option unless you really know what you're doing
and why this option is essential for you."
Questions:
#) I do have to admit, I don't understand what is going on without
"block-notify-after-transfer: on"?
#) Am I save in using "block-notify-after-transfer: on"?
#) Or is the another config option?
Thanks in advance and regards,
Michael
--
19:28
I see a few issues:
- increase the number of workers (at least one TCP worker is too low on the primary if you
have more secondaries)
- acl action notify is not needed on the primary
- acl action transfer is not needed on secondaries
- notify configuration on secondaries doesn't make sense in your case
- there is some inconsistency in secondaryOVH configuration: remote without key vs. acl
with key primary-secondary
On 2/16/24 16:14, Michael Grimm wrote:
Thank you for your help. I will send complete
configs.
Primary hidden:
###############
# server specifics
#
server:
listen: 10.2.2.203@5333
user: knot:knot
rundir: "/var/run/knot"
tcp-workers: 1
udp-workers: 1
identity: ""
# logging
#
log:
- target: syslog
any: info
- target: "/var/log/knot.log"
any: debug
# database managment
#
database:
storage: "/var/db/knot"
kasp-db: "/var/db/knot/kasp"
# key used for acl transactions
#
key:
- id: primary-secondary
algorithm: hmac-sha256
secret: <hidden>
# acl transactions (primary, secondary)
#
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
# remote secondary and authoritative nameservers (KBN, MWN)
#
remote:
- id: secondaryKBN
key: primary-secondary
address: 10.1.1.201 # KBN secondary
via: 10.2.2.203 # outgoing interface
- id: secondaryMWN
key: primary-secondary
address: 10.2.2.201 # MWN secondary
via: 10.2.2.203 # outgoing interface
- id: secondaryOVH
address: 213.251.188.141 # OVH's sdns2.ovh.net (notify,
submission)
via: 10.2.2.203 # outgoing interface
# all remote secondary servers that get notified
#
remotes:
- id: remoteSERVERS
remote: [secondaryKBN, secondaryMWN, secondaryOVH]
# KSK submission checks (only active during ksk rollovers)
#
submission:
- id: kskCHECKER
check-interval: 15m
parent: secondaryOVH
# dnssec policy
#
policy:
- id: ecdsa
algorithm: ecdsap256sha256
ksk-lifetime: 0 # no KSK rollover
zsk-lifetime: 365d
propagation-delay: 6h
nsec3: on
cds-cdnskey-publish: always
ksk-submission: kskCHECKER
# default template used for all zonefiles
#
template:
- id: default
storage: "/usr/local/etc/knot/zones"
file: "%s"
semantic-checks: on
dnssec-policy: ecdsa
dnssec-signing: on
acl: aclTRANSACTIONS
notify: remoteSERVERS
zonefile-sync: -1
zonefile-load: difference
journal-content: changes
# primary zones hosted
#
zone:
- domain: ellael.org
[others snipped]
Secondary (both identical configs):
###################################
# server specifics
#
server:
listen: 10.1.1.201@53
listen: fd00:a:a:a::201@53
user: knot:knot
rundir: "/var/run/knot"
tcp-workers: 1
udp-workers: 1
identity: ""
version: ""
# logging
#
log:
- target: syslog
any: info
- target: "/var/log/knot.log"
any: debug
# database managment
#
database:
storage: "/var/db/knot"
kasp-db: "/var/db/knot/kasp"
# key used for acl transactions
#
key:
- id: primary-secondary
algorithm: hmac-sha256
secret: <hidden>
# acl transactions (primary, secondary)
#
acl:
- id: aclTRANSACTIONS
key: primary-secondary
action: [notify, transfer]
# remote hidden primary and secondary nameservers (MWN, OVH)
#
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.1.1.201 # outgoing interface
block-notify-after-transfer: on
remotes:
- id: remoteSERVERS
remote: [primaryMWN]
# default template used for all zonefiles
#
template:
- id: default
storage: "/usr/local/etc/knot/zones"
file: "%s"
master: primaryMWN
notify: remoteSERVERS
acl: aclTRANSACTIONS
semantic-checks: on
# primary zones hosted
#
zone:
- domain: ellael.org
[others snipped]
Thanks in advance,
Michael
On 16. Feb 2024, at 16:05, Daniel Salzman
<daniel.salzman(a)nic.cz> wrote:
Okay. Please show me the configuration of the zone (template).
On 2/16/24 16:03, Michael Grimm wrote:
Yes, I understand that, now ;-)
But my main concern is this: "Those errors are only logged when a zone gets
updated"
Regards,
Michael
> On 16. Feb 2024, at 15:57, Daniel Salzman <daniel.salzman(a)nic.cz> wrote:
>
> Note that `knotc zone-notify` works on a primary. If you want an explicit refresh on
a secondary, call `knotc zone-refresh`.
>
> On 2/16/24 15:55, Michael Grimm wrote:
>> Daniel Salzman <daniel.salzman(a)nic.cz> wrote
>>> Is there another primary above the hidden master?
>> I am not sure if I do understand your question correctly.
>> Here is my setup:
>> Hidden Primary —> Secondary (2x)
>> Feel free to ask for more info. Complete configs?
>> Thanks,
>> Michael
> --
--
19:36
Another issues are:
`via: 10.1.1.201` - this interface isn't configured and the
specification is not needed if there is just one IPv4 address - remove it
`block-notify-after-transfer: on` - this doesn't make sense too
On 2/16/24 16:14, Michael Grimm wrote:
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.1.1.201 # outgoing interface
block-notify-after-transfer: on
20:18
Hi Daniel,
thank you very much, your mail helped a lot!
I see a few issues:
- increase the number of workers (at least one TCP worker is too low on the primary if
you have more secondaries)
- acl action notify is not needed on the primary
- acl action transfer is not needed on secondaries
- notify configuration on secondaries doesn't make sense in your case
Done, although not understood, yet. I need more reading in the manual.
BUT: Now (almost, see below) everything works as expected.
- there is some inconsistency in secondaryOVH
configuration: remote without key vs. acl with key primary-secondary
No, that's intended. The communication with secondaryOVH needs to be keyless. That is
something I need to separate. And actually it is working as expected at the primary.
But I do need something similar at one of my secondary servers that allows for a zone
transfer from that given secondary to secondaryOVH as set up in NSD config:
allow-notify: 10.2.2.203 primary-secondary
request-xfr: 10.2.2.203@5333 primary-secondary
provide-xfr: 213.251.188.141 NOKEY # allow xfr from secondary
sdns2.ovh.net
# notify is sent from
hidden primary @MWN
My "equivalent" config at that given secondary is:
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
- id: secondaryOVH
address: 213.251.188.141 # allow xfr from secondary
sdns2.ovh.net
via: 10.2.2.201 # outgoing interface
But I do get:
debug: [ellael.org.] ACL, denied, action transfer, remote 213.251.188.141@41425
Your other mail:
Another issues are:
`via: 10.1.1.201` - this interface isn't configured and the
specification is not needed if there is just one IPv4 address - remove it
Yeah, there are more IPv4 addresses in that given FreeBSD jail, I do need it.
`block-notify-after-transfer: on` - this doesn't
make sense too
Done, and thanks to your suggestion, no longer needed.
Thank you very much for your help!
Regards,
Michael
On 2/16/24 16:14, Michael Grimm wrote:
> Thank you for your help. I will send complete configs.
> Primary hidden:
> ###############
> # server specifics
> #
> server:
> listen: 10.2.2.203@5333
> user: knot:knot
> rundir: "/var/run/knot"
> tcp-workers: 1
> udp-workers: 1
> identity: ""
> # logging
> #
> log:
> - target: syslog
> any: info
> - target: "/var/log/knot.log"
> any: debug
> # database managment
> #
> database:
> storage: "/var/db/knot"
> kasp-db: "/var/db/knot/kasp"
> # key used for acl transactions
> #
> key:
> - id: primary-secondary
> algorithm: hmac-sha256
> secret: <hidden>
> # acl transactions (primary, secondary)
> #
> acl:
> - id: aclTRANSACTIONS
> key: primary-secondary
> action: [notify, transfer]
> # remote secondary and authoritative nameservers (KBN, MWN)
> #
> remote:
> - id: secondaryKBN
> key: primary-secondary
> address: 10.1.1.201 # KBN secondary
> via: 10.2.2.203 # outgoing interface
> - id: secondaryMWN
> key: primary-secondary
> address: 10.2.2.201 # MWN secondary
> via: 10.2.2.203 # outgoing interface
> - id: secondaryOVH
> address: 213.251.188.141 # OVH's sdns2.ovh.net (notify,
submission)
> via: 10.2.2.203 # outgoing interface
> # all remote secondary servers that get notified
> #
> remotes:
> - id: remoteSERVERS
> remote: [secondaryKBN, secondaryMWN, secondaryOVH]
> # KSK submission checks (only active during ksk rollovers)
> #
> submission:
> - id: kskCHECKER
> check-interval: 15m
> parent: secondaryOVH
> # dnssec policy
> #
> policy:
> - id: ecdsa
> algorithm: ecdsap256sha256
> ksk-lifetime: 0 # no KSK rollover
> zsk-lifetime: 365d
> propagation-delay: 6h
> nsec3: on
> cds-cdnskey-publish: always
> ksk-submission: kskCHECKER
> # default template used for all zonefiles
> #
> template:
> - id: default
> storage: "/usr/local/etc/knot/zones"
> file: "%s"
> semantic-checks: on
> dnssec-policy: ecdsa
> dnssec-signing: on
> acl: aclTRANSACTIONS
> notify: remoteSERVERS
> zonefile-sync: -1
> zonefile-load: difference
> journal-content: changes
> # primary zones hosted
> #
> zone:
> - domain: ellael.org
> [others snipped]
> Secondary (both identical configs):
> ###################################
> # server specifics
> #
> server:
> listen: 10.1.1.201@53
> listen: fd00:a:a:a::201@53
> user: knot:knot
> rundir: "/var/run/knot"
> tcp-workers: 1
> udp-workers: 1
> identity: ""
> version: ""
> # logging
> #
> log:
> - target: syslog
> any: info
> - target: "/var/log/knot.log"
> any: debug
> # database managment
> #
> database:
> storage: "/var/db/knot"
> kasp-db: "/var/db/knot/kasp"
> # key used for acl transactions
> #
> key:
> - id: primary-secondary
> algorithm: hmac-sha256
> secret: <hidden>
> # acl transactions (primary, secondary)
> #
> acl:
> - id: aclTRANSACTIONS
> key: primary-secondary
> action: [notify, transfer]
> # remote hidden primary and secondary nameservers (MWN, OVH)
> #
> remote:
> - id: primaryMWN
> key: primary-secondary
> address: 10.2.2.203@5333 # MWN hidden primary
> via: 10.1.1.201 # outgoing interface
> block-notify-after-transfer: on
> remotes:
> - id: remoteSERVERS
> remote: [primaryMWN]
> # default template used for all zonefiles
> #
> template:
> - id: default
> storage: "/usr/local/etc/knot/zones"
> file: "%s"
> master: primaryMWN
> notify: remoteSERVERS
> acl: aclTRANSACTIONS
> semantic-checks: on
> # primary zones hosted
> #
> zone:
> - domain: ellael.org
> [others snipped]
> Thanks in advance,
> Michael
>> On 16. Feb 2024, at 16:05, Daniel Salzman <daniel.salzman(a)nic.cz> wrote:
>>
>> Okay. Please show me the configuration of the zone (template).
>>
>> On 2/16/24 16:03, Michael Grimm wrote:
>>> Yes, I understand that, now ;-)
>>> But my main concern is this: "Those errors are only logged when a zone
gets updated"
>>> Regards,
>>> Michael
>>>> On 16. Feb 2024, at 15:57, Daniel Salzman <daniel.salzman(a)nic.cz>
wrote:
>>>>
>>>> Note that `knotc zone-notify` works on a primary. If you want an explicit
refresh on a secondary, call `knotc zone-refresh`.
>>>>
>>>> On 2/16/24 15:55, Michael Grimm wrote:
>>>>> Daniel Salzman <daniel.salzman(a)nic.cz> wrote
>>>>>> Is there another primary above the hidden master?
>>>>> I am not sure if I do understand your question correctly.
>>>>> Here is my setup:
>>>>> Hidden Primary —> Secondary (2x)
>>>>> Feel free to ask for more info. Complete configs?
>>>>> Thanks,
>>>>> Michael
>>>> --
>> --
17 Úno
17 Úno
8:52
Hi,
FTR: My questions are all answered, and I solved the last remaining issue regarding
OVH's secondary server without key.
1) Modification of my firewall: The primary is still cutoff from remote access, except
that one IP of OVH's secondary
2) Now, my primary serves all secondary servers, two of mine plus OVH
3) Added an additional ACL for keyless AFXR to OVH secondary
Thank you very much again. Now, I understand much better what went wrong in my first setup
attempts ;-)
Regards,
Michael
On 16. Feb 2024, at 20:18, Michael Grimm
<trashcan(a)ellael.org> wrote:
Hi Daniel,
thank you very much, your mail helped a lot!
I see a few issues:
- increase the number of workers (at least one TCP worker is too low on the primary if
you have more secondaries)
- acl action notify is not needed on the primary
- acl action transfer is not needed on secondaries
- notify configuration on secondaries doesn't make sense in your case
Done, although not understood, yet. I need more reading in the manual.
BUT: Now (almost, see below) everything works as expected.
- there is some inconsistency in secondaryOVH
configuration: remote without key vs. acl with key primary-secondary
No, that's intended. The communication with secondaryOVH needs to be keyless. That is
something I need to separate. And actually it is working as expected at the primary.
But I do need something similar at one of my secondary servers that allows for a zone
transfer from that given secondary to secondaryOVH as set up in NSD config:
allow-notify: 10.2.2.203 primary-secondary
request-xfr: 10.2.2.203@5333 primary-secondary
provide-xfr: 213.251.188.141 NOKEY # allow xfr from secondary
sdns2.ovh.net
# notify is sent from
hidden primary @MWN
My "equivalent" config at that given secondary is:
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
- id: secondaryOVH
address: 213.251.188.141 # allow xfr from secondary
sdns2.ovh.net
via: 10.2.2.201 # outgoing interface
But I do get:
debug: [ellael.org.] ACL, denied, action transfer, remote 213.251.188.141@41425
Your other mail:
Another issues are:
`via: 10.1.1.201` - this interface isn't configured and the
specification is not needed if there is just one IPv4 address - remove it
Yeah, there are more IPv4 addresses in that given FreeBSD jail, I do need it.
`block-notify-after-transfer: on` - this
doesn't make sense too
Done, and thanks to your suggestion, no longer needed.
Thank you very much for your help!
Regards,
Michael
On 2/16/24 16:14, Michael Grimm wrote:
> Thank you for your help. I will send complete configs.
> Primary hidden:
> ###############
> # server specifics
> #
> server:
> listen: 10.2.2.203@5333
> user: knot:knot
> rundir: "/var/run/knot"
> tcp-workers: 1
> udp-workers: 1
> identity: ""
> # logging
> #
> log:
> - target: syslog
> any: info
> - target: "/var/log/knot.log"
> any: debug
> # database managment
> #
> database:
> storage: "/var/db/knot"
> kasp-db: "/var/db/knot/kasp"
> # key used for acl transactions
> #
> key:
> - id: primary-secondary
> algorithm: hmac-sha256
> secret: <hidden>
> # acl transactions (primary, secondary)
> #
> acl:
> - id: aclTRANSACTIONS
> key: primary-secondary
> action: [notify, transfer]
> # remote secondary and authoritative nameservers (KBN, MWN)
> #
> remote:
> - id: secondaryKBN
> key: primary-secondary
> address: 10.1.1.201 # KBN secondary
> via: 10.2.2.203 # outgoing interface
> - id: secondaryMWN
> key: primary-secondary
> address: 10.2.2.201 # MWN secondary
> via: 10.2.2.203 # outgoing interface
> - id: secondaryOVH
> address: 213.251.188.141 # OVH's sdns2.ovh.net (notify,
submission)
> via: 10.2.2.203 # outgoing interface
> # all remote secondary servers that get notified
> #
> remotes:
> - id: remoteSERVERS
> remote: [secondaryKBN, secondaryMWN, secondaryOVH]
> # KSK submission checks (only active during ksk rollovers)
> #
> submission:
> - id: kskCHECKER
> check-interval: 15m
> parent: secondaryOVH
> # dnssec policy
> #
> policy:
> - id: ecdsa
> algorithm: ecdsap256sha256
> ksk-lifetime: 0 # no KSK rollover
> zsk-lifetime: 365d
> propagation-delay: 6h
> nsec3: on
> cds-cdnskey-publish: always
> ksk-submission: kskCHECKER
> # default template used for all zonefiles
> #
> template:
> - id: default
> storage: "/usr/local/etc/knot/zones"
> file: "%s"
> semantic-checks: on
> dnssec-policy: ecdsa
> dnssec-signing: on
> acl: aclTRANSACTIONS
> notify: remoteSERVERS
> zonefile-sync: -1
> zonefile-load: difference
> journal-content: changes
> # primary zones hosted
> #
> zone:
> - domain: ellael.org
> [others snipped]
> Secondary (both identical configs):
> ###################################
> # server specifics
> #
> server:
> listen: 10.1.1.201@53
> listen: fd00:a:a:a::201@53
> user: knot:knot
> rundir: "/var/run/knot"
> tcp-workers: 1
> udp-workers: 1
> identity: ""
> version: ""
> # logging
> #
> log:
> - target: syslog
> any: info
> - target: "/var/log/knot.log"
> any: debug
> # database managment
> #
> database:
> storage: "/var/db/knot"
> kasp-db: "/var/db/knot/kasp"
> # key used for acl transactions
> #
> key:
> - id: primary-secondary
> algorithm: hmac-sha256
> secret: <hidden>
> # acl transactions (primary, secondary)
> #
> acl:
> - id: aclTRANSACTIONS
> key: primary-secondary
> action: [notify, transfer]
> # remote hidden primary and secondary nameservers (MWN, OVH)
> #
> remote:
> - id: primaryMWN
> key: primary-secondary
> address: 10.2.2.203@5333 # MWN hidden primary
> via: 10.1.1.201 # outgoing interface
> block-notify-after-transfer: on
> remotes:
> - id: remoteSERVERS
> remote: [primaryMWN]
> # default template used for all zonefiles
> #
> template:
> - id: default
> storage: "/usr/local/etc/knot/zones"
> file: "%s"
> master: primaryMWN
> notify: remoteSERVERS
> acl: aclTRANSACTIONS
> semantic-checks: on
> # primary zones hosted
> #
> zone:
> - domain: ellael.org
> [others snipped]
> Thanks in advance,
> Michael
>> On 16. Feb 2024, at 16:05, Daniel Salzman <daniel.salzman(a)nic.cz> wrote:
>>
>> Okay. Please show me the configuration of the zone (template).
>>
>> On 2/16/24 16:03, Michael Grimm wrote:
>>> Yes, I understand that, now ;-)
>>> But my main concern is this: "Those errors are only logged when a zone
gets updated"
>>> Regards,
>>> Michael
>>>> On 16. Feb 2024, at 15:57, Daniel Salzman <daniel.salzman(a)nic.cz>
wrote:
>>>>
>>>> Note that `knotc zone-notify` works on a primary. If you want an explicit
refresh on a secondary, call `knotc zone-refresh`.
>>>>
>>>> On 2/16/24 15:55, Michael Grimm wrote:
>>>>> Daniel Salzman <daniel.salzman(a)nic.cz> wrote
>>>>>> Is there another primary above the hidden master?
>>>>> I am not sure if I do understand your question correctly.
>>>>> Here is my setup:
>>>>> Hidden Primary —> Secondary (2x)
>>>>> Feel free to ask for more info. Complete configs?
>>>>> Thanks,
>>>>> Michael
>>>> --
>> --
--
9:11
So the setup isn't just "Hidden Primary —> Secondary (2x)"!
Then you must have the acl action transfer in the secondary configuration as well.
On 2/16/24 20:18, Michael Grimm wrote:
But I do need something similar at one of my secondary
servers that
allows for a zone transfer from that given secondary to secondaryOVH as
set up in NSD config:
allow-notify: 10.2.2.203
primary-secondary
request-xfr: 10.2.2.203@5333
primary-secondary
provide-xfr: 213.251.188.141 NOKEY # allow
xfr from secondary sdns2.ovh.net
# notify
is sent from hidden primary @MWN
Why do you send NOTIFY from the hidden primary instead of the secondary?
My "equivalent" config at that given secondary is:
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
- id: secondaryOVH
address: 213.251.188.141 # allow xfr from
secondary sdns2.ovh.net
via: 10.2.2.201 # outgoing interface
The zone configuration is missing!
The remote configuration itself does nothing if the id (secondaryOVH) isn't referenced
from notify/master/acl.
In this case you probably need only the acl rule for the transfer from 213.251.188.141.
That's all.
But I do get:
debug: [ellael.org.] ACL, denied, action transfer, remote
213.251.188.141@41425
9:14
Okay, then ignore my last reply :-)
On 2/17/24 08:52, Michael Grimm wrote:
Hi,
FTR: My questions are all answered, and I solved the last remaining issue regarding
OVH's secondary server without key.
1) Modification of my firewall: The primary is still cutoff from remote access, except
that one IP of OVH's secondary
2) Now, my primary serves all secondary servers, two of mine plus OVH
3) Added an additional ACL for keyless AFXR to OVH secondary
Thank you very much again. Now, I understand much better what went wrong in my first
setup attempts ;-)
Regards,
Michael
On 16. Feb 2024, at 20:18, Michael Grimm
<trashcan(a)ellael.org> wrote:
Hi Daniel,
thank you very much, your mail helped a lot!
I see a few issues:
- increase the number of workers (at least one TCP worker is too low on the primary if
you have more secondaries)
- acl action notify is not needed on the primary
- acl action transfer is not needed on secondaries
- notify configuration on secondaries doesn't make sense in your case
Done, although not understood, yet. I need more reading in the manual.
BUT: Now (almost, see below) everything works as expected.
- there is some inconsistency in secondaryOVH
configuration: remote without key vs. acl with key primary-secondary
No, that's intended. The communication with secondaryOVH needs to be keyless. That is
something I need to separate. And actually it is working as expected at the primary.
But I do need something similar at one of my secondary servers that allows for a zone
transfer from that given secondary to secondaryOVH as set up in NSD config:
allow-notify: 10.2.2.203 primary-secondary
request-xfr: 10.2.2.203@5333 primary-secondary
provide-xfr: 213.251.188.141 NOKEY # allow xfr from
secondary sdns2.ovh.net
# notify is sent from
hidden primary @MWN
My "equivalent" config at that given secondary is:
remote:
- id: primaryMWN
key: primary-secondary
address: 10.2.2.203@5333 # MWN hidden primary
via: 10.2.2.201 # outgoing interface
- id: secondaryOVH
address: 213.251.188.141 # allow xfr from secondary
sdns2.ovh.net
via: 10.2.2.201 # outgoing interface
But I do get:
debug: [ellael.org.] ACL, denied, action transfer, remote 213.251.188.141@41425
Your other mail:
Another issues are:
`via: 10.1.1.201` - this interface isn't configured and the
specification is not needed if there is just one IPv4 address - remove it
Yeah, there are more IPv4 addresses in that given FreeBSD jail, I do need it.
`block-notify-after-transfer: on` - this
doesn't make sense too
Done, and thanks to your suggestion, no longer needed.
Thank you very much for your help!
Regards,
Michael
On 2/16/24 16:14, Michael Grimm wrote:
> Thank you for your help. I will send complete configs.
> Primary hidden:
> ###############
> # server specifics
> #
> server:
> listen: 10.2.2.203@5333
> user: knot:knot
> rundir: "/var/run/knot"
> tcp-workers: 1
> udp-workers: 1
> identity: ""
> # logging
> #
> log:
> - target: syslog
> any: info
> - target: "/var/log/knot.log"
> any: debug
> # database managment
> #
> database:
> storage: "/var/db/knot"
> kasp-db: "/var/db/knot/kasp"
> # key used for acl transactions
> #
> key:
> - id: primary-secondary
> algorithm: hmac-sha256
> secret: <hidden>
> # acl transactions (primary, secondary)
> #
> acl:
> - id: aclTRANSACTIONS
> key: primary-secondary
> action: [notify, transfer]
> # remote secondary and authoritative nameservers (KBN, MWN)
> #
> remote:
> - id: secondaryKBN
> key: primary-secondary
> address: 10.1.1.201 # KBN secondary
> via: 10.2.2.203 # outgoing interface
> - id: secondaryMWN
> key: primary-secondary
> address: 10.2.2.201 # MWN secondary
> via: 10.2.2.203 # outgoing interface
> - id: secondaryOVH
> address: 213.251.188.141 # OVH's sdns2.ovh.net (notify,
submission)
> via: 10.2.2.203 # outgoing interface
> # all remote secondary servers that get notified
> #
> remotes:
> - id: remoteSERVERS
> remote: [secondaryKBN, secondaryMWN, secondaryOVH]
> # KSK submission checks (only active during ksk rollovers)
> #
> submission:
> - id: kskCHECKER
> check-interval: 15m
> parent: secondaryOVH
> # dnssec policy
> #
> policy:
> - id: ecdsa
> algorithm: ecdsap256sha256
> ksk-lifetime: 0 # no KSK rollover
> zsk-lifetime: 365d
> propagation-delay: 6h
> nsec3: on
> cds-cdnskey-publish: always
> ksk-submission: kskCHECKER
> # default template used for all zonefiles
> #
> template:
> - id: default
> storage: "/usr/local/etc/knot/zones"
> file: "%s"
> semantic-checks: on
> dnssec-policy: ecdsa
> dnssec-signing: on
> acl: aclTRANSACTIONS
> notify: remoteSERVERS
> zonefile-sync: -1
> zonefile-load: difference
> journal-content: changes
> # primary zones hosted
> #
> zone:
> - domain: ellael.org
> [others snipped]
> Secondary (both identical configs):
> ###################################
> # server specifics
> #
> server:
> listen: 10.1.1.201@53
> listen: fd00:a:a:a::201@53
> user: knot:knot
> rundir: "/var/run/knot"
> tcp-workers: 1
> udp-workers: 1
> identity: ""
> version: ""
> # logging
> #
> log:
> - target: syslog
> any: info
> - target: "/var/log/knot.log"
> any: debug
> # database managment
> #
> database:
> storage: "/var/db/knot"
> kasp-db: "/var/db/knot/kasp"
> # key used for acl transactions
> #
> key:
> - id: primary-secondary
> algorithm: hmac-sha256
> secret: <hidden>
> # acl transactions (primary, secondary)
> #
> acl:
> - id: aclTRANSACTIONS
> key: primary-secondary
> action: [notify, transfer]
> # remote hidden primary and secondary nameservers (MWN, OVH)
> #
> remote:
> - id: primaryMWN
> key: primary-secondary
> address: 10.2.2.203@5333 # MWN hidden primary
> via: 10.1.1.201 # outgoing interface
> block-notify-after-transfer: on
> remotes:
> - id: remoteSERVERS
> remote: [primaryMWN]
> # default template used for all zonefiles
> #
> template:
> - id: default
> storage: "/usr/local/etc/knot/zones"
> file: "%s"
> master: primaryMWN
> notify: remoteSERVERS
> acl: aclTRANSACTIONS
> semantic-checks: on
> # primary zones hosted
> #
> zone:
> - domain: ellael.org
> [others snipped]
> Thanks in advance,
> Michael
>> On 16. Feb 2024, at 16:05, Daniel Salzman <daniel.salzman(a)nic.cz> wrote:
>>
>> Okay. Please show me the configuration of the zone (template).
>>
>> On 2/16/24 16:03, Michael Grimm wrote:
>>> Yes, I understand that, now ;-)
>>> But my main concern is this: "Those errors are only logged when a zone
gets updated"
>>> Regards,
>>> Michael
>>>> On 16. Feb 2024, at 15:57, Daniel Salzman <daniel.salzman(a)nic.cz>
wrote:
>>>>
>>>> Note that `knotc zone-notify` works on a primary. If you want an explicit
refresh on a secondary, call `knotc zone-refresh`.
>>>>
>>>> On 2/16/24 15:55, Michael Grimm wrote:
>>>>> Daniel Salzman <daniel.salzman(a)nic.cz> wrote
>>>>>> Is there another primary above the hidden master?
>>>>> I am not sure if I do understand your question correctly.
>>>>> Here is my setup:
>>>>> Hidden Primary —> Secondary (2x)
>>>>> Feel free to ask for more info. Complete configs?
>>>>> Thanks,
>>>>> Michael
>>>> --
>> --
--
82
days inactive
83
days old
14 comments
3 participants
participants (3)
-
Daniel Salzman -
libor.peltan -
Michael Grimm