- knot-dns-users - lists.nic.cz

by JCA

I have to integrate Knot in framework which will be testing for the presence of a running instance of the Knot daemon by means of 'knotc status'. This works fine, once knotd has loaded all the zones. However, when launching it there will be a window of opportunity during which 'knotc status' will fail, despite the fact that knotd is already running, but still loading its zones. Two questions: 1. Is this a correct description, or am I missing something here? 2. If it is right, is there a way, with the concourse of KNOT tools, to find out whether knotd is already running or still loading zones? I guess that, if it is a matter of just verifying that knotd is running, using the 'ps' command would be simpler. I wonder, however, whether it can be done with KNOT tools alone.

6 let, 2 měsíce

2
2
0 0

Knot DNS 2.7.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.7! This version backports some relevant fixes and improvements from 2.8.1. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.7.7/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.7.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.7.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 2 měsíce

1
0
0 0

Weighted records

by Conrad Hoffmann

Hi there! At work, we make use something often referred to as "weighted records", a feature offered by many managed DNS vendors. We use it to implement e.g. a canary environment, where we test changes on a small portion of production traffic. I played around with knot-dns for a bit (quite impressed), and figured it might be nice to implement such a feature for it. Turns out, the code is so amazing that if you abuse the infrastructure of the geoip module, it only takes an hour (very impressed). If you are interested in trying it, read on further below, but just to state my intention: I was wondering if such a feature would be of interest at all? I realize the geoip module may not be the appropriate for such an implementation, consider this merely a demo of sorts. So here goes nothing: 1. apply attached patch 2. config file snippet: mod-geoip: - id: test config-file: /etc/knot/test.conf ttl: 600 mode: weighted zone: - domain: example.com. file: "/var/lib/knot/example.com.zone" module: mod-geoip/test 3. /etc/knot/test.conf: lb.example.com: - weight: 10 CNAME: www1.example.com. - weight: 5 CNAME: www2.example.com. Results in this: conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig @192.168.1.242 A lb.example.com +short; done | sort | uniq -c 68 www1.example.com. 32 www2.example.com. conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig @192.168.1.242 A lb.example.com +short; done | sort | uniq -c 72 www1.example.com. 28 www2.example.com. conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig @192.168.1.242 A lb.example.com +short; done | sort | uniq -c 66 www1.example.com. 34 www2.example.com. You get the idea. Anyways, any thoughts and feedback would be greatly appreciated. Thanks a lot, Conrad

6 let, 2 měsíce

2
5
0 0

Zone breaks after update to 2.8.0

by Simon Fehlmann

Hi @all I was trying to migrate knot to a new server with Ubuntu 18.04 and knot 2.8.0. I managed this by just copying the content of /var/lib/knot/* from the old to the new server. One of my domains threw an error when starting knot: knotd[5186]: error: [<zone>] zone event 'load' failed (malformed data) keymgr throws the same error. I dumped the data out of the 2.7.6 installation with mdb_dump and imported it into the 2.8.0 installation, which did not help. I then uninstalled 2.8.0 on the new server and installed 2.7.6, migrated data from the old server with the same procedure and it worked, no errors. Just out of curiosity I upgraded then the new server from 2.7.6 to 2.8.0 to see what will happen: It was the exact same behaviour, the zone couldn't load. How can I proceed here? There is obviously something wrong that the update breaks the loading of the zone. Is this on my end or a bug in knot? Thanks Simon

6 let, 2 měsíce

4
6
0 0

Knot DNS 2.8.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.1! This version fixes various DNSSEC-related issues. It's recommended to update from 2.8.0. Special thanks go to Niels Haarbo and Tuomo Soini for their help with debugging! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.1/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 2 měsíce

1
0
0 0

Knot-DNS unused cores

by Sergey Petrov

I perfoms benchmarks with knot-dns as a authoritative server and dnsperf as a workload client. Knot server has 32 cores. Interrupts from 10Gb network card are spreaded across all 32 cores. Knot configured with 64 udp-workers. Each knot thread assigned to one core. So there are at least two knot threads assigned to one core. Then i start dnsperf with command ./dnsperf -s 10.0.0.4 -d out -n 20 -c 103 -T 64 -t 500 -S 1 -q 1000 -D htop on knot server shows 3-4 cores completly unused. Then i restart dnsperf unused cores are changes. That is the reason for unused core?

6 let, 2 měsíce

3
10
0 0

knot UDP or TCP perfermance

by Champion Xie

When we try to use the root zone file to load to verify the UDP or TCP perfermance of knot the result TCP performance is greater than UDP performance -- Best Regards!! champion_xie

6 let, 2 měsíce

2
1
0 0

DNSSEC re-sign failed (invalid parameter)

by Thomas E.

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

6 let, 2 měsíce

3
2
0 0

KSK Rollover - Lab Policy For Testing

by 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

6 let, 3 měsíce

6
17
0 0

running knot-resolver with only kresd-tls.socket

by Daniel Lublin

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?

6 let, 3 měsíce

2
1
0 0

Security changes in our Debian repositories

by Vladimír Čunát

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

6 let, 3 měsíce

2
2
0 0

Knot DNS 2.8.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.0! This version is full of new features and improvements. Please, look at the changelog. Also note that today Knot DNS 2.6 reached its End-of-life and in the following days the official repositories will be upgraded to reflect currently supported versions (current stable -> 2.8.0, previous stable -> 2.7.6). Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.0/NEWS Benchmark: https://www.knot-dns.cz/benchmark/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.0.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 3 měsíce

3
4
0 0

konvert Knot DNS sigantures certs to BIND format.

by Milan Jeskynka Kazatel

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

6 let, 3 měsíce

3
4
0 0

why is kdig different to dig?

by Arsen STASIC

Hi, I'm not sure if it was already discussed on this list. Why is BIND's dig getting a AD flag and kdig not? Obviously sends dig the AD flag by default, but why have you decided this way? dig +noall +comments @dotns1.aco.net univie.ac.at soa +qr ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52963 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d2171ad4016ceb3d ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52963 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 kdig +noall +header @dotns1.aco.net univie.ac.at soa +qr ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 25583 ;; Flags: rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 25583 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 cheers, -arsen

6 let, 3 měsíce

5
7
0 0

Re: [knot-dns-users] knot have chroot or setuid features?

by Daniel Salzman

Hi, Knot DNS doesn't call chroot. As for setuid, look at the source https://gitlab.labs.nic.cz/knot/knot-dns/blob/master/src/knot/common/proces… Another interesting feature is https://gitlab.labs.nic.cz/knot/knot-dns/merge_requests/864 Daniel On 2/21/19 9:50 AM, Champion Xie wrote: > > > -- > Best Regards!! > champion_xie

6 let, 4 měsíce

1
0
0 0

DNSSEC On-slave signing

by Milan Jeskynka 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

6 let, 4 měsíce

3
4
0 0

Migration from djbdns/tinydns to knot-dns.cz

by Frank Matthieß

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

6 let, 5 měsíců

2
3
0 0

Knot DNS 2.7.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.6! This version mainly fixes a very old bug relating pending zone events upon server reload or configuration commit. If you don't use zone journal, please check if it exists and possibly drop it. It can be a consequence of a small regression introduced in the previous version. I'm sorry for that! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.6 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.6.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.6.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

6 let, 5 měsíců

1
0
0 0

zonefile-load: difference

by Volker Janzen

Hi, I want to use Ansible to deploy zone files to my Knot signer (hidden master). The zone files should be generated from the Ansible playbook data and will not contain any DNSSEC related information, just SOA, NS, A, AAAA, TXT and MX records. I'd like to use Knot DNSSEC auto-signing. I can stop the Knot process before deploying new zone files. I use zonefile-load: difference in this case, as of the DNSKEY / CDNSKEY / CDS data should not be replaced with something new. Should this work for me, or is there anything I miss or is there even a better option? Kind regards, Volker

6 let, 5 měsíců

2
1
0 0

Knot DNS 2.7.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.5! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.5 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.5.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

6 let, 5 měsíců

2
1
0 0

knot group in a FreeBSD jail -- Permission Denied to Knotc and Python API

by Rick van Rein

Hi, I'm working on a registry for +31 ENUM, using Knot DNS 2.6.8. The intention is to trigger the Python API from PostgreSQL database views. The postgres user, though added to the knot group and granted rw- on all of /var/db/knot/* and the knotd socket, cannot do thinkgs like conf-read through the Python API or knotc. This is where root and the postgres user diverge: 84630 knotc CALL open(0x7fffffffe100,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>) 84630 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)" 84630 knotc RET open 6 84630 knotc CALL fstat(0x6,0x7fffffffe068) 84630 knotc STRU struct stat {dev=4261341516, ino=125942, mode=0100660, nlink=1, uid=0, gid=0, rdev=4294967295, atime=1545172776.416579000, mtime=1545182138.348328000, ctime=1545182138.348328000, birthtime=1545172776.416478000, size=16, blksize=4096, blocks=2, flags=0x800 } That's root. uid=0 and gid=0 for the /tmp/SENDMDB... file. But now: 84649 knotc CALL open(0x7fffffffe0f0,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>) 84649 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)" 84649 knotc RET open -1 errno 13 Permission denied That's user postgres, even though it is in the knot group. It seems to see the file but have no access, probably due to uid=0, gid=0. Note that matching name. --> What is this file it is trying to open, and is it always mapped to uid=0,gid=0, even if the user running "knotc conf-read" is not root? Could this be a FreeBSD things, or a jail thing? Any advise is welcome! Thanks! -Rick

6 let, 5 měsíců

2
1
0 0

Re: [knot-dns-users] knot group in a FreeBSD jail -- Permission Denied to Knotc and Python API

by Daniel Salzman

I don't think the Makefile is wrong. If you call knotc with an explicit control socket specification, no configuration file is loaded because it's not needed. So there is an issue with the configuration access. But I don't understand why knotd is not affected? You could also test using configuration database. Daniel On 12/21/18 2:44 PM, Rick van Rein wrote: > Hi Daniel, > >> I guess it relates to a temporary confdb, which is created for storing configuration loaded from >> a config file and removed upon. Could you try calling knotc with explicit socket parameter (knotc -s ...)? > > Yes, that solved it. > > The default socket path is @run_dir@/knot.sock, and the ports tree > configures --with-rundir=/var/run/knot but, according to > https://github.com/freebsd/freebsd-ports/blob/master/dns/knot2/Makefile#L32… > it is under defined variables. I will ask Leo if this might need > correction. > > Thanks! > -Rick >

6 let, 6 měsíců

1
0
0 0

Question on KSK rollover

by Volker Janzen

Hi all, one of my zones made a ZSK rollover yesterday. I had an some recursive resolvers validation errors at different times. This is the log output from knot of the rollover: Dec 6 17:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, ZSK rollover started Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public, active Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T18:16:49 Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1543943808 -> 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@45727: started, serial 1543943808 -> 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@45727: finished, 0.00 seconds, 1 messages, 1329 bytes Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public, active Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T19:16:49 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1544113009 -> 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@53131: started, serial 1544113009 -> 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@53131: finished, 0.00 seconds, 1 messages, 43889 bytes Dec 6 18:16:50 a knotd[9924]: info: [voja.de.] AXFR, outgoing, 10.10.10.10@59417: started, serial 1544116609 Dec 6 18:16:50 a knotd[9924]: info: [voja.de.] AXFR, outgoing, 10.10.10.10@59417: finished, 0.00 seconds, 1 messages, 28054 bytes Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public, active Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-07T15:16:48 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1544116609 -> 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@55161: started, serial 1544116609 -> 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@55161: finished, 0.00 seconds, 1 messages, 1329 bytes 10.10.10.10 is the (anonymized) IP of the distribution server, which is a Bind server. The actual authorative nameservers get the zone from Bind with IFXR or AXFR. AXFR is used for distribution to a anycast nameserver pair. When looking at the ZSK rollover timing, I notice that after two hours Knot stopped signing with the old ZSK. Does this make sense? The last event before the rollover has been this resining: Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public, active Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T17:16:48 Is it possible that this is an issue with a propagation-delay that is too low (default value applies). Regards Volker

6 let, 6 měsíců

2
3
0 0

Re: [knot-dns-users] Key sizes with ECDSA

by Full Name

OK, thanks. Just making sure I was not missing something obvious. -----Original Message----- From: "libor.peltan" [libor.peltan(a)nic.cz] Date: 11/29/2018 04:33 AM To: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Key sizes with ECDSA Hi Full Name, indeed, this is not possible. The ECC and EDD algorithm families always stick to one key size for any algorithm. You can't have your KSK and ZSK with different algorithms. On the other hand, this is no big deal. Those algorithms are considered safe enough even with small keys, so you can choose just e.g. ECDSA256 and profit from having small signatures. You can also think of using single-type signing scheme. BR, Libor Dne 28.11.18 v 22:58 Full Name napsal(a): > A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct? -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

6 let, 6 měsíců

1
0
0 0

Key sizes with ECDSA

by Full Name

A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct?

6 let, 6 měsíců

2
1
0 0

Re: [knot-dns-users] Problem to import key material of softhsm into knot

by mark.karpilovskij＠nic.cz

Hi Christian, I am glad to hear that. Let us know if you have any other issues. Best regards, Mark On 2018-11-27 14:04, Christian Petrasch wrote: > Hello Mark, > > I was able to sign with Knot and SoftHSM. I switched to an actual > version of gnutls and recompiled Knot. > > Thank you very much for your good support > > best regards > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Datum: 26.11.2018 16:22 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > also, did you build Knot manually or did you use a package? What is > your current GnuTLS version? It should be at least 3.4.6 for the HSM > to work, at least according to our documentation. > > BR, > > Mark > > On 26. 11. 18 16:09, Mark Karpilovskij wrote: > > Hi Christian, > > I have verified that it is indeed necessary for Knot to use full > length key IDs with PKCS #11, so make sure you do that. Other than > that, I am quite puzzled by the "FAILED TO INITIALIZE KASP (NOT > IMPLEMENTED)" error that you are getting and so far I have been unable > to reproduce it. I will spend some more time on it. Which version of > CentOS are you using? Meanwhile, see if both setting correct policy > configuration and using full length key IDs will help you. > > Best regards, > > Mark > > On 26. 11. 18 12:31, Christian Petrasch wrote: > Hi Mark, > > thanks a lot for you help.. > > I added the keystore to my config.. but I_m getting another error > now.. > > # See knot.conf(5) manual page for documentation. > > server: > listen: [ 127.0.0.1@53, ::1@53 ] > > keystore: > > # KSK > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > # ZSK > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > keystore: a1b1 > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > zone: > - domain: example.com > dnssec-signing: on > dnssec-policy: manual > zonefile-load: difference > file: example.com.zone > storage: /etc/knot/ > > log: > - target: syslog > any: debug > > ### > > [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. > import-pkcs11 a1b1 algorithm=RSASHA256 size=2048 ksk=no > created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y > Failed to initialize KASP (not implemented) > > I tried with the -d parameter as well.. but i got: > > keymgr -d /var/lib/knot/keys/ example.com. import-pkcs11 a1b1 > algorithm=RSASHA256 size=2048 ksk=no created=20181126090000 > publish=20181126090000 retire=+10mo remove=+1y > Error (not exists) > > I read from former knot versions about the "keymgr init" command, but > it is not implemented anymore.. > > Do you have another idea whats going wrong.. ? > > Thanks a lot for your great help :) > > best regards > > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Kopie: knot-dns-users(a)lists.nic.cz > Datum: 26.11.2018 11:56 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > I have checked out your Knot configuration, and I suspect that the > issue might be a missing keystore option in the policy section of your > configuration. Try specifying the ID of the PKCS11 keystore in the > policy section as follows: > > keystore: > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > KEYSTORE: A1A1 > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > Let us know if this helps. > > Best regards, > > Mark > > On 26. 11. 18 9:49, Christian Petrasch wrote: > Hi @ all, > > we are testing with softhsm 2.5 and KNOT 2.7.4... > > I try to import the keys inside softhsm into keymgr to sign with this > a example zone. > > The keymaterial is shown via pkcs11-tool: > > [root@centos-test2 ~]# pkcs11-tool --login --list-objects --module > /usr/local/lib/softhsm/libsofthsm2.so > > Using slot 0 with a present token (0x285d1c08) > Logging in to "testKSK_1". > Please enter User PIN: > Private Key Object; RSA > label: testKSK_1 > ID: a1a1 > Usage: decrypt, sign, unwrap > Public Key Object; RSA 1024 bits > label: testZSK_1 > ID: a1b1 > Usage: encrypt, verify, wrap > Private Key Object; RSA > label: testZSK_1 > ID: a1b1 > Usage: decrypt, sign, unwrap > Public Key Object; RSA 2048 bits > label: testKSK_1 > ID: a1a1 > Usage: encrypt, verify, wrap > > ###### > > The KNOT config is : > > [root@centos-test2 ~]# cat /etc/knot/knot.conf > # See knot.conf(5) manual page for documentation. > > server: > listen: [ 127.0.0.1@53, ::1@53 ] > > keystore: > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > zone: > - domain: example.com > dnssec-signing: on > dnssec-policy: manual > zonefile-load: difference > file: example.com.zone > storage: /etc/knot/ > > log: > - target: syslog > any: debug > > ################### > > And if I try to import the key into keymgr i run the command: > > [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. > import-pkcs11 a1a1 algorithm=RSASHA256 size=2048 ksk=yes > created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y > Error (not exists) > > ### > > I don't know how I can fix this.. maybe anybody can help me ? The > documentation of KNOT is very good.. but at this point it is a little > bit insufficient. Does anybody has examples for this ? > > Thanks a lot in advance for the help.. > > best regards > > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main

6 let, 6 měsíců

1
0
0 0

Problem to import key material of softhsm into knot

by Christian Petrasch

Hi @ all, we are testing with softhsm 2.5 and KNOT 2.7.4... I try to import the keys inside softhsm into keymgr to sign with this a example zone. The keymaterial is shown via pkcs11-tool: [root@centos-test2 ~]# pkcs11-tool --login --list-objects --module /usr/local/lib/softhsm/libsofthsm2.so Using slot 0 with a present token (0x285d1c08) Logging in to "testKSK_1". Please enter User PIN: Private Key Object; RSA label: testKSK_1 ID: a1a1 Usage: decrypt, sign, unwrap Public Key Object; RSA 1024 bits label: testZSK_1 ID: a1b1 Usage: encrypt, verify, wrap Private Key Object; RSA label: testZSK_1 ID: a1b1 Usage: decrypt, sign, unwrap Public Key Object; RSA 2048 bits label: testKSK_1 ID: a1a1 Usage: encrypt, verify, wrap ###### The KNOT config is : [root@centos-test2 ~]# cat /etc/knot/knot.conf # See knot.conf(5) manual page for documentation. server: listen: [ 127.0.0.1@53, ::1@53 ] keystore: - id: a1a1 backend: pkcs11 config: "pkcs11:token=testKSK_1;pin-value=5678 /usr/local/lib/softhsm/libsofthsm2.so" - id: a1b1 backend: pkcs11 config: "pkcs11:token=testKSK_1;pin-value=5678 /usr/local/lib/softhsm/libsofthsm2.so" policy: - id: manual manual: on nsec3: on nsec3-iterations: 16 nsec3-opt-out: on nsec3-salt-length: 8 zone: - domain: example.com dnssec-signing: on dnssec-policy: manual zonefile-load: difference file: example.com.zone storage: /etc/knot/ log: - target: syslog any: debug ################### And if I try to import the key into keymgr i run the command: [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. import-pkcs11 a1a1 algorithm=RSASHA256 size=2048 ksk=yes created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y Error (not exists) ### I don't know how I can fix this.. maybe anybody can help me ? The documentation of KNOT is very good.. but at this point it is a little bit insufficient. Does anybody has examples for this ? Thanks a lot in advance for the help.. best regards -- Christian Petrasch Product Owner Zone Creation & Signing IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: petrasch(a)denic.de http://www.denic.de PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E 8841 549B E0AE Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Thomas Keller Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main

6 let, 6 měsíců

3
5
0 0

mod-onlinesign in master-slave environment

by Oto Stefan

Hello, first of all I would like to express many thanks to the CZ.NIC DNS team for an amazing piece of software which the KnotDNS in my view surely is. Well, to my question. I run two instances of knot 2.6.9 in the master-slave configuration which serve a couple of zones. The zones are DNSSEC signed at master with an automated key management. This works excellent even with the KSK rotation (I am under .cz TLD). However, I also have a subdomain (i.e., 3rd order domain) with synthesized records. The only way to allow DNSSEC for it I was able to find is: - using mod-onlinesign on both the master and slave, - generating a key externally (with bind-utils) and importing it into KASP on both servers, - configuring manual key policy, - adding the appropriate DS record into the parent zone. This seems to work fine, all the validation tests pass. The question is: Is there a better way to achieve the goal (especially with new features like automated key rotation in online signing of the 2.7 version in mind) or what is the recommended practice in a similar situation? Thanks in advance for any suggestion or advice, Have a nice day, Oto

6 let, 6 měsíců

4
4
0 0

Define SALT String for NSEC3

by Christian Petrasch

Hi, is there any knot-dns configuration parameter to define the SALT string for NSEC3 ? I have : nsec3: BOOL nsec3-iterations: INT nsec3-opt-out: BOOL nsec3-salt-length: INT but nothing to configure the string.. Does anybody has an idea ? Any help would be really appreciated.. thanks a lot best regards -- Christian Petrasch Product Owner Zone Creation & Signing IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: petrasch(a)denic.de http://www.denic.de PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E 8841 549B E0AE Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Thomas Keller Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main

6 let, 6 měsíců

4
6
0 0

Knot DNS 2.7.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.4! This version mainly fixes DNSSEC-related issues. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.4 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.4.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

6 let, 7 měsíců

1
0
0 0

Re: [knot-dns-users] Dealing with limited capacity key storage

by Full Name

Feedback much appreciated. Thanks. -----Original Message----- From: "" [daniel.salzman(a)nic.cz] Date: 11/08/2018 03:43 AM To: "Full Name" <nuncestbibendum(a)excite.com> CC: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Dealing with limited capacity key storage On 2018-11-08 01:04, Full Name wrote: > By default, Knot will use the local file system as its key storage. I > believe that, when using the SoftHSM backend, the same is true. For > most practical purposes, the implication is that the key storage has > an unlimited capacity for keys. Now when using an actual HSM, that is > not true - most HSMs will, in general, have a relatively modest keys > storage capacity, especially when compared to that of a local > filesystem. > Yes, that is correct. > Does Knot have with capabilities to deal with such situations? If > I need to have 150 keys in my key storage, but my key storage can't > hold more than 100, how does Knot deal with this? Conceptually, one > only has to wrap the keys in the HSM appropriately and dump then to > disk - where they will remain inaccessible to anybody but the HSM. > After this, one can generate (or unwrap) more keys, and use them as > necessary. Is this something that Knot can already do? The only solution with Knot DNS is using shared keys https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#ksk-shared. Also Single-Type Signing Scheme could help to reduce the number of keys https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#single-type-signing. Daniel

6 let, 7 měsíců

1
0
0 0

python-libknot: How to do "zone-set" command to add resource records

by Frank Matthieß

Hi, i work on a python library based on python/libknot/control.py. I'm at the point to add/remove resource record to a configured zone. I have tried a lot, but got no positive result: "invalid parameter (data: COMMAND = b'zone-set', ERROR = b'invalid parameter', ZONE = b'domain.tld.', OWNER = b'www.domain.tld.', TYPE = b'A', DATA = b'127.0.0.1')" The full test script debug output: DEBUG: _openSocket DEBUG: _zone-begin DEBUG: _cmd: {'cmd': 'zone-begin'} DEBUG: _cmd: {'cmd': 'zone-set', 'zone': 'domain.tld.', 'owner': 'www.domain.tld.', 'rtype': 'A', 'data': '127.0.0.1'} DEBUG: _zone-abort DEBUG: _cmd: {'cmd': 'zone-abort'} invalid parameter (data: COMMAND = b'zone-set', ERROR = b'invalid parameter', ZONE = b'domain.tld.', OWNER = b'www.domain.tld.', TYPE = b'A', DATA = b'127.0.0.1') DEBUG: _zone-begin DEBUG: _cmd: {'cmd': 'zone-begin'} DEBUG: _cmd: {'cmd': 'zone-get', 'zone': 'domain.tld.', 'owner': 'ns1.domain.tld.'} DEBUG: _zone-commit DEBUG: _cmd: {'cmd': 'zone-commit'} resp: { "domain.tld.": { "ns1.domain.tld.": { "A": { "ttl": "86400", "data": [ "192.168.120.211" ] } } } } DEBUG: _closeSocket The "_cmd" call uses libknot.control.send_block[1] internally, the following "{…}" held the function parameters. [1] https://gitlab.labs.nic.cz/knot/knot-dns/blob/master/python/libknot/control… It needs some time to discover "owner" as the query filter for "zone-get", which wasn't that obvious. Now I'm wondering how set the parameter, for adding a resource record to a zone. - frank -- Frank Matthieß Stapenhorster Straße 42b, DE 33615 Bielefeld Mail: frank.matthiess(a)virtion.de GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1

6 let, 7 měsíců

2
1
0 0

Dealing with limited capacity key storage

by Full Name

By default, Knot will use the local file system as its key storage. I believe that, when using the SoftHSM backend, the same is true. For most practical purposes, the implication is that the key storage has an unlimited capacity for keys. Now when using an actual HSM, that is not true - most HSMs will, in general, have a relatively modest keys storage capacity, especially when compared to that of a local filesystem. Does Knot have with capabilities to deal with such situations? If I need to have 150 keys in my key storage, but my key storage can't hold more than 100, how does Knot deal with this? Conceptually, one only has to wrap the keys in the HSM appropriately and dump then to disk - where they will remain inaccessible to anybody but the HSM. After this, one can generate (or unwrap) more keys, and use them as necessary. Is this something that Knot can already do?

6 let, 7 měsíců

2
1
0 0

Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface

by Full Name

I found out what the heck it was, at last. First, softhsm was correctly initialized - no problem there. The issue was that knot.conf file was the following ( the relevant portions alone): keystore: - id: SoftHSM backend: pkcs11 config: "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=1eb6899f1f278686;token=SoftHSMToken;pin-value=SoftHSMPIN /usr/lib/softhsm/libsofthsm2.so" policy: - id: manual manual: on The policy section was missing a keystore entry, which caused Knot to fall back to the default key store. After I added keystore: SoftHSM everything worked as expected. -----Original Message----- From: "" [daniel.salzman(a)nic.cz] Date: 11/07/2018 08:43 AM To: "Full Name" <nuncestbibendum(a)excite.com> CC: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface On 2018-11-05 17:47, Full Name wrote: > I am sorry; I made a mistake when pasting the knot.conf contents here > - I am using the module path all right, and it makes no difference. In > fact, the issue seems to be with the knot.conf parser - be it because > I am doing things incorrectly myself, or because it is broken. I have > noticed the same in Knot 2.6.9 and 2.7.3. > So what is your exact configuration of the keystore? > Can anyone throw some light on this? What else has one got to do to > get Knot to use the PKCS #11 interface for the key store? I have the > necessary library (softHSM) plus the correct data in knot.conf. But > the keymgr function is not using the PKCS #11 interface. What am I > missing? > I think you have to learn how to initialize a PKCS #11 token first. Try something like: export SOFTHSM2_CONF=/path/to//softhsm.conf softhsm2-util --init-token --slot=0 --label="knot" --pin=1234 --so-pin=12345 --module=/usr/lib/softhsm/libsofthsm2.so and follow https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#config ... > I provided some debugging traces in a separate message to > illustrate the issue. I'll be happy to furnish more data, if somebody > knowledgeable on the Knot internals lets me know what traces to > provide. I really need to be able to get Knot to use the PKCS #11 > interface. > > > > -----Original Message----- > From: "" [daniel.salzman(a)nic.cz] > Date: 11/02/2018 05:39 AM > To: "Full Name" <nuncestbibendum(a)excite.com> > CC: knot-dns-users(a)lists.nic.cz > Subject: Re: [knot-dns-users] Knot refusing to use the PKCS #11 > interface > > Hello Full Name, > > The pkcs11 keystore configuration should have the form of > "<pkcs11-url> <module-path>". I will improve the documentation. > > Daniel > > On 2018-11-01 18:04, Full Name wrote: >> I have a knot.conf file with the following keystore section: >> >> keystore: >> - id: TheBackend >> backend: pkcs11 >> config: >> "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System >> Trust" >> >> where the value assigned to the config keyword is obtained from the >> output from the GnuTLS p11tool command: >> >> $ p11tool --list-tokens >> Token 0: >> URL: >> pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust >> Label: System Trust >> Type: Trust module >> Flags: uPIN uninitialized >> Manufacturer: PKCS#11 Kit >> Model: p11-kit-trust >> Serial: 1 >> Module: p11-kit-trust.so >> >> Also in knot.conf I have >> >> policy: >> - id: manual >> manual: on >> >> zone: >> - domain: example.com >> storage: /var/lib/knot/zones/ >> file: example.com.zone >> dnssec-signing: on >> dnssec-policy: manual >> >> With all this in place, I launched the following from the CLI: >> >> # keymgr example.com. generate algorithm=ECDSAP256SHA256 >> >> This does not seem to be using the PKCS #11 library, as instructed in >> knot.conf. I debugged the command above and noticed that, at some >> before the signing operation itself is addressed, the keystore_load >> function from the Knot code base is invoked. This function takes >> several arguments, the second of which is a backend identifier. >> According to the keystore entry in knot.conf, this should be the PKCS >> #11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the >> debugger is that the backend argument is, in fact, >> KEYSTORE_BACKEND_PEM. >> >> Even more intriguing (to somebody unfamiliar with the internal >> workings of Knot, at least) is that, before keystore_load is invoked, >> the check_keystore function is invoked and it evaluates the following >> conditional: >> >> if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 && >> conf_str(&config) == NULL) >> >> This conditional clearly succeeds - i.e. at that point the backend has >> been correctly identified as PKCS #11. But, like I said above, when >> keystore_load gets called later on, such is not the case any longer. >> >> Any idea as to what is going on here? Why is PKCS #11 not being used? >> In the config string above in knot.conf I tried replacing %23 and %20 >> with # and the space character, respectively. It made no difference. >> This all is happening with Knot 2.7.3.

6 let, 7 měsíců

1
0
0 0

Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface

by Full Name

I am sorry; I made a mistake when pasting the knot.conf contents here - I am using the module path all right, and it makes no difference. In fact, the issue seems to be with the knot.conf parser - be it because I am doing things incorrectly myself, or because it is broken. I have noticed the same in Knot 2.6.9 and 2.7.3. Can anyone throw some light on this? What else has one got to do to get Knot to use the PKCS #11 interface for the key store? I have the necessary library (softHSM) plus the correct data in knot.conf. But the keymgr function is not using the PKCS #11 interface. What am I missing? I provided some debugging traces in a separate message to illustrate the issue. I'll be happy to furnish more data, if somebody knowledgeable on the Knot internals lets me know what traces to provide. I really need to be able to get Knot to use the PKCS #11 interface. -----Original Message----- From: "" [daniel.salzman(a)nic.cz] Date: 11/02/2018 05:39 AM To: "Full Name" <nuncestbibendum(a)excite.com> CC: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Knot refusing to use the PKCS #11 interface Hello Full Name, The pkcs11 keystore configuration should have the form of "<pkcs11-url> <module-path>". I will improve the documentation. Daniel On 2018-11-01 18:04, Full Name wrote: > I have a knot.conf file with the following keystore section: > > keystore: > - id: TheBackend > backend: pkcs11 > config: > "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System > Trust" > > where the value assigned to the config keyword is obtained from the > output from the GnuTLS p11tool command: > > $ p11tool --list-tokens > Token 0: > URL: > pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust > Label: System Trust > Type: Trust module > Flags: uPIN uninitialized > Manufacturer: PKCS#11 Kit > Model: p11-kit-trust > Serial: 1 > Module: p11-kit-trust.so > > Also in knot.conf I have > > policy: > - id: manual > manual: on > > zone: > - domain: example.com > storage: /var/lib/knot/zones/ > file: example.com.zone > dnssec-signing: on > dnssec-policy: manual > > With all this in place, I launched the following from the CLI: > > # keymgr example.com. generate algorithm=ECDSAP256SHA256 > > This does not seem to be using the PKCS #11 library, as instructed in > knot.conf. I debugged the command above and noticed that, at some > before the signing operation itself is addressed, the keystore_load > function from the Knot code base is invoked. This function takes > several arguments, the second of which is a backend identifier. > According to the keystore entry in knot.conf, this should be the PKCS > #11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the > debugger is that the backend argument is, in fact, > KEYSTORE_BACKEND_PEM. > > Even more intriguing (to somebody unfamiliar with the internal > workings of Knot, at least) is that, before keystore_load is invoked, > the check_keystore function is invoked and it evaluates the following > conditional: > > if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 && > conf_str(&config) == NULL) > > This conditional clearly succeeds - i.e. at that point the backend has > been correctly identified as PKCS #11. But, like I said above, when > keystore_load gets called later on, such is not the case any longer. > > Any idea as to what is going on here? Why is PKCS #11 not being used? > In the config string above in knot.conf I tried replacing %23 and %20 > with # and the space character, respectively. It made no difference. > This all is happening with Knot 2.7.3.

6 let, 7 měsíců

2
1
0 0

Python libknot: Failed to load libknot.so, patch attached

by Frank Matthieß

Hi, i have the issue, that the example wont work, because there ist no "libknot.so" on my system: root@f-dns4:~# ldconfig -v 2>/dev/null | grep libknot libknot.so.8 -> libknot.so.8.0.0 root@f-dns4:~# lsb_release -a; dpkg-query -W knot No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic root@f-dns4:~# dpkg-query -W knot knot 2.7.3-1~ubuntu18.04.1ppa2 I has made a patch for that, with a search order, if no path is given. Hopefully this help to solve this issue. Greetings Frank -- Frank Matthieß Stapenhorster Straße 42b, DE 33615 Bielefeld Mail: frank.matthiess(a)virtion.de GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1

6 let, 7 měsíců

2
1
0 0

Python library behaviours

by Rick van Rein

Hi, I'm trying to spin a nice transaction model around libknot, intended for better automation, as attached. I'm running into problems. First and foremost, a lack of understanding what should go into what fields when doing other commands than in the "stats" demos. Are there more advanced explanations of what goes into what fields? I tried looking into knotc, but it is rather long. Perhaps there is a log somewhere with the stuff going into knotd? Secondly, the model by which transactions abort is not always logical. Like a commit() that fails but does not turn into an abort() when semantic errors are found. I will run zone-check beforehand, to ensure that this does not happen. Thirdly, I found that the library freezes when supplied with unknown commands or apparently funny data... >>> import knotcontrol >>> kc = knotcontrol.KnotControl() >>> kc = knotcontrol.KnotControl () >>> kc.knot (cmd='stats') KnotControl send {'cmd': 'stats'} KnotControl recv {'server': {'zone-count': ['1']}} {'server': {'zone-count': ['1']}} >>> kc.knot (cmd='zone-stats',item='vanrein.org') KnotControl send {'item': 'vanrein.org', 'cmd': 'zone-stats'} KnotControl recv {} {} >>> kc.knot (cmd='zone-recv',item='vanrein.org') KnotControl send {'item': 'vanrein.org', 'cmd': 'zone-recv'} ...and at this point it freezes, even to ^C -- before and after this sequence, "kdig @localhost vanrein.org soa" worked to query the zone in Knot DNS. Sorry to be testing this early :-S but I'm eager to use it this way. -Rick

6 let, 7 měsíců

2
2
0 0

zone delagation format?

by Milan Sýkora

Hello, could you please send me a short guide how to delegate a zone subnet (class) to different NS. I have a zone i.e. 0.10.in-addr.arpa.zone where I would like to delegate a part of the zone 10.0.0.104/29 (255.255. 255.248) to different NS. It includes 8 IP addresses (10.0.0.104, 10.0. 0.105, 10.0.0.106 .... 10.0.0.111) then I create a record in the mentioned zone like 104/29.0.0.10.in-addr.arpa. 300 NS my.test.server. I tried to understand the syntax in RFC 2317 (https://tools.ietf.org/html/ rfc2317) but it seems to be wrongly implemented from my side. When I tried to "dig" records I have to ask next IP address in the row not like dig -x 10.0.0.105 bud like dig -x 10.0.0.104/29.105 Many thanks for the clarification, best regards Milan.

6 let, 7 měsíců

3
4
0 0

Issue with set_timeout in the Python library

by Rick van Rein

Hi, I am following Daniel's advise > Consider controlling the server directly using our > python wrapper: in trying to get more transactional rigour through the Python library from Git. The library certainly is easier to integrate! But I think I hit upon a bug. The code def __init__ (self, socketpath='/var/run/knot/knot.sock'): """Connect to knotd """ self.ctl = None self.txn_conf = False self.txn_zone = set () self.txn_success = True self.ctl = libknot.control.KnotCtl () self.ctl.connect (socketpath) self.ctl.set_timeout (3600) seems to not set any timeout; it always cuts off after 5s sleep, and never after 4s sleep. This is true for the first command as well as later ones. Same when setting the timeout to 7200, so it's not a ms/s issue. This code is almost literally the same as in StatsServer, except that demo runs too fast to detect timeout problems. I ran into it when working interactively. Ideally, I would want to disable connection timeouts altogether, so it is possible to abort any open transactions upon whatever cause for termination there might be; this should benefit stability. -Rick

6 let, 7 měsíců

2
2
0 0

KnotDNS on FreeBSD 11.2

by Thomas Belian

Hello, I want to switch to KnotDNS on my private zone (bt909.de). I've installed the knot2 port as binary package within a FreeBSD jail. I configured my zones and zone transfer works fine, but KnotDNS didn't answer any query. I have a acl for the zone transfer, is there anything I need to do, that knot answers my queries? Knot is running, I found nothing in the logs, even the port ist open, but Knot just does nothing and my queries run into timeouts. I tried NSD in the same jail, which works fine, but I want to use KnotDNS. Regards, Thomas -- Thomas Belian; https://bt909.de

6 let, 7 měsíců

4
5
0 0

Knot refusing to use the PKCS #11 interface

by Full Name

I have a knot.conf file with the following keystore section: keystore: - id: TheBackend backend: pkcs11 config: "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System Trust" where the value assigned to the config keyword is obtained from the output from the GnuTLS p11tool command: $ p11tool --list-tokens Token 0: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust Label: System Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so Also in knot.conf I have policy: - id: manual manual: on zone: - domain: example.com storage: /var/lib/knot/zones/ file: example.com.zone dnssec-signing: on dnssec-policy: manual With all this in place, I launched the following from the CLI: # keymgr example.com. generate algorithm=ECDSAP256SHA256 This does not seem to be using the PKCS #11 library, as instructed in knot.conf. I debugged the command above and noticed that, at some before the signing operation itself is addressed, the keystore_load function from the Knot code base is invoked. This function takes several arguments, the second of which is a backend identifier. According to the keystore entry in knot.conf, this should be the PKCS #11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the debugger is that the backend argument is, in fact, KEYSTORE_BACKEND_PEM. Even more intriguing (to somebody unfamiliar with the internal workings of Knot, at least) is that, before keystore_load is invoked, the check_keystore function is invoked and it evaluates the following conditional: if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 && conf_str(&config) == NULL) This conditional clearly succeeds - i.e. at that point the backend has been correctly identified as PKCS #11. But, like I said above, when keystore_load gets called later on, such is not the case any longer. Any idea as to what is going on here? Why is PKCS #11 not being used? In the config string above in knot.conf I tried replacing %23 and %20 with # and the space character, respectively. It made no difference. This all is happening with Knot 2.7.3.

6 let, 7 měsíců

2
1
0 0

Knot refusing to use the PKCS #11 interface II

by Full Name

More info on this: The keymgr command invokes first the init_confile function. This results in the following backtrace: #0 conf_db_get (conf=0x6bfcc0, txn=0x7fffffffe1b0, key0=0x47b76a "\bkeystore", key1=0x47b761 "\abackend", id=0x6c6648 "TheBackend", id_len=11, data=0x7fffffffdf70) at knot/conf/confdb.c:704 #1 0x0000000000410018 in conf_rawid_get_txn (conf=0x6bfcc0, txn=0x7fffffffe1b0, key0_name=0x47b76a "\bkeystore", key1_name=0x47b761 "\abackend", id=0x6c6648 "TheBackend", id_len=11) at knot/conf/conf.c:78 #2 0x0000000000417f4a in check_keystore (args=0x7fffffffe090) at knot/conf/tools.c:268 #3 0x000000000041777d in conf_exec_callbacks (args=0x7fffffffe090) at knot/conf/tools.c:62 #4 0x000000000040ebaa in finalize_previous_section (conf=0x6bfcc0, txn=0x7fffffffe1b0, parser=0x6ed560, ctx=0x6c6620) at knot/conf/base.c:506 #5 0x000000000040ee8d in conf_parse (conf=0x6bfcc0, txn=0x7fffffffe1b0, input=0x4783c7 "/etc/knot/knot.conf", is_file=true) at knot/conf/base.c:592 #6 0x000000000040f128 in conf_import (conf=0x6bfcc0, input=0x4783c7 "/etc/knot/knot.conf", is_file=true) at knot/conf/base.c:669 #7 0x000000000040b677 in init_confile ( confile=0x4783c7 "/etc/knot/knot.conf") at utils/keymgr/main.c:240 #8 0x000000000040bb70 in main (argc=4, argv=0x7fffffffe488) at utils/keymgr/main.c:349 A few lines later, keymgr invokes key_command. I get the following backtrace: #0 conf_db_get (conf=0x6bfcc0, txn=0x6bfce0, key0=0x47c042 "\bkeystore", key1=0x47c04c "\abackend", id=0x0, id_len=0, data=0x7fffffffdf90) at knot/conf/confdb.c:705 #1 0x00000000004101a3 in conf_id_get_txn (conf=0x6bfcc0, txn=0x6bfce0, key0_name=0x47c042 "\bkeystore", key1_name=0x47c04c "\abackend", id=0x7fffffffe090) at knot/conf/conf.c:109 #2 0x0000000000419117 in conf_id_get (conf=0x6bfcc0, key0_name=0x47c042 "\bkeystore", key1_name=0x47c04c "\abackend", id=0x7fffffffe090) at ./knot/conf/conf.h:138 #3 0x000000000041a516 in kdnssec_ctx_init (conf=0x6bfcc0, ctx=0x7fffffffe180, zone_name=0x6a81d0 "\aexample\003com", from_module=0x0) at knot/dnssec/context.c:169 #4 0x000000000040aee4 in key_command (argc=3, argv=0x7fffffffe490, optind=1) at utils/keymgr/main.c:113 #5 0x000000000040bba9 in main (argc=4, argv=0x7fffffffe488) at utils/keymgr/main.c:359 In both cases conf_db_get is eventually invoked. With a big difference: the first time, the information concerning the keystore id is present, as the value of id - namely, "TheBackend". With this value, conf_db_get returns KNOT_EOK, and the backend id is retrieved as KEYSTORE_BACKEND_PKCS11. The second time, however, the value of this argument is just the NULL pointer. This causes conf_db_get to return KNOT_ENOENT, and the value of the backend is therefore eventually set to the default - KEYSTORE_BACKEND_PEM. What am I doing wrong? What is causing for the second invocation to of conf_db_get to receive an id argument set to NULL? Is this the way it is supposed to work, or is it a bug in the Knot 2.7.3 code? If it is not, what do I have to do in order to get Knot to use the PKCS #11 interface? By the way, I forgot to mention in my previous email that Knot was built with PKCS #11 support all right.

6 let, 7 měsíců

1
0
0 0

Re: [knot-dns-users] Best practices for knot inline DNSSEC signing and zone loading

by libor.peltan

Hi Sebastian, 1) that's OK. You don't need to worry about that warning unless you edit the zonefile on the signer manually. You can also consider zonefile-less signer, either completely headless (needs AXFR after each daemon start) or with the zone stored in journal (needs some thoughts regarding journal capacity policies). Check "zonefile-load", "journal-content", "max-journal-db-size" and "max-journal-usage" options in config. 2) No, "discontinuity in changes history" is not expected. Could you please describe what did you do before such warning appeared, with longer snippets of the log? In any case, there is no need to be scared of journal getting full, once you read the documentation ;) https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour BR, Libor Dne 29.10.18 v 13:07 Sebastian Wiesinger napsal(a): > Right now I have two zone types for my knot test setup, one where knot > is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and > one where the knot is the master for the zone and zone data is coming > out of a git repository and gets signed. > > Reading older threads on this ML and browsing the configuration has > led me to the following configuration and I wanted to make sure this > is actually supported or if there is a best practice that is > different. > > > 1) Inline DNSSEC signing for slave zone. > > zone: > - domain: example.com > serial-policy: unixtime > storage: "/var/lib/knot/slave" > file: "%s.zone" > zonefile-load: difference > dnssec-signing: on > dnssec-policy: rsa-de > master: ns1_signer > notify: ns1 > acl: acl_ns1 > > policy: > - id: rsa-de > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > ksk-submission: tld_de > > > This seems to work fine, zone gets transferred from master (with low > serial), signed and with a new unixtime serial transferred out again. > I'm not sure if "zonefile-load: difference " makes any difference for > a slave zone but without it I get warnings about possibly malformed > IXFRs... > > 2) Inline DNSSEC for master zone from git: > > zone: > - domain: dnssec-test.intern > serial-policy: unixtime > storage: "/var/lib/knot/master" > file: "%s.zone" > zonefile-sync: -1 > dnssec-signing: on > dnssec-policy: rsa > acl: acl_ns1 > zonefile-load: difference-no-serial > > policy: > - id: rsa > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > > > This also works but I get warnings like this: > > [dnssec-test.intern.] journal, discontinuity in changes history > (1540307365 -> 28), dropping older changesets > > Is this expected? Also I read in older threads that this might fill > up the journal. Is that still the case? > > > Best Regards > > Sebastian >

6 let, 7 měsíců

2
7
0 0

(where) is the python control script packaged?

by Rick van Rein

Hi, You/Daniel pointed me to the Python control library, but I cannot find it in the 2.7.3 packages -- is that forgotten, or am I missing it? Thanks, -Rick

6 let, 7 měsíců

4
3
0 0

Question about obtaining information for parent zone of DNSSEC KSK rollover

by Maximilian Engelhardt

Hi, I'm having a question about DNSSEC KSK rollover and obtaining the relevant information for submission to the parent zone of the new key. I'm currently using these steps: - running "keymgr example.org list" - manually identifying the new key using the parameters "ksk=yes" and having a look at the created, publish, ready and active parameters. The new key always seems to be the one with active=0 and I also check the dates of the other parameters for plausibility. I then note the tag of the identified key. - using "keymgr example.org dnskey <keytag>" or "keymgr example.org ds <keytag>" to get the corresponding information for submission to the parent zone. Is there an easier way of achieving this, especially without the manual key identification step? Ideally would be a single command I can run and specify the zone of interest and it will output the dnskey and/or ds information of the new key. Thanks, Maxi

6 let, 7 měsíců

3
4
0 0

Best practices for knot inline DNSSEC signing and zone loading

by Sebastian Wiesinger

Right now I have two zone types for my knot test setup, one where knot is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and one where the knot is the master for the zone and zone data is coming out of a git repository and gets signed. Reading older threads on this ML and browsing the configuration has led me to the following configuration and I wanted to make sure this is actually supported or if there is a best practice that is different. 1) Inline DNSSEC signing for slave zone. zone: - domain: example.com serial-policy: unixtime storage: "/var/lib/knot/slave" file: "%s.zone" zonefile-load: difference dnssec-signing: on dnssec-policy: rsa-de master: ns1_signer notify: ns1 acl: acl_ns1 policy: - id: rsa-de algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 ksk-submission: tld_de This seems to work fine, zone gets transferred from master (with low serial), signed and with a new unixtime serial transferred out again. I'm not sure if "zonefile-load: difference " makes any difference for a slave zone but without it I get warnings about possibly malformed IXFRs... 2) Inline DNSSEC for master zone from git: zone: - domain: dnssec-test.intern serial-policy: unixtime storage: "/var/lib/knot/master" file: "%s.zone" zonefile-sync: -1 dnssec-signing: on dnssec-policy: rsa acl: acl_ns1 zonefile-load: difference-no-serial policy: - id: rsa algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 This also works but I get warnings like this: [dnssec-test.intern.] journal, discontinuity in changes history (1540307365 -> 28), dropping older changesets Is this expected? Also I read in older threads that this might fill up the journal. Is that still the case? Best Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

6 let, 7 měsíců

1
0
0 0

KSK Algorithm Rollover Question

by Sebastian Wiesinger

Hi, I'm currently testing a KSK algorithm rollover with my zone. I changed the signature scheme from RSA to ECDSA. Knot started adding new RRSIGs and new keys and now waits for the new DS to be published at the parent zone. One thing strikes me as odd though: http://dnsviz.net/d/6v6.de/W9AmtA/dnssec/ Looking at the graph the new KSK (54879) is not signing anything right now. Shouldn't it sign the DNSKEY records of the ZSKs so that the chain stays intact when the DS record changed at the parent zone? Kind Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

6 let, 8 měsíců

2
3
0 0

geoip secondary DNS with DNSSEC

by Mark Karpilovskij

Dear Volker, it is true that the method for creating a CSK is not explicitly mentioned in the documentation, we shall fix that. You can create a CSK using our keymgr utility by specifying both 'ksk=yes' and 'zsk=yes' parameters of the 'generate' command. E.g. $ keymgr -c /path/to/knot.conf example.com. generate ksk=yes zsk=yes remove=+1y creates an immediately active CSK with a 1 year lifetime. You can check out all possible timestamp settings in the docs <https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#generate-arguments>. Please note that the geoip module is currently not very well integrated into Knot's DNSSEC workflow. For instance, the only way to refresh RRSIGs precomputed by the module is to reload it (knotc zone-reload). One approach for now could be to create a CSK with a strong algorithm (e.g. the default ECDSAP256SHA256) and a long lifetime, e.g. 1 year, and to set the same lifetime for the RRSIGs. The policy configuration could look like this: policy: - id: manual manual: on algorithm: ECDSAP256SHA256 rrsig-lifetime: 365d zone: - domain: example.com. dnssec-signing: on dnssec-policy: manual Then you would only have to perform a manual key rollover while reloading the zone so that the module computes the new signatures. We will update the documentation to include this information. In addition, you can sync the key from one server to others by copying the KASP lmdb database e.g. using the mdb_dump and mdb_load tools. If you have any further questions, let us know! Best regards, Mark On 19.10.2018 10:13, Volker Janzen wrote: > Hi all, > > I'd like to test the geoip module with a signed zone. The > documentation recommends using manual mode for signing. As far as I > know, the geoip information is not transferred via AXFR. That would > mean, that I've to transfer the signing key to the secondary servers > along with the geoip (and zone) configuration. To reduce caveats with > ZSKs, I'd like to use CSK. As a result I just need to sync one key per > zone to secondary servers. I checked the Knot documentation on how to > use a CSK for a zone, but the CSK is only mentioned twice in the > documentation with no example on how to actually use it. Can someone > point me to a configuration example for setting up a CSK? > > > Kind regards, > Volker

6 let, 8 měsíců

3
2
0 0

geoip secondary DNS with DNSSEC

by Volker Janzen

Hi all, I'd like to test the geoip module with a signed zone. The documentation recommends using manual mode for signing. As far as I know, the geoip information is not transferred via AXFR. That would mean, that I've to transfer the signing key to the secondary servers along with the geoip (and zone) configuration. To reduce caveats with ZSKs, I'd like to use CSK. As a result I just need to sync one key per zone to secondary servers. I checked the Knot documentation on how to use a CSK for a zone, but the CSK is only mentioned twice in the documentation with no example on how to actually use it. Can someone point me to a configuration example for setting up a CSK? Kind regards, Volker

6 let, 8 měsíců

1
0
0 0

DDNS with DNSSEC, is this expected behavior or a bug

by Maximilian Engelhardt

Hi, I'm using a zone with DNSSEC signing enabled that is updated using DDNS. The update procedure is very simple and looks like this: ==> test_ddns.sh <== #! /bin/sh ZONE="example.org." cat << EOF | nsupdate server localhost zone ${ZONE} update delete ${ZONE} A update add ${ZONE} 60 IN A 127.0.0.1 send quit EOF And the corresponding output in the knot log is this: Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, successfully signed Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 2018-10-24T22:58:46 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, update finished, serial 1539809849 -> 1539809926, 0.02 seconds Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] zone file updated, serial 1539809849 -> 1539809926 I'm wondering if the "next signing at 1970-01-01T01:00:00" output is correct as this seems suspicious to me. Running "knotc zone-status example.org" gives the following output: [example.org.] role: master | serial: 1539809926 | transaction: none | freeze: no | refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: not scheduled | NSEC3 resalt: +29D23h53m28s | parent DS query: not scheduled Is this expected behavior or a bug in knot? I can give more information or create a proper bugreport if needed. I also recently had the problem that knot didn't respond to ddns updates until it was restarted. I don't know if this is related or a different problem, however I currently don't have more information about this. Thanks, Maxi

6 let, 8 měsíců

3
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users