In my opinion we don't want TLS at all, but rather a UDP based protocol, so that the latency advantages of DNS aren't lost. I believe DNSCurve solves this.
If you want UDP, DNS over DTLS also exists.
Doesn't really save you anything; DTLS still involves a connection with a handshake, so you have increased latency and memory overhead. Its usefulness is in low latency transport where head-of-line blocking would be detrimental (e.g. real-time streaming video; phone calls; VPNs).
DNSCurve, by comparison, is connection-less -- meaning no handshake latency, no connection overhead, and denial-of-service resilience.
DoH on QUIC is probably the end result
DNSCurve requires an out-of-band process for the exchange of key information. This is how it works around the handshake requirement. It's been a while since I read the spec though, so not sure what the current process is.
DNS-over-TLS with a persistent connection to the resolver can be more efficient than UDP-based protocols since you can put multiple queries or answers into one packet. DNS supports pipelined queries and out-of-order responses over TCP and TLS so there isn’t a head-of-line blocking problem.