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 <[email protected]> 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/[email protected]/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
>>
>>
>>
>> --
> --
--
