We will harden the code in question for today's release, but we're still unsure as to what caused the error. We're guessing that your zone got somehow corrupted - we'll investigate more today. Once the new release comes out, please delete all the .db files on your slave, to make sure you get the right data.

Edited Sep 10, 2014

~~We will harden the code in question for today's release, but we're still unsure as to what caused the error.~~ We're guessing that your zone got somehow corrupted - we'll investigate more today. Once the new release comes out, please delete all the .db files on your slave, to make sure you get the right data.

If we don't have luck with the core dump, having your zone files would help a lot. But I understand that can be a problem. However, if they are not highly classified, it would be great if you could email them to me (obviously I will not disclose the zone files anywhere).

Edited Sep 10, 2014

If we don't have luck with the core dump, having your zone files would help a lot. But I understand that can be a problem. However, if they are not highly classified, it would be great if you could email them to me (obviously I will not disclose the zone files anywhere).

I must admit that we do not yet know what's causing this. We have a testing setup mimicking yours as close as possible, we're constantly signing the zones and hitting it with all the possible queries for your zones. No luck crashing the server. Maybe your servers get some queries we haven't generated. What kind of traffic do you get at your servers? Are there some automated queries? Could you try to capture DNS messages around 8am using tcpdump? You can scramble the source IPs, we only care about DNS queries. I am sorry that this is taking us so long to fix. If we get core dumps + some info about the traffic, we should have the fix soon.

I must admit that we do not yet know what's causing this. We have a testing setup mimicking yours as close as possible, we're constantly signing the zones and hitting it with all the possible queries for your zones. No luck crashing the server. Maybe your servers get some queries we haven't generated. What kind of traffic do you get at your servers? Are there some automated queries? Could you try to capture DNS messages around 8am using tcpdump? You can scramble the source IPs, we only care about DNS queries. I am sorry that this is taking us so long to fix. If we get core dumps + some info about the traffic, we should have the fix soon.

I've set up an at job to capture traffic on UDP/53 from 7:30. I'm afraid I'll get the resolver's traffic too.

I don't know what king of traffic get, mostly machine generated (MX & bots) I guess, as only a few people use the services hosted on these addresses.
I'll try to get the cores because I'm very curious about that.

At last, do not delay your release for me, I can live with a few 5 seconds DNS outage per day for a while

I've set up an at job to capture traffic on UDP/53 from 7:30. I'm afraid I'll get the resolver's traffic too.
I don't know what king of traffic get, mostly machine generated (MX & bots) I guess, as only a few people use the services hosted on these addresses.
I'll try to get the cores because I'm very curious about that.
If you want to mimic the server, you may grab the kernel I use at http://apt.geekwu.org/pool/main/l/linux-source-3.2.61-grsec/linux-image-3.2.61-grsec_201407280723_amd64.deb (I use grsecurity, but no RBAC. I should have said that before, but I forget this one, sorry)
At last, do not delay your release for me, I can live with a few 5 seconds DNS outage per day for a while

The problem is connected to a combination of DNSSEC and query module + query to RR type that is not covered by the module (but domain is). We do not currently sign any of the synthesized records, and Knot crashed while trying to prove one of the responses. We're discussing what the right action is. Either way, we'll have a fix soon.

Edited Sep 12, 2014

The problem is connected to a combination of DNSSEC and query module + query to RR type that is not covered by the module (but domain is). We do not currently sign any of the synthesized records, and Knot crashed while trying to prove one of the responses. We're discussing what the right action is. Either way, we'll have a fix soon.