Deploying an application protocol that does neither, such as DNS, directly over UDP is a bad idea. If you were to run DNS over DTLS (TLS over UDP), that would be a different beast, and probably ok.
And to clarify, encryption is important to prevent tampering and preserve users's privacy. Session management is important to protect agains redirect attacks with spoofed source IP, or session hijacking.
I'm not against the core part of your argument, just against the blaming of a particular choice of transport layer, which is fundamentally irrelevant. Encryption is great. Meanwhile DNS doesn't really need the concept of a session, does it? At the end of the day it's just a single lookup which can very well be fire and forget. That we're encrypting the request (ideally) and also the response (ideally) is no reason to add in loads more complexity.
DoH3 means running DNS over HTTP over QUIC over UDP. Here QUIC does both session management and encryption.
In both cases, we are running a simple application protocol (DNS) over other protocols that handle the Internet-level problems I raised, so all is good.
The problem is with running your application protocol directly and strictly over UDP and nothing else.
And related to sessions, there are two things. For one, in reality today, you typically do a whole host of DNS requests even to load a single site (many common sites have upwards of 20 domains they use, and that's before loading any ads). So having a persistent session to send all of those requests on would not change much, even if it's not technically necessary. Secondly, even if you really want to avoid sessions, you then still need some other mechanism to prevent source IP spoofing.
Any protocol which allows a host to send a small request to a server and cause that server to send a large response to the src IP of that request is a major problem for the health of the internet. Requiring a handshake to solve this is one simple way to avoid the problem entirely. DNS implementations have had to find all sorts of other mitigations to address this (I believe they now typically don't allow responses more than a factor of 1.something larger than the request, or something like that? Which of course brings in all sorts of extra problems and unnecessary traffic)
Yes, and the person you're replying mentioned that it was perfectly possible to encrypt data over UDP. Presumably they meant DTLS. So what's your concern?
