As noted in the last message, this patch uses the combination of /dev/urandom + user space random.

Here /dev/urandom periodically (once every 128 random calls) seeds user space using srandom. Inturn user space random prng is used to generate the dns query id.

Attached is 

a) the full patch wrt uclibc master (592574ae535c35de500f6c3e8d8400d0bb0d985a), as well as 

b) the delta patch wrt my last patch (patch_20220505IST0032_urandomid_against_dnspoison.patch)

Based on thoughts from others also either the simple urandom only or this urandom+random based solution could be used against the dns poison issue. Or may be others might have some other strategy in mind.

Please do note that this is currently only tested on a x86 linux virtual machine+container environment, by using uclibc-ng and standard linux gcc build setup (coerced to use uclibc-ng by disabling standard includes and passing header paths and libs manually to gcc and inturn verifying the random id using tcpdump and dprints). So testing against other setups would be useful. At a high level chances are on linux or freebsd or similar targets, hopefully the patch should be fine, as it uses only /dev/urandom, srandom and random mainly.
--