We've stumbled upon a problem with two zones that are slaved at our
server running NSD 3.2.18 The zone contains something like this:
*.foo.bar.nordu.net www.foo.bar.nordu.net
The RR www.foo.bar.nordu.net doesn't seem to get into the zone at
the slave (then I look in the zone file dump).
There are fixes in svn for the next 3.2.x release that are about
wildcard addition and removal, caused by the recent wildcard fixes.
Perhaps related, the nsd.log is containing this stuff too:
[1416437470] nsd[11647]: warning: prehash: collision of wildcard
denial for foo.bar.nordu.net.. Sign zone with different salt to
remove collision.
This issue will remain even if you were to use the patched NSD from
the code repository. Supposedly, it only depends on the zone and
nsec3 parameters.
But someone else reported this zone wildcard problem (for the
non-wildcard RR) for a unsigned zone too…
Yes, you seem to have two problems, the wildcard and this nsec3
collision. If the nsec3 collision is also a bug in the nsd code, and
not an actual sha1 collision, we should somehow isolate and debug it.
(probability is on that being a bug).