crash in nsd ec8d14f8aa32903e894033c678a7268091002a92

[nlnetlabs]

crash in nsd ec8d14f8aa32903e894033c678a7268091002a92

[wcawijngaards]

Are you using the latest version? There are recent fixes in this area, so it may already have been fixed (if you are using an older version). What version are you using?

[jaredmauch]

Version is that git commit in issue name.

[wcawijngaards]

Thanks! Did not see that. This is very recent. Bug looks like it happened in the AXFR of your zone svanheule.net. During the clean of the NSEC3 tree by hash. The tree looks like it contains eg. deleted values.
From the config it looks like you have a database file enabled, this is the default, but we recommend database: "" and then it writes to text files once in a while. I do not think that makes a difference for the bug in question.
I see that the zone is expired, from the SOA record that must mean it has no updates in 4 weeks. And the old version updated with the new version gives the problem. Is the problem reproducible by loading the old zone file (from text file, or from the database (can be exported with 'make udb-inspect', ./udb-inspect -l -vv > some_file and editing to get svanheule.net ) , then after loading it getting a fresh download over that? It would be nice to reproduce.

[wcawijngaards]

The stack trace indicates that your zone contents is from 'Mon 12 Nov 2018 04:30:31 PM CET'
It must have failed to update all this time. Also DNSSEC signatures I guess are expired in that version by now.
Another way to get the zone file is to move away (for analysis) the zonefile /etc/nsd/secondaries/svanheule.net (to `svanheule.net.bak' or something) and then nsd-control write svanheule.net

[jaredmauch]

Do you want the files for debug purposes?

[wcawijngaards]

Yes, I am hoping to reproduce the crash by loading the old file (and perhaps also by triggering an AXFR transfer, it does not really seem to get into the contents of that new zone when the crash happens). You can also see if it does that if the crash happens again if you load the old zone file again.
If it does not do that, ehm. Something must be wrong, somehow. Some other debug would be needed.

[jaredmauch]

Moving the zone file away seems to have mitigate this. It's still an odd crash.

[jaredmauch]

Going to close this as likely fixed in #105