Hi!
We've been experimenting with backups and disaster recovery in our knot
test setup and have been running into a weird issue.
Basically our backup strategy right now is to perform incremental
backups of the /var/lib/knot and the /etc/knot directories via rsync.
When we try to restore these backups knot starts successfully, but logs
the following messages for each of the zones that are currently in a
signed template:
2019-03-08T11:43:05 info: [example.com.] DNSSEC, signing zone
2019-03-08T11:43:05 error: [example.com.] zone event 'DNSSEC re-sign'
failed (invalid parameter)
When we try to query information about these zones via dig we receive a
SERVFAIL rcode for them.
All of the zones that are not processed through the DNSSEC mechanism are
unaffected by this.
We also experienced th same behavior, when we were experimenting with
adding new zones that are signed immediately.
To workaround this problem we currently add the zone in an unsigned
state (aka default template) to knot and after that we switch the
template of the zone to "signed".
This works like a charm for new zones and can also be used to recover
each of the broken zones after restoring the backup, but we'd rather not
use this workaround during disaster recovery as it would impose the
danger of breaking the zones if it is not performed correctly.
The templates and policies in our knot.conf look like this right now:
policy:
- id: shared
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
zsk-lifetime: 1d
ksk-lifetime: 2d
ksk-shared: true
ksk-submission: resolver
nsec3: true
cds-cdnskey-publish: always
template:
- id: default
storage: "/var/lib/knot"
semantic-checks: on
global-module: mod-stats
master: primary
notify: secondaries
acl: [primary, secondaries]
serial-policy: unixtime
dnssec-signing: off
- id: signed
dnssec-signing: on
dnssec-policy: shared
master: primary
notify: secondaries
acl: [primary, secondaries]
serial-policy: unixtime
zone:
- domain: example.com
template: signed
Thanks,
Thomas
Hi,
we are testing knot at the moment and are struggling with the concept of
automatic KSK rollovers. We are planning to fetch the current CDS for
further automatic processing and try to figure out how to achieve a
policy that performs KSK rollovers in a short period of time for testing
purposes. Until now we have not seen any KSK rollovers and we are not
sure why this is not happening. Can someone show me an example of a
policy that schedules a KSK rollover within a very short period, let's
say once a day? What policy parameters must be set? And what must be the
zone's parameters in terms of TTL and SOA values (expire, refresh, etc)?
Thanks a lot,
Thomas
Ahoj,
I'm tinkering with running knot-resolver for DNS-over-TLS (only). My kresd@1
is listening on the public interface by using a drop-in override file,
following kresd.systemd(7) (kresd-tls.socket.d/override.conf).
Thing is, I would like knot to not listen on port 53 on any interface, not
even localhost. But this is precisely what it does.
I naively tried to stop it from doing so, first with a
kresd.socket.d/override.conf with:
[Socket]
ListenStream=
But that failed with journalctl -u kresd.socket containing `kresd.socket:
Unit has no Listen setting (ListenStream=, ListenDatagram=, ListenFIFO=,
...). Refusing.`
And also by trying to disable that "socket-unit", with a
kresd(a)1.service.d/override.conf containing:
[Service]
Sockets=
Sockets=kresd-tls.socket
Sockets=kresd-control(a)%i.socket
But that did nothing.
Finally, using `systemctl mask kresd.socket` I get it to stop listening on
(localhost) port 53. But then instead systemd find itself in "degraded"
mode...
Any tip on how to accomplish this cleanly?
Hello Knot DNS users.
Our deb package signing key may have been compromised and has been
revoked. Open Build Service repositories are not affected.
The affected systems (https://deb.knot-dns.cz/knot-latest and
https://deb.knot-dns.cz/knot) now contain a new Debian repository. The
packages were re-built and re-signed with a new GPG key
rsa4096/0x8A0EFB02C84B1E9B.
We thank to security researcher calling himself "p3n73st3r" who notified
us earlier today.
Regards
Your Knot DNS team
Hello community,
can I somehow convert stored certificates for a signed zone to BIND format?
My use case is to change used topology for authoritative servers. I´m manage
existing zones in Knot, now I would like to transfer it to BIND and use
existing certificates for signing it on BIND due to DS records in parent
zones. The knot will be reconfigured as a slave.
Is it possible to achieve it?
Thanks.
--
Smil Milan Jeskyňka Kazatel
Hello, community,
could someone more describe the On-slave signing on both sides - slave and
master in the case where the master server runs on bind and slave is Knot
DNS?
I would like to achieve signing for "hidden master" configuration.
I found in Knot DNS documentation:
***
It is possible to enable automatic DNSSEC zone signing even on a slave
server. If enabled, the zone is signed after every AXFR/IXFR transfer from
master, so that the slave always serves a signed up-to-date version of the
zone.
It is strongly recommended to block any outside access to the master server,
so that only the slave’s signed version of the zone is served.
Enabled on-slave signing introduces events when the slave zone changes while
the master zone remains unchanged, such as a key rollover or refreshing of
RRSIG records, which cause inequality of zone SOA serial between master and
slave. The slave server handles this by saving the master’s SOA serial in a
special variable inside KASP DB and appropriately modifiying AXFR/IXFR
queries/answers to keep the communication with master consistent while
applying the changes with a different serial.
It is recommended to use UNIX time serial policy on master and incremental
serial policy on slave so that their SOA serials are equal most of the time.
***
Thanks for any advice.
Regards,
kaza
Hello all,
we want to migrate to a state of the art nameserver software.
Our startingpoint is djbdns/tinydns.
Our first step should be to to use zone transfer from tinydns to knot-dns
(2.7.6).
I configure the knot-dns a slave:
# knotc conf-read
…
acl.id = master
acl[master].address = 5.28.40.220
acl[master].action = notify
remote.id = master
remote[master].address = 5.28.40.220
…
zone.domain = vtnx.net.
zone[vtnx.net.].master = master
zone[vtnx.net.].acl = master
and add a initial soa rr for that domain:
vtnx.net. 0 SOA ns1.vtnx.net. hostmaster.vtnx.net. 1 16384 2048 1048576 2560
This the exact soa of the running vtnx.net domain, but a diffrent serial.
After triggering the notification from the master, i got this logging:
Jan 24 07:53:19 ns1-neu knotd[26299]: info: [vtnx.net.] notify, incoming, 5.28.40.220@38668: received, serial none
Jan 24 07:53:19 ns1-neu knotd[26299]: info: [vtnx.net.] refresh, outgoing, 5.28.40.220@53: remote serial 1548307450, zone is outdated
Jan 24 07:53:19 ns1-neu knotd[26299]: warning: [vtnx.net.] IXFR, incoming, 5.28.40.220@53: malformed response SOA
Jan 24 07:53:19 ns1-neu knotd[26299]: warning: [vtnx.net.] refresh, remote master not usable
Jan 24 07:53:19 ns1-neu knotd[26299]: error: [vtnx.net.] refresh, failed (no usable master)
What about "malformed response SOA"?
Why is this an IXFR and no AXFR?
- Frank
--
Frank Matthieß Mail: frank.matthiess(a)virtion.de
GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1
virtion GmbH Stapenhorster Straße 42b, DE 33615 Bielefeld
Geschäftsführer: Michael Kutzner
Handelsregister HRB 40374, Amtsgericht Bielefeld, USt-IdNr.: DE278312983
