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
Hello fellow Knot users,
We're using Knot on some of our public authoritative servers. We operate a hidden primary configuration where there are two internal primary servers sending notifies to publicly accessible servers whenever zones change (ofc internal servers allow zone transfers & queries from the knot servers).
By design, our hidden internal primary servers operate in a hot/cold setup - one of them is answering to zone transfers / sending out notifies and the other one is not (dns server software is not running on the cold server).
This configuration causes knot to log alarming errors:
Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote 10.54.54.1@8054, remote serial 2021083015, zone is up-to-date, expires in 864000 seconds
Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote hidden-ns-2.internal, address 10.54.54.2@8054, failed (connection reset)
Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote hidden-ns-2.internal, address [ipv6_address]@8054, failed (connection reset)
Feb 1 17:28:45 ns2 knotd[624]: warning: [zone.fi.] refresh, remote hidden-ns-2.internal not usable
Feb 1 17:28:45 ns2 knotd[624]: error: [zone.fi.] refresh, failed (no usable master), next retry at 2024-02-01T17:58:45+0200
Feb 1 17:28:45 ns2 knotd[624]: error: [zone.fi.] zone event 'refresh' failed (no usable master)
Specifically, error "(no usable master)" is worrying - knot is able to reach hidden-ns-1.internal and verify that the zone it has is up-to-date. Also zone updates work normally and the zones don't seem to expire away (as zones should do if no master is reachable for an extended period of time).
Looks like this error appeared in version 3.3.0. 3.2.9 did not log similar errors (except in cases where all primaries really were unreachable). Has there been some design change in 3.3.0 (ie is this intentional) or could this be a bug? Or could it be related to our configuration?
Our configuration relies heavily on templates. These should be the important bits from knot's config, with ipv6 addresses hidden:
acl:
- id: "hidden-ns-1.internal"
address: [ 10.54.54.1, ipv6_address ]
action: notify
- id: "hidden-ns-2.internal"
address: [ 10.54.54.2, ipv6_address ]
action: notify
remote:
- id: "hidden-ns-1.internal"
address: [ 10.54.54.1@8054, ipv6_address@8054 ]
via: [ x.x.x.x, ipv6_address ]
- id: "hidden-ns-2.internal"
address: [ 10.54.54.2@8054, ipv6_address@8054 ]
via: [ x.x.x.x, ipv6_address ]
template:
- id: default
storage: /var/lib/knot/zones
master: hidden-ns-1.internal
master: hidden-ns-2.internal
acl: hidden-ns-1.internal
acl: hidden-ns-2.internal
semantic-checks: false
global-module: mod-rrl/default
zone:
- domain: zone.fi
--
Juha Suhonen
Senior Systems Specialist
CSC - Tieteen tietotekniikan keskus Oy
juha.suhonen(a)csc.fi
Hi,
I wonder if it would be possible that one may use arithmetics in knot.conf such as:
propagation-delay: 5 * dnskey-ttl
I'd like to set a propagation-delay safety net during ZSK rotations depending on SOA TTL set for any given zone.
As dnskey-ttl defaults to zone SOA TTL that would allow for propagation-delay definitions as multiples of SOA TTLs.
As I couldn't find that in the documentation, I do assume that this cannot be done, right?
Are there alternatives at hand I overlooked?
Regards,
Michael
Hi,
I'm evaluating the Knot DNS server as a DNSSEC signer engine. I'm
currently running version 3.2.6 together with SoftHSM version 2.6.1 on
an Ubuntu 20.04 linux server.
Now I have a problem with keymgr crashing with a segmentation fault
and dumping core. This happens with some of the commands of keymgr,
but not all (the command keymgr -l runs fine). The commands 'keymgr
trondheim.no list' produces the correct output, but then crashes.
/var/log/apport.log indicates that a dbus session is missing in the
environment:
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: called for pid
811052, signal 11, core limit 0, dump mode 2
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: not creating core
for pid with dump mode of 2
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: executable:
/usr/sbin/keymgr (command line "keymgr trondheim.no list")
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023:
is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: apport: report
/var/crash/_usr_sbin_keymgr.0.crash already exists and unseen,
skipping to avoid disk usage DoS
Running the command as 'dbus-run-session keymgr trondheim.no list' gives:
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: called for pid
811173, signal 11, core limit 0, dump mode 2
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: not creating core
for pid with dump mode of 2
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: executable:
/usr/sbin/keymgr (command line "keymgr trondheim.no list")
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023:
is_closing_session(): Could not determine DBUS socket.
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: apport: report
/var/crash/_usr_sbin_keymgr.0.crash already exists and unseen,
skipping to avoid disk usage DoS
I've tried to run the command as root and as the knot user, and I have
to admit that I'm not very familiar with how to manage dbus sessions.
I want to run the keymgr command from cron or from some other system
shell, for periodically monitoring the keys. However, I'm unsure why
keymgr wants to communicate on the dbus. Is it possible to disable this?
Regards,
Erik Østlyngen
Hi,
I am still very new to knot ;-)
FYI: This is Knot DNS 3.3.3 because 3.3.4 hasn't been shown up in FreeBSD's ports collectioon, yet.
Here are my settings regarding dnssec policy:
policy:
- id: ecdsa
algorithm: ecdsap256sha256
ksk-lifetime: 3650d
zsk-lifetime: 330d
propagation-delay: 1d
nsec3: on
cds-cdnskey-publish: rollover
Whatever I tell nsec3, either "on" or "true", only NSEC RR are generated, no NSEC3.
dns> grep -i nsec3 zones/ellael.org
dns>
dns> grep -i nsec zones/ellael.org
3600 IN RRSIG NSEC 13 2 3600 20240226084528 20240212071528 9562 ellael.org. fkpFcgkVq8ZRZT0GX5kVcfPZBB5S/2Gvh4XqrkrywbZXFKiCttYqCX7rBdJSbyem5G8Bxg1LKaxu7LrIoxtyVA==
3600 IN NSEC _dmarc.ellael.org. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY CAA
3600 IN RRSIG NSEC 13 3 3600 20240226084528 20240212071528 9562 ellael.org. R7Pz2JuKi7vQDe0KMt29NHGtKvuEnH2LPKcxTWLP9HyfuMxJx4BEyPE6i+JAw8RxfSIqWAcV/KMyCHaLgFtXXw==
3600 IN NSEC _token._dnswl.ellael.org. TXT RRSIG NSEC
3600 IN RRSIG NSEC 13 4 3600 20240226084528 20240212071528 9562 ellael.org. 3oUCWWTH2s9oH/Ea0b+MDrrQcOEuTbwx1iEuXaLq7wFribrnIGY8JeeiE3TO59n1lckKm4hia+2ox324xoxCzA==
[snip]
What am I doing wrong?
Thanks in advance and kind regards,
Michael
Hi,
I am very new to Knot [1].
Excerpts from my knot.conf:
policy:
...
ksk-lifetime: 3650d
zsk-lifetime: 330d
propagation-delay: 1d
...
dns> knotc zone-status ellael.org
[ellael.org.] role: master | serial: 2024021201 | re-sign: +12D8h42m21s
I am a bit puzzled by that "re-sign: +12D8h42m21s".
Does that mean "time until newly issued signatures" and becomes triggered by default "rrsig-lifetime: 14d" value?
If so, I am very much relieved, if not, what is going on, then?
Here is my question:
How can I find out the dates for upcoming KSK or ZSK rollovers?
This I couldn't find in the documentation, sorry.
Thanks and regards,
Michael
[1]
I've been bitten by that subtle bug in mailing list processing system ;-) My questions regarding migration strategy has become obsolete in the meantime, because I managed to migrate successfully. Thanks to the great documentation of Knot I could help myself ;-)
Subject: GUI Frontends for Knot DNS Server
Good day from Singapore,
Are there any GUI frontends for configuring Knot DNS Server?
I prefer GUI configuration interface. It is more efficient than
command line interface (CLI).
Thank you.
Regards,
Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
Blogs:
https://tdtemcerts.blogspot.comhttps://tdtemcerts.wordpress.com
Hello,
Running knot-resolver 5.6.0-1 amd64 (latest available via apt) on
debian-12 bookworm, fully upgraded.
systemctl start kresd@1 fails to run.
systemctl status kresd@1 shows the following errors:
[system] error while loading config:
...b/x86_64-linux-gnu/knot-resolver/kres_modules/policy.lua:378: bad
argument #1 to 'create' (table expected, got nil) (workdir
'/var/lib/knot-resolver')
Here is my kresd.conf. It had been running ok for a long time ( I don't
recall making any changes) :
- Default empty Knot DNS Resolver configuration in -*- lua -*-
-- Bind ports as privileged user (root) --
net = { '127.0.53.0' }
-- Switch to unprivileged user --
user('knot-resolver','knot-resolver')
-- Unprivileged
-- cache.size = 100*MB
policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains))
policy.add(policy.suffix(policy.STUB({'127.53.0.0'}), internalDomains))
policy.TLS_FORWARD({
-- multiple servers can be specified for a single slice
-- the one with lowest round-trip time will be used
{'9.9.9.9', hostname='dns.quad9.net'},
{'149.112.112.112', hostname='dns.quad9.net'},
})
All help is greatly appreciated,
Mike Wright
Dear mailing list subscribers,
due to a subtle bug in our mailing list processing system, a few emails
sent to the mailing list <knot-dns-users(a)lists.nic.cz> over the past two
years were blocked and awaiting approval without our knowledge. After
filtering out spam, we will review what we believe is still relevant and
reach out to the senders directly in the coming days.
If your email did not pass through the moderation phase, please resend
it to the list after the middle of next week. We are sorry for this
issue.
Our thanks go to Juha Suhonen who helped us discover the problem by
pointing out that his email is still waiting. Thank you, Juha.
Best regards,
David Vašek, Knot DNS team
