knot-dns-users Leden 2014

knot-dns-users@lists.nic.cz

11 participants
11 discussions

Case handling of zone names and in $ORIGIN

by Olafur Gudmundsson

I started to play with the dnssec signing features in Knot. I had this in my .conf file B-100.tld { file "B-100.zone"; …. } In the B-100.zone file I had $ORIGIN B-100.tld. I get Jan 31 16:27:32 bigredone knot[31315]: [error] Zone 'B-100.tld.': mismatching origin in the zone file. Jan 31 16:27:32 bigredone knot[31315]: [error] Failed to load zone 'B-100.tld.'. When I changed to $ORIGIN b-100.tld. Same error When I changed the conf line for B-100 to b-100 zone got loaded, I when I changed Origin to upper case but kept the lower case in conf file then zone was loaded. Summary: conf file requires zone name to be lower case, origin can be either case. (not documented) I do not think this what users expect. Either respect the case that users present or downcase both zone name and name on $ORIGIN line Also I would be great to have knot-checkzone command that one can use to verify the syntax of zone with output to standard output. Olafur

10 let, 10 měsíců

Knot DNS 1.4.2 patch release

by Jan Včelák

Hello List! We really appreciate your feedback on the previous release - both positive and negative. Thank you for that, it motivates us to make Knot DNS even better. Today, CZ.NIC Labs proudly announce the Knot DNS 1.4.2. There are quite a lot of changes: * The new release includes a compatibility fix for the AXFR/IXFR issues, which occurred when accepting transfers from tinydns/axfrdns. * In some cases, a TSIG did not fit into the outgoing transfer causing the transfer to be terminated. This problem was addressed as well. * Also, journal files are newly created only when necessary. It means that some disk space is spared when IXFR, DDNS, and DNSSEC signing are disabled. Feel free to delete the existing journal files if the zones fits into this category. * In addition, problems with incorrect logging categories regarding zones were reported. The logging was reviewed and should be appropriate with the new release. * We also fixed several problems in DNSSEC. Firstly, the 'knotc signzone' command was broken and caused a deadlock of the main server thread. It does not happen with the new version. Secondly, prior to this release, the signatures were refreshed two hours before their expiration, which was found to be extremely insufficient. With the new release, signatures are refreshed one tenth of the signature lifetime before their expiration. With the default configuration, the signature lifetime is 30 days, which implies that the signatures are refreshed three days before the expiration. * Moreover, RRSIGs in the additional records not-fitting into the DNS message do not cause packet truncation, but are simply skipped. We are looking forward to your reactions and comments. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.2.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, 10 měsíců

RRSIG in additional section: reason for TC?

by Hauke Lampe

Hello. I configured "max-udp-payload 1464" and noticed that Knot 1.4 sets tc if it can't fit RRSIGs for records in the additional section while 1.3.4 didn't. I was wondering what the reasoning is behind this behaviour. Shouldn't validating resolvers ignore unsigned record sets in the additional section anyway? In my tests, Knot 1.4 almost always sets tc unless it can fit all DNSKEYs, nameserver addresses and their signatures in the additional section. That seems a bit excessive. There are only a few narrow buffer sizes ranges that don't result in a truncated response, depending on the reply content: > $ l=""; i=1800; j=$i; while [ "$i" -lt "4097" ]; do n="`dig +bufsize=$i +ignore +norec +dnssec openchaos.org soa @nsig17.openchaos.org |grep ";; flags:"`"; [ "$l" != "$n" ] && { echo "$j - $(($i-1)): $l"; l=$n; j=$i; }; i=$(($i+1)); done; echo "$j - $(($i-1)): $n" > 1883 - 1898: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 4 > 2102 - 2129: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 6 > 2333 - 2348: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 8 > 2552 - 2567: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 10 > 2771 - 2798: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 12 > 3002 - 3017: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14 > 3221 - 3236: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 16 > 3440 - 3455: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 18 > 3659 - 3686: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 20 > 3890 - 4096: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 22 FWIW, the attached patch works for me. It should remove the last additional record if its RRSIG doesn't fit. Hauke

10 let, 11 měsíců

Warning messages does not contain domain name

by Petr Šťastný

Hi, the majority of warning messages does not contain particular domain name (zone name), so it is impossible to figure which zone file is wrong. For example: > 2014-01-23T20:13:07 [warning] encountered identical extra SOA record > 2014-01-23T20:13:07 [warning] encountered identical extra SOA record > 2014-01-23T20:13:07 [warning] TTL does not match TTL of its > RRSet.Changing to 19200 Can you please add zone names into all error and warning messages related to one zone? Thanks Petr Šťastný

10 let, 11 měsíců

Disable journals

by Petr Šťastný

Hello, I want to use Knot for master zones only without any DNS updates, so journal files are not needed. But they are created for every zone and it seems impossible to disable them. But this is bad in my situation when I want to serve 200000+ zones, because it creates 200000+ journal files in one directory (but they are never used). Should be possible to disable journal files or create them only in case of need or at lease divide them into more subdirectories? It would be also nice to be able to choose another directory for journal files in configuration. "storage" option is for both (zone files and journal files). Or explicitly state journal file path and filename in "zone" section. Thanks Petr Šťastný

10 let, 11 měsíců

Knot 1.4.0 a retezec duvery.

by Josef Karliak

Hoj vespolek. trosku jsem se uz ztratil s dnssecem s knotem. Vygeneroval jsem si klice, rekl knotu, kde ma klice hledat, knot je podepsal, zadna stiznost od nej. Klic jsem zadal i do keysetu na web4u, to proslo taky. Ale pokud si udelam drill my zony, drill oznami, ze mi chybi DS zaznam nebo trusted key: drill -TD ajetaci.cz Warning: No trusted keys were given. Will not be able to verify authenticity! ;; Domain: . ;; Signature ok but no chain to a trusted key or ds record [S] . 172800 IN DNSKEY 256 3 8 ;{id = 33655 (zsk), size = 1024b} . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} Checking if signing key is trusted: New key: . 172800 IN DNSKEY 256 3 8 AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX195Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6WybBZ6kuqED ;{id = 33655 (zsk), size = 1024b} [S] cz. 86400 IN DS 54576 10 2 397e50c85ede9cde33f363a9e66fd1b216d788f8dd438a57a423a386869c8f06 ;; Domain: cz. ;; Signature ok but no chain to a trusted key or ds record [S] cz. 18000 IN DNSKEY 256 3 10 ;{id = 40877 (zsk), size = 1024b} cz. 18000 IN DNSKEY 257 3 10 ;{id = 54576 (ksk), size = 2048b} cz. 18000 IN DNSKEY 256 3 10 ;{id = 54602 (zsk), size = 1024b} [S] Existence denied: ajetaci.cz. DS ;; No ds record for delegation ;; Domain: ajetaci.cz. ;; Signature ok but no chain to a trusted key or ds record [S] ajetaci.cz. 3600 IN DNSKEY 257 3 5 ;{id = 36256 (ksk), size = 2048b} ajetaci.cz. 3600 IN DNSKEY 256 3 5 ;{id = 11937 (zsk), size = 1024b} [S] ajetaci.cz. 3600 IN A 77.48.63.10 ;;[S] self sig OK; [B] bogus; [T] trusted -- 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, 11 měsíců

Logging categories

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ý

10 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

10 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

10 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

10 let, 11 měsíců

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users Leden 2014