Good morning,
is there some tool to migrate configuration from Knot 2.2 to actual
3.3.x ? There are some configuration changes, they're so far so good,
but I'm stuck on migrating DNSSEC keys now.
Thanks and best regards.
J.Karliak
Hi,
When i try to install knot via ports as your documentation sayshttps://www.knot-dns.cz/docs/2.4/html/installation.html
[cid:f31a0a83-7640-46e7-8586-d353f8c3d8f0]
it points me to a verison of 2015
https://www.freshports.org/dns/knot
Can you guys change the line to
# cd /usr/ports/dns/knot3 just to be more clear for a new user of freebsd
https://www.freshports.org/dns/knot3
Com os meus melhores cumprimentos,
André Cruz
Howdy,
I’m trying to get Knot 3.3.5 to use authenticated DNSSEC bootstrapping following the blog article and docs. However, I’m getting an error for the signalling zones, but I fail to figure out what I may have overlooked.
error: [_signal.ns2.droso.dk <http://signal.ns2.droso.dk/>.] module 'mod-onlinesign/authsignal', incompatible with automatic signing
Relevant knot.conf snippets (in order):
policy:
- id: ecc
algorithm: ecdsap256sha256
nsec3: on
rrsig-refresh: 7d
mod-onlinesign:
- id: authsignal
nsec-bitmap: [CDS, CDNSKEY]
policy: ecc
template:
- id: default
…
dnssec-signing: on
dnssec-policy: ecc
…
zone:
- domain: _signal.ns2.droso.dk <http://signal.ns2.droso.dk/>
module: [mod-authsignal, mod-onlinesign/authsignal]
Any hint appreciated
Best
Erwin
Good morning,
ISC bind is strict about CNAME of NS server:
skipping nameserver 'aa.bb.cz' because it is a CNAME, while resolving
'9.4/4.3.2.1.in-addr.arpa/PTR'.
How about Knot resolver ?
Thanks and best regards
J.Karliak
Hi,
I have a use case, where today we’re running BIND and a daemon uses rndc to create/remove/update zones on secondary servers.
According to `man knotc` knotc only supports UNIX sockets (old ubuntu man page showed ‘-p’ parameter to specify port).
I know I could use a catalog zone, but that would be a bigger change than I prefer right now. The primary server is running BIND+DLZ
with a PostgreSQL backend. Replacing the primary is on the roadmap, but for now, I just want to replace the secondaries.
Is there a good way to remotely add zones to a knot secondary?
.einar
Hello,
When doing something quite dramatic in knot.conf like adding and/or removing a zone, is "knotc reload" a suitable approach to honour those changes or would you recommend restarting the whole process?
"knotc reload" seems to work just fine in test, I'm just looking for some further confidence I suppose.
Thanks
Angus
debian 12
# uname -a
Linux rip.psg.com 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
# knotc --version
knotc (Knot DNS), version 3.2.6
AXFR of a 750k zone from seattle to, lebanon, europe, iceland, southern
africa, ...) fails over v5 and v6, i.e. somewhat larger rtt
same AXFR seattle seattle or seattle to ashburn works v4 and v6.
seattle to dallas v4 good, v6 fails, but it smells of an HE.net hop.
when it fails, it is always within a hundred or so mytes of the same
place, approximately 10% through the file.
pcap of seattle->beirut at https://archive.psg.com/240323.beirut.pcap
the last payload is in frame 217. at 219, seattle (b) sends a
FIN/PSH/ACK. then at 251, after acking everything, beirut (nabil)
FIN/ACKs seattle's FIN and we're dead.
i am not positive this is the key question as my tcp fu is a bit rusty.
but why did seattle send the FIN at 219, 10% through the file?
randy
