DNS resolver security

The current DNS resolver, to put it mildly, isn't at the state of the art security-wise. There should probably be work on that as some point.

A few things to consider (non-exhaustive):

- Source port randomization: we are currently using port 53, like most resolvers from 15 years ago. This makes it easier to spoof responses (I wouldn't say poison the cache, since our resolver doesn't have a cache). Randomizing the source port is a little bit tricky because both the TCP/IP compartment AND the resolver would need to claim random ports at runtime and coordinate. Assigning a fixed chunk of ports to the resolver isn't great since it diminishes a lot the entropy gained/return on investment. Also, our attacker model so far has been a MITM attacker, and randomization doesn't help there. The proper solution is probably support DNS-over-TLS/HTTPS.
- Case randomization (0x20): this would be easy to implement and would make spoofing a bit harder. Still doesn't help with MITM attackers.
- DNS cookies: should be reasonably easy to implement and would further complicate spoofing. Still doesn't help with MITM attackers.
- DNS-over-TLS/HTTPS: it would be great to have these. I have not looked at how to implement them in detail, but I would assume that we can implement them as a second resolver sitting on top of TLS.

Let's discuss these here!

Useful resources/fun reads:
- https://casey.byu.edu/papers/2023_usenixsecurity_resolversec.pdf
- https://www.usenix.org/system/files/usenixsecurity25-afek.pdf
- https://www.usenix.org/system/files/conference/usenixsecurity26/sec26_prepub_ben-simhon.pdf

Start by locating and reviewing the current DNS resolver implementation, then compare the listed options—case randomization, DNS cookies, source-port randomization, and DNS-over-TLS/HTTPS—with the referenced papers. Done requires an agreed security approach and implementation scope; this issue currently asks for discussion rather than specifying one change.

Written by the indexing model from the issue text.