Hi,
this happened to me for the second time, that https://dnsviz.net <https://dnsviz.net/> tells me:
| enfer-du-nord.net/CDNSKEY: The CDNSKEY RRset must be signed with a key that is represented in both the
| current DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1.
| enfer-du-nord.net/CDS: The CDS RRset must be signed with a key that is represented in both the current
| DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1.
I do not understand what that means.
#) I haven't modified my KSK for some time now
#) I did notify my parent zone about a modified list of nameservers (via registrar's web portal)
I am not absolutely sure if the latter is the cause for these error messages.
I 'fixed' that issue by re-uploading my unmodified KSK DNSKEY (via registrar's web portal).
Hmm, how can I fix that issue the right way?
Any hints are highly welcome,
Michael
Hi,
given the case that a ip6/xy block might be delegated to me by my ISP, I began investigating Knot DNS' functionality with regard to ip6.arpa.
Hereby I stumbled over the module synthrecord and do not really understand what it is used for.
From https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#synthrecord-automati…
"Records are synthesized only if the query can't be satisfied from the zone."
Please excuse my ignorance, but why would/should/must one return something else than the following for hosts not in the zone?
kbn> host 2001:dead:beef::1
Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.d.a.e.d.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)
Any feedback is highly appreciated, thanks.
Regards,
Michael
Hi,
This is just a possible feature request. We’re planning on using Knot for user
hosted domains. To do that we’ll have to add and remove zones dynamically,
so we’ve enabled the config db.
What surprised us is that this means that the config file isn’t used at all anymore
(except you can use it to prime the config db).
As it is, we’ll have to embrace the config db, which makes our ansible playbook
more complicated. It’s easy to add a config file template in ansible, it’s more
complicated to issue `knotc conf-begin; knotc conf-set; knotc conf-commit` logic.
I wish knot was more like nsd, where you have the config file nsd.conf, but if
you add zones with `nsd-control addzone ….` it gets added to a seperate zonelist
file, which nsd reads on startup. It means we can have a static config file, but
still be able to add and delete zones dynamically.
nsd doesn’t have automatic DNSSEC key management and catalog zones in knot
are really easy to use, which is why we’re going with knot for this project. I just
wanted to lay it out there as an idea for the future :)
.einar
Hi Bill,
You can't mix a configuration database and a configuration file.
You can initialize a database with `knotc conf-init` or `knotc conf-import`.
Then if you start knotd, the database will be used for reading and persistent writing.
The configuration database format is a custom format using LMDB. It's not intended to be accessed externally!
Daniel
On 3/29/25 19:56, Billiam Crashkopf wrote:
> Hi all,
>
> I'm running Knot 3.4.4 on FreeBSD 14.2, installed from the distribution package repository.
>
> I'm trying to understand, is there a way to configure knotd using both the configuration file and the database? For example, can I use the configuration file for directives like listen and template, then use the configuration database for storing individual zone settings? So far, it appears that knotd only uses one or the other. Furthermore, there doesn't seem to be any command to explicitly load or flush configuration from the database. If I start with the config file, I can initialize the database, but upon stopping knotd nothing seems to be saved to the database. I also don't see any documentation on tooling to inspect the database on disk. What is the file format of the database?
>
> If anybody can help me to know more about how it works I would be most appreciative.
>
> Thanks,
>
> Bill
>
Hello!
In July 2024, in the Knot-DNS 3.3.8 release message, Daniel writes:
>I would like to ask users with hardware HSMs to send us the output of `keymgr <hsm_keystore_id> keystore-test`
>This will allow us to update https://www.knot-dns.cz/docs/latest/html/appendices.html#compatible-pkcs-11…
We're now running Knot 3.4.4 against a Thales HSM (I have no details of the
actual device/model in use at this time) and I see the following data:
$ keymgr -c etc/knot.conf thales keystore-bench
Keystore id 'thales', type PKCS #11, threads 1
Algorithm Sigs/sec
RSASHA256 33
ECDSAP256SHA256 27
ED25519 n/a
ED448 n/a
My first reaction was "hmm, that's slow".
Is there a list (above URL isn't it) of comparable results which I could show
the HSM operators and/or is anybody willing to share their data?
Thanks & regards,
-JP
Hi Vladimir,
I appreciate your response and it's great to know you validate by default.
I apologize for posting to the wrong list.
Best,
Henry
On Wed, Mar 12, 2025 at 9:14 AM Vladimír Čunát <vladimir.cunat(a)nic.cz>
wrote:
> Hello.
> On 10/03/2025 17.01, birgelee--- via knot-dns-users wrote:
>
> This ballot requires compliance with RFCs 4035 (specifically an implementation of a "security-aware" resolver as defined in Section 4) and 6840. To the best of my knowledge Knot would be a viable choice for conforming to this ballot particularly since there is a reference to RFCs 4035 in the config documentation and 6840 implements several key features of modern DNSSEC. Given the need for documentable compliance by CAs, a statement of intended support from the Knot team would be extremely helpful.
>
> This is about resolvers apparently, so we're slightly off-topic here, as
> we have a split knot-resolver-users(a)lists.nic.cz - but I expect this
> thread to be very short.
>
> Knot Resolver *does support* modern DNSSEC validation, as described in RFC
> 4035, 6840, and some others. And we validate by default, etc.
>
> --Vladimir
>
Hi all,
I know this topic has been dead for a bit, but I did want to specifically find out if Knot is intended to be compliant with DNSSEC RFCs 4035 and 6840. I ask because I am computer security researcher and I do a lot of work with the CA/Browser Froum. I recently proposed a draft ballot that would mandate all publicly-trusted web CAs validate DNSSEC:
https://github.com/cabforum/servercert/pull/571
This ballot requires compliance with RFCs 4035 (specifically an implementation of a "security-aware" resolver as defined in Section 4) and 6840. To the best of my knowledge Knot would be a viable choice for conforming to this ballot particularly since there is a reference to RFCs 4035 in the config documentation and 6840 implements several key features of modern DNSSEC. Given the need for documentable compliance by CAs, a statement of intended support from the Knot team would be extremely helpful.
Best,
Henry
https://henrybirgelee.com/
is there any guidance on using mod-rrl on a public server with a
moderate load, say 6kqps? we have rtfm, and remain unsure of
what we are doing. we want cookies, and therefore need to turn
rrl on. but with it turned on, we seem to drop a *lot* of
replies, a lot.
mod-rrl:
- id: default
rate-limit: 200
slip: 2
randy
