We're using dnsjava in a high-volume environment. We've observed high lock contention related to the secure random number generation. Ultimately, the issue is that the JDK's NativePRNG has a synchronized block on the hot path in implNextBytes.

In dnsjava, SecureRandom is used for header IDs and in NioUdpClient. The latter can be disabled [when it's safe] with dnsjava.udp.ephemeral.use_ephemeral_port.

I wanted to document this problem but, because it probably doesn't affect a lot of people, I am not sure what should be done, if anything. We're using a fork that works around this and a couple of other problems.

Some thoughts:

• In the ideal world, Java would perhaps provide ThreadLocalSecureRandom that caches randomness at thread level to reduce pressure on NativePRNG. This would resolve the contention except in a highly-inefficient and unlikely scenario with short-lived threads.
• If dnsjava makes secure random generation pluggable, heavy users could provide their own implementation that perform better under high concurrency.
• Another property can be added to disable the use of SecureRandom, which might be safe when dnsjava is used with a local recursive resolver.