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

by Horigome Yoshihito

Hello, all When using knot DNS resolver, the following error was output. Feb 06 20:19:43 dns02 kresd[24857]: error: /usr/lib/knot-resolver/predict.lua:34: 'struct rr_type' has no member named 'nil' $ kresd -V Knot DNS Resolver, version 1.2.1 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial Is it related to setting reorder_RR (true)? Is this a configuration issue in this case? Or is it a known bug? Thanks.

9 let, 3 měsíce

2
4
0 0

forward requests for only one zone

by Adam Bambuch

Hi, Is there any chance to configure the mod-dnsproxy to forward all requests for only one zone to another dns server? I have this configuration in bind configuration file: zone "example.com" IN { type forward; forwarders { 1.2.3.4; }; }; Is there any way to do it in knot? Best regards,

9 let, 3 měsíce

2
2
0 0

Knot Resolver 1.2.1 release

by Ondřej Surý

Dear Knot Resolver users, Knot Resolver 1.2.1 has been released. It was discovered during internal testing that under special query combinations the Knot Resolver can provide Insecure data from the cache on negative answers that would be otherwise Bogus due invalid signatures. The update from 1.2.0 to 1.2.1 is recommended. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.1.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 3 měsíce

1
0
0 0

Knot IXFR/AXFR issues

by Antti Ristimäki

Hello, We have a setup where a Knot DNS server is a slave and a DNS provisioning system acts as a hidden master. The DNS server process in the hidden master is some vendor specific implementation, not NSD, Bind or anything well-known. Now, for random zones we see the following errors in Knot when trying to update the zone: Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] notify, incoming, a:b:c:d::e@51097: received, serial none Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] refresh, outgoing, a:b:c:d::e@8054: remote serial 2017013116, zone is outdated Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] IXFR, incoming, a:b:c:d::e@8054: starting Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] IXFR, incoming, a:b:c:d::e@8054: failed (malformed data) Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] refresh, outgoing, a:b:c:d::e@8054: fallback to AXFR Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] refresh, remote '....' not usable As we can see, Knot first receives a notify message that triggers IXFR. For yet unknown reason, IXFR fails due to "malformed data", after which Knot fallbacks to AXFR. However, from tcpdump capture (I can share the pcap off-list, if needed) we can see, that Knot reuses the same TCP socket for AXFR as it used for IXFR, but immediately after sending the AXFR query Knot sends TCP RST to the hidden master thus closing the TCP connection, making the remote/master server to be unusable from Knot's point of view. The negative thing is that after the failure Knot gives up trying to update the zone, leaving the zone to its old SOA serial, maybe until it expires. So far we also don't know, what causes the IXFR to fail in the first place. From what we can see, the zone data seems to be valid so it's unclear why Knot fails with "malformed data". However, after manually running "knotc zone-retransfer <zone>" once, subsequent IXFRs succeed. Unfortunately we have very limited options to configure the hidden master, because as said, it is a vendor specific implementation. So we have two issues here: failing IXFR and then failure in AXFR fallback due to TCP connection reset on the Knot side. Do you have any ideas? Oh, forgot to mention that the Knot version is 2.4.0. Thank you in advance for all help, Antti

9 let, 3 měsíce

2
1
0 0

Knot DNS and statistics

by Frantisek Princ

Hello, after some testing I have deployed Knot DNS to one of our authoritative servers with almost 90k zones and it looks very well. I have one small problem with statistics, especiallly with interpreatation of statistics (mod-stats). There are some counters, but i cannot find any reliable approach, how to calculate numbers like queries per second, which is interesting for future hardware scaling. Did I missed anything? Or would it be possible to add one simple counter - something like server.uptime = (seconds from last reload).- because all counters are reset after reload. Finally, thanks for Knot DNS - well done! Best regards, Frantisek Princ

9 let, 3 měsíce

2
1
0 0

Unable to use mod-dnstap in 2.4.0

by Frantisek Princ

Hello, I am trying to use mod-dnstap on Knot DNS 2.4.0, but I am getting this error root@knot:~# knotc conf-check error: config, file '/etc/knot/knot.conf', line 27, item 'mod-dnstap', value '' (invalid item) error: failed to load configuration file '/etc/knot/knot.conf' (invalid item) Here is used configuration: server: user: knot:knot listen: [ 0.0.0.0@53, ::@53 ] log: - target: stderr any: warning - target: syslog server: info zone: notice any: error acl: - id: acl_dk-hostmaster address: [ 193.163.102.6, 2a01:630:0:40:3:4:5:6 ] action: transfer - id: acl_hu-hostmaster address: 193.239.249.0/24 action: transfer control: listen: knot.sock timeout: 30 mod-dnstap: - id: capture_all sink: /tmp/capture.tap template: - id: default global-module: mod-dnstap/captuer_all global-module: mod-stats include: /var/lib/knot-data/zones/zones_include_knot Knot DNS is installed on Debian Jessie from package (version 2.4.0-1+0~20170120113157.17+jessie~1.gbp8e34c2) I found similar topic in archives ( https://lists.nic.cz/pipermail/knot-dns-users/2016-September/000944.html ), but there was no solution. Regards, František Princ

9 let, 3 měsíce

2
4
0 0

knot 2.4 dnssec failure

by Bastien Durel

Hello, I've tried to upgrade from knot 2.3.3 to 2.4.0, but ran into a DNSSEC related error, invalidating my DNSSEC-enabled zones : 2017-01-25T15:33:42 notice: [geekwu.org.] journal, obsolete exists, file '/var/lib/knot/external/geekwu.org.db' 2017-01-25T15:33:42 error: [geekwu.org.] DNSSEC, failed to initialize (not found) 2017-01-25T15:33:42 error: [geekwu.org.] zone event 'load' failed (not found) stracing the error leads to this : [pid 16787] open("/var/lib/knot/external/keys/policy_\\x06policy.json", O_RDONLY) = -1 ENOENT (No such file or directory) I have some policy files in /var/lib/knot/external/keys: -rw-r--r-- 1 knot knot 320 janv. 26 2016 policy_default.json -rw-r--r-- 1 knot knot 320 janv. 26 2016 policy_default_rsa.json -rw-r--r-- 1 knot knot 320 juin 14 2016 policy_ecdsa.json >From where these \\x06policy may come ? Thanks, -- Bastien

9 let, 3 měsíce

4
3
0 0

Knot Resolver 1.2.0 release

by Ondřej Surý

Dear Knot Resolver users, CZ.NIC is proud to release a new release of Knot Resolver. The team has worked very hard to bring: - reworked DNSSEC Validation, that fixes several know problems with less standard DNS configurations, and it is also a solid base for further improvements - optional EDNS(0) Padding support for DNS over TLS - support for debugging DNSSEC with CD bit - DNS over TLS is now able to create ephemeral certs on the runtime (Thanks Daniel Kahn Gilmore for contributing to DNS over TLS implementation in Knot Resolver.) - configurable minimum and maximum TTL (default 6 days) - configurable pseudo-random reordering of RR sets - new module 'version' that can call home and report new versions and security vulnerabilities to the log file This release also fixes bugs, most notable ones: - The resolver was setting AD flag when running in a forwarding mode. Thanks Stéphane Bortzmeyer for reporting this issue! - We now correctly return RCODE=NOTIMPL on meta-queries and non IN class queries - Fix crash in hints module when hints file was empty - Fix non-lowercase hints We also have a new LRU implementation under the hood. That's it! Thank you for using Knot Resolver. And if you are not using it yet, please give it a try. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 3 měsíce

1
0
0 0

Knot DNS 2.4.0 released

by Ondřej Surý

Dear Knot DNS users, CZ.NIC is proud to release the 2.4.0 release of Knot DNS. This release contains many improvements over 2.3.x release of Knot DNS. The Knot DNS 2.4.x is the new stable branch. Starting from this release we are going to support current stable (2.4.x) and previous stable (2.3.x) branches, and at the same time we are deprecating previous Knot DNS 1.6.x release. Now the new features we are so excited about! * We have a new journal to store zone changes, it's key features are: - all journals for all zones are in a single LMDB database (defaults to storage/journal; 1G size) - the occupied space is measured per zone - old changesets get preserved after zone flush until we run out of space - if zone flushing is disabled and journal gets full, it tries to free up space by merging older changesets - all changes are done by transactions, resulting in always-consistent DB (but some mutexes still necessary for opening DB && for keeping zone contents consistent with journal) - kjournalprint provides a way to list zones in journal - old journal is automatically imported, but the configuration needs to be updated manually * Thanks to qp-trie (originally proposed by Tony Finch) adapted to Knot DNS we have much lower memory consumption when Knot DNS is used with many zones * The zone timers and zone events have been refactored and improved * The SOA query and transfer now shares the TCP connection * There's a new statistics module for traffic measurements There are also several other bugfixes and improvements related to transfers, timers and other areas. And that's it! Thank you for using Knot DNS. And we are really looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.4.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.4.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 3 měsíce

5
6
0 0

DS record digest

by Jakub Andrys

Hi, can someone please give me any explanation (or command) how my domain registrator got from this record what i give him: liberland.cz. 3600 DNSKEY 257 3 13 ei9T3egqng+nlAHeNfF6BzggGCyvS2lU5ih2BZuvkzFGxkBdUJ0blgSiW5iYIROvAEHQv5Ls3sNPA9JIt8iRjg== this record: liberland.cz. 17999 IN DS 21107 13 2 9405F3324FDCE3F0CC4E5D94CBFB5D8A4F211E3010D447B5FD73765F9EEC20EB ??? I want sign child zones but I can't find where i get hash ,,9405F3324FDCE3F0CC4E5D94CBFB5D8A4F211E3010D447B5FD73765F9EEC20EB" And algorithm in RFC: https://tools.ietf.org/html/rfc4034#section-5.4 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); "|" denotes concatenation DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. doesn't help me :-/ Thanks and regards, Jakub

9 let, 3 měsíce

3
3
0 0

Knot Resolver 1.2.0-rc1 (Release Candidate 1) release

by Ondřej Surý

Dear Knot Resolver users, CZ.NIC is proud to release a new release candidate of Knot Resolver. The team has worked very hard to bring: - reworked DNSSEC Validation, that fixes several know problems with less standard DNS configurations, and it is also a solid base for further improvements - optional EDNS(0) Padding support for DNS over TLS - support for debugging DNSSEC with CD bit - DNS over TLS is now able to create ephemeral certs on the runtime (Thanks Daniel Kahn Gilmore for contributing to DNS over TLS implementation in Knot Resolver.) - configurable minimum and maximum TTL (default 6 days) - configurable pseudo-random reordering of RR sets - new module 'version' that can call home and report new versions and security vulnerabilities to the log file This release also fixes bugs, most notable ones: - The resolver was setting AD flag when running in a forwarding mode. Thanks Stéphane Bortzmeyer for reporting this issue! - We now correctly return RCODE=NOTIMPL on meta-queries and non IN class queries - Fix crash in hints module when hints file was empty - Fix non-lowercase hints We also have a new LRU implementation under the hood. That's it! Thank you for using Knot Resolver. And if you are not using it yet, please give it a try. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.0-rc1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0-rc1.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 3 měsíce

2
3
0 0

mod-synth-record + DNSSEC = SERVFAIL

by Alarig Le Lay

Hi, I use mod-synth-record to provide some reverse records for a LAN. mod-synth-record: - id: tregon-grifon type: forward prefix: ip6- ttl: 400 network: 2a00:5884:8316::/48 mod-synth-record: - id: tregon-grifon-reverse type: reverse prefix: ip6- origin: tregon-grifon.swordarmor.fr ttl: 400 network: 2a00:5884:8316::/48 They are both very simple: eddy ~ # cat /var/lib/knot/tregon-grifon.swordarmor.fr.zone.nodnssec @ 864000 IN SOA tregon-grifon.swordarmor.fr. hostmaster.swordarmor.fr. ( 2 3600 900 1209600 43200 ) 864000 IN NS tregon-grifon.swordarmor.fr. IN AAAA 2a00:5884:8316::1 A 89.234.186.16 eddy ~ # cat /var/lib/knot/6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa.zone.nodnssec @ 864000 IN SOA tregon-grifon.swordarmor.fr. hostmaster.swordarmor.fr. ( 2 3600 900 1209600 43200 ) 864000 IN NS tregon-grifon.swordarmor.fr. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR tregon-grifon.swordarmor.fr. 6.2.4.c.f.6.5.5.d.7.4.d.0.4.d.f.3.5.6.2 IN PTR pika-tregon.swordarmor.fr. tregon-grifon.swordarmor.fr. is signed with DNSSEC, but I have a RRSIG only for the records in the pasted file. alarig@pikachu ~ % dig -t RRSIG tregon-grifon.swordarmor.fr. ; <<>> DiG 9.10.4-P3 <<>> -t RRSIG tregon-grifon.swordarmor.fr. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53081 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tregon-grifon.swordarmor.fr. IN RRSIG ;; ANSWER SECTION: tregon-grifon.swordarmor.fr. 3600 IN RRSIG A 13 3 3600 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. YlT/vCMLDyGHwKLoMOdQqENwWTyhphrbBatKhhtvCteTubwBp9FCrf9b /jc0cRM07a321de7kw3cYPD3lfbPYA== tregon-grifon.swordarmor.fr. 864000 IN RRSIG NS 13 3 864000 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. l6HiWFaqz3Hys7aknEHEG6woKJ9xdYqopxNUTOYmMk94733jMnDiH5bx fDKGPjgyVCkbQWfFsJCr/udwnelSaQ== tregon-grifon.swordarmor.fr. 864000 IN RRSIG SOA 13 3 864000 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. OUWibAYe8oyRBWgGyPAxG0etUcGQe1ZEZ+1ywZIi1xQvhWMQy/0B+HNH RyQYYdJ9eXqXPP3uQRyXPTtsa+9KKQ== tregon-grifon.swordarmor.fr. 3600 IN RRSIG AAAA 13 3 3600 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. NIEEeURn0/RH9IqWxGM9W74Gf8UqDh4Bqap0NlZ4XQ+95FpfylAQKxo0 KZUNCDCXCFQ4Rpg/dJH4EhpWw8Pxtw== tregon-grifon.swordarmor.fr. 43200 IN RRSIG NSEC 13 3 43200 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. 6T2+GjrRU8qU/zGNmY8R9bmkNUFGPJuJQP2qkhakV0GeiyseEWA5yPDE /YIELH04KKAE3yrudo8S6xcaQ6DveQ== tregon-grifon.swordarmor.fr. 864000 IN RRSIG DNSKEY 13 3 864000 20161208210625 20161124210625 57104 tregon-grifon.swordarmor.fr. F/jepDBqQriHFUSN8mnkiNZ6l3vP5K8ob44yuHkHBupimIo4S6hvuZXD F7AnbF5GtVsZPDdjA4qumkv1HaiTFQ== ;; Query time: 160 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Mon Nov 28 11:02:27 CET 2016 ;; MSG SIZE rcvd: 794 alarig@pikachu ~ % dig -t RRSIG ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ; <<>> DiG 9.10.4-P3 <<>> -t RRSIG ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27161 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. IN RRSIG ;; Query time: 457 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Mon Nov 28 11:02:33 CET 2016 ;; MSG SIZE rcvd: 100 So, I get a SERVFAIL when I try to resolve the AAAA. alarig@pikachu ~ % dig -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ; <<>> DiG 9.10.4-P3 <<>> -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38279 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. IN AAAA ;; Query time: 2701 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Mon Nov 28 11:02:47 CET 2016 ;; MSG SIZE rcvd: 100 But it works perfectly if I use a resolver that does not verify DNSSEC alarig@pikachu ~ % dig -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. @ns0.fdn.fr ; <<>> DiG 9.10.4-P3 <<>> -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. @ns0.fdn.fr ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55433 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. IN AAAA ;; ANSWER SECTION: ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. 400 IN AAAA 2a00:5884:8316:2653:fd40:d47d:556f:c427 ;; AUTHORITY SECTION: tregon-grifon.swordarmor.fr. 10800 IN NS tregon-grifon.swordarmor.fr. ;; ADDITIONAL SECTION: tregon-grifon.swordarmor.fr. 10800 IN A 89.234.186.16 tregon-grifon.swordarmor.fr. 10800 IN AAAA 2a00:5884:8316::1 ;; Query time: 105 msec ;; SERVER: 2001:910:800::12#53(2001:910:800::12) ;; WHEN: Mon Nov 28 11:03:33 CET 2016 ;; MSG SIZE rcvd: 186 -- alarig

9 let, 5 měsíců

4
5
0 0

Segfault in knot 2.3.1-1~bpo8+ and 2.3.2-1

by Jeroen Massar

Hola, As recently a variety of people claimed to me that 'running DNSSEC is not scary'.... I was like, lets try again after having tried it ~10 years ago and it failing miserably. DNSSEC auto-maintain style looks to be better; still not as nice as running dual-nsd's in master mode; but we'll live with those moving parts. It ran fine for a bit, till I noticed the signatures of the zone had expired and noticed the master simply did not bother to update the sigs anymore. So much for 'automatic' mode. Restarting it caused a nice crash: Debian provided jessie-backports 2.3.1-1~bpo8: ``` knotd[6679]: *** Error in `/usr/sbin/knotd': double free or corruption (out): 0x00007f4244042e80 *** ``` Then was like... lets try the latest edition: Debian provided unstable 2.3.2-1: ``` knotd[11892] general protection ip:7fb8f7f0f218 sp:7fb8ce1cc3b0 error:0 in libc-2.24.so[7fb8f7e98000+195000] ```` yes, that is on a newer libc, hence different style error message it seems. The 2.3.1 edition was able to report: ``` error: [example.com] changes from journal applied 1 -> 1 (invalid parameter) ```` before crashing out, the 2.3.2 just borks out. Unfortunately there are no dbgsym packages for those editions, thus can't easily dig what goes wrong where without having to resort to manually building it all. I could also not find a way to signup to: https://gitlab.labs.nic.cz/users/sign_in to be able to file a ticket about this. Any extra details that one should be providing outside of the above (link to that list is welcome ;) ) Should I attempt knot-nightly? Greets, Jeroen PS: News on https://labs.nic.cz/en/ ends in April 2016...

9 let, 5 měsíců

4
9
0 0

Knot DNS 2.3.3 released!

by Ondřej Surý

Dear Knot DNS users, CZ.NIC is proud to release a new version of Knot DNS. This is mainly bug fix release, but there are some small improvements included as well. There are few fixes related to timers and DNSSEC. We have also fixed double free in journal code, and memory leak in kzonecheck. All domains are now fully-qualified in the logs and there's a new utility to print journal contents - kjournalprint. We would also like to invite everyone to migrate from Knot DNS 1.6.x to the current stable Knot DNS 2.x.x release. And that's it! Thank you for using Knot DNS. And we are really looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.3.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.3.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 5 měsíců

2
1
0 0

Creating TXT/SPF records

by Tom Preissler

Hi, I am just about to create some SPF records for my domain, and it seems I can't do it the right way. The record should look like preissler.co.uk. 3600 TXT "v=spf1 mx -all" and I am creating it with knotc, interactive or not doesn't matter. knotc zone-begin preissler.co.uk knotc zone-unset preissler.co.uk preissler.co.uk. 3600 TXT "v=spf1 mx -all" knotc zone-commit preissler.co.uk this then gives me [preissler.co.uk.] preissler.co.uk. 3600 TXT "v=spf1" "mx" "-all" which is wrong. If I use "'" it's the same. Then using knotc zone-set preissler.co.uk preissler.co.uk. 3600 TXT v=spf1 mx -all I get error: (name does not belong to the zone) [preissler.co.uk] preissler.co.uk. 3600 TXT v=spf1 mx -all I am aware I could just edit the zonefiles or use DDNS probably... but surely, there must be a way? Regards Thomas -- www.preissler.co.uk | Twitter: @module0x90 GPG: BA359D78200264B363314AF5E3839138A11FFD2A

9 let, 5 měsíců

2
2
0 0

Knot na FreeBSD v jailu

by Pavol

Dobry den, pokousim se rozbehnout knot-2.3.1 (kompilace z ports) na jailu na FreeBSD 11 Problem je v tom, ze knot neodpovida na udp portu a to i kdyz to zkousim primo v jailu. Jine porty napr. smtp primo z jailu funguji, mozna je to jenom nejaka chyba v nastaveni knot-2.3.1 Toto vsechno jsem zkousel: * netcat z jailu na stejny jail udp port 53 - funguje * netcat z hostu do jailu udp 53 - funguje * netcat z jineho hostu na host kde bezi jail udp 53 - funguje Takto to dopadne primo z jailu ale i z jineho hosta: # kdig liguros.net aaaa @ns1.liguros.net ;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP) ;; WARNING: response timeout for 5.135.156.9@53(UDP) ;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP) ;; WARNING: response timeout for 5.135.156.9@53(UDP) ;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP) ;; WARNING: response timeout for 5.135.156.9@53(UDP) ;; WARNING: failed to query server ns1.liguros.net@53(UDP) Toto vidim v pfctl -s states all udp 2001:470:cadd:1::5[53] <- 2001:470:cadd:2::53[60288] NO_TRAFFIC:SINGLE all udp 2001:470:cadd:1::5[53] <- 2001:470:cadd:2::53[40209] NO_TRAFFIC:SINGLE relevantni rules pass in inet6 proto tcp from any to 2001:470:cadd:1::5 port = domain flags S/SA keep state pass in inet6 proto udp from any to 2001:470:cadd:1::5 port = domain keep state takto jsou jeste nastavene rdr na ip4 adresu jailu: rdr pass on em0 inet proto tcp from any to any port = domain -> 10.0.0.5 rdr pass on em0 inet proto udp from any to any port = domain -> 10.0.0.5 rdr pass on lo1 inet proto tcp from any to any port = domain -> 10.0.0.5 rdr pass on lo1 inet proto udp from any to any port = domain -> 10.0.0.5 i kdyz nemyslim si, ze je to pf vina, protoze se do jailu napr. pomoci netcat "dostanu" ns jail: ns:/usr/ports/dns/knot2@[22:44] # sockstat USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root knotd 1650 7 dgram -> /var/run/logpriv root knotd 1650 8 udp4 10.0.0.5:53 *:* root knotd 1650 9 tcp4 10.0.0.5:53 *:* root knotd 1650 10 udp6 2001:470:cadd:1::5:53 *:* root knotd 1650 11 tcp6 2001:470:cadd:1::5:53 *:* root knotd 1650 15 stream /var/run/knot/knot.sock Poradte mi prosim, jak danou vec dale debugovat. Predem mockrat dekuji. Pavol ############################################### English follows ############################################### I am trying to get knot 2.3.1 (from ports) working in a jail, but I am unable to connect to the udp port even when trying directly from jail. Using netcat from within jail and also from other machines gets through into the jail. I don't think it is pf's fault. How can I debug this a bit more? Thank you for your help Pavol -- Email encryption for everyone via @fsf https://u.fsf.org/zb

9 let, 5 měsíců

3
3
0 0

Re: [knot-dns-users] Knot na FreeBSD v jailu

by Pavol

Thank you, this (--enable-recvmmsg=no) fixes it for me. Hopefully the patch and new version will get into ports soon. Thank you very much for your help. Pavol, now with working DNS on FreeBSD :) On 24.11.2016 13:05, Leo Vandewoestijne wrote: > On Thu, 24 Nov 2016, Vladim??r ??un??t wrote: > >> Hi, >> I hope English will be understandable enough (to you). >> >> On 11/23/2016 11:00 PM, Pavol wrote: >>> I am trying to get knot 2.3.1 (from ports) working in a jail, but I am >>> unable to connect to the udp port even when trying directly from jail. >>> Using netcat from within jail and also from other machines gets >>> through into the jail. I don't think it is pf's fault. >>> >>> How can I debug this a bit more? >> >> Was knot compiled with recvmmsg support? The FreeBSD implementation of >> this was buggy and I don't know which version got fixed: >> https://github.com/freebsd/freebsd/pull/91 >> It's possible to disable the functions by passing --enable-recvmmsg=no >> to ./configure. >> > I was already on that, and requested that two weeks ago: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214303 > > Somehow my confirm did not came trough, I just did that again. > > -- > > With kind regards, > > > Leo Vandewoestijne > <***(a)dns.company> > <www.dns.company> > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users > -- Email encryption for everyone via @fsf https://u.fsf.org/zb

9 let, 5 měsíců

1
0
0 0

Don't preserve CD flag?

by John-Paul Gignac

I'm an engineer at Dyn and I work on the same team as Matthijs Mekking. I noticed that commit 3f950e1d ( https://gitlab.labs.nic.cz/labs/knot/commit/3f950e1d3f323b0ebbd339de29f8c8b…) changes the handling of the CD bit in responses. The test code comments indicate that this is in accordance with https://tools.ietf.org/html/rfc4035#section-3.1.6, but my reading is that it contradicts section 3 of the same RFC. I was wondering if somebody could explain the history or the thinking behind this change. Thanks in advance! John-Paul Gignac

9 let, 6 měsíců

2
2
0 0

"make check" FAIL with 1.6.0/1.6.8 on Arch Linux

by Tom Preissler

Hi, I am about to migrate my authoritative Bind instance to Knot. My server is Debian Jessie, and the available packge there is 1.6.0-1. I wanted to play on my Arch Linux installation at home to try the migration out, so I am trying to compile aur/knot-lts, which is 1.6.8-1. Compiling it is fine, but "make check" fails: dnssec_sign.............FAILED 45, 50, 53, 56 (killed by signal 6, core dumped) I tried 1.6.0 directly from source as well, same for 1.6.8 from source. I even downloaded the Debian source and compiled that on AL, same error. ldd tests/.libs/lt-dnssec_sign linux-vdso.so.1 (0x00007ffc1a1d2000) libknot.so.0 => /home/tomtom/Rubbish/knot-dns/knot-lts/knot-1.6.0/src/.libs/libknot.so.0 (0x00007fda7c3b4000) liblmdb.so => /usr/lib/liblmdb.so (0x00007fda7c19f000) libzscanner.so.0 => /home/tomtom/Rubbish/knot-dns/knot-lts/knot-1.6.0/src/zscanner/.libs/libzscanner.so.0 (0x00007fda7bf45000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fda7bd2f000) libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007fda7bb29000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fda7b925000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fda7b708000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fda7b404000) liburcu.so.4 => /usr/lib/liburcu.so.4 (0x00007fda7b1fc000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fda7ad84000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fda7a9e6000) /lib64/ld-linux-x86-64.so.2 (0x00007fda7c5db000) liburcu-common.so.4 => /usr/lib/liburcu-common.so.4 (0x00007fda7a7e1000) Versions: usr/lib/liblmdb.so is owned by extra/lmdb 0.9.18-2 usr/lib/libz.so.1 is owned by core/zlib 1.2.8-4 usr/lib/libcap-ng.so.0 is owned by extra/libcap-ng 0.7.8-1 usr/lib/libdl.so.2 is owned by core/glibc 2.24-2 usr/lib/libpthread.so.0 is owned by core/glibc 2.24-2 usr/lib/libm.so.6 is owned by core/glibc 2.24-2 usr/lib/liburcu.so.4 is owned by community/liburcu 0.9.2-1 usr/lib/libcrypto.so.1.0.0 is owned by core/openssl 1.0.2.j-1 usr/lib/libc.so.6 is owned by core/glibc 2.24-2 usr/lib/liburcu-common.so.4 is owned by community/liburcu 0.9.2-1 I have attached the detailed segfault output separately. Regards Tom -- www.preissler.co.uk | Twitter: @module0x90 GPG: BA359D78200264B363314AF5E3839138A11FFD2A

9 let, 6 měsíců

2
2
0 0

Knot Resolver 1.1.0-8 is caching delegation's TTL instead of zone's TTL

by Arsen STASIC

Hi, I have recently started using Knot Resolver. Thanks for that really nice piece of software. Knot Resolver seems to cache the TTL of parent zone (= delegation) instead of the TTL which is in the zone itself. dig +noall +auth @n.ns.at univie.ac.at ns univie.ac.at. 10800 IN NS ns3.univie.ac.at. univie.ac.at. 10800 IN NS ns4.univie.ac.at. univie.ac.at. 10800 IN NS ns5.univie.ac.at. univie.ac.at. 10800 IN NS ns7.univie.ac.at. univie.ac.at. 10800 IN NS ns8.univie.ac.at. univie.ac.at. 10800 IN NS ns10.univie.ac.at. dig +noall +ans @ns10.univie.ac.at univie.ac.at ns univie.ac.at. 600 IN NS ns7.univie.ac.at. univie.ac.at. 600 IN NS ns4.univie.ac.at. univie.ac.at. 600 IN NS ns8.univie.ac.at. univie.ac.at. 600 IN NS ns3.univie.ac.at. univie.ac.at. 600 IN NS ns5.univie.ac.at. univie.ac.at. 600 IN NS ns10.univie.ac.at. dig +noall +ans @ns10.univie.ac.at ns10.univie.ac.at a ns10.univie.ac.at. 600 IN A 192.76.243.2 Knot Resolver is caching 10800 instead of 600: dig +noall +answer @127.0.0.1 ns10.univie.ac.at a ns10.univie.ac.at. 10634 IN A 192.76.243.2 Bind, unbound and pdns-recursor cache authoritative TTL (600). I have tried to file a bug report at https://gitlab.labs.nic.cz/labs/knot/issues , but I wasn't able to create a user account. cheers, -arsen

9 let, 6 měsíců

2
1
0 0

Knot DNS 2.3.2

by Ondřej Surý

Dear Knot DNS users, CZ.NIC has just released a new version of Knot DNS. This is mainly bug fix release, but there are some small improvements included as well. There are few fixes related to templates (the root zone now expands to an empty string), timers (zone transfer refresh), ENTs and CD bit handling. knotc is now faster and zone purge also purges timers. You can also specify a journal path and timeout of dnsproxy module. We would also like to invite everyone to migrate from Knot DNS 1.6.x to the current stable Knot DNS 2.x.x release. And that's it! Thank you for using Knot DNS. And we are really looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.3.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.2.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 6 měsíců

1
0
0 0

Enable Multi Core CPU in KnotDNS

by shidiq＠pandi.id

Hi All, i'm using knot dns in centos 7 and cpu usage average is 70-90%. i have multi core cpu in this server, but just 1 cpu use by knot DNS. How to enable more than 1 core cpu in knot dns? Thanks, .shidiq

9 let, 6 měsíců

2
1
0 0

xip.io functionality with Knot?

by Tobias Brunner

Hi Knot people, As xip.io is very unreliable, I was wondering if it is possible to achieve a similar service with Knot? Examples what xip.io is doing: 10.0.0.1.xip.io resolves to 10.0.0.1 www.10.0.0.2.xip.io resolves to 10.0.0.2 foo.10.0.0.3.xip.io resolves to 10.0.0.3 bar.baz.10.0.0.4.xip.io resolves to 10.0.0.4 Cheers, Tobias

9 let, 6 měsíců

2
1
0 0

snapshot 186526

by Bastien Durel

Hello, I see there's an "unreleased" snapshot in http://deb.knot-dns.cz/knot/ repository, is it intentionnal ? The following packages are currently pending an upgrade: knot 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 knot-dnsutils 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 libdnssec2 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 libknot4 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 libzscanner1 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 ======================================================================== Package Details: Reading changelogs... --- Changes for knot (knot knot-dnsutils libdnssec2 libzscanner1) --- knot (2.3.1-1+0~20161025234932.8+jessie~1.gbp186526) unstable; urgency=medium ** SNAPSHOT build @18652664b6e8eeb47ba878c1ff6790f5b6ce3451 ** * UNRELEASED -- Ondřej Surý <ondrej(a)sury.org> Wed, 26 Oct 2016 01:49:34 +0200 Regards, -- Bastien

9 let, 6 měsíců

1
0
0 0

knot 2.3.0-3: Automatic DNSSEC signing: Current limitations and creating trusted-keys { ... }

by georg＠riseup.net

Hi all, I'm running {knot,knot-dnsutils} 2.3.0-3~bpo8+1 out of Debian jessie-backports, and enabled automatic DNSSEC signing, which works great! I've got two question, as per the subject: - According to [1], "KSK rollover is not implemented.". Does this mean, if the key was created and exists, then currently knot doesn't change / rollover the KSK? Is it safe to assume, that as long one is using this version, the key stays the same? - I'm running Unbound to do resolving and forwarding some forward and corresponding reverse zones to knot. To make DNSSEC work, I've created a trusted-keys { ... } file with all the KSK created and used by / with knot. Right now, I've created this file manually, using $ keymgr zone key show ... and $ cat $name_of_zone.json and putting it all together. Right now, is there a tool / utility / command which does this already? TIA and all the best, Georg [1] https://www.knot-dns.cz/docs/2.x/html/configuration.html#limitations

9 let, 6 měsíců

4
5
0 0

What is stored in Knot's zone timer database?

by Anand Buddhdev

Dear Knot devs, When Knot writes out the zone timer database, what pieces of information about a zone are stored? Regards, Anand

9 let, 6 měsíců

3
4
0 0

is there a out-of-the-box receipt to use knot as a DNS cache for a Tor exit relay ?

by Toralf Förster

As a lazy slacker I do wonder about such a knot-in-a-nutshell-for-tor-exit-relay-operator-dummies doc ? ;) -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7

9 let, 7 měsíců

3
6
0 0

Multi-value options in "template" and "zone" sections

by Anand Buddhdev

Hi, This is mainly a question for the Knot developers. Suppose I have: template: - id: default acl: acl1 zone: - domain: zone acl: acl2 Does "zone" get "acl2" or "acl1, acl2" applied to it? Regards, Anand

9 let, 7 měsíců

2
3
0 0

Knot DNS 2.3.1 release

by Ondřej Surý

Hi fellow Knot DNS users and other mailing list lurkers, CZ.NIC just released a new version of Knot DNS. There are some bug fixes and improvements as usual. We fixed missing glue records in some responses, and there were some other minor nits. The most notable improvement was a speed-up of conf-commit and conf-diff operations when using zonedb. Users with hundred thousands zones and more will be amazed (we hope). There's also new EDNS Client Subnet API in libknot soon to be used in our sibling project Knot Resolver. On the new features front, kdig now can print TLS hierarchy for DNS over TLS, the knotc now contains zone-purge command and we have new mod-whoami module and new dnstap logging options contributed by Robert Edmonds. We would also like to invite everyone to migrate from Knot DNS 1.6.x to the current stable Knot DNS 2.x.x release. And that's it! Thank you for using Knot DNS. And we are really looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.3.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ Regards, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 7 měsíců

1
0
0 0

Where can I found the module of Geoip

by hou guanghua

Dear<https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users> sir, In the discussion issue, the feature "view" as bind will be supported next version. Where can I found the source code of module Geoip? Regards, Guanghua

9 let, 7 měsíců

1
0
0 0

Knot 2 on CentOS 6

by Anand Buddhdev

I would like to thank Jan Včelák for submitting the gnutls30 package into EPEL 6. This allows one to build Knot 2 for RHEL/CentOS 6 without having to hunt down any dependencies. We still run CentOS 6 and it's useful to be able to upgrade to Knot 2 on our servers. Thanks Jan! Regards, Anand

9 let, 7 měsíců

2
1
0 0

configuring dnstap in knot 2.2.1

by Lowell Mower

Hello: I've compiled knot 2.2.1 and configured with the --enable-dnstap flag but continue to get errors when starting knot and configuring it to use dnstap to write to a file see below: * * * * * * * * * * * * * * * * * * * * * * * * ./configure: knot 2.2.1 Target: linux-gnu x86_64 Compiler: gcc -std=gnu99 CFLAGS: -g -O2 -Wall -Werror=format-security -Werror=implicit -fpredictive-commoning LIBS: -lcap-ng -ldl -lpthread -lm LibURCU: -lurcu GnuTLS: -lgnutls -lnettle -I/usr/include/p11-kit-1 Jansson: -ljansson Libedit: -ledit -I/usr/include/editline LMDB: embedded Sanitizer: LibFuzzer: no Prefix: /usr/local Run dir: ${prefix}/var/run/knot Storage dir: ${prefix}/var/lib/knot Config dir: ${prefix}/etc/knot Configuration DB mapsize: 500 MiB Timers DB mapsize: 100 MiB Knot DNS libraries: yes Knot DNS daemon: yes Knot DNS utils: yes Knot DNS documentation: yes Use SO_REUSEPORT: yes Fast zone parser: no Utilities with IDN: no Systemd integration: no Dnstap support: yes Code coverage: no Bash completions: no PKCS 11 support: no Continue with 'make' command * * * * * * * * * * * * * * * * * * * * * * * * /etc/knot.conf server: listen: 100.88.99.132 nsid: knot-2.2.1-dnsproxy-0.1.0 log: - target: syslog any: info remote: - id: authcore address: 127.0.0.1@53535 mod-dnsproxy: - id: sdt remote: authcore template: - id: default global-module: mod-dnsproxy/sdt mod-dnstap: - id: capture_all sink: /tmp/dnstap.tap template: - id: default global-module: mod-dnstap/capture_all * * * * * * * * * * * * * * * * * * * * * * * * knotc -c /etc/knot.conf reload error: config, file '/etc/knot.conf', line 21, item 'mod-dnstap', value '' (invalid item) error: failed to load configuration file '/etc/knot.conf' (invalid item) * * * * * * * * * * * * * * * * * * * * * * * * I've tried various configurations and have been using: https://www.knot-dns.cz/docs/2.x/html/configuration.html#dnstap-dnstap-enab… as a guide. What am I missing?

9 let, 8 měsíců

3
4
0 0

DNS Cookies support

by Ulrich Wisser

Hi everybody! Today I wrote some code to test support for DNS Cookies. But unfortunately I couldn't find any servers supporting DNS Cookies. Of course this is most likely an error in my code. I couldn't find anything in the documentation, so my question is, does knot 2.3.0 support DNS Cookies? Could someone please point me to a server supporting DNS Cookies? What would be a good test? Right now I do send a query with a cookie and see if I get a cookie in return. Kind Regards Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 8 měsíců

3
4
0 0

Re: [knot-dns-users] Error with secondaries: IXFR failed to start (not enough memory)

by daniel.salzman＠nic.cz

On 2016-08-22 19:55, Hugo Salgado wrote: > Hi Daniel. > Yes, I changed the storage directory to other location with right > permissions, and now the logs said: > > 2016-08-22T17:52:21 info: [manojitos.cl] zone loader, semantic check, > completed > 2016-08-22T17:52:21 info: [manojitos.cl] loaded, serial 2016010416 -> > 2016010417 > 2016-08-22T17:52:21 info: [manojitos.cl] NOTIFY, outgoing, > 200.1.123.7@53: serial 2016010417 > 2016-08-22T17:52:22 info: [manojitos.cl] IXFR, outgoing, > 200.1.123.7@16933: incomplete history, fallback to AXFR > 2016-08-22T17:52:22 info: [manojitos.cl] AXFR, outgoing, > 200.1.123.7@16933: started, serial 2016010417 > 2016-08-22T17:52:22 info: [manojitos.cl] AXFR, outgoing, > 200.1.123.7@16933: finished, 0.00 seconds, 1 messages, 3820 bytes > > So there's no error. > > Thanks a lot. Can I suggest to improve the previous error log? Maybe > if it can say "bad permission" instead of "not enough memory" could > be better to administrators :) > Of course, the message is very confusing. Best, Daniel > Best, > > Hugo > > > On 08/22/2016 01:22 PM, daniel.salzman(a)nic.cz wrote: >> Hi, >> >> You have the storage directory under /etc. I suspect the server is not >> allowed to create a zone journal file there. The journal is important >> for IXFR. >> Could you verify that? In such a case you can configure proper >> zone.file location >> but different zone.storage directory. >> >> Daniel >> >> On 2016-08-22 16:18, Hugo Salgado wrote: >>> Hi Daniel. Here I'm attaching my .conf. >>> >>> Thanks a lot! >>> >>> Hugo >>> >>> On 08/22/2016 05:46 AM, Daniel Salzman wrote: >>>> Hi Hugo, >>>> >>>> I can't reproduce your problem. Could you send me your configuration >>>> file >>>> please? Don't forget to mangle sensitive information, like TSIG key. >>>> >>>> Thank you, >>>> Daniel >>>> >>>> On 08/19/2016 07:57 PM, Hugo Salgado wrote: >>>>> Hi. >>>>> I have a KNOT master with a small zone (32 records), which is >>>>> logging an >>>>> error after the secondary (BIND) tries to update the zone. AFAIK, >>>>> Bind >>>>> tries with IXFR first, but my master says: >>>>> >>>>> 2016-08-19T16:32:12 error: [manojitos.cl] IXFR, outgoing, >>>>> 200.1.123.7@29095: failed to start (not enough memory) >>>>> >>>>> After that the secondary retries with AXFR, and that works: >>>>> >>>>> 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, >>>>> 200.1.123.7@13644: started, serial 2016011013 >>>>> 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, >>>>> 200.1.123.7@13644: finished, 0.00 seconds, 1 messages, 2573 bytes >>>>> >>>>> The error is the same the first time I provision the zone in the >>>>> secondary as in following updates. Is there a bug in the error >>>>> message, >>>>> or should I worry for some memory requirement in my server (or >>>>> service)? >>>>> >>>>> I'm with Knot 2.3.0 on a FreeBSD 10.3-release-p7. The secondary is >>>>> not >>>>> under my administration, but I was told is Bind with an up-to-date >>>>> version. >>>>> >>>>> Thanks! >>>>> >>>>> Hugo >>>>> >>>>> _______________________________________________ >>>>> knot-dns-users mailing list >>>>> knot-dns-users(a)lists.nic.cz >>>>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >>>>

9 let, 8 měsíců

1
0
0 0

dnsproxy module performance

by Matthijs Mekking

Hi, I recently tested the mod-dnsproxy performance and I am disappointed in the results: Knot in our test setup can do ~320K QPS. When using our own proxy in front of knot, we achieve quite a performance hit, only able to do ~120K QPS. However, when configuring knot to use the mod-dnsproxy, the performance drops to ~7K QPS. I am planning to investigate what causes this significant drop, but if you have any insights or other measurements already I would love to hear about them. Best regards, Matthijs

9 let, 8 měsíců

4
8
0 0

Error with secondaries: IXFR failed to start (not enough memory)

by Hugo Salgado

Hi. I have a KNOT master with a small zone (32 records), which is logging an error after the secondary (BIND) tries to update the zone. AFAIK, Bind tries with IXFR first, but my master says: 2016-08-19T16:32:12 error: [manojitos.cl] IXFR, outgoing, 200.1.123.7@29095: failed to start (not enough memory) After that the secondary retries with AXFR, and that works: 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, 200.1.123.7@13644: started, serial 2016011013 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, 200.1.123.7@13644: finished, 0.00 seconds, 1 messages, 2573 bytes The error is the same the first time I provision the zone in the secondary as in following updates. Is there a bug in the error message, or should I worry for some memory requirement in my server (or service)? I'm with Knot 2.3.0 on a FreeBSD 10.3-release-p7. The secondary is not under my administration, but I was told is Bind with an up-to-date version. Thanks! Hugo

9 let, 9 měsíců

1
0
0 0

KNOT - Web GUI

by Ing. Peter Palhazy | NWS

Dobry den, zamyslame pouzit KNOT na DNS serveroch. Avsak potrebujeme k tomu aj nejaky WEB GUI. Disponujete niecim takym? Pripadne viete o nejakom pouzitelnom? Na Vasej www stranke som to zatial zial nenasiel.. dakujem --

9 let, 9 měsíců

1
0
0 0

Knot DNS 2.3.0 release

by Jan Včelák

Hello! CZ.NIC just released a new version of Knot DNS. There are some bug fixes and improvements as usual. But most of the changes are new features. The bug fixes are mostly insignificant, so I'll make it quick: - We have resolved a problem with NSEC-signed zones when a wildcard was incorrectly expanded below a closer empty non-terminal. - The checks on the incoming IXFR were improved so that we now refuse transfers containing non-existing records to be removed. This problem was identified in draft-song-dnsop-ixfr-fallback-01. - The kdig utility can now correctly process IXFR response with empty content (i.e. when the zone is up-to-date). - The server now makes sure that PKCS #11 modules are not loaded multiple times. As for the improvements: - The code for semantic checks was refactored and the error messages should be a bit more readable. - The TC flag setting in delegation is now set only if the mandatory glue doesn't fit. Optional glue may not fit and the TC flag won't be set See my e-mail "glue and TC flags revisited" for more details: https://lists.nic.cz/pipermail/knot-dns-users/2016-June/000905.html - With the new version, you can set different EDNS(0) payload size for IPv4 and IPv6. See max-ipv4-udp-payload and max-ipv6-udp-payload configuration options. And now the interesting new stuff: - DNSSEC policy can be now defined in the server configuration. This makes automatic signing even easier to use. It's only a few lines of the configuration file. Really. Please, have a look at the "Automatic DNSSEC signing" section in the documentation. For easy transition, if the policies are not defined in the server configuration, the ones from the old KASP database are used instead. The keymgr with the --legacy option can be used to maintain the old policies. The KASP database is still used to store signing state and private key material. This might be changed in the future versions. - We have added support for automatic NSEC3 resalting. For this purpose, the new nsec3-salt-length and nsec3-salt-lifetime policy options were added. Please note that in the previous releases, the NSEC/NSEC3 mode for DNSSEC signing was determined by the presence of NSEC3PARAM record in the zone. This is no longer true. The nsec3 policy option is used instead. Note that this option was already present in older releases but it didn't work; please check your signing policies before the upgrade. - The control interface was extended to allow changing the zone content. It's experimental, the changes are internally processed similarly to DDNS which brings the same performance drawbacks, but we would like to builds some more robust interface on top of this one. - The zone size limit for DDNS, AXFR, and IXFR can be now enforced using the max-zone-size option. The default is unlimited. This is our solution for the CVE-2016-6171. Please note that for IXFR, the effective limit for the total size of the records in the transfer is twice the configured value. However the final zone size must satisfy the limit fully. - The kdig utility can talk TLS. Also EDNS(0) padding is supported. Does your local resolver support DNS-over-TLS? Give it a try: $ kdig +tls +alignment=512 www.knot-dns.cz And that's it! Thank you for using Knot DNS. And we are really looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.3.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.0.tar.xz.asc Best regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 9 měsíců

4
5
0 0

Knot Resolver 1.1.0 released

by Ondřej Surý

Hi everyone, CZ.NIC is proud to release second production release of Knot Resolver 1.1.0. We have included fixes that allows more brokeness in the upstream DNS :) as well as several notable new features: * RFC7873 DNS Cookies * RFC7858 DNS over TLS * HTTP/2 web interface, RESTful API * Metrics exported in Prometheus * DNS firewall module * Explicit CNAME target fetching in strict mode * Query minimisation improvements * Improved integration with systemd You can read more about those features in our blogpost: http://en.blog.nic.cz/2016/08/12/knot-dns-1-1-0/ Cheers, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 9 měsíců

1
0
0 0

Knot DNS 1.6.8 patch release

by Jan Včelák

Hey list! CZ.NIC also released Knot DNS 1.6.8 today. The release contains only one tiny feature backported from 2.3.0: - The zone size limit for DDNS, AXFR, and IXFR can be now enforced using the max-zone-size option. The default is unlimited. This is our fix for the CVE-2016-6171. That was short. :-) The tarballs are available as usual. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v1.6.8/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.gz.asc Cheers, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 9 měsíců

1
0
0 0

Old ZSK not removed from zone

by Ulrich Wisser

Hi! It seems I do have a problem with dnssec policy. DNSSEC for wisser.se is automatically managed by knot. If you do a "dig dnskey wisser.se" you will find a lot of old ZSK in my zone. I did some "digging" with the keymgr tool and found the following conf for all old keys algorithm 8 size 2048 flags 256 active -1 retire 0 remove 0 I guess the retire and remove values are the problem. How do I set them for the old keys? And how do I configure my policy to set them for future keys? Kind regards Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 9 měsíců

2
1
0 0

AXFR size limit (CVE-2016-6171)

by Jan Včelák

Hello everyone. I would like to provide some clarification on CVE-2016-6171 which has been assigned to Knot DNS a few days ago. The CVE is basically about a missing configuration option to limit the size of incoming AXFR. The reporter claims that the master can generate infinite outgoing zone transfer and thus exhaust the slave's resources. We believe that master and slave servers should have appropriate trust relationship. And therefore we think this problem rather fits operational security that implementation security. If your master server is trusted, then you should not be affected by this CVE. Please note that the AXFR from untrusted master is not the only possibly source of malicious zone transfer. The IXFR and DDNS qualify as well. We have been requested to add a feature to limit incoming zone transfer about a month ago [1]. The changes are almost finished and will cover AXFR, IXFR, and DDNS. The feature will be included in Knot DNS 2.3 and will be also backported for the older 1.6 release. If you have any comments or questions, don't hesitate and tell us. [1] https://gitlab.labs.nic.cz/labs/knot/issues/464 Best regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 10 měsíců

1
0
0 0

kdig / knsupdate: "; ; ERROR: failed to parse keyfile '...' ; ; DEBUG: srv_info_free: null parameter"

by georg＠riseup.net

tl;dr: I've searched the Internets a lot these past days, but weren't able to find a way to make kdig and knsupdate work with keys. How is this handled? Hello knot people, I've got a problem with kdig and knsupdate, specifically using the -k parameter. I'm using: - Debian 8.5 - dnssec-tools 2.2-2 (out of stretch) - knot-dnsutils 2.2.0-2~bpo80+1 (out of j-bp) - dnsutils 1:9.9.5.dfsg-9+deb8u6 (out of jessie) I'm creating the key with: # dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com which gives: # cat Khost.example.com.+157+11483.* host.example.com. IN KEY 512 3 157 42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I= Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: 42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I= Bits: AAA= Doing then: # knsupdate -d -k Khost.example.com.+157+11483. which gives: ;; ERROR: failed to parse keyfile 'Khost.example.com.+157+11483.' ;; DEBUG: srv_info_free: null parameter I've found [1], and indeed, I'm running into the mentioned error if using knot-dnsutils 1.6.0-1 out of jessie. Besides this, I wasn't able to find anything useful. But, doing this: # knsupdate -y hmac-md5:host.example.com:42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I= works, the same as nsupdate does: # nsupdate -k Khost.example.com.+157+11483. Could someone shed some light on what I'm doing wrong? Any help appreciated... Thanks in advance and for your work on knot! All the best, Georg [1] https://lists.nic.cz/pipermail/knot-dns-users/2015-February/000579.html

9 let, 10 měsíců

2
4
0 0

Knot Debian installation - 301 Moved Permanently [IP: 217.31.192.140 80],

by Maren S. Leizaola

Hello, Even if I force wget to accept your expired certificate I can't get apt-get update to work when pointing to your servers. It has been like this for a few days now. Hit http://ftp.debian.org wheezy-updates/main Translation-en/DiffIndex Err http://deb.knot-dns.cz wheezy/main amd64 Packages 301 Moved Permanently [IP: 217.31.192.140 80] Ign http://deb.knot-dns.cz wheezy/main Translation-en W: Failed to fetch http://deb.knot-dns.cz/knot/dists/wheezy/main/binary-amd64/Packages 301 Moved Permanently [IP: 217.31.192.140 80] E: Some index files failed to download. They have been ignored, or old ones used instead. Could someone have a look at this please? DO you think that many users have just switched back to bind because of this? or is it just me? Regards, Maren.

9 let, 10 měsíců

3
2
0 0

Re: [knot-dns-users] forcing minimal fragment size for IPv6 datagrams

by Daisuke HIGASHI

Hi, I anyway wrote a patch for disabling PMTUD for UDP socket (for both IPv4/IPv6), and posted to issue tracker: https://gitlab.labs.nic.cz/labs/knot/issues/467#note_24304 This patch includes extra bonus for mitigating DNS fragmentation attack for IPv4 UDP, by using Linux's newer sockopt IP_PMTUDISC_OMIT. I tried to illustrate how PMTUD badly interact with DNS over UDP, which draft-andrews-dnsext-udp-fragmentation is addressing. Assuming that there is a small MTU link between DNS requester and DNS responder. Responder is serving large response, which size is exceeding that small MTU (1454): Apparently many DNS operator don't want timeout and retransmission. MTU MTU MTU Requester--1500--[router1]--1454--[router2]--1500-- Responder | . . | | . . | o --------------------------------------------->| 1. Requester initiates | . . | DNS query. | . . | | . .<-------------o 2. Responder generates | . . | large DNS resnponse | . . | (packet size > 1454) | . . | | . o------------->| 3. Intermediate router | . . | drops large packet | . . | due to small MTU, and | . . | generates ICMPv6 | . . | "Packet Too Big", | . . | since the response | . . | packet can't go | . . | through the link. | . . | | . . | Responder would learn | . . | smaller path MTU toward | . . | requester, but | . . | does not resend | . . | the response. (It's UDP!) ~ ~ ~ ~ | . . | o---------------------------------------------->| 4. After timeout | . . | requester retries | . . | query. | . . | |<----------------------------------------------| 5. Responder generates | . . | fragmented DNS response | . . | which can go throgh | . . | the "MTU 1454" link. | . . | Regards, -- Daisuke Higashi

9 let, 10 měsíců

1
0
0 0

glue and TC flag revisited

by Jan Včelák

Hello. There has been a rather long discussion about the change in TC flag setting for glue records after the Knot DNS 2.1.1 release. Based on the feedback, we have decided to tune the server's behavior a little bit. First of all, the definitions for "glue" differ and the recent RFC 7719 (DNS Terminology) doesn't help. So just to make this absolutely clear, let's define "mandatory glue": Mandatory glue are non-authoritative address records for the name servers in the delegation and within the bailiwick of that delegation. RFC 1034 Section 4.3.2 [1] describes the algorithm for response construction. As per step 3.b, we include mandatory glue into the additional section. If it doesn't fit, the TC flag is set. And as per step 6., we include other authoritative address records for name servers in the delegation. If these records don't fit, the TC flag is not set. [1] https://tools.ietf.org/html/rfc1034#section-4.3.2 Let's show that on an example. Consider the following zone: $ORIGIN tc.test. @ SOA ns admin 1 60 60 1800 60 ns AAAA 2001:DB8::1 foo NS ns.foo ns.foo AAAA 2001:DB8::10 bar NS bar NS a.ns.bar NS b.ns.bar NS ns.foo NS ns NS foo.test. bar AAAA 2001:DB8::20 a.ns.bar AAAA 2001:DB8::30 Now query for www.bar.tc.test would result in a response with delegation. The authority section would contain NS records for bar.tc.test. And the additional section will contain address records for following names as follows: - bar required (mandatory glue) - a.ns.bar required (mandatory glue) - ns optional (authoritative record, possibly with RRSIG) - b.ns.bar omitted (mandatory glue but unavailable) - ns.foo omitted (non-authoritative outside bailiwick) - foo.test omitted (non-authoritative outside zone) So what do you think? Is it better? This change is already included in the master branch (in case you want to test it). But there is still some time to change it before the next release. Best regards, Jan

9 let, 10 měsíců

1
0
0 0

receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED

by Roger Murray

Hello Everybody, I am seeing a response from a knot name server that I am working on that has me a little confused. When I do zone transfer requests from clients that aren’t allowed to do a zone transfer I expect to receive rcode 5 REFUSED, but I am receiving rcode 9 NOTAUTH. Is this the expected behaviour? Is this configurable? Best Regards, /rog knotd (Knot DNS), version 2.2.1 on Ubuntu 14.04 installed from .cz package knot: Installed: 2.2.1-1+trusty+1 Candidate: 2.2.1-1+trusty+1 Version table: *** 2.2.1-1+trusty+1 0 500 http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/ trusty/main amd64 Packages

9 let, 11 měsíců

4
4
0 0

should NSEC3 be default?

by Jan Včelák

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision... We would appreciate any comments from your point of view. :-) Jan

9 let, 11 měsíců

7
11
0 0

RRL and dnsproxy

by Matthijs Mekking

Hi, I recently started trying out Knot DNS and it has been a pleasure so far. I like the query modules and how easy it is to construct a query plan. I am thinking of putting knot as the public-facing server and enable RRl on it. However, I noticed that rate limiting comes *before* forwarding the unsatisfied query to the remote backend. This means effectively that all the queries will be rate limited by error classification. Wouldn't it be better to apply ratelimits after all stages of the query plan have been processed? In other words, rate limit based on the final response, rather than an intermediate state. This way you can truly use knot as a rate-limiting, public-facing server protecting your backend name server. Thoughts? Best regards, Matthijs

9 let, 11 měsíců

2
2
0 0

Knot DNS 2.2.1 patch release

by Jan Včelak

Hello everyone. CZ.NIC Labs has just released a patched version of Knot DNS. The 2.2.1 version contains some important bug fixes and a few small improvements. Let's jump directly into it: - The previous version was inconsistent in setting the TC flag for delegations with a glue. We have decided to modify the behavior slightly and the TC flag is now set always if a complete glue doesn't fit the response. - Logging of individual categories (server or zone) didn't work in the previous release. This problem is now resolved. Logging all categories (any configuration option) was not affected. - We have eliminated data race in the code responsible for zone file flushing. When more zone files were flushed concurrently, flushing of some zones could fail. This problem is fixed in the new release. - If you are running Knot DNS on OpenWRT, we advise you to update to the new release. There has been a critical bug possibly making the server to crash. - There had been several issues with the control utility: The timeout for reconfiguration is now parsed correctly. The "maxreaders limit reached" error is gone. And the interactive mode now completes multiple zone names if allowed by the command. The server will also refuse to perform the reload, if there is an active configuration transaction. - We have removed switch for Link Time Optimization from the configure script, because LTO is still rather problematic. If you want to use LTO, set the CFLAGS and LDFLAGS appropriately. - We have improved the logging and status messages to differentiate between an unavailable zone and a zone with zero serial. - We have added a list of PKCS #11 devices which had been tested with automatic DNSSEC signing. We are looking forward to your feedback. The sources are available as usual: Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.2.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz.asc Cheers, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 11 měsíců

7
13
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users