Attached is an updated patch, where I have updated/modified dnsrand_next to int from uint16_t, so that it is the same as local_id (even though local_id does discard the upper 16/...bits), just in case there is some issue in some combination of buildtools/endieness/...

In future / Other possibilities:

In case reading /dev/urandom is considered to be too much overhead or leading to eating up of entropy in the system from other users perspective or so, one could change to a two level logic, where /dev/urandom is read once every 128 or 256 dns queries to (re)set the seed for the random prng call. And in turn use the random c call for getting the dns query id. As the random prng is reseeded every 128 or 256 calls, so I am lazily assuming that its state cant be leaked from such a short run, to allow anyone to predict the id, before reseeding.

--