knot-dns-users

knot-dns-users@lists.nic.cz

738 discussions

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, 7 měsíců

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, 7 měsíců

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, 7 měsíců

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, 8 měsíců

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, 8 měsíců

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, 9 měsíců

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, 9 měsíců

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, 9 měsíců

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, 9 měsíců

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, 9 měsíců

← Newer
1
...
25
26
27
28
29
30
31
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users