Hi,
we performed successfully an algorithm rollover. After changing the
algorithm in the configuration file everything worked as expected. All
zones have been updated to the new algorithm.
When I now sign a new zone the zone is being signed with the old
algorithm's key and an algorithm rollover is being triggered immediately.
Is this an expected behavior? How can I avoid this? Do I have to delete
the old key?
Thanks a lot,
Thomas
Hi!
I have two Debian 10 Buster systems, both patched up current, and both
running Knot 3.0.4-1~cz.nic~buster1 from the apt repository at
https://deb.knot-dns.cz/knot-latest/.
Both Knot installations have virtually identical configs .. really
only different in the related hosts and zone lists. Their logging
configs are both:
log:
- target: syslog
any: info
One of these Knot instances logs to syslog, and the other logs to
systemd-journald. I'm trying to figure out why the difference, and
I've come up empty. The Knot docs simply say that if Knot is compiled
against systemd, then a 'syslog' setting will use systemd-journald.
Mostly I want to know so that I can convince the one using journald to
stop doing that. :) What other things might trigger Knot to use
syslog on a systemd-managed host?
Hi,
is it possible to have two different DNSSEC policies in place? For
example having one domain singed with Alg 8 and another one with Alg 13?
Thanks a lot,
Thomas
Hi!
Today we tried to do a dynamic update to the dnskey set.
What we want to do is to import the ZSK from another signer.
Didn’t work so well.
Feb 16 17:15:28 ip-172-31-38-41 knotd[24222]: warning: DDNS, refusing to update DNSSEC-related record
I guess knot doesn’t like dynamic DNSSEC updates.
I even tried with policy manual:on.
What does one have to do to be allowed to add (or delete) DNSKEY records?
/Ulrich
Hello all, I am attempting to test freezing a zone, and something appears not to be working (that something could be my understanding of how it is supposed to work).
Using a very simple example.com zone (the default that ships with v3.0.4), I am able to query for "mail.example.com" and get the correct response back. I then query for "test.example.com" and get an NXDOMAIN, as expected. Then I do the following:
$ sudo knotc zone-freeze example.com
OK
$
Doing a zone-status, I see:
$ sudo knotc zone-status example.com
[example.com.] role: master | serial: 2010111219 | transaction: none | freeze: yes | expiration: not scheduled | notify: not scheduled
$ sudo knotc zone-begin example.com
OK
$ sudo knotc zone-set example.com test 3600 A 150.150.150.150
OK
$ sudo knotc zone-commit example.com
OK
$ sudo knotc zone-flush example.com
OK
$
After the zone-flush, I am able to query for "test.example.com" and I get back the A-record with address 150.150.150.150. I would have thought that with the zone frozen, the zone-flush would not go through and the A-record for "test" would not be added.
Am I missing something obvious, or does zone-freeze just not work in version 3.0.4?
Thanks in advance,
~J
Hello,
I have just run into a weird problem and since I have failed to look
this up on the Web myself, I wonder if anyone here could give me a
pointer regarding what to do with it.
I run a Linux/arm DNS server based on knot-3.0.4. It used to serve as a
slave in a zone whose master was a knot-2.9, with automatic DNSSEC
signing _on master only_ set up and working. The zone configuration
(minus "master" and "acl" keywords) looked as follows:
zonefile-load: difference-no-serial
journal-content: all
semantic-checks: on
# dnssec-signing: on
# dnssec-policy: nsec3
where "nsec3" is a policy also defined in Knot configuration, identical
to the one used on the master. In this role everything worked fine.
Recently it has been decided to retire the original master server and
replace it with the erstwhile slave. I removed the "master" line from
the zone configuration in knot.conf (yes, I did leave the DNSSEC line
commented out) in addition to setting up replication to a new slave
server, copied the key files + the KASP dump from the old master and
installed them in the right places, then restarted knot. Again, so far
so good.
I then attempted to re-enable DNSSEC by uncommenting those two lines -
and immediately after I'd run 'knotc reload' Knot began spamming the
system log with lines like
info: [example.com.] zone file parsed, serial corrected 2021020301 ->
2021020303
info: [example.com.] DNSSEC, key, tag 4533, algorithm
RSASHA1_NSEC3_SHA1, KSK, public, active
info: [example.com.] DNSSEC, key, tag 10532, algorithm
RSASHA1_NSEC3_SHA1, public, active
info: [example.com.] DNSSEC, signing started
info: [example.com.] DNSSEC, successfully signed
info: [example.com.] loaded, serial 2021020302 -> 2021020303 ->
2021020302, 113233 bytes
info: [example.com.] DNSSEC, next signing at 2021-02-10T13:21:14+0000
info: [example.com.] zone file parsed, serial corrected 2021020301 ->
2021020303
info: [example.com.] DNSSEC, key, tag 4533, algorithm
RSASHA1_NSEC3_SHA1, KSK, public, active
info: [example.com.] DNSSEC, key, tag 10532, algorithm
RSASHA1_NSEC3_SHA1, public, active
info: [example.com.] DNSSEC, signing started
info: [example.com.] DNSSEC, successfully signed
info: [example.com.] loaded, serial 2021020302 -> 2021020303 ->
2021020302, 113233 bytes
info: [example.com.] DNSSEC, next signing at 2021-02-10T13:21:14+0000
info: [example.com.] zone file parsed, serial corrected 2021020301 ->
2021020303
[...and so on...]
This was accompanied by knot consistently requiring much more CPU power
than usual. I also noticed that unlike before, running 'knotc
zone-flush' or shutting Knot down does NOT update the plain-text zone files.
From what I could see by removing old DNSSEC signatures and the NSEC3
chain from the zone file, restarting Knot and then querying the server
with dig, the server does indeed sign the zone. Therefore, my current
working hypothesis is that somehow Knot does not update its internal
zone state following the successful signing, thus continuing to think
the outdated zone file found on the file system is the latest available
version. The problem is, I do not know why it does it or how I could
make it stop.
Any and all suggestions will be very much appreciated!
Cheers,
--
MS
Hi all,
I can't quite figure this out, I have two servers running Knot DNS 3.0.3 on Ubuntu 20.04.
horus.bastetrix.net is the primary, sekhmet.bastetrix.net is the secondary.
One of the zones hosted on these servers is selfhosting.cloud.
Whenever I commit a change to selfhosting.cloud, this happens in the log. As you can see, for some reason the IPv4 address returns a NOTAUTH error and then Knot successfully notifies over IPv6.
Dec 27 00:53:37 horus.bastetrix.net knotd[174159]: warning: [selfhosting.cloud.] notify, outgoing, remote 192.195.251.53@53, server responded with error 'NOTAUTH'
Dec 27 00:53:37 horus.bastetrix.net knotd[174159]: info: [selfhosting.cloud.] notify, outgoing, remote 2620:98:400c::53@53, serial 5
Dec 27 00:53:38 horus.bastetrix.net knotd[174159]: info: [selfhosting.cloud.] IXFR, outgoing, remote 2620:98:400c::53@36778, started, serial 4 -> 5
Dec 27 00:53:38 horus.bastetrix.net knotd[174159]: info: [selfhosting.cloud.] IXFR, outgoing, remote 2620:98:400c::53@36778, finished, 0.00 seconds, 1 messages, 295 bytes
sekhmet only logs a successful notify and IXFR from the v6 address, nothing about the failed v4 notify:
Dec 27 00:53:37 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] notify, incoming, remote 2620:98:400a::53@58782, serial 5
Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] refresh, remote 2620:98:400a::53@53, remote serial 5, zone is outdated
Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] IXFR, incoming, remote 2620:98:400a::53@53, started
Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] IXFR, incoming, remote 2620:98:400a::53@53, finished, 0.00 seconds, 1 messages, 295 bytes
Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] refresh, remote 2620:98:400a::53@53, zone updated, 0.40 seconds, serial 4 -> 5
Dec 27 00:53:38 sekhmet.bastetrix.net knotd[536887]: info: [selfhosting.cloud.] zone file updated, serial 4 -> 5
I am attaching the knot.conf for both servers. I double checked both configs multiple times and don't see why that particular warning is happening during zone notify.
Can someone shed some light on this mystery?
--
Sadiq Saif
https://bastetrix.com
Hi,
We're migrating our signer from OpenDNSSEC to Knot 3.0. Our new design
will have one active signer and at least one backup signer. Zone data is
deployed from git to both signers. We've got syncing of the keys working
using `knotc zone-backup +nozonefile` and `knotc zone-restore
+nozonefile`. I'm still unsure of how hot to keep the standby. In the
dev env now I have the standby set to a manual dnssec policy to keep it
from rolling it's keys. The keys are synced from the active signer every
hour. Both the active and the backup signers are creating signatures but
SOA serials don't match. Both signers have `serial-policy: dateserial`
and `zonefile-sync: -1` but we're considering adding `zonefile-load:
difference-no-serial`.
We've discussed stopping signing on the backup altogether and including
the zonefiles in the backup. The problem we have with this idea is that
problems with signing on the backup won't be discovered until it goes
active.
Are other people doing active-backup signers and how do you set it up?
.einar
