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

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

12 let, 4 měsíce

1
0
0 0

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

12 let, 4 měsíce

1
0
0 0

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

12 let, 4 měsíce

2
5
0 0

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

12 let, 4 měsíce

3
2
0 0

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, 4 měsíce

2
1
0 0

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, 4 měsíce

2
3
0 0

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, 4 měsíce

2
3
0 0

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, 4 měsíce

2
3
0 0

Knot 1.3.4 crash

by Anand Buddhdev

Hi Knot devs, I'm setting up Knot 1.3.4 on one of our production systems, and it keeps crashing. I ran it under gdb, and I have this: knotd: libknot/updates/xfr-in.c:905: xfrin_process_axfr_packet: Assertion `node != ((void *)0)' failed. The output of "thread apply all bt" is: Thread 133 (Thread 0x7fffd07ef700 (LWP 26754)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec9f0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec9f0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 132 (Thread 0x7fffd08f0700 (LWP 26753)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec950) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec950) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 131 (Thread 0x7fffd09f1700 (LWP 26752)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec8b0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec8b0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 130 (Thread 0x7fffd0af2700 (LWP 26751)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec810) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec810) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 129 (Thread 0x7fffd0bf3700 (LWP 26750)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec770) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec770) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 128 (Thread 0x7fffd0cf4700 (LWP 26749)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec6d0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec6d0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 127 (Thread 0x7fffd0df5700 (LWP 26748)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec630) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec630) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 126 (Thread 0x7fffd0ef6700 (LWP 26747)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec590) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec590) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 125 (Thread 0x7fffd0ff7700 (LWP 26746)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec4f0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec4f0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 124 (Thread 0x7fffd14ab700 (LWP 26745)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec450) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec450) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 123 (Thread 0x7fffd15ac700 (LWP 26744)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec3b0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec3b0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 122 (Thread 0x7fffd16ad700 (LWP 26743)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec310) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec310) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 121 (Thread 0x7fffd17ae700 (LWP 26742)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec270) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec270) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 120 (Thread 0x7fffd18af700 (LWP 26741)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec1d0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec1d0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 119 (Thread 0x7fffd19b0700 (LWP 26740)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6cc0e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6cc0e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 118 (Thread 0x7fffd1eec700 (LWP 26739)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6cc040) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6cc040) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 117 (Thread 0x7fffd1fed700 (LWP 26738)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc2a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc2a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 116 (Thread 0x7fffd20ee700 (LWP 26737)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc200) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc200) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 115 (Thread 0x7fffd21ef700 (LWP 26736)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc160) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc160) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 114 (Thread 0x7fffd22f0700 (LWP 26735)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc0c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc0c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 113 (Thread 0x7fffd23f1700 (LWP 26734)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc020) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc020) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 112 (Thread 0x7fffd2be6700 (LWP 26733)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbf80) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbf80) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 111 (Thread 0x7fffd3122700 (LWP 26732)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbee0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbee0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 110 (Thread 0x7fffd3223700 (LWP 26731)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbe40) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbe40) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 109 (Thread 0x7fffd3324700 (LWP 26730)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbda0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbda0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 108 (Thread 0x7fffd3425700 (LWP 26729)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbd00) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbd00) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 107 (Thread 0x7fffd3526700 (LWP 26728)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbc60) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbc60) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 106 (Thread 0x7fffd3627700 (LWP 26727)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbbc0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbbc0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 105 (Thread 0x7fffec654700 (LWP 26726)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbb20) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbb20) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 104 (Thread 0x7fffec755700 (LWP 26725)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dba80) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dba80) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 103 (Thread 0x7fffec856700 (LWP 26724)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db9e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db9e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 102 (Thread 0x7fffec957700 (LWP 26723)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db940) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db940) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 101 (Thread 0x7fffeca58700 (LWP 26722)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db8a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db8a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 100 (Thread 0x7fffecb59700 (LWP 26721)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db800) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db800) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 99 (Thread 0x7fffecc5a700 (LWP 26720)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db760) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db760) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 98 (Thread 0x7fffecd5b700 (LWP 26719)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db6c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db6c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 97 (Thread 0x7fffece5c700 (LWP 26718)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db620) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db620) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 96 (Thread 0x7fffecf5d700 (LWP 26717)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db580) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db580) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 95 (Thread 0x7fffed05e700 (LWP 26716)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db4e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db4e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 94 (Thread 0x7fffed15f700 (LWP 26715)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db440) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db440) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 93 (Thread 0x7fffed260700 (LWP 26714)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db3a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db3a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 92 (Thread 0x7fffedd9d700 (LWP 26713)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db300) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db300) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 91 (Thread 0x7fffede9e700 (LWP 26712)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db260) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db260) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 90 (Thread 0x7fffedf9f700 (LWP 26711)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db1c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db1c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 89 (Thread 0x7fffeea81700 (LWP 26710)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db120) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db120) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 88 (Thread 0x7fffeeb82700 (LWP 26709)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db080) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db080) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 87 (Thread 0x7fffeedb7700 (LWP 26708)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dafe0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dafe0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 86 (Thread 0x7fffeeeb8700 (LWP 26707)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daf40) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daf40) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 85 (Thread 0x7fffeefb9700 (LWP 26706)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daea0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daea0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 84 (Thread 0x7fffef5f9700 (LWP 26705)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dae00) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dae00) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 83 (Thread 0x7fffef6fa700 (LWP 26704)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dad60) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dad60) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 82 (Thread 0x7fffef7fb700 (LWP 26703)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dacc0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dacc0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 81 (Thread 0x7fffef8fc700 (LWP 26702)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dac20) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dac20) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 80 (Thread 0x7fffef9fd700 (LWP 26701)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dab80) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dab80) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 79 (Thread 0x7fffefafe700 (LWP 26700)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daae0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daae0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 78 (Thread 0x7ffff42dc700 (LWP 26699)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daa40) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daa40) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 77 (Thread 0x7ffff43dd700 (LWP 26698)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da9a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da9a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 76 (Thread 0x7ffff44de700 (LWP 26697)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da900) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da900) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 75 (Thread 0x7ffff45df700 (LWP 26696)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da860) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da860) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 74 (Thread 0x7ffff46e0700 (LWP 26695)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da7c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da7c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 73 (Thread 0x7ffff47e1700 (LWP 26694)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da720) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da720) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 72 (Thread 0x7ffff48e2700 (LWP 26693)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da680) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da680) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 71 (Thread 0x7ffff49e3700 (LWP 26692)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da5e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da5e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 70 (Thread 0x7ffff4ae4700 (LWP 26691)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040aaf7 in tcp_loop_master (thread=0x6da540) at knot/server/tcp-handler.c:520 #2 0x00000000004951be in thread_ep (data=0x6da540) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 69 (Thread 0x7ffff536a700 (LWP 26690)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9f90) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9f90) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 68 (Thread 0x7ffb77bff700 (LWP 26689)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9ef0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9ef0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 67 (Thread 0x7ffff546b700 (LWP 26688)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9e50) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9e50) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 66 (Thread 0x7ffff556c700 (LWP 26687)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9db0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9db0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 65 (Thread 0x7ffff7feb700 (LWP 26686)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9d10) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9d10) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 64 (Thread 0x7ffff6170700 (LWP 26685)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9c70) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9c70) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 63 (Thread 0x7ffff606f700 (LWP 26684)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9bd0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9bd0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 62 (Thread 0x7fffeffff700 (LWP 26683)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9b30) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9b30) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 61 (Thread 0x7ffff5f6e700 (LWP 26682)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9a90) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9a90) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 60 (Thread 0x7ffff5e6d700 (LWP 26681)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d99f0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d99f0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 59 (Thread 0x7ffff51df700 (LWP 26680)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9950) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9950) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 58 (Thread 0x7ffff4be5700 (LWP 26679)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d98b0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d98b0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 57 (Thread 0x7ffff41b6700 (LWP 26678)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9810) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9810) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 56 (Thread 0x7fffd3f28700 (LWP 26677)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9770) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9770) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 55 (Thread 0x7fffef4ba700 (LWP 26676)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d96d0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d96d0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 54 (Thread 0x7fffeec83700 (LWP 26675)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9630) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9630) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 53 (Thread 0x7fffee8a0700 (LWP 26674)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9590) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9590) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 52 (Thread 0x7fffedc62700 (LWP 26673)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d94f0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d94f0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 51 (Thread 0x7fffedb61700 (LWP 26672)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9450) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9450) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 50 (Thread 0x7fffec539700 (LWP 26671)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d93b0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d93b0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 49 (Thread 0x7fffec438700 (LWP 26670)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9310) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9310) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 48 (Thread 0x7fffec337700 (LWP 26669)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9270) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9270) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 47 (Thread 0x7fffec236700 (LWP 26668)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d91d0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d91d0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 46 (Thread 0x7fffec135700 (LWP 26667)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9130) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9130) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 45 (Thread 0x7fffd29f3700 (LWP 26666)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9090) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9090) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x7fffd28f2700 (LWP 26665)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8ff0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8ff0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x7fffd12fa700 (LWP 26664)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8f50) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8f50) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x7fffd11f9700 (LWP 26663)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8eb0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8eb0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x7fffd10f8700 (LWP 26662)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8e10) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8e10) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x7fffd0672700 (LWP 26661)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8d70) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8d70) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x7fffd0571700 (LWP 26660)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8cd0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8cd0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x7fff8ddad700 (LWP 26659)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8c30) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8c30) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x7fff8d621700 (LWP 26658)): #0 0x00007ffff6dc698e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000043dcb0 in evsched_next (s=0x6cc590) at common/evsched.c:206 #2 0x00000000004095cb in evsched_run (thread=0x6cd820) at knot/server/server.c:49 #3 0x00000000004951be in thread_ep (data=0x6cd820) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 36 (Thread 0x7fffd0470700 (LWP 26657)): #0 0x0000000000440a80 in _log_msg (src=LOG_ZONE, level=128, msg=0x7fffd046e930 "[debug] Created new node for the record.\n") at common/log.c:245 #1 0x0000000000440c94 in log_msg (src=LOG_ZONE, level=7, msg=0x4a43e8 "Created new node for the record.\n") at common/log.c:308 #2 0x0000000000433f1c in xfrin_process_axfr_packet (xfr=0x7ffb516c4590) at libknot/updates/xfr-in.c:836 #3 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb516c4590) at libknot/nameserver/name-server.c:3973 #4 0x000000000040d429 in xfr_task_xfer (thread=0x6d33d0) at knot/server/xfr-handler.c:759 #5 xfr_process_event (thread=0x6d33d0) at knot/server/xfr-handler.c:853 #6 xfr_worker (thread=0x6d33d0) at knot/server/xfr-handler.c:1119 #7 0x00000000004951be in thread_ep (data=0x6d33d0) at knot/server/dthreads.c:170 #8 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #9 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x7fffd036f700 (LWP 26656)): #0 0x00007ffff701c4ab in vfprintf () from /lib64/libc.so.6 #1 0x00007ffff70218e0 in buffered_vfprintf () from /lib64/libc.so.6 #2 0x00007ffff701c51e in vfprintf () from /lib64/libc.so.6 #3 0x00007ffff70d80eb in __fprintf_chk () from /lib64/libc.so.6 #4 0x0000000000440a4d in fprintf (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at /usr/include/bits/stdio2.h:98 #5 _log_msg (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at common/log.c:255 #6 0x0000000000440c94 in log_msg (src=LOG_ZONE, level=7, msg=0x4a43e8 "Created new node for the record.\n") at common/log.c:308 #7 0x0000000000433f1c in xfrin_process_axfr_packet (xfr=0x7ffb502d5c10) at libknot/updates/xfr-in.c:836 #8 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb502d5c10) at libknot/nameserver/name-server.c:3973 #9 0x000000000040d429 in xfr_task_xfer (thread=0x6d3330) at knot/server/xfr-handler.c:759 #10 xfr_process_event (thread=0x6d3330) at knot/server/xfr-handler.c:853 #11 xfr_worker (thread=0x6d3330) at knot/server/xfr-handler.c:1119 #12 0x00000000004951be in thread_ep (data=0x6d3330) at knot/server/dthreads.c:170 #13 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #14 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x7fff8c71f700 (LWP 26655)): #0 0x00007ffff700a925 in raise () from /lib64/libc.so.6 #1 0x00007ffff700c105 in abort () from /lib64/libc.so.6 #2 0x00007ffff7003a4e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007ffff7003b10 in __assert_fail () from /lib64/libc.so.6 #4 0x00000000004349cd in xfrin_process_axfr_packet (xfr=0x7ffb516c2d30) at libknot/updates/xfr-in.c:905 #3 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb516c4590) at libknot/nameserver/name-server.c:3973 #4 0x000000000040d429 in xfr_task_xfer (thread=0x6d33d0) at knot/server/xfr-handler.c:759 #5 xfr_process_event (thread=0x6d33d0) at knot/server/xfr-handler.c:853 #6 xfr_worker (thread=0x6d33d0) at knot/server/xfr-handler.c:1119 #7 0x00000000004951be in thread_ep (data=0x6d33d0) at knot/server/dthreads.c:170 #8 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #9 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x7fffd036f700 (LWP 26656)): #0 0x00007ffff701c4ab in vfprintf () from /lib64/libc.so.6 #1 0x00007ffff70218e0 in buffered_vfprintf () from /lib64/libc.so.6 #2 0x00007ffff701c51e in vfprintf () from /lib64/libc.so.6 #3 0x00007ffff70d80eb in __fprintf_chk () from /lib64/libc.so.6 #4 0x0000000000440a4d in fprintf (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at /usr/include/bits/stdio2.h:98 #5 _log_msg (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at common/log.c:255 #6 0x0000000000440c94 in log_msg (src=LOG_ZONE, level=7, msg=0x4a43e8 "Created new node for the record.\n") at common/log.c:308 #7 0x0000000000433f1c in xfrin_process_axfr_packet (xfr=0x7ffb502d5c10) at libknot/updates/xfr-in.c:836 #8 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb502d5c10) at libknot/nameserver/name-server.c:3973 #9 0x000000000040d429 in xfr_task_xfer (thread=0x6d3330) at knot/server/xfr-handler.c:759 #10 xfr_process_event (thread=0x6d3330) at knot/server/xfr-handler.c:853 #11 xfr_worker (thread=0x6d3330) at knot/server/xfr-handler.c:1119 #12 0x00000000004951be in thread_ep (data=0x6d3330) at knot/server/dthreads.c:170 #13 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #14 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x7fff8c71f700 (LWP 26655)): #0 0x00007ffff700a925 in raise () from /lib64/libc.so.6 #1 0x00007ffff700c105 in abort () from /lib64/libc.so.6 #2 0x00007ffff7003a4e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007ffff7003b10 in __assert_fail () from /lib64/libc.so.6 #4 0x00000000004349cd in xfrin_process_axfr_packet (xfr=0x7ffb516c2d30) at libknot/updates/xfr-in.c:905 ---Type <return> to continue, or q <return> to quit--- #5 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb516c2d30) at libknot/nameserver/name-server.c:3973 #6 0x000000000040d429 in xfr_task_xfer (thread=0x6d3290) at knot/server/xfr-handler.c:759 #7 xfr_process_event (thread=0x6d3290) at knot/server/xfr-handler.c:853 #8 xfr_worker (thread=0x6d3290) at knot/server/xfr-handler.c:1119 #9 0x00000000004951be in thread_ep (data=0x6d3290) at knot/server/dthreads.c:170 #10 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #11 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7ffff7fec880 (LWP 26450)): #0 0x00007ffff70b97ee in pselect () from /lib64/libc.so.6 #1 0x000000000040796b in remote_poll (r=<value optimized out>) at knot/ctl/remote.c:418 #2 0x00000000004045d7 in main (argc=<value optimized out>, argv=<value optimized out>) at knot/main.c:353

12 let, 4 měsíce

1
0
0 0

Knot a OpenWRT

by Liquid

Dobrý den, bude někdy dostupný balíček Knot DNS serveru i pro OpenWRT platformu? Liquid

12 let, 5 měsíců

2
1
0 0

Knot DNS 1.4.0-rc2 & 1.3.4

by Marek Vavruša

Hi Everyone, we're on a fast track for the 1.4.0 final release as a late Christmas present now, so I'd like to give you a second preview of what is to come. On top of all that, we've encountered a several bugs, namely a race condition in event scheduling and bad additionals processing in special cases, so we decided to break the jinx of today's date and release a new stable version as well with backported fixes. But I digress, what's new in the 1.4.0 rc2 ? We implemented IDN support in the utilities, DNSSEC signing now supports GOST algorithm and several other enhancements. Speaking of which, 1.4.0 users can rejoice over prettier zone files, where DNSSEC-related data are written separately from the others, thus improving readability. Then there's configuration, where 'dnssec-keydir' and 'storage' can be configured for each zone separately and lower memory consumption. In fact we have a new benchmark section on our webpage which we update every now and then, so you can have a look not only at the response rate but also at the startup time and the memory consumption that I was talking about. Here's the page: https://www.knot-dns.cz/pages/benchmark.html The whole benchmarking is open source, so you can have a look at the scenarios, download the test suite yourself and see how we measure things. I'd like to thank Jonathan Hoppe and all for the bugreports and feedback. It's very appreciated. That's all, enjoy the spooky Friday 13th and the weekend. Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.xz.asc Kind Regards, Marek

12 let, 5 měsíců

1
0
0 0

dnssec_keydir and storage per zone config patch

by Kamil Sopko

Hi, I found this project quite promising, but I would like to configure dnssec_keydir and storage per zone . Now all keys and db files are in one directory, that is probably OK if you have couple of zones, also if they are very big, but we have configured about 48k zones(this can be configured to tree and separated by includes), which means at start 48.000 db files and 48.000x4 = 192.000 DNSSEC key files(later when rotating keys it can be even more). It is probably acceptable when accessing db files, because I did not found any directory crawling here, but only from performance point of view, not from administrator's (backups/listing/quick fixes etc). I thing problem is in dnssec_keydir, becouse of way how keys are filtered(libknot/dnssec/zone-keys.c method knot_load_zone_keys) by name and included or removed from zone. Also as I understand updating(insert/delete inodes) large directories can harm performance of updating a lot. I think It will often block listing of files for key searching, slowdown parallel writing to directories etc. Also crawling large array for few keys for zone(192k lines for 4 files). Compare: one dnssec_keydir /data: list whole directory 192k for find 4 lines per zone dnssec_keydir /data/e/ex/exa/exam/example.com/K* (this structure is example and can be configurable by dnssec_keydir variable in zone, think of it as emulating some sort of binary tree): 6 x access to sub directory+ list only one directory for 4 lines (max 6-8 when rotating) I attached patch, which I believe solve this with little performance penalty and little more memory usage(only for those which want tree structure for example). About structure it should not be created on demand, but precreated by administrator/script . I believe it can save lots of time and disk io. At the end I may be totally wrong, I did not made any tests yet. Kamil -- Kamil Sopko Dodavatel technické podpory pro savana.cz s.r.o. Lounská 983/43, 405 02 Děčín VI-Letná Telefon: +420 478 472 100 Provozní doba: PO-PÁ 8-118 hod a SO-NE 9-12 hod Web: www.savana.cz

12 let, 5 měsíců

1
0
0 0

Knot DNS 1.4.0-rc1 is out!

by Jan Včelák

Hello list, some time has passed since the Knot DNS 1.4.0 beta release, and now we are proudly announcing the first release candidate! Thank you for all your notes and comments. We have fixed quite a lot of bugs and done some refactoring. But most of the efforts were put into stabilization of the automatic DNSSEC signing. There are still some issues that we are aware of, and we will fix those before gold release. But now is a perfect time to give Knot DNS 1.4 another shot! Your feedback is appreciated. Below is a list of significant changes since 1.4.0 beta: - refactored zone loading - improved journal locking - various fixes in client utilities - DNSSEC: fixed a lot of memory allocation errors - DNSSEC: improved logging (zone signing, key loading) - DNSSEC: key pre-publication is possible (uses timestamps in key file) - DNSSEC: presence of 'dnssec-keydir' config option does not enable signing - DNSSEC: improved scheduling of zone resigning Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.xz.asc Best regards, Jan

12 let, 5 měsíců

1
0
0 0

Knot DNS 1.3.3 patch & 1.4.0 beta release

by Marek Vavruša

Hi Everyone, we're having a special release today. Two in one, so let's get to it briefly. First things is our first beta version ever released (did you know?). It is a sneak peek of one of the major features we are working on right now. That new thing is the automatic DNSSEC signing. While it is still an EXPERIMENTAL feature, we would like to encourage you to give it a try and let us know what you think, like or hate. This would help us immensely to change things when we still have time to do so, and iron out bugs before we bake a release candidate. The configuration is quite simple and can be found in the documentation. More so, we have written a short "how to" on our Wiki page here: https://gitlab.labs.nic.cz/labs/knot/wikis/dnssec-quickstart And the shortcomings here: https://gitlab.labs.nic.cz/labs/knot/wikis/dnssec-limitations All in all, it should be as simple as giving it a directory with keys and push the button. Is it really? A lot of changes happened under the bonnet as well (and some things still in progress!). Things like reduced memory usage, faster query processing, test modules and faster zone loading. But more on that in the final release when things settle down. Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.xz.asc Now back to the 1.3.3 patch release. It's probably tad less exciting, but fixes a few important bugs for example in query processing or notify messages being ignored in some cases. Also a few touch ups in the documentation and zone loading. Yet again, many thanks for the bugreports! As always, you can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.xz.asc Best, Marek -- 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

12 let, 6 měsíců

8
22
0 0

Re: [knot-dns-users] Email lists available (1000)

by Jon Francis

12 let, 6 měsíců

1
0
0 0

Knot DNS, DNS UPDATE and OpenDNSSEC

by Matthias-Christian Ott

Hi, without DNS UPDATE OpenDNSSEC can be configured to read an unsigned zone file, sign it and reload the zone [1]. With DNS UPDATE it gets more complicated. It seems that you have to run a hidden primary that receives that updates and transfers the unsigned zones to OpenDNSSEC which in turn transfers the zones to a slave server. There are some alternatives if you manipulate zone files with custom scripts. While a hidden primary may be acceptable and zone transfers are probably the most reliable solution, it is an overkill for my use case and adds to much complexity. I could use Knot DNS to sign the zones, but it doesn't automate KSK rollovers and I need to execute a custom binary to update the keys at the registrar which is also not supported. Perhaps Knot DNS could remove all DNSSEC RRs before it transfers the zone to OpenDNSSEC, but it's kind of a hack and I'm not sure if this a good idea. OpenDNSSEC also delayed support for dynamic updates to 2.x, which means 2014 and or later. So this is not an option. Does anyone have suggestions to solve this problem? Regards, Matthias-Christian [1] http://www.bortzmeyer.org/opendnssec-nsd.html

12 let, 6 měsíců

6
9
0 0

Change on version statment

by Eric Kom

Hi, I am new on this list, and have just installed and start using Knot for the first time on freeBSD: #uname -r 10.0-BETA1 Look pretty nice and light. very close to Bind/Unix daemon configuration styles. After I have started the daemon, #knotd -d and check his status: #knotc status OK and check the version: #knotd -V Knot DNS, version 1.3.2 I tried to hide the version as above: # # This is a sample of a minimal configuration file for Knot DNS. # # For exhaustive list of all options see samples/knot.full.conf # in the source directory or refer to user manual. # system { # Identity of the server (see RFC 4892). ##identity on; ## version "My First Knot Config.."; # Version of the server (see RFC 4892) version on; # User for running server # May also specify user.group (e.g. knot.knot) user root.knot; # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage # storage "/usr/local/var/lib/knot"; # Directory for storing run-time data # e.g. PID file and control sockets # default: ${localstatedir}/run/knot, configured with --with-rundir # rundir "/usr/local/var/run/knot"; } interfaces { all_ipv4 { address 0.0.0.0; port 53; } all_ipv6 { address [::]; port 53; } } control { # Default: knot.sock (relative to rundir) listen-on "knot.sock"; # As an alternative, you can use an IPv4/v6 address and port # Same syntax as for 'interfaces' items # listen-on { address 127.0.0.1@5533; } # Specifies ACL list for remote control # Same syntax as for ACLs in zones # List of remotes or groups delimited by comma # Notice: keep in mind that ACLs bear no effect with UNIX sockets # allow server0, admins; } #remotes { # master0 { # address 198.51.100.1@53; # } # slave0 { # address 203.0.113.1@53; # } #} zones { # Example master zone # example.com { # file "/usr/local/etc/knot/example.com.zone"; # xfr-out slave0; # notify-out slave0; # } # # Example slave zone # example.net { # file "/usr/local/var/lib/knot/example.net.zone # xfr-in master0; # notify-in master0; # } } log { syslog { # log errors of any category any error; # for <category> and <severity> see above # log also warnings and notices from category 'zone' zone warning, notice; # log info from server server info; } # Log fatal, warnings and errors to stderr stderr { any error, warning; } After I have reloaded the daemon with: #knotc reload OK The version remain the same. Another question is, when I tried to run the command knotd -c knot.conf, I received errors as above: root@chris:/usr/local/etc/knot # knotd -c knot.conf 2013-10-25T19:46:00 Reading configuration '/usr/local/etc/knot/knot.conf' ... 2013-10-25T19:46:00 [error] Cannot bind to socket (errno 48). 2013-10-25T19:46:00 [error] Could not bind to UDP interface 0.0.0.0 port 53. 2013-10-25T19:46:00 [error] Cannot bind to socket (errno 48). 2013-10-25T19:46:00 [error] Could not bind to UDP interface :: port 53. 2013-10-25T19:46:00 [warning] Server started, but no zones served. and the errors makes me to pkill knot the process and start the daemon again. I my doing wrong? Sorry for the configuration statements in the mail. -- Kind Regards Eric Kom Senior IT Manager - Metropolitan Schools _________________________________________ / You are scrupulously honest, frank, and \ | straightforward. Therefore you have few | \ friends. / ----------------------------------------- \ \ .--. |o_o | |:_/ | // \ \ (| Kom | ) /'\_ _/`\ \___)=(___/ 2 Hennie Van Till, White River, 1240 Tel: 013 750 2255 | Fax: 013 750 0105 | Cell: 078 879 1334 erickom(a)kom.za.net | erickom(a)metropolitancollege.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5

12 let, 6 měsíců

2
1
0 0

Knot DNS 1.3.2

by Lubos Slovak

Hi there, 1.4.0 is nearly finished, but it will take some time until it's stable, so we fixed some minor issues in the current stable version and released 1.3.2. Now you can specify the max UDP payload to be used with EDNS0 in the configuration. We also fixed bug causing the max payload to limit also some TCP responses. Besides that, we fixed build on SLE 10 and a problem with reloading, when files included in configuration file were not closed. Everything is in its usual place: Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.xz.asc Packages available at www.knot-dns.cz should be updated as well. Regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

12 let, 7 měsíců

1
0
0 0

Knot DNS 1.3.1 patch release

by Marek Vavruša

Hi Everyone, while we are busy with the new stuff for the 1.4.0, we decided to backport a few important patches and release 1.3.1 as soon as possible. Feature wise, not much has changed - the ACLs are a little bit smarter and look for the longest address prefix match, but otherwise it's a patch only release. Namely a bug that caused a few extra bytes in an answer with NSID was fixed, also a potential interoperability issue with TSIG signature over multiple packets in zone transfers and TSIG key secret being wrongly parsed without quotes. As always, you can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. I wish you pleasant last bits of summer. Kind Regards, Marek -- 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

12 let, 8 měsíců

3
2
0 0

Knot-DNS port FreeBSD 9.1

by Robert Vojcik

Zdravim, mozno sa to uz tu riesilo. Planujete novu verziu 1.3.1 propagovat aj do FreeBSD portov ? Aktualne je tam verzia 1.3.0 rc1. Samozrejme je moznost si to skompilovat rucne, ale preferoval by som porty ak mate v plane ich udrzovat :) -- Robert

12 let, 8 měsíců

4
4
0 0

Duplicate CNAME output in kdig

by Erwin Lansing

I was just giving kdig and khost a spin, when I noticed some very long output for a simple query with khost. Looks like the aliases is expanded multiple times: erwin@panda:/home/erwin % khost www.droso.dk www.droso.dk. is an alias for koala.droso.dk. koala.droso.dk. has IPv4 address 213.239.220.246 www.droso.dk. is an alias for koala.droso.dk. koala.droso.dk. has IPv6 address 2a01:4f8:a0:7163::2 www.droso.dk. is an alias for koala.droso.dk. erwin@panda:/home/erwin % host www.droso.dk www.droso.dk is an alias for koala.droso.dk. koala.droso.dk has address 213.239.220.246 koala.droso.dk has IPv6 address 2a01:4f8:a0:7163::2 I would say once is enough :-) Cheers, Erwin -- Med venlig hilsen/Best Regards Erwin Lansing Network and System Administrator DK Hostmaster A/S Kalvebod Brygge 45, 3. sal 1560 København V Tlf. 33 64 60 60 Fax.: 33 64 60 66 Email: erwin(a)dk-hostmaster.dk Homepage: http://www.dk-hostmaster.dk .dk Danmarks plads på Internettet ------------------------------------------------------------------------- This is an email from DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee please notify the sender immediately and delete this e-mail from your system. You are not permitted to disclose, distribute or copy the information in this e-mail. --------------------------------------------------------------------------

12 let, 9 měsíců

2
1
0 0

system.nsid reconfiguration bug

by Anand Buddhdev

Hello Knot developers, I'm trying out Knot 1.3.0 final, and testing the new options for system.identity, system.version and system.nsid. At first, I did this: system { identity yes; version yes; nsid yes; } The alert ones will note that I didn't use "on", but accidentally used "yes", so Knot parsed them all as strings, and gave me unexpected but correct results. ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt id.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15951 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 79 65 73 (y) (e) (s) ;; QUESTION SECTION: ;id.server. CH TXT ;; ANSWER SECTION: id.server. 0 CH TXT "yes" ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt version.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56914 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 79 65 73 (y) (e) (s) ;; QUESTION SECTION: ;version.server. CH TXT ;; ANSWER SECTION: version.server. 0 CH TXT "yes" Note that the NSID value is also "yes". So I realised my mistake, and changes the values from "yes" to "on", and HUPped the server. Now I get: ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt id.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27835 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: Messages has 7 extra bytes at end ;; QUESTION SECTION: ;id.server. CH TXT ;; ANSWER SECTION: id.server. 0 CH TXT "admin.authdns.ripe.net" ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt version.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60856 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: Messages has 7 extra bytes at end ;; QUESTION SECTION: ;version.server. CH TXT ;; ANSWER SECTION: version.server. 0 CH TXT "Knot DNS 1.3.0" Note the warnings from dig about the extra bytes at the end. It seems that if you change the value of NSID and reconfigure the server, it does not appear to pick up the new value correctly. Stopping Knot completely and starting it fixes it, but there appears to be a bug during reconfiguration.

12 let, 9 měsíců

6
12
0 0

Výhodné nabídky ubytování v Chorvatsku

by Ubytování v Chorvatsku

12 let, 9 měsíců

1
0
0 0

Knot DNS v1.3.0 final!

by Marek Vavruša

Hi Everyone, as promised last week, I am proud to announce the 1.3.0 final is out! It's been a long release cycle since the last final release, but it brought lots and lots of bugfixes and a slew of new features. Let me reiterate briefly what's new since the 1.2.0 - one of the most visible features is the new zone file parser, which eliminated the whole zone compilation process and sped up both startup and preparation. There's also a magical configure option --enable-fastparser which makes it even faster (about 2x), very close to loading a binary zone. We also brought our own alternative to DNS utilities like dig, host and nsupdate which aim to be compatible with the ISC counterparts, but also bring some nimble enhancements like pretty comments and output for dig. No smaller are changes to the configuration. Features like groups of remotes, include in config, UNIX sockets for remote control, new knotc commands and general build scripts overhaul that make it nicer for the package maintainers and users. There also was a major refactoring effort under the bonnet (and more to come), which shows in a lower memory consumption, maintainability and trim code base. For many many more, check our web pages or have a look at the NEWS file for an exhaustive list of changes and bugfixes. Back on the ground, we fixed several bugs since rc5 last week. Namely answering from names at or below insecure delegation points, new defaults for CH TXT special zones, randomly disconnected transfers and secondary groups not being initialized when dropping privileges. Also the bootstrap retry timer is now progressive. Many thanks for Anand Buddhdev, Jonathan Hoppe, Johan Ihren, Erwin Lansing and many others who have sent constructive reports, ideas, encouragements and actual code (How cool is that?). As always, you can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- 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

12 let, 9 měsíců

2
1
0 0

Knot DNS 1.3.0-rc5

by Marek Vavruša

Hi, as the 1.3.0 final release is coming out next monday, we would like you to check if everything works for you. There are three major fixed bugs - interrupts during AXFR bootstrap, which is now miles faster for a large number of zones. Also support for obsolete record types in zone transfers. And finally, out of zone records are now discarded during zone transfer, but the transfer as a whole is accepted. There is a new known issue, in which slave zone transfer fails to reschedule. We haven't been able to reproduce that, so if you experience this, please let us know. You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc5/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- 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

12 let, 9 měsíců

3
8
0 0

knotc doesn't wait with "-w"

by Anand Buddhdev

Hello Knot developers, I'm testing 1.3.0-rc4, and have found something that looks like a bug. I'm running knot using the CentOS upstart supervisor, and in the upstart script, I have: pre-stop exec knotc -c $CONF -w stop This means that when I run "initctl stop knot", upstart will run "knotc -c /etc/knot/knot.conf -w stop". The "-w" is supposed to make knotc wait until the server has stopped. However, in reality this is not happening. When the stop command is given, Knot logs this: 2013-07-17T22:48:23 Stopping server... 2013-07-17T22:48:23 Server finished. 2013-07-17T22:48:23 Shut down. And knotc returns *immediately*. However, if I examine the process table, I see the knotd process still running. It takes knotd about 10 more seconds to actually exit, at 22:48:33. This is problematic for upstart. Since knotc has returned, but the knotd process hasn't yet died, upstart thinks that it has not responded to the stop request, and so upstart uses the sledgehammer (kill -9) to stop the knotd process. My assumption is that the knotd process is still doing housekeeping stuff, so the KILL signal is not a good idea. By the looks of it, the "-w" flag to knotc isn't doing what it's supposed to, ie. wait for the server to exit. Could you please investigate this and fix it? (As an aside, I can work around this in upstart by using the option "kill timeout 60" which will make upstart wait at least 60 seconds before trying a KILL signal, by which time knotd should have exited. But this is just a work-around, not a solution). Regards, Anand Buddhdev RIPE NCC

12 let, 10 měsíců

2
3
0 0

Knot DNS 1.3.0-rc4

by Marek Vavruša

Hi there, it seems like we're on streak of fixing stuff this summer, so we have a new fourth release candidate! Main reason is, that we wanted to address two major issues before the 1.3.0 goes golden. First one is a performance regression with AXFR bootstrapping, which also failed to reschedule the request at some points of failure. This should be now fixed with a small but neat performance boost thanks to asynchronous mode of connecting. Second major bug was a RRSIG ending up in a wrong section in an answer to a DS query. After a bit of a discussion, we have decided to reintroduce the 'pidfile' config option and also a new '--with-configdir' configure option to set the default config file directory, which now defaults to $(sysconfdir)/knot. Huge thank you goes to Jonathan Hoppe and Erwin Lansing for bugreports! You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc4/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- 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

12 let, 10 měsíců

2
1
0 0

各个费用

by 张经理

我司有商品销售、广告、建筑安装、服务业、租赁影视制作、培训咨询、网络服务、翻译、印刷会务会议、餐饮住宿、材料、文化娱乐、道路交通国际运输、增值税、海关等票.收费合理为客户节省运作成本提供优质服务. 联系电话：13430930130 业务QQ：780215123 联系人：张经理注；可验证后付款顺祝商祺

12 let, 10 měsíců

1
0
0 0

Listening on IPv6 address

by Leoš Bitto

Hello, it seems that knotd suffers from the same issue as described here: http://lists.scusting.com/index.php?t=msg&th=244420 I have Debian 7.0 with http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-i386/net/knot_1.2.0-… and this is in /var/log/syslog after reboot: Jun 3 22:37:43 ns knot[2091]: Binding to interface 2xxx:xxxx:xxxx:xxxx::1 port 53. Jun 3 22:37:43 ns knot[2091]: [error] Cannot bind to socket (errno 99). Jun 3 22:37:43 ns knot[2091]: [error] Could not bind to UDP interface 2xxx:xxxx:xxxx:xxxx::1 port 53. I have a static IPv6 address configured in /etc/network/interfaces. Restarting knot later binds to this IPv6 address without any problem - it is only the first start which fails (during OS booting). What do you think that is the proper way of making knotd reliably listen on a static IPv6 address? I would prefer if I could avoid restarting knotd. Leos Bitto

12 let, 10 měsíců

2
6
0 0

obsolete rundir

by jh＠netriplex.com

Hello Knot folks: The 'rundir' obsoletes 'pidfile' config option, as the PID file will always be placed in 'rundir'." This is cool, unless you want to run multiple instances of KNOT on a single machine. Can you reconsider this? Jonathan

12 let, 10 měsíců

3
2
0 0

Bootstraping issue in 1.3

by jh＠netriplex.com

Hello KNOT folks, We've found an issue 1.3 with bootstrapping. We're using FreeBSD 9.x, but we also quickly confirmed it exists on Ubuntu 12.x to confirm it was not isolated to FreeBSD. We're testing with about 3000 to 4000 zones, so our environment is not even very large at this point and the bootstrapping failures are very problematic. There are three causes that we've seen thus far: 1. If the AXFR TCP connect is interrupted by a signal, the whole AXFR is aborted and the bootstrap is rescheduled instead of selecting on the socket to either get the successful connection, or until it times out/fails. This can result in a flood of connects, with little to no progress in the bootstrapping. 2. When connected, if a recv() is interrupted by a signal, it isn't retried. This results in connections being dropped that don't need to be dropped. 3. If a successful connect is made, but the remote end subsequently drops it (e.g., resets the connection), then the bootstrap fails without being rescheduled. This was found when slaving from a non-KNOT DNS server that may have TCP rate limiting enabled, or something of that nature. Either way, the fact that it is not rescheduled is very undesirable. I suspect that there are other cases of interrupted system calls not being handled correctly. Here is some additional info that may help find the root cause: - The greater the latency between the master and slave, the worse the problem is. We tested with a slave 80 ms RTT away and it was very bad. - The more worker threads you have, the worse the problem is. So even locally (slave 0 ms away from master) we could reproduce the issue fairly easily. Hopefully this can be remedied! Cheers, Jonathan

12 let, 10 měsíců

2
1
0 0

Knot 1.3.0-rc3 bug report

by Anand Buddhdev

Hi Knot people, I've been trying out rc3, and I've found a few issues, as documented below: 1. In the knotc man page, the "-s" option shows the default as @rundir@/knot.sock. I guess that should have been substituted with the compile-time setting, but wasn't. 2. knotc start doesn't do anything now. It should be removed. 3. knotc restart only stops the server, but does not start it. It should be removed. 4. When configured as a slave, and Knot receives a zone via AXFR containing the following record: <owner-obscured>. 86400 IN TXT "Alliance Fran\195\167aise de Kotte" it serves this record correctly when queried over DNS: dig @a.b.c.d +norec +short txt <owner-obscured>. "Alliance Fran\195\167aise de Kotte" But when saving the zone to disk, this record gets written out as: <owner-obscured>. 86400 IN TXT "Alliance Fran\4294967235\4294967207aise de Kotte" So when Knot restarts and tries to load this zone, it gives an error: Error in zone file /var/lib/knot/XX:4875: Number is bigger than 8 bits. 5. I have configured Knot to log to the file /var/log/knot/knot.log. Most logging goes into it. However, some error messages are still leaking into syslog, for example, the following appears in both Knot's log file, as well as in /var/log/messages (via syslog): logfile: 2013-06-28T20:17:25 [error] Incoming AXFR of 'XX.' with 'a.b.c.d@53': General error. /var/log/messages: Jun 28 20:17:25 admin knot[1630]: [error] Incoming AXFR of 'XX.' with 'a.b.c.d@53': General error. I would expect Knot to send logging to syslog only while it is starting, and it hasn't setup its logging to file yet. Once logging to a file has started, there should be no more logs to syslog, so this looks like a bug, albeit harmless. That's about it for Friday evening :) Regards, Anand Buddhdev RIPE NCC

12 let, 10 měsíců

2
1
0 0

Knot DNS v1.3.0-rc3 released!

by Marek Vavruša

Hi Everyone, I'm happy to announce the third and probably last release candidate for Knot DNS 1.3.0 is out there! This release candidate is a bit special to us, featuring not only a slew of bugfixes but also introducing a new feature. Quite a lot of you asked for a tool to estimate memory consumption for given zone, this is now a new action 'memstats' available in knotc utility. The usage is quite similar to the 'checkzone' command, but it prints out estimated memory consumption instead. You can also pick specific zones if you like. Second quite substantial change is deprecation of 'knotc start'. The preferred method of startup is now using knotd directly, optionally with -d flag for running in background. Also, knotd doesn't create PID files when running in foreground. This is to play nice with managed init scripts and to be able to write out PID atomically. On top of that, you can also alter default 'storage' and 'rundir', see ./configure --help for that. The 'rundir' obsoletes 'pidfile' config option, as the PID file will always be placed in 'rundir'. Third and last substantial change is that knotc now uses UNIX sockets by default and is also now a preferred mode of operation, although IP sockets are still supported. We believe this is safer for now, as the control protocol is not encrypted. It is also enabled by default, to disable control interface completely, add an empty control section to the configuration. But of course, being a release candidate, we didn't forget to pack in a bugfixes. Namely processing of IXFR with a lot of serial changes, processing of TSIG keyfile in knotc and a couple performance regressions related to zone transfers. Big thanks for numerous hours of testing and witty feedback for this release goes to Anand Buddhdev, thank you! You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Kind regards, Marek -- 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

12 let, 10 měsíců

2
1
0 0

DNSSEC implementation survey

by Ondřej Surý

[sorry for cross-post, please don't cross-post when replying] Hi, we are currently implementing DNSSEC in Knot DNS and we would like to gather opinions on this topic. I think we have all have more experience of DNSSEC deployment now and it would be very valuable for us to gather that experience and forge an implementation that would be liked by the users. Could you please spare a few minutes and fill a little survey of ours on this topic? https://docs.google.com/forms/d/1gS-Z1NAL78oFOU51HR6jmg-ZkAevU2CrvCHQgrNnXL… If you don't want to give your answers to NSA :), you can reply to this email (the Reply-To is set to knot-dns-users(a)lists.nic.cz), or just send the feedback back to me. Thank you very much, Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------

12 let, 10 měsíců

1
0
0 0

PID files are passé

by Anand Buddhdev

Dear knot users/developers, I'm testing Knot 1.3.0-rc2. One issue I've run into is when knot exits uncleanly. In this case, it leaves its PID file behind in /var/lib/knot/knot.pid. On the following attempt to start knot, it sees the PID file, and refuses to start, so I have to remove the stale PID file by hand. If I run knot under a supervisor, such as upstart, then it tries to run knot, fails, tries again rapidly in succession, and eventually gives up, at which point knot isn't running. My first observation is that in cases where knot is running under a supervisor, the PID file is not necessary. The supervisor knows knot's PID, and can signal it directly (to reload, or stop). Could you consider making the PID file optional? As in, if in knot.conf, I have: pidfile ""; then knot should not attempt to write (or read or delete) a PID file at all. Alternatively, could you make knot a bit smarter so that if it detects a PID file at startup, but that PID is either not in use, or the process using it is not knot, then it should remove the PID file? Without either of these possibilities, I have to add logic in my startup scripts or supervisor scripts to remove any stale PID files. If I only had one instance of knot, I could do that simply with "rm -f /var/lib/knot/knot.pid", but I'd like to run multiple instances of knot, and so I would have multiple PID files, whose locations I would have to extract from the config file first in order to delete them reliably. This starts to get hairy... I hope I have made a reasonable case for providing an option to not record a PID file, or clean up one before starting. My preference is for the first option, ie. not writing a PID file. Regards, Anand Buddhdev RIPE NCC

12 let, 11 měsíců

3
8
0 0

Knot DNS 1.3.0-rc2 released

by Marek Vavruša

Hi, this is hopefully a last release candidate before the final goes out. Thanks to a massively helpful feedback, we've tackled a few issues from the first rc, namely a name compression-related bug, proper resolution of some CNAME chain loops and a couple log messages and minor annoyances. Also a small sneak peek, as to what can you expect in the final release. Upon several requests, we will add a new (sort of) feature - a memory requirements estimation tool. This should give you a rough idea about how much memory you need to load the zones or for transfers. If you have any special experience about the memory requirements of 1.3.0-rc1, please let us know, this would be immensely helpful to fine tune the estimates. Thanks again for support and very constructive remarks and questions! You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Enjoy the weekend, Marek -- 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

12 let, 11 měsíců

3
2
0 0

Estimating Knot's memory usage

by Anand Buddhdev

Dear Knot developers, I'm testing Knot 1.3.0-rc1 now. One of the things I'd like to be able to do is to estimate Knot's memory usage without actually loading all my zones into it (because if it runs out of memory it will be killed). One very crude way was to load a single zone from a plain text zone file, and comparing the memory used by knot with the size of the zone on disk. For a zone of size 229MB, knot is using about 1.3GB of RAM. So I could say that knot wants about 6x as much RAM for each zone. Is this a reasonable asumption? Alternatively, since you know how knot uses memory for a zone, are you able to provide a small program which can read zones one at a time, calculate the RAM required for each zone, and then print a summary of the total RAM required to load all those zones into knot? We frequently get questions from our users along the lines of "I'd like you to slave this new zone" or "we are going to sign this zone; will your server be able to load it?" It would help an operator immensely if he can get an estimate of the additional RAM required. Regards, Anand Buddhdev RIPE NCC

12 let, 11 měsíců

2
3
0 0

Semantic check warning with wildcard

by Anand Buddhdev

Our BIND server slaves a zone which has the following record (I have replaced the actual TLD with placeholders): *.XX. 60 IN CNAME SERVER.SLD.XX. BIND loads this zone without complaining. However, knot 1.3.0-rc1 refuses to load this zone with the following error: 2013-06-07T13:53:50 [warning] Semantic warning in node: *.XX.: CNAME: CNAME cycle! 2013-06-07T13:53:50 [error] Semantic check found fatal error on line=10 2013-06-07T13:53:54 [error] Zone could not be loaded (-9992).2013-06-07T13:53:54 [error] Zone XX. could not be loaded. As a side note, it looks like there's a newline missing somewhere, because two log lines have appeared on a single line. And what's the -9992 in brackets? Regards, Anand

12 let, 11 měsíců

2
1
0 0

Loaded -12 out of 0 zones?

by Anand Buddhdev

Testing knot 1.3.0-rc1, I'm seeing a strange message in the log if I start it without defining any zones: 2013-06-07T10:44:13 Binding to interface 127.0.0.1 port 5353. 2013-06-07T10:44:13 Configured 1 interfaces and 0 zones. 2013-06-07T10:44:13 2013-06-07T10:44:13 Changing group id to '10073'. 2013-06-07T10:44:13 Changing user id to '10073'. 2013-06-07T10:44:13 Loading 0 zones... 2013-06-07T10:44:13 Loaded -12 out of 0 zones. 2013-06-07T10:44:13 [warning] Not all the zones were loaded. 2013-06-07T10:44:13 Starting server... 2013-06-07T10:44:13 Server started in foreground, PID = 10514 2013-06-07T10:44:13 PID stored in /var/lib/knot/knot.pid 2013-06-07T10:44:13 [warning] Server started, but no zones served. Notice the "-12 out of 0 zones.". Bug? Anand

12 let, 11 měsíců

2
1
0 0

Knot DNS 1.3.0-rc1 is out!

by Marek Vavruša

Hi everyone, we've been very busy for the last couple months, and I'm glad to let you know, that the Knot DNS v1.3.0 first release candidate is finally out! This is a feature-full release, packing a lot of new stuff and improvements. The major change since 1.2.0 is the zone compilation, which is now deprecated and zone files are parsed directly on startup. This was made possible with the new zone file parser, which is neck to neck in terms of speed with whole parsing to loading a precompiled zone. So no more 'compile' steps. Configuration file is also improved with the handy 'group' keyword, that allows you to make groups of remotes and also a support to include another part of config file. This is useful for example if you want to store keys elsewhere. We also now support queries to pseudo CH zone (RFC4892 style), so that is configurable as well (we support identity, version and hostname). On the backend part, we have overhauled several internal structures to lower memory consumption and improved speed and scheduling of zone transfers. Log messages for those are improved as well, giving a more verbose overview of what was transferred, which serial and how long. Apart from that, there are a lot of smaller performance improvements, revamped build system and a lot of small details. For example zone files written out on slave contain a source address, time and other useful information. See NEWS or gitlog for more details. Last new (sort of) feature is, that we included our own DNS tools. Namely kdig, khost and knsupdate. They are quite compatible with BIND9 tools, but they also bring several improvements in logging, prettified output and checks. Be sure to check them out. We also had a terrific user feedback, thanks to Erwin Lansing, Anand Buddhdev, Jan-Piet Mens and everyone for the reports. So that's mostly it! For a full overview of changes see: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Kind regards, Marek -- 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

12 let, 11 měsíců

1
0
0 0

Question about recursion

by Joerg Stephan

Hey guys, i am currently playing around with some dns solutions, currently its knot :-) Is there any solution for recursion. I would like to add an powerdns server to any node which could do lookups for new zones while the configfile isnt written. As you may know registrys like denic are using realtime checks while ordering a domain. Regards Joerg

12 let, 11 měsíců

3
3
0 0

knot 1.2.0 dropping privileges too early

by Erwin Lansing

Thanks for the 1.2.0, some really nice features in there. I especially like the zonestatus command. I have one problem though. It seems that knot drops its root privileges too early, before trying to bind to the interface. Configured with: system { user bind.bind }; Results in: Apr 23 12:26:26 l knot[25585]: [error] Could not bind to UDP interface 127.0.0.1 port 53. Apr 23 12:26:26 l knot[25585]: [error] Could not bind to UDP interface ::1 port 53. Changing to root.bind, makes it work, hence my guess it's related to dropping privileges. This is on FreeBSD 9.0. Any hints appreciated. Best, Erwin -- Med venlig hilsen/Best Regards Erwin Lansing Network and System Administrator DK Hostmaster A/S Kalvebod Brygge 45, 3. sal 1560 København V Tlf. 33 64 60 60 Fax.: 33 64 60 66 Email: erwin(a)dk-hostmaster.dk Homepage: http://www.dk-hostmaster.dk .dk Danmarks plads på Internettet ------------------------------------------------------------------------- Dette er en e-mail fra DK Hostmaster A/S. Denne e-mail kan indeholde fortrolig information, som kun er til brug for den tiltænkte modtager. Hvis du ved en fejl har modtaget denne e-mail, bedes du venligst straks give afsenderen besked om dette og slette e-mailen fra dit system uden at offentliggøre, videresende eller tage kopi af meddelelsen. This is an email from DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee please notify the sender immediately and delete this e-mail from your system. You are not permitted to disclose, distribute or copy the information in this e-mail. --------------------------------------------------------------------------

13 let

2
4
0 0

Debian repository

by Igor Živković

Hello, I can't access your deb packages: W: Failed to fetch http://deb.knot-dns.cz/debian/dists/wheezy/main/source/Sources 403 Forbidden [IP: 81.91.84.116 80] W: Failed to fetch http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-amd64/Packages 403 Forbidden [IP: 81.91.84.116 80] Could you please check it out? -- Igor Živković

13 let, 1 měsíc

2
1
0 0

Query timeout when testing

by jh＠netriplex.com

Hi, We're using the latest version 1.2.0 after updating from 1.1.0. It seems that when we run a dnsperf against it, we now get many query timeouts. It isn't that we're overloading the server, because we can run a 2nd server with dnsperf and get similar throughput (22k qps) but it too has query timeouts of about just under 1%. This seemed like maybe it was the response rate limiting, but it says it is off by default. To be sure, I set the parameter in the config to be off. Am I missing something? Is there something else I need to turn off? Thanks for any guidance anyone can provide! Jonathan

13 let, 1 měsíc

2
2
0 0

Knot DNS 1.2.0 final is out!

by Marek Vavruša

Hello everyone, we're happy to announce that the Knot DNS 1.2.0 final is out after the fourth release candidate. Just to reiterate what's new and fixed in the 1.2.0, we brought 3 new features in the 1.2.0. First is a support for dynamic updates (DDNS) including forwarding to the primary master, which received a couple of bugfixes in the early release candidates. Since the third release candidate there is a Response Rate Limiting as a new way to combat increasing amplification/reflection attacks. It's been slightly reworked since the release candidate and disabled by default. You can enable it by setting 'rate-limit' config option to a sensible value. Last feature is a reworked control utility which is now able to control the daemon remotely and even introduced a few new commands, namely 'zonestatus' to fetch the status of served zones. Aside from the new features, it also fixes a few bugs. Namely missing RRSIGs in the response to the ANY type, processing of some malicious domain names and a detection of broken implementation of recvmmsg() on some Linux distributions. As usual, you can find a full list of changes at https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2.0/e… Sources: https://secure.nic.cz/files/knot-dns/knot-1.2.0.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- 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

13 let, 1 měsíc

1
0
0 0

Knot DNS 1.2.0-rc4 released

by Marek Vavruša

Hi everyone, as an outcome of the discussions on the RRL mailing lists and a stellar feedback in recent weeks, we have decided to slip yet another release candidate before the 1.2.0 finally goes out. The release candidate features a reworked classification in RRL in respect to the RRL technical memo and also includes code to resolve hash collisions in the former implementation. Also a new 'zonestatus' command was introduced to knotc and a several bugs were fixed, namely logfile ownership problems, faster rate of SOA queries on refresh and knotc respecting 'control' section in configuration. As usual, you can find a full list of changes at https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2.0-r… Sources: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc4.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc4.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Have a nice weekend, Marek -- 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

13 let, 1 měsíc

1
0
0 0

Knot memory usage

by Anand Buddhdev

On a server with 16 GB of RAM, my instance of BIND can load my 5174 zones into memory and use around 13 GB. Knot didn't do so well. At some point while trying to XFR-in these zones, it hit the memory limit and the Linux out-of-memory killer came along and killed it. When I started it up again, it began loading zones in from the disk, but then appeared to go into some kind of loop, and the CPU usage was 100%. This is usually a sign that it is stuck in some kind of loop or deadlock. The only want to stop it is with a KILL signal (TERM doesn't work). The log didn't output anything. How can I help debug this? Do you have any numbers on how much RAM Knot will require given a bunch of zones? This would allow me to estimate how much RAM I will need in a server for the zones I have. Regards, Anand

13 let, 1 měsíc

3
5
0 0

Query logging

by jh＠netriplex.com

Hello, Is there any existing functionality to log queries? I've enabled all existing logging for the "answer" category and do not see any. But maybe it is unsupported in version 1.1.0? log { syslog { answering all; } } Thanks, Jonathan

13 let, 1 měsíc

5
7
0 0

Documentation nits

by Jan-Piet Mens

Hello, I'd like to mention a few nits about Knot's documentation, if you don't mind. :) 1. Docs linked to from https://www.knot-dns.cz/documentation.html have URLs which don't look permanent; this makes it difficult to link to individual pages. It would be better imo, to have permanent URIs. 2. The usage message for [knotc flush] says "Flush journal and update zone files.". I understand this to mean zones that have received updates (RFC2136) will be written out, but this doesn't occur. I note zones are written out only at the end of a `zonefile-sync' period. 3. ixfr-from-differences, while documented in the manual, points to 'Controlling running daemon', but it doesn't say there, that the syntax is 'on/off'. Enabling this in zones {} doesn't seem to do anything here: I was expecting to see a "*.ixfr" or some such file containing diffs, but I get none; neither for incoming xfr, nor for DNS updates. 4. Docs specify in 'Controlling running daemon' there is a knotc option -a, but the code doesn't have that: knotc: invalid option -- 'a' Same for 'Running Knot DNS' chapter. Regards, -JP

13 let, 1 měsíc

3
2
0 0

knotc refresh speed

by jh＠netriplex.com

Hello, Yesterday I had Knot 1.1.0 installed and with 4000 test zones on a slave server configuration, a knotc refresh would hit my master to check SOA on all zones very quickly (I would see over 600 queries per second). It could generally complete the task in well under 60 seconds. Today I have upgraded to 1.2.0-RC3 and with the same 4000 test zones on a slave server configuration a knotc refresh is extremely slow. It issues SOA queries to the master at about 10 queries per second. Why this change? Is there any setting I can implement to speed this up? In a production environment with 250k+ zones, this obviously won't work. Thanks! Jonathan

13 let, 1 měsíc

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users