knot-dns-users

knot-dns-users@lists.nic.cz

8 participants
750 discussions

by Petr Šťastný

Hi, I think there is something wrong with logging categories. Documentation says: > server - Messages related to general operation of the server. > zone - Messages related to zones, zone parsing and loading. I use Knot 1.4.1 with the following configuration: > log { > file "/var/log/knot/knot-server.log" { > server error, warning, notice, info; > } > > file "/var/log/knot/knot-zone.log" { > zone error, warning, notice, info; > } > > stderr { > any error, warning; > } > } Everything is logged only into knot-server.log and knot-zone.log is always empty. knot-server.log file contains: > 2014-01-20T21:45:12 Knot DNS 1.4.1 starting. > 2014-01-20T21:45:12 Rate limiting set to 20 responses/sec. > 2014-01-20T21:45:12 Binding to interface 0.0.0.0 port 53. > 2014-01-20T21:45:12 Binding to interface :: port 53. > 2014-01-20T21:45:12 Configured 2 interfaces and 1 zones. > 2014-01-20T21:45:12 Changing group id to '1001'. > 2014-01-20T21:45:12 Changing user id to '1001'. > 2014-01-20T21:45:12 Server started as a daemon, PID = 25371 > 2014-01-20T21:45:12 PID stored in > '/usr/local/knot/1.4.1/var/run/knot/knot.pid' > 2014-01-20T21:45:12 Server changed directory to /. > 2014-01-20T21:45:12 Zone 'xxxx.eu.' loaded (serial 2013042301) > 2014-01-20T21:45:12 Loaded 1 out of 1 zones. > 2014-01-20T21:45:12 Starting server... > 2014-01-20T21:45:12 Binding remote control interface to > /usr/local/knot/1.4.1/var/run/knot/knot.sock > 2014-01-20T21:45:25 Reloading configuration... > 2014-01-20T21:45:25 Zone 'xxx.eu.' is up-to-date (serial 2013042301) > 2014-01-20T21:45:25 Loaded 1 out of 1 zones. > 2014-01-20T21:45:25 Configuration reloaded. And the question is: why are messages related to zone loading logged in "server" category and not in "zone" category (which is said in documentation)? Thanks Petr Šťastný

11 let, 11 měsíců

Re: [knot-dns-users] 1.4.0 dumping zones with non-existent dates

by daniel.salzman＠nic.cz

Hi Anand, Never mind. I understand your situation. Initially, we had just timestamps in zone dumps. I prefer this, since it makes smaller dumps and it is faster to process such records. Afterwards, we turned it off due to incompatibility with Bind. Because Bind is unable to load these dumps if you need it. Is there still anybody who requires human-readable timestamps in zone dumps from Knot? If not, we probably disable this functionality. Thanks, Dan On 2014-01-10 23:08, Anand Buddhdev wrote: > On 10/01/2014 19:42, daniel.salzman(a)nic.cz wrote: > >> We have probably found the problem. The function gmtime, which we use, >> is not thread safe. So I have replaced it with a better one. Please, >> try the attached patch. > > Hi Daniel, > > Thanks for this. However, I prefer not to test this on our current Knot > servers, as they are running in production. I have applied Marek's > earlier patch which disabled human-readable timestamps, and that's > keeping this problem away. > > Actually, I even asked Marek why you convert the timestamps to > human-readable in the zone dumps. After all, the zone files are only > going to be read back in by Knot, so you'd save some cycles when > writing > and reading the zones, by not converting them back and forth between > human-readable and unix timestamp. > > Is it reasonable to ask that you just dispense with human-readable > timestamps? > > Regards, > > Anand

11 let, 11 měsíců

Knot DNS 1.4.1 patch release

by Marek Vavruša

Hi Everyone, about a week ago, CZ.NIC Labs released the 1.4.0 and received some positive responses, but also discovered a few issues here and there. I'll try to summarize the important bits. Since the 1.4.1, OpenSSL >= 1.0.0 is required on configure as we ran into several issues with the older versions. If that means a problem for you, please let us know, we can always try to work something out. That also fixes compile failures on some platforms with OpenSSL < 1.0.0 Moreover, we've ran into a race condition when generating timestamps in the zone file. This affects both 1.3 & 1.4 users, so if you run Knot on slave with secured zones and experience a refusal to load a zone after reload, I advise you to rebootstrap the zones from the master. As for the other issues, we've fixed an empty APL record support and immediate zone file syncing if you use that (it didn't flush the zone correctly after resign and 'knot zonestatus' didn't handle this properly). All that plus more code coverage bugfixes and papercuts. Yet again, many thanks to our dear users for the bug reports, hints and nudges in the right direction. Last thing, as you can see, we've dropped the bz2 source packages. I hope that doesn't affect anyone, two should be more than enough. Here's a full change log: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.xz.asc Kind Regards, Marek, CZ.NIC Labs -- Marek Vavruša 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, 11 měsíců

1.4.0 dumping zones with non-existent dates

by Anand Buddhdev

Hello Knot users, We discovered today that When Knot 1.4.0 dumps zones to disk, it sometimes writes out the dates in RRSIG expiry and inception fields like this: 20140230203521 Yes, that's apparently 30 February! If you later restart Knot, or reload it, it will refuse to load this zone, and begin returning REFUSED responses for it. I spoke with the good folk at CZNIC, and Marek quickly provided me with a patch, attached here. It turns off pretty-printing of the dates, so that the expiry and inception dates are written in unix time. This fixes the problem for us, so if you're running Knot in production, you may want to apply this patch too. We don't yet know where this bug is, but needless to say Marek and his colleagues are investigating, and I'm sure a proper fix for it will appear in due course. Regards, Anand Buddhdev RIPE NCC

11 let, 11 měsíců

Knot DNS 1.4.0 released!

by Marek Vavruša

Hi Everyone, I hope you had a terrific Christmas. Now, I know it's all work, but after some time spent in the release candidate, CZ.NIC Labs are proud to release Knot DNS 1.4.0 final version. There have been a several bugfixes, odds and ends since the last release candidate. Namely NSEC3/transfer related bugs and case sensitivity of QNAME, there's a link for an exhaustive list of changes below. But allow me to reiterate what's new since the 1.3 version. Shall we? Since the first beta, we have brought a new major feature on the table. A technology preview of an automatic DNSSEC signing. Now, since it's not a final product, there are still a few shortcomings; mainly key management and auxiliary tools missing. However, that shouldn't stop you from giving it a try! We've written a short "how to" on our wiki page here: https://gitlab.labs.nic.cz/labs/knot/wikis/dnssec-quickstart But it's really as simple and creating signing keys and setting "dnssec-enable on;" There are few more enhancements like IDN in the utilities, zone serial policies and fancier zone file printout. Plus a lot of changes under the bonnet. Say for example the memory consumption, which is significantly lower (~35% for our large zones). We've also doubled our (continuous) efforts in producing both unit and operational test cases, not to mention Knot DNS being kindly accepted in the Coverity Scan program for open source software. We've also spent some time on other related projects. Say the comparison of the authoritative name servers, that you can find here: https://www.knot-dns.cz/pages/benchmark.html The whole effort is open source, you can try it yourself or even create new test cases, any feedback is welcome. https://gitlab.labs.nic.cz/labs/dns-benchmarking With all that, the work is far from finished. We're going to further polish the Knot DNS 1.4 features and prepare a new version at the same time. By the way, we have a few surprises for you in that department as well. Last but not least, we and the whole CZ.NIC Labs would like to thank you, our users and supporters, who poured a lot of time into helping us shape the Knot DNS the way it is. It's truly appreciated. Here's a full change log: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.xz.asc Kind Regards, Marek, CZ.NIC Labs -- Marek Vavruša 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, 11 měsíců

Feature request: inherit xfr-in, xfr-out, etc from "zones" section

by Anand Buddhdev

Hello Knot devs, The Knot zones directive allows some options at the top-level (such as "storage", "disable-any", etc). However, the following options can only be specified per zone: xfr-in xfr-out notify-in notify-out update-in Could you make it so that these options can also be specified at the top level so that all zones specified after can inherit the same options. This is useful when I have the same master or set of masters for a whole bunch of zones, and I don't need to specify them each time for each zone separately. Regards, Anand

11 let, 12 měsíců

Knot 1.4.0-rc2 is case-sensitive!

by Anand Buddhdev

I exposed Knot 1.4.0-rc2 to real queries, and noticed it was giving REFUSED responses for a significant number of queries. Digging further, it looks like the QNAMEs were mixed-case, such as: 42.234.11.86.In-adDR.ArPA So here's where I discovered a show-stopper bug: # dig +norec @193.0.9.5 ptr 42.234.11.86.in-addr.arpa ; <<>> DiG 9.9.4-P1 <<>> +norec @193.0.9.5 ptr 42.234.11.86.in-addr.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16021 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;42.234.11.86.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 234.11.86.in-addr.arpa. 86400 IN NS ns1.virginmedia.net. 234.11.86.in-addr.arpa. 86400 IN NS ns2.virginmedia.net. 234.11.86.in-addr.arpa. 86400 IN NS ns3.virginmedia.net. 234.11.86.in-addr.arpa. 86400 IN NS ns4.virginmedia.net. # dig +norec @193.0.9.5 ptr 42.234.11.86.In-adDR.ArPA ; <<>> DiG 9.9.4-P1 <<>> +norec @193.0.9.5 ptr 42.234.11.86.In-adDR.ArPA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 57269 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;42.234.11.86.In-adDR.ArPA. IN PTR # dig +norec @193.0.9.5 ptr 42.234.11.86.IN-ADDR.ARPA ; <<>> DiG 9.9.4-P1 <<>> +norec @193.0.9.5 ptr 42.234.11.86.IN-ADDR.ARPA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18592 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;42.234.11.86.IN-ADDR.ARPA. IN PTR

12 let

How do I provide AXFR to the world?

by Anand Buddhdev

Hi people, For some zones I'm operating, I wish to provide AXFR to the world. How do I define a remote that matches 0.0.0.0/0 and ::/0? Regards, Anand

12 let

Graceful back-off for failing AXFRs

by Anand Buddhdev

Hi Knot developers, I'm testing Knot 1.4.0-rc2, which is configured with 5167 zones, all slaves. When I start Knot, it has to bootstrap all of them. It manages to bootstrap 4331 of them, but for the other 832, I get SERVFAIL from the master. Knot schedules retries for them within a 5-minute period, with some jitter. But with 832 zones, they keep coming up for AXFR continuously, and Knot keeps trying continuously. I'd like to request an improvement to Knot's scheduler so that it tries failing zones less and less frequently, to avoid being stuck in a retry cycle. How about some kind of exponentail back-off with a sane maximum of something like 24 hours? Before anyone asks why those 832 zones are SERVFAILing, I'll tell you. They're not under my direct control, and I can't get the operators to fix that easily, but I'm stuck with them, so I have to deal with them. Regards, Anand Buddhdev RIPE NCC

12 let

include directive in zones section

by Anand Buddhdev

Hello Knot developers, I appear to have run into a bug. I'm trying to run Knot 1.3.4, and the zones section of my config looks like this: zones { ripe.net { file "ripe.net.zone"; xfr-in admin; notify-in admin; } nro.net { file "nro.net.zone"; xfr-in admin; notify-in admin; } ... ... ... include "/etc/knot/ns.ripe.net.zones"; } However, when I try to verify this config, I get: # knotc -c default.conf checkconf 2013-12-20T22:43:19 [error] Config error in 'default.conf' (line 922 token ';') - syntax error 2013-12-20T22:43:19 [error] Couldn't parse config file, refusing to continue. If I remove the include directive, the configuration verifies. The documentation says I should be able to use the include directive almost anywhere in the config file. ---- A.9 include Statement The include statement is a special statement which can be used almost anywhere on any level in the configuration file. It makes inclusion of another file possible. The path of the included file can be either absolute or relative to a configuration file currently being processed. ---- Am I hitting some kind of bug where the include directive isn't being recognised inside the zones section? If it is a bug, I would *really* appreciate a fix if possible. I know it's Xmas and all, but I'm setting up some servers with Knot, and I'd love to be able to use the config this way instead of working around it. Regards, Anand

12 let

← Newer
1
...
62
63
64
65
66
67
68
...
75
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users