Hi Fredrik, 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. Best regards, Wouter On 03/02/17 21:40, Fredrik Pettai wrote:> Hi, > > 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? :) > > Re, > /P > _______________________________________________ > nsd-users mailing list > nsd-users at NLnetLabs.nl > https://open.nlnetlabs.nl/mailman/listinfo/nsd-users >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20170206/c8fc27b6/attachment.bin>
> On 6 Feb 2017, at 09:40, W.C.A. Wijngaards <wouter at nlnetlabs.nl> wrote: > > Hi Fredrik, > > 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? Re, /P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20170206/43d58914/attachment.bin>
On Mon, Feb 06, 2017 at 09:40:29AM +0100, W.C.A. Wijngaards wrote:> At what verbosity level should I log these messages, you would think? > Then I'll fix the code for that.methinks that detecting a real hash collision "in the wild" would deserve attention. Could the colliding names be made available? -Peter
> On 6 Feb 2017, at 09:40, W.C.A. Wijngaards <wouter at nlnetlabs.nl> wrote: > > Hi Fredrik, > > Change the nsec3 salt at the zone signer for this zone.Too bad, the RC release of NSD didn?t make it? After bumping NSD and a restart of the daemon, the problem disappeared... [2017-02-07 18:22:08.209] nsd[583]: error: nsec3 hash collision for name=ad.xxxxxx.se. [2017-02-07 18:22:20.967] nsd[25257]: info: zone xxxxxx.se read with success [2017-02-07 18:22:20.967] nsd[25257]: info: rehash of zone xxxxxx.se. with parameters 1 0 10 4b196e0c58c4 ? (But at least I have the option to look at the queries now if the issue surface again?) /P