It seems to me that neither TLS or DTLS are appropriate transports for DNS. Both are connection oriented transports, with DTLS simply allowing that connection to be lossy.
To maintain the performance of DNS, you'd want a connectionless protocol. Although I'm not sure whether perfect forward security would be possible without adding a round-trip.
DNS can work very well over TCP and TLS. It avoids most head-of-line blocking problems, because responses are usually small (a few KB), and they can be returned out-of-order. It's still relatively new for servers to implement DNS-over-TCP well (i.e. handling pipelined queries concurrently, and returning responses out-of-order) - you need BIND 9.11 or `dnsdist`. I did some brief testing yesterday, and in most cases TCP is as fast as UDP or faster. I was using a client based on `adns` which keeps one persistent TCP connection open.
I'm aware that this is the case once the connection is established. What I was referring to was the latency of TCP and TLS connection establishment, involving multiple round trips. Maintaining a persistent connection introduces the problem of requiring the DNS server maintain state for each client.
> To maintain the performance of DNS, you'd want a connectionless protocol.
What you're looking for is DNSCurve.
The only reason people are interested in DNS over TLS is the garbage middleboxes that intercept and interfere with DNS (and thereby break DNSCurve or anything like it), which typically don't interfere with TLS.
If you could use an arbitrary protocol then it might as well be DNSCurve. If you can't then it has to be TLS. Even DNS over DTLS is people not realizing why TLS was used to begin with.
It seems the thing to do is to default to DNSCurve and fallback to DNS over TLS/HTTPS if that fails.
To maintain the performance of DNS, you'd want a connectionless protocol. Although I'm not sure whether perfect forward security would be possible without adding a round-trip.