knot-dns-users

knot-dns-users@lists.nic.cz

3 participants
755 discussions

Knot DNS 1.99.1 (preview of DNSSEC with KASP)

by Jan Včelák

Hello everyone! After months of keeping our secrets, we would like to share with you a preview of a new DNSSEC implementation in Knot DNS. The new DNSSEC will be one of the key features for the upcoming Knot DNS 2.0. If you are watching our source repository, you may have noticed a tag v1.99.0 appearing silently at the end of 2014. At that time, Knot DNS was already using the newly implemented DNSSEC, but the only visible change was a different key format. And internally, GnuTLS/Nettle was replaced OpenSSL for cryptographic operations. Today, CZ.NIC Labs releases Knot DNS 1.99.1. The next step towards the 2.0. Knot DNS 1.99.1 adds initial support for DNSSEC KASP (Key And Signature Policy). This is our vision of real-world DNSSEC deployment. Essentially, you define a policy (used algorithm, key sizes, key lifetime, signature lifetime, etc.) and the server will do the heavy lifting. It will generate keys and publish/roll them correctly, so you don't have to compute and set timing meta-data on private keys manually. At the moment, the KASP support is quite limited: Single algorithm, single KSK, and single ZSK can be specified in the policy. The server is able to generate initial keys and perform ZSK rollovers (key pre-publish method). More features are coming soon. A documentation on KASP [1] is currently available on the project wiki, including the reference manual for a new management utility keymgr [2]. [1] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-setup [2] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-keymgr-reference Source archives are available as usual: https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.gz Please note, that Knot DNS 1.99.1 is not ready to replace Knot DNS 1.6.x. We are looking forward to hear some feedback from you. And we are happy to answer all your questions and concerns. Best regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

11 let

DNSSEC and slave zones?

by Jan-Piet Mens

Good evening, I don't seem to be able to configure Knot 1.6.1 to sign a zone it slaves in: example.com { file "/usr/local/etc/knot/aa/example.com.zone"; xfr-in home; dnssec-keydir "/usr/local/etc/knot/aa"; dnssec-enable on; } If I omit the two 'dnssec-*' parameters, the zone is slaved in. Adding them, however, results in no transfer; log shows: notice: [example.com] automatic DNSSEC signing enabled, disabling incoming XFRs Is it currently possible with Knot to sign a slaved zone? Regards, -JP

11 let, 1 měsíc

Re: [knot-dns-users] Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Leo

Hi, > How would one go about converting from PowerDNS to KnotDNS on an active > realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary > disruption of services to existing DNS users? > If it's truly anycast it should only be easier, I would simply: - stop announcing the anycasted prefix at node #1 - once you see no queries anymore: convert and test - after finishing: switch on routing - repeat untill node #last Unless you have bizarre performance complications, above would be more safe than converting an active node. Did I maybe misunderstand the question? Or did you mean: "how to convert from pdns with a transactional SQL backend to a conventional DNS setup with Knot" ..? Leo

11 let, 1 měsíc

Knot DNS and IN NS records

by Eugene Bolshakoff

Hello All, I've decided to use Knot DNS as secondary nameserver for my local zone. I have several subnets connected via VPN and they have their own nameservers. So, there are records in my zone zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 zu.mithril. 3600 IN NS zu-gw.vpn.mithril. and I want to resolve domain in zu.mithril: BIND (master): # dig @tessa.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @tessa.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7626 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; ANSWER SECTION: melissa.zu.mithril. 0 IN A 172.19.3.1 ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 143 msec ;; SERVER: 172.19.37.1#53(172.19.37.1) ;; WHEN: Wed Jan 14 19:24:27 2015 ;; MSG SIZE rcvd: 92 KNOT (secondary): # dig @mira.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @mira.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10182 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 0 msec ;; SERVER: 172.19.38.2#53(172.19.38.2) ;; WHEN: Wed Jan 14 19:24:51 2015 ;; MSG SIZE rcvd: 76 I understand that it's happening because of recursion in bind, but how can I solve this problem in knot? -- With best regards, Eugene Bolshakoff

11 let, 2 měsíce

Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Ret Law

How would one go about converting from PowerDNS to KnotDNS on an active realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary disruption of services to existing DNS users?

11 let, 2 měsíce

Knot DNS v1.6.1 release

by Jan Kadlec

Hello list! Today, CZ.NIC Labs are releasing a new version of Knot DNS. This release introduces a new feature and fixes few bugs. The new feature is a support for Single Type Signing Scheme in automatic DNSSEC implementation. As far as bugfixes are concerned, we've fixed a couple of problems with IXFR/DDNS journal file. Most importantly, it was sometimes not respecting its file size limit (ixfr-fslimit configuration option). We've also fixed incompatibility with OpenSSL 0.9.8. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz.asc There are not many changes in this release, but those of your who use IXFR or DDNS should definitely upgrade. Regards and thanks for using Knot DNS, Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 2 měsíce

Knot 1.6.1 and journal size tuning

by Anand Buddhdev

Hi Knot developers, I've now installed version 1.6.1 on some servers, and I'm observing some journal related issues, and I have questions about them. First off, here's one issue: 2014-12-15T06:00:56 info: [203.in-addr.arpa] NOTIFY, incoming, 193.0.0.198@53535: received serial 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] refresh, outgoing, 193.0.0.198@53: master has newer serial 3006121317 -> 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:57 warning: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: failed to write changes to journal (not enough space provided) 2014-12-15T06:00:58 notice: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: fallback to AXFR 2014-12-15T06:00:58 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:59 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: finished, serial 3006121317 -> 3006121318, 0.65 seconds, 171 messages, 7960312 bytes So it looks like the IXFR is too big, and won't fit into the journal, and Knot is falling back to AXFR. When I requested this IXFR by hand, I got: $ dig ixfr=3006121317 203.in-addr.arpa @193.0.0.198 ... ... ;; XFR size: 121779 records (messages 170, bytes 7963389) The size of the IXFR in bytes is below the configured file size limit (10M), but I suspect that 7963389 bytes probably take up more room in the journal, so Knot can't write into it, and is falling back to AXFR. Are you able to tell me (approximately of course), how much disk space is required for a given number of bytes of IXFR? This will help me tune the setting of ixfr-fslimit to avoid this unnecessary fallback to AXFR.

11 let, 3 měsíce

Knot 1.6.1 and full journal

by Anand Buddhdev

Hi Knot developers, I have another question about journals. I've noticed that for one zone, the journal size is 9M (with my configured limit at 10M). Now, I see this each time in the logs: 2014-12-15T07:56:02 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:13:09 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:16:35 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:20:27 notice: [103.in-addr.arpa] journal is full, flushing It looks like once a journal is close to the maximum size, then it just remains at that size, with the result that each time an IXFR comes in, and overflows the journal, Knot wants to flush the changes to disk immediately. Does Knot discard old records from the journal at this point? Anand

11 let, 3 měsíce

zlib dependency

by Matthias-Christian Ott

Knot DNS depends on zlib to calculate Adler-32 checksums. A comment in crc.h states that it “should be removed”. I want to use knsupdate on OpenWRT and would also like to remove the dependency. Unfortunately, there is no single library that provides only Adler-32 checksums and every examined software either relies on zlib or its bundled implementation of varying quality and speed. Other projects seem to use CRC32C because there is an instruction to calculate it in the SSE4.2 instruction set. But again there is no library that only implements only CRC32C checksums. Switching to CRC32C would also make the journal format incompatible. I'm inclined to just copy the reference implementation from RFC 1950 for my purposes but wanted to check with the upstream maintainers whether there are any plans or ideas. It would also be nice if the configure script would have an option to not include and compile unused functionality from libknot and libzscanner to minimize binaries sizes. - Matthias-Christian

11 let, 3 měsíce

failed (connection refused)

by Eric Kom

Good day All, Please I got a connection refused when trying to setup a master and slave on the same network. THIS IS AN EXTRACT FROM MY MASTER KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { storage "/var/lib/knot"; metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-out slaveOnKnot; notify-out slaveOnKnot; } } root@ns1:~# knotc reload OK root@ns1:~# grep knot /var/log/syslog Nov 27 07:10:41 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 07:10:41 ns1 knotd[469]: 2014-11-27T07:10:41 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: 2014-11-27T08:08:09 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 09:27:33 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:27:33 ns1 knotd[469]: info: reloading configuration Nov 27 09:27:34 ns1 knotd[469]: info: configuration reloaded Nov 27 09:27:34 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014102701 -> 2014112700 Nov 27 09:27:34 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) Nov 27 09:29:46 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:29:46 ns1 knotd[469]: info: reloading configuration Nov 27 09:29:47 ns1 knotd[469]: info: configuration reloaded Nov 27 10:13:37 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:13:37 ns1 knotd[469]: info: reloading configuration Nov 27 10:13:37 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:14:15 ns1 knotd[469]: info: reloading configuration Nov 27 10:14:15 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014112700 -> 2014112701 Nov 27 10:14:15 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) THIS IS AN EXTRACT FROM MY SLAVE KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage # storage "/var/lib/knot"; # # # Example slave zone metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-in masterOnKnot; notify-in masterOnKnot; } } root@ns2:~# knotc reload OK root@ns2:~# grep knot /var/log/syslog Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@10548: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@13456: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@60566: unauthorized request Nov 27 08:47:30 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@54094: unauthorized request Nov 27 09:28:36 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:28:36 ns2 knotd[397]: info: reloading configuration Nov 27 09:28:36 ns2 knotd[397]: info: [metropolitanbuntu.co.za] zone will be bootstrapped, serial 0 Nov 27 09:28:36 ns2 knotd[397]: info: configuration reloaded Nov 27 09:28:36 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:28:36 ns2 knotd[397]: 2014-11-27T09:28:36 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: 2014-11-27T09:29:01 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: 2014-11-27T09:29:54 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:30:02 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:30:02 ns2 knotd[397]: info: reloading configuration Nov 27 09:30:02 ns2 knotd[397]: info: configuration reloaded Nov 27 09:31:49 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:49 ns2 knotd[397]: 2014-11-27T09:31:49 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: 2014-11-27T09:31:56 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: 2014-11-27T09:32:34 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: 2014-11-27T09:34:15 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: 2014-11-27T09:37:59 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: 2014-11-27T09:45:29 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: 2014-11-27T10:00:45 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:14:26 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 10:14:26 ns2 knotd[397]: info: reloading configuration Nov 27 10:14:26 ns2 knotd[397]: info: configuration reloaded -- -- Kind Regards Eric Kom Senior IT Manager - Metropolitan Schools _________________________________________ / You are scrupulously honest, frank, and \ | straightforward. Therefore you have few | \ friends. / ----------------------------------------- \ \ .--. |o_o | |:_/ | // \ \ (| Kom | ) /'\_ _/`\ \___)=(___/ 2 Hennie Van Till, White River, 1240 Tel: 013 750 2255 | Fax: 013 750 0105 | Cell: 078 879 1334 erickom(a)kom.za.net | erickom(a)metropolitancollege.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5

11 let, 3 měsíce

← Newer
1
...
55
56
57
58
59
60
61
...
76
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users