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

by Anand Buddhdev

11 let, 2 měsíce

1
0
0 0

Fwd: Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

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

11 let, 2 měsíce

2
1
0 0

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

by Marek Vavruša

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

11 let, 2 měsíce

1
0
0 0

Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

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

11 let, 2 měsíce

4
8
0 0

Re: [knot-dns-users] knot-dns-users post from fay-mutluluk-hikayeleri@fotoalem.com requires approval

by Jan Včelák

Dne St 28. května 2014 16:19:49, knot-dns-users-owner(a)lists.nic.cz napsal(a): > As list administrator, your authorization is requested for the > following mailing list posting: > > List: knot-dns-users(a)lists.nic.cz > From: fay-mutluluk-hikayeleri(a)fotoalem.com > Subject: You are in the financial matrix. Choose the red pill! > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > https://lists.nic.cz/cgi-bin/mailman/admindb/knot-dns-users > > to approve or deny the request.

11 let, 2 měsíce

1
0
0 0

Knot DNS 1.4.6 patch release

by Jan Kadlec

Hello List! Today, we release Knot DNS 1.4.6 with two minor fixes. First issue we've fixed would only occur when doing DNSSEC key rollover using the key metadata (via the dnssec-settime tool, for example) - there was a possibility that the server would try to sign the zone continuously for a limited amount of time. DNSSEC data would stay valid all the time though. The other fix concerns mainly RRL users with recvmmsg enabled - when using SLIP other than 1, responses that should have been dropped were actually sent as empty UDP datagrams. Such responses would not be helpful to the attacker, as they are actually smaller than the queries, but they could confuse legitimate clients. This applies for the responses to malformed query messages as well, even if the RRL is disabled. All in all, if you do not use the automatic DNSSEC or RRL, there's probably no need to update. Hopefully, this is the last release before the 1.5RC1 comes out, so stay tuned. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.6/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.xz.asc Updated packages will be available shortly. Thank you for using Knot DNS. Regards, Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 2 měsíce

1
0
0 0

knot as a recursive server too - it is planned ?

by Josef Karliak

Hi there, do you plan to enable/run Knot as a recursive server too ? We used our master dns server as a recursive server too (only for our servers), but after migrating from Bind to Knot it is not possible. For now I had to change asking secondary dns server with bind, but ... :) Thanks and best regards J.Karliak.

11 let, 3 měsíce

7
9
0 0

knot 1.4.x and enabling debug.

by Josef Karliak

Hi, I've some problems with my domains, I was unreacheable because of knot wasn't responding. I want to run debug, I've this in my knot.conf: ... ... log { syslog { any all; zone all; } file "/var/log/knotd.debug" { server debug; zone debug; } ... ... but the "/var/log/knotd.debug" file is empty. Did I missed something ? :) About knot : he was running, SOA querried to master server that my knot makes slave, but didn't answered for my domains that he manage. After restart knot all's fine... Anyway I made a few minutes ago update of the knot, maybe some "old" bug fixed in the new version, now running "knot-1.4.4-49.1.x86_64". Thanks and best regards J.Karliak.

11 let, 3 měsíce

2
1
0 0

[PATCH] Turn off TTL display when printing a question section

by Robert S. Edmonds

Question resource records do not include a TTL field (per RFC 1035 §4.1.2), so it seems strange to display a zero TTL when printing the question section. This makes kdig match the question section dump style of drill and dig. --- src/utils/common/exec.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/utils/common/exec.c b/src/utils/common/exec.c index 92af2df..aa5485d 100644 --- a/src/utils/common/exec.c +++ b/src/utils/common/exec.c @@ -200,9 +200,10 @@ static void print_section_question(const knot_dname_t *owner, size_t buflen = 8192; char *buf = calloc(buflen, 1); knot_rrset_t *question = knot_rrset_new(owner, qtype, qclass, NULL); + knot_dump_style_t qstyle = style->style; + qstyle.show_ttl = 0; - if (knot_rrset_txt_dump_header(question, 0, buf, buflen, - &(style->style)) < 0) { + if (knot_rrset_txt_dump_header(question, 0, buf, buflen, &qstyle) < 0) { WARN("can't print whole question section\n"); } -- 1.9.1

11 let, 3 měsíce

2
1
0 0

Knot DNS 1.4.5

by Jan Včelák

Hello Everyone! Today, we announce the Knot DNS 1.4.5, which includes one security fix. We found out, that the TSIG validation code contains a possible weakness. The received TSIG digest was compared using string comparison functions, instead of functions intended for binary data. As a result, under certain conditions, the TSIG digest was compared only partially. We believe that this has no huge security impact, but it is worth fixing as soon as possible. Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.xz.asc Corresponding patch (applicable to older releases): https://gitlab.labs.nic.cz/labs/knot/commit/e796477dd60020031610b156fdca07a… We are sorry for the complications. Best Regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 4 měsíce

1
0
0 0

Knot NSEC3 with opt-out

by Klaus Darilion

Hi! I use knot 1.4.4 and sign my zones with NSEC3. Is NSEC3 with opt-out supported? If yes, how can I activate opt-out? I tried setting the flag in the NSEC3PARAM record but apparently this does not activate opt-out. Thanks Klaus

11 let, 4 měsíce

2
4
0 0

Knot DNS 1.5 technology preview

by Marek Vavruša

Hi Everyone, we're getting closer to the 1.5 release and because we're mostly feature complete now, I think today might be a good opportunity to share some of the new stuff we've created and hear out your opinions. There's a ton of improvements that I can't cover in a few paragraphs, but I've picked 3 of those that I think are the pillars for the bigger plan for this year. Just so you know, there is no tarball this time, but if you're brave enough, you can actually try everything covered here. You can find the code in our git repository under a tag "v1.5.0-alpha": $ git clone -b v1.5.0-alpha https://gitlab.labs.nic.cz/labs/knot.git 1. Query processing and code base We've known for a while that there were parts of the code that we weren't happy with. It's not just that it was getting hard to patch and read, but with we had a ton of ideas that we couldn't get implemented because of the limitations (in fact, this effort bears fruits as soon as of this release, but more on that later). One of those places was query processing and dealing with queries in general. Naturally, we've sat down and reworked this from scratch. Now, from the user perspective it's not so exciting - yes we made it RFC compliant in several cases and it's faster than ever (I'm running benchmarks as we speak, so you might want to check out our webpage later). It's still a preview and we're ironing things out, so don't take the numbers as final. For those who are interested in the details (thank you!), it's much much more important because the code lays a solid foundation for the cool stuff to come while being lightweight. How much? Around 10+k LOC which is roughly 10-15% of our code base gone and we offset that by adding almost 5k LOC worth of test cases. To put it in another words, it means it does more with less and we're not done here. 2. Separating Knot DNS library We also improved the Knot DNS build process overall. The code providing basic building blocks for the server and utilities is now held in the libknot library, which is by default linked dynamically to these components. You will also notice the libzscanner library, our high-performance zone scanner written in Ragel (with no dependencies on Knot DNS). We plan to build some other projects on top of that and provide public headers in the future (which is more likely to happen for the libzscanner - if someone is interested). But currently, you may benefit from a smaller size of the binaries. 3. Pluggable query processing modules + auto forward/reverse records New features are always a compromise - usually between ease of use, complexity and resource usage. But what if we could make the core as lightweight as possible and let the user choose? The new processing API is built like a Lego (don't step on it though), it breaks down the processing into independent parts that together form a plan for query processing. So what we did was, we've created an interface for loadable modules and let it add/remove or change the query processing plan as the module sees fit. This allows to keep complexity at bay (for those who don't want extra stuff) and provide a playground for new ideas. We actually have a first module - it can synthesize per-answer forward/reverse records for IPv4/IPv6 addresses from a template in configuration file (see 4.11 in the documentation on further information). For the impatient, an example speaks the best: We have an IPv6 reverse zone we need to take care of, but the problem is the address space is too big to generate a zone file. So we create an empty zone, put in static records we want and let the module to synthesize other records per-answer (if they fit in the template and aren't present in the zone): # Configuration: 1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa { query_module { synth_record "reverse dynamic- example. 400 2620:0:b61::/52"; } Now if we load Knot DNS, and kdig for a reverse record, we get a following reply: $ kdig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa. ;; QUESTION SECTION: ;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa. 0 IN PTR ;; ANSWER SECTION: ..snip.. 400 IN PTR dynamic-2620-0000-0b61-0000-0000-0000-0000-0001.example. Forward records can be dealt with in a similar fashion, see the manual 4.11 for more examples and information. To sum it up, modules could be a way to accommodate for the "should this be a in a nameserver?" sort of things. If you don't like it, just don't put it in the configuration and you're good. As of now the module API is open (no "how to" though), and so are we for ideas. Phew, this was longer than I expected and I barely scratched the surface. As you see, this version is going to be a lot about tidying up and opening up the possibilities. So what's your take on this? Best, Marek -- Marek Vavrusa, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 4 měsíce

1
0
0 0

Knot DNS 1.4.4

by Marek Vavruša

Hi Everyone, while we in the CZ.NIC Labs are all focused on the next big thing, I thought now it might be a good time to get out another of our (admittedly highly irregular) monthly patch releases. Bug fixes aside, there are a couple improvements that we hope will make your life easier. Here's the breakdown: - 'knotc reload' does not immediately refresh/notify unchanged zones. This fixes the flurry of refresh messages after each reload and makes it lightweight enough to be used frequently. Note that new/changed zones are still added and old zones are removed. However, if you want to refresh zones explicitly, you need to call 'knotc refresh' after reload now. - 'knotc -f refresh' now truly forces a zone refresh. To put it in another words, it's akin to the 'retransfer' command that you missed in the Knot DNS and instead of checking for new zone, it starts a full transfer of the zone right away. - 'knotc' remote commands are now logged in the daemon logfile Now, there are several bugfixes as well. See the NEWS for a complete list, but here's a selection of the most notable - in several cases notify messages weren't sent after a zone resign, progressive bootstrap retry regression was fixed, few issues with journal and maximum entry size. There is also a slight behaviour change in the zone file parser and the daemon itself. First - zone file parser now accepts asterisk in the domain name labels (wildcards aside). As for the daemon, if a zone is in a slave mode and fails to load for some reason, it immediately tries to reboostrap from the master server instead of just reporting an error. I'd also like to thank to Robert S. Edmonds for amending various spelling errors and typos in manpages and documentation, thanks! So that's it, I hope the improvements make this update a little worthwhile before new stuff comes out later this spring. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz.asc Kind Regards, Marek -- Marek Vavrusa, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 4 měsíce

1
0
0 0

Some issues with dnssec signed domain.

by Josef Karliak

Hi there, I migrated our primary DNS from Bind to Knot. I runned some tests by nic.cz's dnscheck, but there is an error: DNSSEC signature RRSIG(fnhk.cz/IN/SOA/64431) fails to validate the RR set: key 1: keytag does not match key 2:RSA Verification failed Link to test: http://dnscheck.labs.nic.cz/?time=1395821962&id=102810&view=advanced&test=s… Knot doesn't complains to anything in the system log, fnhk.cz zone is succefully signed. What did I missed ? Thanks and best regards J.Karliak.

11 let, 4 měsíce

2
3
0 0

[PATCH] various spelling and typo fixes

by Robert S. Edmonds

--- Doxy.page.h | 2 +- doc/introduction.texi | 2 +- man/kdig.1.in | 2 +- man/khost.1.in | 2 +- src/utils/common/params.h | 2 +- src/utils/dig/dig_exec.c | 4 ++-- src/utils/dig/dig_params.h | 4 ++-- src/utils/nsupdate/nsupdate_params.h | 2 +- 8 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Doxy.page.h b/Doxy.page.h index 03e43e5..e1b91f2 100644 --- a/Doxy.page.h +++ b/Doxy.page.h @@ -33,7 +33,7 @@ Knot DNS supports the following DNS features: - AXFR - master, slave - IXFR - master (primary master experimental), slave - TSIG -- ENDS0 +- EDNS0 - DNSSEC, including NSEC3 - NSID - Unknown RR types diff --git a/doc/introduction.texi b/doc/introduction.texi index fccb2f1..96e53cb 100644 --- a/doc/introduction.texi +++ b/doc/introduction.texi @@ -31,7 +31,7 @@ Knot DNS supports the following DNS features: @item TCP/UDP protocols @item AXFR, IXFR - master, slave @item TSIG -@item ENDS0 +@item EDNS0 @item DNSSEC, including NSEC3 @item NSID @item Unknown RR types diff --git a/man/kdig.1.in b/man/kdig.1.in index 69a19e8..c313411 100644 --- a/man/kdig.1.in +++ b/man/kdig.1.in @@ -151,7 +151,7 @@ Show TTL value. Use TCP protocol (default is UDP for standard query and TCP for AXFR/IXFR). .TP .BR + [ no ] fail -Stop quering next nameserver if SERVFAIL response is received. +Stop querying next nameserver if SERVFAIL response is received. .TP .BR + [ no ] ignore Don't use TCP automatically if truncated reply is received. diff --git a/man/khost.1.in b/man/khost.1.in index e25ba35..1bf677b 100644 --- a/man/khost.1.in +++ b/man/khost.1.in @@ -41,7 +41,7 @@ Print help. Disable recursion. .TP .B \-s -Stop quering next nameserver if SERVFAIL response is received. +Stop querying next nameserver if SERVFAIL response is received. .TP .B \-T Use TCP protocol. diff --git a/src/utils/common/params.h b/src/utils/common/params.h index 78dd70a..d7c34c6 100644 --- a/src/utils/common/params.h +++ b/src/utils/common/params.h @@ -98,7 +98,7 @@ typedef struct { bool hide_cname; } style_t; -/*! \brief Parametr handler. */ +/*! \brief Parameter handler. */ typedef int (*param_handle_f)(const char *arg, void *params); /*! \brief Parameter argument type. */ diff --git a/src/utils/dig/dig_exec.c b/src/utils/dig/dig_exec.c index aaab062..e10b7a8 100644 --- a/src/utils/dig/dig_exec.c +++ b/src/utils/dig/dig_exec.c @@ -409,7 +409,7 @@ static void process_query(const query_t *query) WALK_LIST(server, query->servers) { srv_info_t *remote = (srv_info_t *)server; - DBG("Quering for owner(%s), class(%u), type(%u), server(%s), " + DBG("Querying for owner(%s), class(%u), type(%u), server(%s), " "port(%s), protocol(%s)\n", query->owner, query->class_num, query->type_num, remote->name, remote->service, get_sockname(socktype)); @@ -652,7 +652,7 @@ static void process_query_xfr(const query_t *query) // Use the first nameserver from the list. srv_info_t *remote = HEAD(query->servers); - DBG("Quering for owner(%s), class(%u), type(%u), server(%s), " + DBG("Querying for owner(%s), class(%u), type(%u), server(%s), " "port(%s), protocol(%s)\n", query->owner, query->class_num, query->type_num, remote->name, remote->service, get_sockname(socktype)); diff --git a/src/utils/dig/dig_params.h b/src/utils/dig/dig_params.h index 7287fb7..c9caa3b 100644 --- a/src/utils/dig/dig_params.h +++ b/src/utils/dig/dig_params.h @@ -90,7 +90,7 @@ typedef struct { int32_t wait; /*!< Ignore truncated response. */ bool ignore_tc; - /*!< Stop quering if servfail. */ + /*!< Stop querying if servfail. */ bool servfail_stop; /*!< Class number (16unsigned + -1 uninitialized). */ int32_t class_num; @@ -116,7 +116,7 @@ typedef struct { /*! \brief Settings for dig. */ typedef struct { - /*!< Stop processing - just pring help, version,... */ + /*!< Stop processing - just print help, version,... */ bool stop; /*!< List of DNS queries to process. */ list_t queries; diff --git a/src/utils/nsupdate/nsupdate_params.h b/src/utils/nsupdate/nsupdate_params.h index 599c9b4..e823f75 100644 --- a/src/utils/nsupdate/nsupdate_params.h +++ b/src/utils/nsupdate/nsupdate_params.h @@ -43,7 +43,7 @@ /*! \brief nsupdate-specific params data. */ typedef struct { - /*!< Stop processing - just pring help, version,... */ + /*!< Stop processing - just print help, version,... */ bool stop; /*!< List of files with query data. */ list_t qfiles; -- 1.9.0

11 let, 4 měsíce

2
1
0 0

Audit the consistency of zone files, out of sync MX

by Maren S. Leizaola

Hello, What do you guys recommend to audit every resource record in a zone file against all the records in all the DNS. I want something that I feed the master zone file and then goes to each NS server and ensures that the records are correct in all of them. For some strange reason all my DNS servers have the same SOA Serial, but after deleting two MX records, some 4 out of 5 the DNS servers have not taken this update. I've yet to figure out the cause, but I see that SOA Serial is not to be trusted. Regards, Maren.

11 let, 5 měsíců

1
1
0 0

Re: [knot-dns-users] knot-dns-users Digest, Vol 28, Issue 9

by Maren S. Leizaola

On 2/24/2014 7:00 PM, knot-dns-users-request(a)lists.nic.cz wrote: > Date: Mon, 24 Feb 2014 09:16:27 +0100 > From: Jan Kadlec <jan.kadlec(a)nic.cz> > To: "Maren S. Leizaola" <leizaola(a)hk.com> > Cc: knot-dns-users(a)lists.nic.cz > Subject: Re: [knot-dns-users] GLUE and additional records. > Message-ID: > <1393229787.1717.12.camel(a)labs.jan.kadlec.ws.eth.1.office.nic.cz> > Content-Type: text/plain; charset="UTF-8" > > Hello Maren and thanks for your report. Knot normally sends glue records > in additional section, it seems as if you might have encountered a bug. > Could you provide more data? One NS, A (AAAA) combination and a dig > output for this combination should be enough. Thanks again, Jan. > The environment is as follows. I host hk.com on 6 DNS servers, right now 5 are bind and one is Knot. hk.com's name servers are a,b,c,d,e,f.udrtld.net b is running Knot. Try this link www.intodns.com/hk.com This reports that B provides no glue. Please ignore the errors on f. i've yet not setup urdtld.net on it. dig -cA hk.com @b.udrtld.net when I do a dig -cA hk.com @a.udrtld.net Am I making any mistakes here? Maren.

11 let, 5 měsíců

4
9
0 0

GLUE and additional records.

by Maren S. Leizaola

Hello, I am currently testing Knot on our zones and find that it does not give any of the additional records which contain the IP of the names servers ie knot servers donot provide Glue records. This is one good thing that Bind does at it reduces the number of queries a resolver has to make. Is there any way for us to be able to do this. Regards, Maren.

11 let, 5 měsíců

2
1
0 0

/help

by Maren S. Leizaola

/subscribe /list

11 let, 5 měsíců

1
0
0 0

Knot DNS 1.4.3

by Marek Vavruša

Hi Everyone, I think the time is ripe for a small status update, preview of things to come and a new patch release. Sounds good? So, at the moment, our team at the CZ.NIC Labs is working towards the next major thing, but I'd like to reiterate that we didn't forget about the 1.4 and as of today we have a new release with several important backported bugfixes, here's the brief version: * Two bugs related to authenticated denial of existence proof with a certain combination of wildcard expansions triggering an assertion failure * Comparison of $ORIGIN and zone file in configuration is case insensitive * Corrupted journal data caused a cleanup failure during the zone loading In addition to the bugfixes, we have also slipped in a small enhancement - "include" statement in the configuration can include whole directory, this is useful if you have really a lot of includes in one place. Now a brief status update on what are we working on and what can you expect in the next few weeks/months. The next major release is going to happen later this spring and it's going to be focused on three things mostly - covering the code by tests, cleaning up and polishing existing features. There's going to be a feature or two, but that is not the main focus. The reason is the functionality we have piled up over the time has taken it's toll and now is the right time to sit back and make the features leaner and meaner (that includes usability as well), as that was always an integral idea behind Knot DNS. Plus less things means less things to break, right? I'd like to thank namely Petr Stastny and Olafur Gudmundsson (among others) for bugreports, ideas and thoughts. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz.asc Kind Regards, Marek -- Marek Vavrusa, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 5 měsíců

1
0
0 0

Feature request: force zone retransfer

by Anand Buddhdev

Hi Knot developers, I have a feature request: I'd like a knotc command that will force Knot to transfer a zone that is configured as a slave. The only command I can issue at the moment is "refresh", but this will not transfer a zone if Knot has a higher serial than the master. Such a forced transfer command is useful to help recover from situations where due to some operational error on the master server, the serial number has gone back, and we deliberately need our Knot server to sync to that old serial number. Without this command, the only way to make Knot recover is to stop it, delete the zone file from disk and start it again. But this is not ideal on a running server with lots of zones, because the stop and start times can be quite high (in our case, 37s to stop, and 1m30s to start). Both BIND and NSD provide such commands to ignore the serial number check and force zone transfers. I'd love to see such a command for Knot too. Regards, Anand

11 let, 6 měsíců

2
1
0 0

Case handling of zone names and in $ORIGIN

by Olafur Gudmundsson

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

11 let, 6 měsíců

2
1
0 0

DS records

by Sime Ramov

Hello, I'm using Knot DNSSEC automatic signing and all is well and working. How would one go about obtaining proper DS records for registrar glue with least amount of trouble? Thanks for Knot DNS, by far the most pleasant experience in comparison with all other DNS servers. I've had zero issues with it, flawless operation from the start!

11 let, 6 měsíců

3
3
0 0

Knot DNS 1.4.2 patch release

by Jan Včelák

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

11 let, 6 měsíců

4
6
0 0

RRSIG in additional section: reason for TC?

by Hauke Lampe

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

11 let, 6 měsíců

2
1
0 0

Warning messages does not contain domain name

by Petr Šťastný

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

11 let, 6 měsíců

2
1
0 0

Disable journals

by Petr Šťastný

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

11 let, 6 měsíců

2
3
0 0

Knot 1.4.0 a retezec duvery.

by Josef Karliak

Hoj vespolek. trosku jsem se uz ztratil s dnssecem s knotem. Vygeneroval jsem si klice, rekl knotu, kde ma klice hledat, knot je podepsal, zadna stiznost od nej. Klic jsem zadal i do keysetu na web4u, to proslo taky. Ale pokud si udelam drill my zony, drill oznami, ze mi chybi DS zaznam nebo trusted key: drill -TD ajetaci.cz Warning: No trusted keys were given. Will not be able to verify authenticity! ;; Domain: . ;; Signature ok but no chain to a trusted key or ds record [S] . 172800 IN DNSKEY 256 3 8 ;{id = 33655 (zsk), size = 1024b} . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} Checking if signing key is trusted: New key: . 172800 IN DNSKEY 256 3 8 AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX195Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6WybBZ6kuqED ;{id = 33655 (zsk), size = 1024b} [S] cz. 86400 IN DS 54576 10 2 397e50c85ede9cde33f363a9e66fd1b216d788f8dd438a57a423a386869c8f06 ;; Domain: cz. ;; Signature ok but no chain to a trusted key or ds record [S] cz. 18000 IN DNSKEY 256 3 10 ;{id = 40877 (zsk), size = 1024b} cz. 18000 IN DNSKEY 257 3 10 ;{id = 54576 (ksk), size = 2048b} cz. 18000 IN DNSKEY 256 3 10 ;{id = 54602 (zsk), size = 1024b} [S] Existence denied: ajetaci.cz. DS ;; No ds record for delegation ;; Domain: ajetaci.cz. ;; Signature ok but no chain to a trusted key or ds record [S] ajetaci.cz. 3600 IN DNSKEY 257 3 5 ;{id = 36256 (ksk), size = 2048b} ajetaci.cz. 3600 IN DNSKEY 256 3 5 ;{id = 11937 (zsk), size = 1024b} [S] ajetaci.cz. 3600 IN A 77.48.63.10 ;;[S] self sig OK; [B] bogus; [T] trusted -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (with ADSP) . Pokud mate problemy s dorucenim emailu, zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji. My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP) policy and check. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

11 let, 6 měsíců

4
8
0 0

Logging categories

by Petr Šťastný

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

11 let, 6 měsíců

2
1
0 0

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

by daniel.salzman＠nic.cz

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

11 let, 7 měsíců

4
4
0 0

Knot DNS 1.4.1 patch release

by Marek Vavruša

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 7 měsíců

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

11 let, 8 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

11 let, 8 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

11 let, 8 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

11 let, 8 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

11 let, 9 měsíců

8
22
0 0

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

by Jon Francis

11 let, 9 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

11 let, 9 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

11 let, 9 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

11 let, 10 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

11 let, 11 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

11 let, 11 měsíců

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users