Is there another primary above the hidden master?

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: --

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: --

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

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: > 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 &lt;daniel.salzman(a)nic.cz&gt; 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 &lt;daniel.salzman(a)nic.cz&gt; 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 &lt;daniel.salzman(a)nic.cz&gt; 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 >>>> -- >> --

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

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

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…).

On 16. Feb 2024, at 17:11, libor.peltan &lt;libor.peltan(a)nic.cz&gt; 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): --