Fragmentation is a complex subject. If avoiding fragmentation was obviously good, then UDP packets would always be sent with the don't fragment (DF) bit set. In reality, that would make some situation much worse than allowing fragmentation to happen.

DoT and DoH are certainly not faster than UDP. It is only in the long tail that DoT and DoH work better.

If encryption is required for DNS, then obviously UDP and plain TCP not suitable. But operators of authoritative DNS servers are very reluctant to support DoT. The IETF is still trying to hash out how to use DoT between recursive resolvers and authoritative server.

> If avoiding fragmentation was obviously good

In the general case frags are always bad, and instead of blocking DNS over TCP your firewall should be alerting on them.

In the case of the DNS resolution protocol, UDP frags are double-bad. The protocol (not updated since the 1980s) specifies that TCP retry should only occur if a UDP response is received with TC=1; if the UDP response is dropped, TCP retry never occurs. In the case of a UDP frag if a portion of the original datagram is dropped the response is never reassembled, TC=1 is never observed, and TCP retry never occurs.

Thanks. Apropos "virtual turtles all the way down" I was expecting something along the lines of the well-recognized historical practice of site to site VPNS and tunnelling for DNS backhaul.

It's not fair to conflate "DNS operators" with the relationship between authoritative and recursive operators.

The (main) problem with encryption has to do with context. In order to achieve privacy, key and/or secret material needs to be negotiated between the ends and this context needs to be retrievable for reference. There is no provision in the DNS for that. There is no provision in the transport per se either. I argue that this is appropriate and correct, that generating and negotiating this material is a separate concern and developing the protocols to do so proceeds on a different track (QED).

A better term than "connection" for the concept we are about to discuss would be "circuit". Once in possession of the approprate key material (and the out of band signaling this implies) it's possible for the parties to exchange individually encrypted messages in the open, but this ignores network issues such as dropped packets and fragmentation to name a couple. This could be dealt with but it is not a general solution.

If you're going to solve problems it's generally accepted that it's prudent to solve them generally: hence the notion of a circuit. (Frags and dropped packets are other general problems to be solved by a circuit implementation.)

It's easy to see that such a generalized circuit is a tunnel and that UDP (or TCP) packets of arbitrary size (up to architectural limits, but significantly larger than either ATM or ethernet frames) can transit such a tunnel with guarantees of no loss and no fragmentation.

DNS specifies a very lightweight convention of its own for encapsulating UDP traffic in a TCP tunnel: the payloads are prepended with with a (2 byte) length word [0]. The tunnel protocol (carefully) doesn't even specify that responses via this tunnel need to preserve the ordering of requests. Bearing in mind that context needs to be preserved for each (active) request, the context required for the tunnel itself is amortized by the number of requests using the particular tunnel instance or circuit. (No need to worry about frags, all messages are preserved up to the architectural limit specified by the underlying DNS protocol.)

So, this is one example of solving the message-vs-stream dilemma in the real world. We can see that IP-over-IP is a real thing and that DNS provides a point solution for eliding frame size issues but that more general solutions also exist which also support e.g. encryption.

The key architectural consideration is mostly who maintains the circuit context and where it is maintained.

[0] Yes of course the redundant IP header is omitted for the encapsulated messages.