knot-dns-users

knot-dns-users@lists.nic.cz

1 participants
744 discussions

Re: Configuration database vs file questions

by Daniel Salzman

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 >

7 měsíců, 3 týdny

HSM keystore-bench

by Jan-Piet Mens

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

8 měsíců, 1 týden

Knot DNS 3.4.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.5! This is mostly a feature release. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.5 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

8 měsíců, 1 týden

Re: Knot compliance with

by Henry Birge-Lee

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 >

8 měsíců, 1 týden

Knot compliance with

by birgelee＠princeton.edu

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/

8 měsíců, 1 týden

mod-rrl

by Randy Bush

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

8 měsíců, 2 týdny

IXFR versions journaling without using file

by Jeremy C. Reed

I have static zones that are regenerated continually (every few seconds) with a knotc zone-reload _zonename_ after. Doing dig queries using ixfr= always used AXFR until I enabled per-zone zonefile-load: difference We saw logs periodically like: warning: [foo.bar.example.com.] failed to update zone file (operation not permitted) This is because the files created are a different user than the knotd. We are not doing automated signing nor dynamic updates. This is with Knot 3.2.6. 1) Why would it try writing to the source zone file? Anyways, we got rid of that warning with zonefile-sync: -1 And the time to between the zone-reload and serving the new zone data improved too. I noticed with experimenting with journal-db-max-size and journal-max-size the data.mdb was around 80% larger than the defined size. As I removed and added records, the number of differences reduced and I couldn't do IXFRs for many versions behind which I assume is default journal-max-depth: 20. I believe this means the journaling was dropping versions and does not require keeping at least 20 versions (not a "minimum". I am fine with that. I was able to trigger error like error: [foo.bar.example.com.] zone event 'load' failed (not enough space provided) which I assume was due to journaling even when dropping old versions still doesn't have enough space for most recent changes. We are experimenting with increasing journal-max-size to work around this. It appears that the differences are fully handled in memory first before updating to the journal file. I also see the journal file have large jump in file size and never small increments. 2) Since I have no purpose to reuse a journal file for system restart or recovery -- since I am building new zone files frequently, is there any way to not use a journal file and just have knotd do this all in memory? That way it is never writing to the journal every few seconds while I continue to offer IXFR out support? If not, maybe I will use memory file system for the journal files. By the way, this is for around ten zones varying from around 1000 records to over 8 million records for the larger zones, They are changing from a few records every few seconds to maybe a thousand records every 30 seconds. Thanks

8 měsíců, 2 týdny

IXFR response has interspersed IXFR and OPT records and more

by Jeremy C. Reed

I am testing IXFR for servers I did not install nor have easy access to. version.server. says it is 3.2.6. I know there are IXFR changes since then per the NEWS file and from git log. I don't see same behavior on my different version different systems but they are also configured differently. The knot.conf zones are not configured with "zonefile-load: difference" and the response effectively has the entire zone as if was AXFR and not the changes. If I pass the IXFR SOA SERIAL to latest it has no changes (answer has has the SOA only with same serial). I used dnspython to output the response from doing IXFR queries (IXFR question with SOA authoritative set with the serial in the query). I noticed the output abruptly stops when "dig" doesn't stop. So I used tcpdump many times to compare knot, named, and my other knot. I found an odd behavior in this knot 3.2.6 response which dig ignores and my dnspython fails. After the expect record it has 1) OPT record with the requestors pay load size (class 1232) and edns rcode and flags (all zeros ttl), then 00 rdlength and 00 rdata field. 2) then 28 bytes I don't understand such as: 40 11be dc80 0000 0101 fa00 0000 01 or 40 20be dc80 0000 0102 0300 0000 01 or 40 0fe1 6a81 0000 0102 0500 0000 00 or 12 8de1 6a81 0000 0100 9200 0000 00 3) then an IXFR record following other labels ... 0363 6f6d 00 three characters "com" and end of domain 00 fb IXFR record type 00 01 INternet class and then ends there, with NO ttl, rdlength, nor rdata. 4) followed by next label length, label ... etc with rrtype, class, ttl, rdlength, rdata and so on. This odd OPT, bytes I don't know, partial/broken IXFR record, may be repeated a few times. I assume these were interspersed where IXFR's SOA records should be. I couldn't find an RFC that suggested using interspersed OPT nor IXFR records. I find it odd that OPT record is in my ANSWER section. I find it odd that the IXFR record is incomplete. And I don't know what the other bytes are in-between. This recognizable to anyone? The IXFR works fine as seen with dig or when I use named as my secondary but I assume the named is ignoring the junk parts too.

8 měsíců, 3 týdny

mod-onlinesign: extra DNSKEY causes double signatures

by Peter Thomassen

Hi, Consider a zonefile with @ DNSKEY 257 3 13 ZAtZvaK2/uVw+LG2AA12Dt/ZZ+YN0IF3pFwjfBp8Jd2DXjVU0cdxfpkY StUdbFu24Js6T5uROHo8lSG9rhgduw== and configuration zone: - domain: example.com storage: /config/ file: example.com.zone module: mod-onlinesign -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525

9 měsíců, 1 týden

Dynamic update fails after zone creation via catalog

by Daniel Gröber

Hi Knots, I use catalog zones to sync the set of zones my (hidden)master and slaves handle. I'm trying to stop messing with zone files on my master, instead switching exclusively to nsupdate (along with Tony Finch's nsdiff). In my testing it seems updating the zone after adding it via a catalog is not possible: $ knotc zone-status dxld.at [dxld.at.] role: master | serial: - | catalog: dxld.catalog. | re-sign: +9D15h6m14s Yet the update fails: $ knsupdate -y $SECRET <<EOF > server ns0.dxld.at. > zone dxld.at. > add dxld.at. 3600 IN SOA ns0.dxld.at. hostmaster.dxld.at. 1 2m 5m 1w 5m > send update failed: SERVFAIL Nothing is logged with `logging: any: debug` except a "ACL, allowed, action update". As soon as I create the zone on the server with zone{-begin,-set,-commit} it starts working ofc. I guess this is just not supported, but is there a good reason? I would find it quite convenient to do all my DNS ops over port 53 without touching ssh ;-) Thanks, --Daniel

9 měsíců, 3 týdny

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users