knot-dns-users

knot-dns-users@lists.nic.cz

6 participants
749 discussions

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

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, 10 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, 10 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, 10 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, 11 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, 11 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, 11 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

7 let

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

7 let

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?

7 let

← Newer
1
...
26
27
28
29
30
31
32
...
75
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users