An AtomicInteger would generate predictable results, which is a no-go to avoid the Kaminsky attacks. Since SecureRandom is thread safe, the synchronization around it can be removed. And volatile would can be avoided by always generating an id (instead of -1) in the no-arg constructor.

If you open a PR, you may want to create it against the release/3.4.x branch as master won't get a new release soon.

I was suggesting using an AtomicInteger not for id generation, but for storing the id and setting it using an atomic, lock-free compareAndSet.

And volatile would can be avoided by always generating an id (instead of -1) in the no-arg constructor.

That would be the best option IMHO. But but then we lose the lazy initialization of the ID field, which looks like the intention of the author of that class. Using SecureRandom too much can also be extremely slow (when low on entropy), so if there are use cases that generate many Header instances but don't need to initialize their ID field, they'd see worse performance due to this change. Is that a common scenario?

I was suggesting using an AtomicInteger not for id generation, but for storing the id and setting it using an atomic, lock-free compareAndSet.

Ah, I see.

And volatile would can be avoided by always generating an id (instead of -1) in the no-arg constructor.

That would be the best option IMHO. But but then we lose the lazy initialization of the ID field, which looks like the intention of the author of that class. Using SecureRandom too much can also be extremely slow (when low on entropy), so if there are use cases that generate many Header instances but don't need to initialize their ID field, they'd see worse performance due to this change. Is that a common scenario?

The default implementation of SecureRandom is SHA1PRNG, which AFAIK doesn't do reseeds and thus will never run out of entropy. I wouldn't know when an unset ID would be useful. Answers coming from the network have an ID which is parsed, and sending request need an ID anyway. The only case where the ID must be statically 0 is DNS over HTTP since the protocol is TCP and the order of delivery is guaranteed.

The reason for the lazy initialization, as far as I remember, was to avoid needing to generate a random ID that would immediately be overridden when parsing a header from wire format. It's possible that this is no longer needed; there is an alternate constructor that specifies the ID, and it's used when constructing a header from wire format (which is likely the common case; I'm not sure if there's any other code that separates the construction and parsing).

(and for the record, DoH doesn't require an ID of 0, it's a SHOULD. It's also not because of ordered delivery, it's because the use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. With HTTP/2, there's no guarantee that responses will be ordered, but they will be correlated by HTTP stream.)

@ibauersachs SHA1PRNG is the default only in windows (see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SecureRandomImp). On Linux, a slower default implementation is used.

Still, if we can agree that the ID has to be set in the constructor either via a parameter or using SecureRandom, then getID becomes just a simple getter with no synchronization.

Yes, you're right, I forgot about the DoH http-based caching. I don't have the project open ATM to search for references, but if parsing the message creates an empty Header instance, we should change that. But I assume that's already the case.

If the SecureRandom performance really turns out to be an issue I think we can revisit that later.

But I assume that's already the case.

It is. I took a glance at the parsing code before submitting the PR.

The Message constructors that take a byte[] or ByteBuffer call Header(DNSInput in), which in turn calls this(in.readU16());.
So it looks like the parsing flow creates the header with the ID from the wire.