I noted that one of our name servers slaving customer zones started to spew these messages over and over again:
...
[2017-02-03 18:16:03.069] nsd[27083]: error: nsec3 hash collision for name=ad.xxxxxx.se.
[2017-02-03 18:16:03.078] nsd[27083]: error: nsec3 hash collision for name=ad.xxxxxx.se.
[2017-02-03 18:16:03.111] nsd[27083]: error: nsec3 hash collision for name=ad.xxxxxx.se.
…
And it’s filling up the log file very fast...
It’s probably true and perhaps a real problem at the customer side, but does nsd really need to log 20+ lines with this message every second?
I’ve upgraded to nsd 4.1.14 to check if the error (messages) would go away, but doesn’t seem to affect neither the issue, nor the amount of “spam” nsd pushes to the log file…
So, could nsd please not dos itself with these messages?
Change the nsec3 salt at the zone signer for this zone.
The sender is sending queries for a nonexist name that hashes (exactly)
to the same hash as the hash for an existing name in the zone. This is
what NSD logs. With this printout you can figure out that the short
NSEC3-string for the query name, and the nsec3 string for one of the
names in your zone, have the same hash.
NSD has replied SERVFAIL to that client, since an NSEC3 nonexistance
proof is impossible. So, no issues except the log file spam.
At what verbosity level should I log these messages, you would think?
Then I'll fix the code for that.
Change the nsec3 salt at the zone signer for this zone.
The master is a InfoBlox appliance I've heard.
The sender is sending queries for a nonexist name that hashes (exactly)
to the same hash as the hash for an existing name in the zone.
Oh, is this possible? This is just a small zone containing ~1200 RRs
(Which leads to the question if it exist any kind of statistics regarding this?)
Looks more like a bug or non-existing or bad verification at the master/signer side
This is what NSD logs. With this printout you can figure out that the short
NSEC3-string for the query name, and the nsec3 string for one of the
names in your zone, have the same hash.
NSD has replied SERVFAIL to that client, since an NSEC3 nonexistance
proof is impossible. So, no issues except the log file spam.
At what verbosity level should I log these messages, you would think?
Then I'll fix the code for that.
I’m running at verbosity: 2
I have no special requirements regarding the verbosity level.
Would it be wrongly placed if it was moved to verbosity 3?
Perhaps just one notification about hash collision would suffice for verbosity 2?
Hmm…perhaps I interpreted your explanation above
Are you saying someone (else?) is querying the zone at my NSD slave, and that those queries
(because there are a lot for log entries), are “expanded" to the exact same hash as an existing hash for another record in the zone?
…which also sounds like it shouldn’t be possible (in theory).
Ok, this has surfaced once again on our slave running NSD 4.1.15
The triggering reason seems to be (remote) master is running Infoblox and the nsec3 hash collision comes then asking the slave about a previously deletes record. I think this was the same senario as in the original case.
I see that 4.1.17 has a "Fix potential null pointer in nsec3 adjustment tree”.
Should I just upgrade and see if that resolves the issue, or do you want me to pull some diagnostics out of NSD before?
