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

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

10 let, 4 měsíce

2
1
0 0

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

10 let, 5 měsíců

1
0
0 0

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

10 let, 5 měsíců

2
1
0 0

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?

10 let, 5 měsíců

3
2
0 0

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

10 let, 5 měsíců

6
7
0 0

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.

10 let, 6 měsíců

3
2
0 0

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

10 let, 6 měsíců

3
2
0 0

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

10 let, 6 měsíců

3
4
0 0

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

10 let, 6 měsíců

3
4
0 0

When will you remove the limitation that a zone be signed by a KSK and ZSK ?

by Olafur Gudmundsson

In your documentation you say: Single-Type Signing Scheme is not supported. I only want to sign with a single key in some cases, i.e. there is no value in having the split as updating my parent is easy. Olafur

10 let, 7 měsíců

2
2
0 0

Rhel 6.3 RPM ?

by Lynch Davis

I am looking around for an rpm deployment since I have a "hardened" box that I wanted to install this on. Was going to try to build my own, but it looks like libucru is not readily available for the this distribution either. help or links? Thanks, Lynch

10 let, 7 měsíců

2
1
0 0

synchronized processing for specific RR Type

by Lynch Davis

Hi - I was reading on the faq about zone events serialization. Has this feature been implemented? I am experimenting with a processing that would require this feature, and if I could simply add a query processor and specify serialization, a majority of my problem (I think) would be solved. I have yet to explore the full feature set of the query_processor to know if this is a correct statement, but I am hopefull. Thanks, Lynch

10 let, 7 měsíců

2
1
0 0

Knot DNS 1.6.0 (final release)

by Jan Včelák

Hello everyone! CZ.NIC Labs proudly presents the final release of Knot DNS 1.6.0. This version also becomes an LTS (Long-term support) version of the Knot DNS software. We added two more bugfixes on top of the features covered by the previous e-mails announcing the release candidates. And as this is the final release, let's highlight the most important changes: The only new feature in Knot 1.6.0 is 'persistent zone timers'. The refresh, expire, and flush zone timers are now stored in file-backed database. Thus, the state of the timers survives a complete restart of the server. (Please note that the feature is optional and requires the LMDB library.) The processing of letter case in RDATA domain names was modified: In most cases, the names are converted to lower-case letters. The exception are RR types, which are treated case-sensitively in DNSSEC. With this change, some Knot DNS internals were simplified and also problems with invalid signatures issued by Knot DNS for mixed-case RR sets should be gone. A few minor bugs in EDNS processing were resolved. And since the -rc2, we fixed forced zone retransfer (knotc refresh -f <zone>), which got broken at some point during 1.5 development. And we also corrected slave zone expiration, when the master is responding to SOA queries but refusing the transfer. We would like to thank Anand Buddhdev for helping us in testing the release candidates and also for reporting the last two bugs. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.xz.asc Best regards, Jan -- Jan Včelák, 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

10 let, 7 měsíců

3
4
0 0

How to allow certain hosts to do AXFR?

by Rainer Duffner

Hi, is it possible to allow certain IPs to AXFR all zones? I need this for our helpdesk, so they can send zonefiles to customers etc. I don’t want knot to send ixfrs etc. to these IPs.

10 let, 7 měsíců

3
2
0 0

KNOT zone file

by Eric Kom

Hi all, I'm new on KNOT, and has been running BIND for many years now and would like to set up another master server to serve the domain metropolitanbuntu.co.za on a different network based on Debian and Knot. The Knot-DNS server its running fine: root@ns1:/etc/knot# knotc status OK The metropolitanbuntu.co.za zone was defined in the knot.conf file, just simple definition: 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 master zone # example.com { # file "/etc/knot/example.com.zone"; # xfr-out slave0; # notify-out slave0; # } # # Example slave zone # example.net { # file "/var/lib/knot/example.net.zone # xfr-in master0; # notify-in master0; # } metropolitanbuntu.co.za { file "/var/lib/knot/metropolitanbuntu.co.za.zone"; } } After ran: root@ns1:/etc/knot# knotc -c knot.conf reload OK And checked the Syslog: root@ns1:/etc/knot# grep knot /var/log/syslog Oct 18 09:33:23 ns1 knotd[414]: info: remote control, received command 'refresh' Oct 18 09:33:47 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:33:47 ns1 knotd[414]: info: reloading configuration Oct 18 09:33:47 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:33:47 ns1 knotd[414]: info: configuration reloaded Oct 18 09:42:24 ns1 knotd[414]: info: remote control, received command 'status' Oct 18 09:45:03 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:45:03 ns1 knotd[414]: info: reloading configuration Oct 18 09:45:03 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:45:03 ns1 knotd[414]: info: configuration reloaded The metropolitanbuntu.co.za zone look up to date. My question is: its the zone file looks like the BIND one? do I have to create it, may be I missed the zone declaration in the Knot manual? It is possible to do the master to master replication from BIND to KNOT? Thanks for your support. -- -- 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

10 let, 8 měsíců

2
3
0 0

Subject: how to assign multiple addresses for one zone?

by Junyoung Park

Hi! I have a question to configure knot dns for split-dns server. (only master , no slaves) If my router have two interfaces, eth0 (connected with ISP) and eth1 (internal private). About same zone (ex. example.com), i want to responses different ways for eth0, eth1. (ex. eth0, www.example.com -> read /etc/knot/external.example.zone, eth1, www.example.com -> /etc/knot/internal.example.zone) How can i configure it?

10 let, 8 měsíců

5
4
0 0

DNSSEC and Zone files

by dptrash＠arcor.de

I have DNSSEC in knot-dns activated. It always signs my file and it is very difficult to change my zone file with the dnssec stuff inside. Is it possible, to keep the zone file clean and it creates a .signed file for dnssec?

10 let, 8 měsíců

2
1
0 0

Knot DNS 1.6.0-rc2 (release candidate)

by Jan Včelák

Hello list! The second release candidate of Knot DNS 1.6.0 by CZ.NIC Labs is here! The update contains just a few changes, which improve the new persistent slave zones timers feature. The database for the zone timers was being opened before the privileges were dropped and UID/GID changed. As a result, the database could not be reopened after invoking the "knotc reload" command and updated timers could not be written into the database. This problem is resolved now. If you are updating from -rc1, you will need to fix the database ownership to match your knotd user. We also increased the maximal size of the database from 10 MB to 100 MB. This should be enough for thousands of slave zones. And finally, we improved a logging of errors related to database operations. If you have a time to try the new release candidate, please, do so. The final release will probably slip a few days, but it is still scheduled for the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.xz Have a nice weekend! Best regards, Jan, CZ.NIC Labs

10 let, 8 měsíců

1
0
0 0

Knot DNS 1.6.0-rc1 (release candidate)

by Jan Včelák

Hello everyone! Today, CZ.NIC Labs presents the first release candidate of Knot DNS 1.6.0. This comes quite soon after the release of the 1.5.3, which took place about a month ago. For this time, we were really conservative about inclusion of new features. We want to maintain Knot DNS 1.6.0 as a stable version and we intend to provide bug fixes for this release for a longer period of time. The 1.6.0 brings just one new feature - persistent timers for slave zones: The server stores zone expire, refresh, and flush timers in the file-backed database. The timers are written whenever they change and are recovered when the server is started. As a result, the timers will survive a full server restart. The persistent timers feature is an optional feature and depends on the LMDB library. Please, make sure the library is available at the build time and check the output of the 'configure' script, if you want to use this feature. We also modified domain names letter-case handling in RDATA. Previously, we preserved letter case of domain names in RDATA fields. With the 1.6.0, the domain names are converted to lower-case letters, unless the RR type is "new" and should be handled case-sensitively for compatibility with old servers. We believe that this approach is RFC-compliant. The letter case handling modification allowed us to simplify the DNSSEC signing code a little bit and also resolved problems with invalid signatures issued by Knot DNS for some mixed-case RR sets. All the other changes are various small bug fixes. Please, give Knot DNS 1.6.0-rc1 a try and report any troubles you encounter. We are looking forward to your feedback. If everything goes well, we plan to release the final version at the beginning of the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.xz Best regards, Jan, CZ.NIC Labs

10 let, 8 měsíců

1
0
0 0

Feature requests

by josten＠no-io.net

Hey everyone, I have a production Knot DNS setup; there are two features that I believe would make it even better than what it is now. * Under the zones section a way to just "push" all master zones to slaves; the slaves should just accept any zone from a verified master in the slaves knot.conf. * The ability to just load zones from disk without explicitly stating the zone in knot.conf. For example in /var/lib/knot/example.com.zone; Knot DNS automatically loads the example.com.zone without it being identified in the knot.conf under the zone section. Of course it should do checks (like it does now) before loading the zone, and then gracefully fail and log to the logging mechanism. Other than that; awesome DNS server!

10 let, 8 měsíců

2
1
0 0

[PATCH] dnstap: Fix ProtobufCBufferSimple usage that is incorrect as of protobuf-c 1.0.0

by Robert Edmonds

protobuf-c 1.0.0 added a new 'allocator' field to ProtobufCBufferSimple that controls memory allocation, which must be NULL in order to request the default system allocator. Allocating ProtobufCBufferSimple objects on the stack without zeroing the entire object can result in protobuf-c's memory allocation functions dereferencing a garbage pointer. Note that the use of the zero initializer in this instance generates a warning on some gcc versions: dnstap.c: In function 'dt_pack': dnstap.c:26:2: warning: missing braces around initializer [-Wmissing-braces] ProtobufCBufferSimple sbuf = {0}; ^ dnstap.c:26:2: warning: (near initialization for 'sbuf.base') [-Wmissing-braces] This warning is spurious and was fixed recently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=211289 --- src/dnstap/dnstap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/dnstap/dnstap.c b/src/dnstap/dnstap.c index 41d42e7..cf3770c 100644 --- a/src/dnstap/dnstap.c +++ b/src/dnstap/dnstap.c @@ -23,7 +23,7 @@ uint8_t* dt_pack(const Dnstap__Dnstap *d, uint8_t **buf, size_t *sz) { - ProtobufCBufferSimple sbuf; + ProtobufCBufferSimple sbuf = {0}; sbuf.base.append = protobuf_c_buffer_simple_append; sbuf.len = 0; -- 2.0.0

10 let, 8 měsíců

2
1
0 0

knot-1.4.4-49.1.i586 on opensuse 12.2 and automatic resign zone not approved ?

by Josef Karliak

Good afternoon, I made a change in our zone, changed serial of the zone and reload the zone. When I check the syslog, I saw some complains, that the signatures was out of date. For example: Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: A. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: AAAA. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: NSEC. This happens for all records in the zone. Last change was 11.8.2014, knot signed it and planned resign to 7.9.2014: Aug 11 13:39:10 slimak knot[22992]: Semantic checks completed for zone=fnhk.cz. Aug 11 13:39:10 slimak knot[22992]: Zone 'fnhk.cz.' reloaded (serial 2014081101) Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing started... Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-09-07T11:39:10. Aug 11 13:39:10 slimak knot[22992]: Loaded 5 out of 5 zones. Aug 11 13:39:10 slimak knot[22992]: Applied differences of 'fnhk.cz.' to zonefile. Aug 11 13:39:10 slimak knot[22992]: Configuration reloaded. Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081102). on 7.9.2014 the zone was resigned automatically: Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing zone... Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-10-04T11:39:10. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Started (serial 2014081102 -> 2014081103). Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Serial 2014081102 -> 2014081103. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Finished in 0.01s. And after today's changes knot told me that the signatures was out of date. I've this similar version of knot on my own server, there is no problem Any ideas ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (with ADSP) . Pokud mate problemy s dorucenim emailu, zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji. My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP) policy and check. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

10 let, 8 měsíců

2
2
0 0

Problem with CNAME in uppercase

by Didier ALBENQUE

Hi, I am currently testing knot and I have found a problem when CNAME are in uppercase. My primary server is running with BIND. I have these two declarations : myserver IN A 10.1.1.1 myserver-alias IN CNAME MYSERVER On the knot secondary server, after zone transfer, all seems ok : myserver.mydomain.fr. 900 A 10.1.1.1 myserver-alias.mydomain.fr. 900 CNAME MYSERVER.mydomain.fr. But when I ask knot for myserver-alias, I have a NXDOMAIN response (tcpdump output below) : 17:00:29.718834 IP dns-client.38146 > knot-server.domain: 4787+ A? myserver-alias.mydomain.fr. (43) 17:00:29.719011 IP knot-server.domain > dns-client.38146: 4787 NXDomain*- 1/1/0 CNAME MYSERVER.mydomain.fr. (123) 17:00:29.719555 IP dns-client.54520 > knot-server.domain: 2945+ A? myserver-alias.mydomain.fr.mydomain.fr. (54) 17:00:29.719637 IP knot-server.domain > dns-client.54520: 2945 NXDomain*- 0/1/0 (111) Tested with knot 1.5.1 and 1.5.2 Best regards, -- Didier ALBENQUE SG/SDSI/BSE Architecte technique Le café est un breuvage qui fait dormir, quand on n'en prend pas. Alphonse Allais ---------------------------------------------------------------------- Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.

10 let, 9 měsíců

2
2
0 0

Debian archive signing key, available over https?

by Andreas Olsson

Greetings Regarding the gpg key used to sign http://deb.knot-dns.cz/debian/. Any chance that that key could be available for downloaded by way of https://, or perhaps just have its fingerprinted listed on https://www.knot-dns.cz/pages/download.html? While the https:// CA model is far from perfect it'd still like to think it being a step up compared to regular http://, and at the same time a lot easier to document than the process of following the signatures in a gpg web of trust. // Andreas

10 let, 9 měsíců

2
2
0 0

Knot DNS v1.5.3 bugfix release

by Jan Kadlec

Hello list! CZ.NIC Labs are releasing a new version of Knot DNS today. This release fixes a regression that got introduced in the 1.5.2 release. This bug was causing Knot slaves to crash when receiving some specific IXFRs (more info: https://gitlab.labs.nic.cz/labs/knot/issues/294). Users that use Knot DNS as a slave should definitely upgrade. We've also added fixes for other issues we've recently discovered. Among those fixes are a fix to a very rare synchronization error during server reload (https://gitlab.labs.nic.cz/labs/knot/issues/296) and a fix to make dynamic query modules work properly with DNSSEC (https://gitlab.labs.nic.cz/labs/knot/issues/295). Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz.asc We apologize for two bugfix releases in such a short time, please be assured that we're expanding our tests and we'll also be changing our release policy to try to prevent any future regressions. Special thanks for bug reports go to Anand Buddhdev and Bastien Durel. 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

10 let, 9 měsíců

1
0
0 0

Re: [knot-dns-users] problem with debian repository

by Ondřej Surý

JFTR I did push the 1.5.2 to wheezy-backports directly since 1.5.2 contains a remote vulnerability, so it's available there - see https://tracker.debian.org/knot Cheers, -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Leoš Bitto" <leos.bitto(a)gmail.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Tuesday, September 9, 2014 12:06:45 PM > Subject: Re: [knot-dns-users] problem with debian repository > On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote: >> Dne 22.8.2014 09:52, Peter Hudec napsal(a): >>> Hi, >>> >>> this mail is directed for debian repository maintainers. >>> >>> The debian repository is not working properly, the Packages(.gz) and >>> Sources(.gz) files are empty. >>> >> >> I'm observing same problem. However, I've noticed that latest version of >> Knot is available in official wheezy-backports tree. >> > > http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too. > However I do not agree with the availability in the official > wheezy-backports > (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) - > the previous version 1.5.1 was not there until the last week, and the > current version 1.5.2 is not there at all (which might actually be a > good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294). > > > Leoš Bitto > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

10 let, 9 měsíců

1
0
0 0

Re: [knot-dns-users] problem with debian repository

by Ondřej Surý

Could you please flush your DNS cache (deb.knot-dns.cz should point to sophie.nic.cz now) and try again? The debarchive got broken and I couldn't fix it, so it has been replaced by reprepro. In case you can't flush your caches, please just temporarily change deb.knot-dns.cz to sophie.nic.cz. Also the repository is now signed: # wget -O - http://deb.knot-dns.cz/debian/apt.key | apt-key add - Full instructions can be found here: http://deb.knot-dns.cz/debian/README.txt Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Leoš Bitto" <leos.bitto(a)gmail.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Tuesday, September 9, 2014 12:06:45 PM > Subject: Re: [knot-dns-users] problem with debian repository > On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote: >> Dne 22.8.2014 09:52, Peter Hudec napsal(a): >>> Hi, >>> >>> this mail is directed for debian repository maintainers. >>> >>> The debian repository is not working properly, the Packages(.gz) and >>> Sources(.gz) files are empty. >>> >> >> I'm observing same problem. However, I've noticed that latest version of >> Knot is available in official wheezy-backports tree. >> > > http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too. > However I do not agree with the availability in the official > wheezy-backports > (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) - > the previous version 1.5.1 was not there until the last week, and the > current version 1.5.2 is not there at all (which might actually be a > good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294). > > > Leoš Bitto > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

10 let, 9 měsíců

1
0
0 0

problem with debian repository

by Peter Hudec

Hi, this mail is directed for debian repository maintainers. The debian repository is not working properly, the Packages(.gz) and Sources(.gz) files are empty. http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-amd64/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-i386/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/source/Sources .... I tested only wheezy distribution release. best regards Peter Hudec

10 let, 9 měsíců

3
2
0 0

Knot DNS 1.5.2 bugfix release

by Jan Kadlec

Hello list! Today, Knot DNS version 1.5.2 has been released by CZ.NIC Labs. This is a bugfix release. Unfortunately, while doing some internal testing, we've found a remote vulnerability that can crash the server. So far, we've had no reports that would suggest that someone else has discovered this vulnerability, but it is important all users upgrade as soon as possible. CVE for this vulnerability is CVE-2014-0486. We've also included a couple more fixes: Knot was refusing AXFR-style IXFR transfers, meaning these transfers had to be sent twice. Further, Knot was not properly escaping the hash character in domain names when saving the text zone file. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz.asc Again, we advise all users to upgrade immediately. We are truly sorry for any inconvenience caused by this. 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

10 let, 9 měsíců

2
1
0 0

knot init in Debian

by Zdeněk Zámečník

I have following issue with Knot: when I try to stop it by command /etc/init.d/knot stop then the daemon is still running. If i run command knotc stop then it's stopped but immediately run again. If I kill it by command kill, it's the same... As I found the /etc/init.d/knot is not working at all and Knot is probably run during boot by /etc/init/knot.conf and I'm not able to control it. The "unkillable" proccess is named /usr/sbin/knotd -c /etc/knot/knot.conf My environment: Debian 7 AMD64, OpenVZ container, kernel 2.6.32-openvz-042stab092.2-amd64, Knot 1.5.0-1 I tried to install Knot on another older machine where is Debian 7 too but upgraded from 6 and it's KVM virtual machine. There it works correctly via init.d script and the proccess is named /usr/sbin/knotd *-d* -c /etc/knot/knot.conf Do you have an idea why it's working on older machine correctly and on the second with OpenVZ not? Thanks for any help. Zdenek Z.

10 let, 9 měsíců

6
10
0 0

multimaster docs?

by Nicolás Reynolds

hi, i see knot 1.5.0 has multimaster support but i can't find more info/docs on this, can you point me to it? -- D

10 let, 9 měsíců

3
3
0 0

Knot and systemd

by Anand Buddhdev

Hello Knot folk, I'm building Knot RPM packages for use on CentOS 7, and I have to write systemd unit files. Before I write anything, I'd love to hear from others who may already have done such work, to learn from it. Let me describe my ideas. On my existing Knot servers running on CentOS 6 with upstart, I have 2 upstart scripts, viz. knot.conf, and knot-instance.conf. The knot.conf upstart script looks in /etc/knot for .conf files, and for each one, runs knot-instance with the config file as a parameter. This way, a simple "start knot" will start all instances. In systemd, there is better support for instances, so I want to create a knot@.service template unit, and a knot.target target unit. Then, I can create new instances with "systemctl enable knot(a)conf1.conf" and "systemctl enable knot(a)conf2.conf". Finally, running "systemctl start knot.target" should start all configured instances. Does this sound reasonable? I would also like to know about Knot's built-in support for systemd. I can't find any documentation about it. Could one of the devs please describe what Knot actually does if it's compiled with systemd support? Would you mind adding this information to the online documentation? Regards, Anand

10 let, 10 měsíců

2
3
0 0

Knot DNS 1.5.1 release

by Jan Kadlec

Hello list! Today, CZ.NIC Labs are releasing Knot DNS version 1.5.1! Let's discuss bugfixes first. Most notably, we've fixed a bug in automatic DNSSEC signing: domain names in RDATA were not lowercased before signing, resulting in bogus signatures. Other interesting bugfixes include proper handling of DDNS prerequisites and some TSIG and EDNS corner cases. As for the new features, we've added a basic support for logging using systemd journal. At the moment, log messages related to zone have the ZONE field set, which means that you can easily filter log messages based on zone name criteria. We plan to add more fields in the future to allow more fine-grained filtering. We're looking forward to your suggestions in this area. Moreover, we've improved DDNS performance for large zones by grouping incoming updates together and executing them as a bulk. This partially mitigates problems with RCU and copying the zone structure, but dynamic updates' running time is still proportional to size of the zone and not to the size of the actual updates. Improving this is one of our top priorities, and code in this release will help us to do so. Finally, we've improved and unified format of logging messages. Most notable, each logging message concerning a zone is now prepended with [zone name]. If you parse the output of log files, be sure to update your scripts. Further, we now enforce a more strict policy for DNSSEC signing keys: at least one active pair of KSK and ZSK keys of the same algorithm must be present at all times, or Knot will refuse to sign the zone. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz.asc Be sure to let us know if you run into any problems. Have a nice day 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

10 let, 10 měsíců

1
0
0 0

workflow for zone signing on master

by chrysn

hello, i'm operating a small hidden master server (four zones spread out to two external NS servers), and want to introduce dnssec. so far, i have kept my zone files in /etc under version control, but now knot starts overwriting them, which is kind of important because of the serial number increments, but also removes file structure, and comments and generally messes with the changelog. i could not quite infer from the documentation what the recommended work flow is in this situation: * will things work if i just make the zone files read-only for bind? * should i keep the original files separate and copy them over to the knot-writable destinations for each refresh? if yes, can that be automated from within knot? in either case, i have to take care of the serial numbers. my current numbering scheme (YYYYMMDDXX with year, month, day and per-day number) produces sufficiently few automated changes that incrementing by 10 each time i edit the unsigned file on one deay would work, but what is best practice there? best regards chrysn ps. please keep me in cc when replying, as i'm not subscribed to the list. -- There's always a bigger fish. -- Qui-Gon Jinn

10 let, 11 měsíců

4
4
0 0

Knot DNS 1.5.0 final release

by Jan Kadlec

Hello Knot DNS users! After two release candidates, CZ.NIC Labs proudly release Knot DNS 1.5.0 final. This new version differs greatly from the old 1.4 branch - we've rewritten quite a big portion of our code, and we've built a foundation for next cool features to come. But you've probably read about the changes in 1.5.0 in the previous release messages, so here's just a brief list of improvements that are visible to users: Optional query modules (currently we have dnstap and response synthesization modules implemented), lower memory footprint and improved zone events handling (for those of you with problems with zone expiring, 1.5.0 should not have this problem). We've also done a lot of under-the-hood changes, with lots of refactoring and massive code reductions. Apart from all this, we've been very busy writing tests - our current test code coverage is around 75 percent. Here are the changes we've made from 1.5.0-rc2: Features: - DDNS forwarding reimplemented Improvements: - Transfer sizes logged in bytes if needed - Logging outgoing NOTIFY messages - Logging unauthorized incoming NOTIFYs Bugfixes: - Zone flush planning after bootstrap - Incorrect incoming AXFR message sizes - DDNS signing changes were freed too soon, with possibility of stale data - knotc remote control key handling Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz.asc We've done all we could to test Knot DNS 1.5.0 on our end, now it's time you gave it a try! We hope you'll be as happy with it as we are. Today's thanks for bug reports go to Anand Buddhdev and Motomu Utsumi. Have a nice day 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

10 let, 11 měsíců

1
0
0 0

Re: [knot-dns-users] Two hidden masters - sending notifications to public slaves.

by Ondřej Surý

Hi Maren, you should turn the explicit notification both in bind and knot. For Knot use "notify-out <slave1> <slave2>;" + "xfr-out <slave1> <slave2>;" See the documentation: https://www.knot-dns.cz/static/documentation/html/configuration.html#master… For Bind use "notify explicit;" + "also-notify;", see: http://www.zytrax.com/books/dns/ch7/xfer.html#notify Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Maren S. Leizaola" <leizaola(a)udr.hk.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Monday, July 7, 2014 1:32:52 PM > Subject: [knot-dns-users] Two hidden masters - sending notifications to public slaves. > Hi, > > We are setting up to do zone generations of two separate hidden masters > which will take turns on the zone generation. > > Public/visible DNS servers "should" get notifies from both servers and > select the one with the with the highest serial number. > > I am planning to run bind on one server and knot on the other. On bind i > have the issue that it would not send notifies to the name servers until > I turned on "notify-soa yes;". However I realise that his will only > notify one single DNS server and introduces a single point of failure. > > Does Knot have any issues sending the notifies. How do I go about > getting this done? > > Regards, > Maren > > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

10 let, 11 měsíců

4
5
0 0

Problem with expiring zones - new stable version

by Jakub Stollmann

Hello, after upgrading to new stable version 1.4.7 we noticed a problem with zones, which are expiring (i've seen some bugfix -expiration timer). It happened second time now, and i think its happening every week (7days). Zones, which expired are selected randomly, count of expired zones is ~8. expired zones are listed like this: somezone.net. type=slave | serial=0 | bootstrap idle | After manually refreshing zone everything works fine. TTL is 86400 - 1 day We are using knot as slave dns. Bind9 is master. Thanks for some advices. Jakub

10 let, 11 měsíců

2
1
0 0

Random source port for incoming NOTIFY

by Gonzalo Muñoz

Hello everybody, We're currently testing Knot for a slave server with a BIND master, and we've noticed that NOTIFY messages from this master are not being processed by Knot. As I understand, BIND uses a random source port for NOTIFY messages, as a precaution against attacks. Also, if I understand correctly, when I add a remote master to a zone in Knot, if I don't specify a port for it then it defaults to 53- This leads me to believe that Knot is rejecting NOTIFY messages from the BIND master, because they come from an unexpected, random port. Is this correct? Can this situation be rectified to allow NOTIFY messages from random ports? Thank you very much in advance. Gonzalo Muñoz NIC Chile

10 let, 11 měsíců

3
4
0 0

Two hidden masters - sending notifications to public slaves.

by Maren S. Leizaola

Hi, We are setting up to do zone generations of two separate hidden masters which will take turns on the zone generation. Public/visible DNS servers "should" get notifies from both servers and select the one with the with the highest serial number. I am planning to run bind on one server and knot on the other. On bind i have the issue that it would not send notifies to the name servers until I turned on "notify-soa yes;". However I realise that his will only notify one single DNS server and introduces a single point of failure. Does Knot have any issues sending the notifies. How do I go about getting this done? Regards, Maren

10 let, 11 měsíců

1
0
0 0

Knot DNS 1.4.7 patch & 1.5.0-rc2 releases

by Jan Kadlec

Hello list! Today we release two new versions of Knot DNS: 1.4.7 patch release and a second release candidate of 1.5.0: 1.4.7 patch release fixes few minor issues and one major one, here they are in the order of their importance: - Assertion failure when serializing NAPTR records - this error can pop up with DDNS and transfers, regular queries are safe. - Knot could send mismatched IXFRs with automatic DNSSEC enabled. - Some DDNS corner cases were not handled properly. - Slave zone EXPIRE timer could be improperly set. - Zone semantic checks gave some false positive warnings. The NAPTR assertion failure is quite serious, so we recommend all users to update. We sincerely apologize for this. Hopefully all the code reduction and refactoring we did will pay off and versions 1.5 and beyond will see fewer patch releases. Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.7/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz.asc 1.5.0 second release candidate contains two new features: - edns-client-subnet support for kdig, see https://gitlab.labs.nic.cz/labs/knot/issues/252 for more info - Asynchronous startup is now configurable (config option "asynchronous-start"). Two minor improvements: - Faster zone reload. - Text zone files are no longer written to disk right after bootstrap, but are flushed in accordance with the "zonefile-sync" config option. And the following bugfixes: - Knot did not close connection with remote during transfer when the remote replied with SERVFAIL. - Knot was giving wrong log message during IXFR -> AXFR fallbacks. - Some zone events were not handled properly during reloads. We encourage everyone to give the second release candidate a try and send us as much feedback as possible :) Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz.asc We'd like to thank Anand Buddhdev, Alex Massover and Bastien Durel for feedback and bug reports. Have a nice day 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

1
0
0 0

Parallel dynamic DNS updates

by Alex Massover

Hello, I'm trying to understand if Knot can solve our performance problem with big scale dynamic DNS deployment. Currently we use BIND and the performance of Dynamic Updates is insufficient for our requirements. Doing some research I understood that BIND processes updates sequentially and can't really benefit from SMP. I understand how RCU allows parallel reads with updates. But reads is not an issue in our deployment. My question is, does Knot able to process multiple updates in parallel (and not sequentially) and provide a better scale for _updates_? As far as I understand it depends on data structure hierarchy implemented in Knot. -- Alex Massover | Telefónica Digital Architect M +972-54-2279512 alex(a)jajah.com<mailto:alex@jajah.com>

11 let

3
7
0 0

Knot 1.4.6 Aborted on NAPTR ddns update

by Alex Massover

Hello, We have Knot 1.4.6 on CentOS installation. When doing NAPTR ddns update, like this: nsupdate > server x.x.x.x > update add 3.1.1.1.1.1.1.1.1.2.7.9.9.our.domain.com. 172800 NAPTR 1 1 "u" "E2U+sip" "!^.*$!sip:123@freeswitch.org!" . > send ; Communication with server failed: timed out It fails with: knotd: libknot/rrset.c:1703: rrset_serialize: Assertion `size_one == rr_size' failed. Aborted No issues with ddns updates with TXT records. -- Alex Massover | Telefónica Digital Architect M +972-54-2279512 alex(a)jajah.com<mailto:alex@jajah.com>

11 let

2
2
0 0

Re: [knot-dns-users] Master-slave replication

by Bastien Durel

Le samedi 14 juin 2014 à 00:10 +0200, Jan Kadlec a écrit : > Hello, > one more thought: Could you please check your master log file for this > warning message: (log for category: zones and severity: warning has to > be enabled) "Zone file for '...' changed, but serial didn't - won't > create changesets."? This happens when you change the zone, but the > serial remains the same. > Note that Knot will change the serial when automatic DNSSEC is enabled, > so before creating the zone file in the script, you have to get the > current serial from server and increment that serial. Updating your zone > files using this approach might help you, but it is nevertheless a bug. Hello, I had this warning sometimes. I edit my zone files with emacs in zone mode, so the serial is auto-incrementing, but I have to save it twice to pass over the dnssec auto-increment. I put a check in my makefiles to ensure the old serial is lower than the new one. Look like it works with that, here was my mistake :) Thanks a lot ! Regards, -- Bastien Durel <bastien+knot(a)durel.org>

11 let

1
0
0 0

Master-slave replication

by Bastien Durel

Hello I have some zones in 2 knots in a master-slave relation When I update zones in master, there are replications issues in slave: - sometime changed records are duplicated (old and new value) - sometime removed records persists - sometime the RRSIG records are duplicated (old and new value) I often have to erase slave zones and to restart knot to get correct zone. I update master zone via makefiles that re-create (unsigned) zone files and then reload knot via knotc What is my mistake ? Regards, -- Bastien

11 let

2
3
0 0

Re: [knot-dns-users] Parking page with a large number of zones pointing the the same file.

by Ondřej Surý

Hi Maren, it would never be the 'same' zone file, since you have different full labels (foo.example.net is different from foo.example.com) per zone after loading them into the memory. I would suggest that this use case scenario would be best served by some new query processing dynamic module[1] that you would configure for all those zones and that would always respond with the same data. 1. See the Knot DNS 1.5.0rc1 release notes and documentation Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Maren S. Leizaola" <leizaola(a)udr.hk.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Thursday, June 12, 2014 7:50:02 PM > Subject: [knot-dns-users] Parking page with a large number of zones pointing the the same file. > Hello, > I would like to know what the memory allocation/usage > would be like if say I point 1M zones to the same zone file. > > Will it allocate memory for each of the zones or can it just allocate > memory once as it is the same zone file ? > > Regards, > Maren. > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

11 let

2
1
0 0

Parking page with a large number of zones pointing the the same file.

by Maren S. Leizaola

Hello, I would like to know what the memory allocation/usage would be like if say I point 1M zones to the same zone file. Will it allocate memory for each of the zones or can it just allocate memory once as it is the same zone file ? Regards, Maren.

11 let

1
0
0 0

Knot 1.5 - what does state "idle" mean?

by Anand Buddhdev

11 let

1
0
0 0

Fwd: Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

Hi Peter, On 4 June 2014 12:08, Peter Andreev <andreev.peter(a)gmail.com> wrote: > Just a few thoughts to start from: > > 1. Masters have to have possibility to exchange their states to each > other, including zones, journals. This means that "multi-master" > should be a "per-zone" feature; It is, the multi-master is enabled like: example.com { xfr-in master1, master2; } and the "master2" is then used for failover if the zone transfer with "master1" fails for example. Usually, you don't need multiple masters until you have a specific use case for that. > 2. Each master in case of dynamic update has to forward this update to > other masters. This means that server should look to its configuration > rather than to mname field; That is true, but this may also cause problems with some specific setups. Like for example hidden master that can only sign the zone, but can't forward dynamic updates and such. That is not to say relying on mname is always the best. Truth is, I don't like the idea of authoritative servers forwarding messages, but it seems there are legitimate use cases for that. Maybe we could let the zone operator override the mname with the configuration and put a warning in there, or is there a complete error-proof solution I'm not aware of? > 3. In case of first start there should be option for operator to tell > server if it starts as slave and has to sync from other masters, or it > should consider itself as master and provide data to others. As of now, the zone is treated as master unless it has at least one remote in the "xfr-in" option. Maybe it's not very intuitive, but we have a new configuration (to allow remote configuration as well) in planning, so this could be something to consider. > There is a lot to discuss actually, for example, what to do with > DNSSec? How to handle requests from slaves on first start? > > As for me, such master should be specialized software with main focus > not on performance, but on management and inter-server communication. I tend to agree, I originally wanted to support multiple masters only to provide failover for zone transfers. > 2014-06-04 13:35 GMT+04:00 Alex Massover <alex(a)jajah.com>: >> Hi, >> >> >> >> Please see inline >> >> >> >> From: marek(a)vavrusa.com [mailto:marek@vavrusa.com] On Behalf Of Marek >> Vavruša >> Sent: 04 June 2014 11:13 >> To: Alex Massover >> Cc: knot-dns-users(a)lists.nic.cz >> >> >> Subject: Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate! >> >> >> >> Hi Alex, the "xfr-in" statement always allowed a list of remotes as masters. >> However, only the first one was always used. With the 1.5.0, other remotes >> are used for >> >> failover should the first master be inaccessible or returning lame answers. >> There isn't any advanced functionality like load balancing or anything, do >> you need something like that? >> >> Also, the update forwarding to primary master is not reimplemented in the >> rc1 (but will be in final, see KNOWN_ISSUES). In that case, the things get >> tricky - in past, we used the first remote in the list >> >> as a primary. With the list now, we should probably take the primary NS as >> is in the SOA of the zone. Thoughts? >> >> >> >> [Alex] Will this guarantee data consistency, providing there are a number of >> slave servers with update forwarding? >> >> Also, I'm not sure I understand how the second master gets the updated zone, >> when the first fails. >> >> >> >> >> >> Best, >> >> Marek >> >> >> >> On 4 June 2014 09:35, Alex Massover <alex(a)jajah.com> wrote: >> >> Hello, >> >> >> >> I'm not able to find any information about how multi-master works. >> >> >> >> Can someone point me to the info, please? Does it work with dynamic updates? >> >> >> >> BR, Alex. >> >> >> >> From: knot-dns-users-bounces(a)lists.nic.cz >> [mailto:knot-dns-users-bounces@lists.nic.cz] On Behalf Of Marek Vavruša >> Sent: 03 June 2014 21:31 >> To: knot-dns-users(a)lists.nic.cz >> Subject: Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate! >> >> >> >> Here are the correct links for those baffled by my (admittedly) poor mail >> formatting skills. >> >> >> >> Changelog: >> https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS >> >> Sources: >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz >> >> GPG signatures: >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz.asc >> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz.asc >> >> >> >> Marek >> >> >> >> -- >> >> Marek Vavrusa, 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 >> >> >> On 3 June 2014 20:10, Marek Vavruša <marek.vavrusa(a)nic.cz> wrote: >>> >>> Hi Everyone, >>> >>> with the 1.5.0 mostly feature-complete, us jolly folks at the CZ.NIC Labs >>> thought >>> that the time has come to share it with you in form of a first release >>> candidate. >>> I'd like to tell you a story first - I was browsing through the NEWS file, >>> looking back >>> at the things we've done since the 1.0.0 two years ago. Oddly enough, one >>> of the new >>> features was an "optimized memory consumption", and I've seen this repeat >>> a few times. >>> I would have thought that the Knot DNS consumes zero memory by now, but it >>> appears it doesn't >>> work that way. The law of diminishing return still applies, and the >>> changes in between the versions >>> seem almost insignificant. Sometimes at least (recently, I've added a >>> benchmark of 1M small zones to our benchmark [1], which showed how much >>> memory did we need per each zone). >>> We addressed that. And despite the new preallocated packet buffers and >>> other features, we still managed to cut down the resource requirements for >>> TLD use cases for about 20%. >>> My point is, while the 20% does not seem that impressive alone, but the >>> steep release-over-release tendency of smaller memory footprint and faster >>> startup/answer performance just shows the unrelenting attention to the >>> seemingly insignificant stuff, like structure alignment or packet >>> distribution. That's what we're commited to. >>> >>> Now, what's actually new in the 1.5.0? I've touted the major changes under >>> the bonnet earlier this >>> year and boy, we've been busy. One of the major changes is the new query >>> processing, which allowed us to do several cool things. The query processing >>> is broken down to the set of step, >>> that are built like a LEGO, and each of the steps can be altered by the >>> modules. >>> We have two modules now - a module capable of synthesizing forward/reverse >>> records according to the configuration template. This for example solves the >>> IPv6 reverse records problem (SLAAC as well), as we don't have to generate >>> massive zones, but rather create the records on the fly. >>> The second module is a dnstap query/response log. Heard about the dnstap >>> [2]? It's a pretty ingenious solution to the fine-grained capture of the DNS >>> traffic without compromising the performance. >>> >>> By the way, the utilities (kdig) support it too and you can either capture >>> or replay queries now. >>> The good thing about modules is that it allows us to streamline (about 12K >>> LOC less) the core functionality and extend the server at the some time. >>> Think RRL, load balancing, geo-aware answers. >>> >>> What about other things? As for the visible changes, for instance a >>> multi-master failover, improved logs, asynchronously loaded zones, much more >>> accurate "knotc memstats" and "zonestatus" tools, new user manual ... >>> I could probably bore you to death with the nitty gritty stuff, so check >>> out the changelog to know more. That being said, I'd like to ask your help. >>> The new stuff, like the asynchronous zone loading or logging, change the >>> usability a little. Did we break your scripts or use case? Compliment, >>> cheeky remark or angry rant? Please let us know, we'd like to get most of >>> the kinks ironed out till the final release. Thank you. >>> >>> Changelog: >>> https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS >>> >>> Sources: >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz >>> >>> GPG signatures: >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz.asc >>> https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz.asc >>> >>> [1] http://knot-dns.labs.nic.cz/pages/benchmark.html#tab-resource-usage >>> [2] http://dnstap.info/ >>> >>> Kind Regards, >>> >>> Marek >>> >>> -- >>> Marek Vavrusa, 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 >> >> >> >> >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >> > > > > -- > Is there any problem Exterminatus cannot solve? I have not found one yet.

11 let

2
1
0 0

Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

Hi Anand, I see this could be a problem, is the backoff causing the delays for failed zone transfers? There is a configuration option "background-workers" with which you can limit the number of parallel requests, but if you can email me some statistics about failed/passed transfers and transfers/second we can probably work out some more clever queuing. Cheers, Marek On 4 June 2014 12:11, Marek Vavruša <marek(a)vavrusa.com> wrote: > Hi Anand, > > I see this could be a problem, is the backoff causing the delays for > failed zone transfers? > There is a configuration option "background-workers" with which you > can limit the number of parallel requests, > but if you can email me some statistics about failed/passed transfers > and transfers/second we can probably work out > some more clever queuing. > > Cheers, > Marek > > On 4 June 2014 12:06, Anand Buddhdev <anandb(a)ripe.net> wrote: >> On 03/06/2014 20:10, Marek Vavruša wrote: >> >>> Hi Everyone, >>> >>> with the 1.5.0 mostly feature-complete, us jolly folks at the CZ.NIC Labs >>> thought >>> that the time has come to share it with you in form of a first release >>> candidate. >> >> Great stuff Marek! >> >> I've started an instance of 1.5.0-rc1 with a few thousand slave zones >> configured. The bootstrap takes quite a while as Knot has to XFR all the >> zones in. >> >> It looks like Knot is hitting our master very hard, because it seems to >> want to make too many parallel connections. I see this in the logs: >> >> 2014-06-04T09:58:51 [error] AXFR of 'zone' with 'master': Requested >> resource is busy. >> >> Each such error will cause Knot to retry the zone later, and waste time >> and cycles. Is there any way to get Knot to limit the number of parallel >> XFRs it does? Or re-use TCP connections? >> >> The Knot server has been running for over 15 minutes now, and has still >> not finished boot-strapping all the zones. >> >> Regards, >> >> Anand >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

11 let

1
0
0 0

Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

Hi Everyone, with the 1.5.0 mostly feature-complete, us jolly folks at the CZ.NIC Labs thought that the time has come to share it with you in form of a first release candidate. I'd like to tell you a story first - I was browsing through the NEWS file, looking back at the things we've done since the 1.0.0 two years ago. Oddly enough, one of the new features was an "optimized memory consumption", and I've seen this repeat a few times. I would have thought that the Knot DNS consumes zero memory by now, but it appears it doesn't work that way. The law of diminishing return still applies, and the changes in between the versions seem almost insignificant. Sometimes at least (recently, I've added a benchmark of 1M small zones to our benchmark [1], which showed how much memory did we need per each zone). We addressed that. And despite the new preallocated packet buffers and other features, we still managed to cut down the resource requirements for TLD use cases for about 20%. My point is, while the 20% does not seem that impressive alone, but the steep release-over-release tendency of smaller memory footprint and faster startup/answer performance just shows the unrelenting attention to the seemingly insignificant stuff, like structure alignment or packet distribution. That's what we're commited to. Now, what's actually new in the 1.5.0? I've touted the major changes under the bonnet earlier this year and boy, we've been busy. One of the major changes is the new query processing, which allowed us to do several cool things. The query processing is broken down to the set of step, that are built like a LEGO, and each of the steps can be altered by the modules. We have two modules now - a module capable of synthesizing forward/reverse records according to the configuration template. This for example solves the IPv6 reverse records problem (SLAAC as well), as we don't have to generate massive zones, but rather create the records on the fly. The second module is a dnstap query/response log. Heard about the dnstap [2]? It's a pretty ingenious solution to the fine-grained capture of the DNS traffic without compromising the performance. By the way, the utilities (kdig) support it too and you can either capture or replay queries now. The good thing about modules is that it allows us to streamline (about 12K LOC less) the core functionality and extend the server at the some time. Think RRL, load balancing, geo-aware answers. What about other things? As for the visible changes, for instance a multi-master failover, improved logs, asynchronously loaded zones, much more accurate "knotc memstats" and "zonestatus" tools, new user manual ... I could probably bore you to death with the nitty gritty stuff, so check out the changelog to know more. That being said, I'd like to ask your help. The new stuff, like the asynchronous zone loading or logging, change the usability a little. Did we break your scripts or use case? Compliment, cheeky remark or angry rant? Please let us know, we'd like to get most of the kinks ironed out till the final release. Thank you. Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS> Sources: https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.gz https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz.asc>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz.asc>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.xz.asc [1] http://knot-dns.labs.nic.cz/pages/benchmark.html#tab-resource-usage [2] http://dnstap.info/ Kind Regards, Marek -- Marek Vavrusa, 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

4
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users