The reason aDoT exist is that DoT was written under a specific charter. To quote the RFC 7858: It might work equally between recursive clients and authoritative

The reason aDoT exist is that DoT was written under a specific charter. To quote the RFC 7858: It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter. There is nothing inherent of the DoT protocol that forces a model of client->recursive->authoritative. The RFC is pretty light on even mentioning recursive. It mention a technical aspect of recursive client in exactly one place, which is when discussing connection reuse for multiple requests by saying it should (not must) reuse TCP connection if possible. The RFC really just boils down to the concept of applying TLS to a tcp and udp based protocol. The DoH RFC 8484 is very different and as mentioned above there is no one who is suggesting to apply it in any form beyond as a technology between stub resolver and a recursive server. The dns-privacy IETF is quite relevant in context. If we want to be technically correct here, there is a draft RFC for authoritative servers running DoT called aDoT, with DANE as authentication. Lets imagine a DoH protocol for email where Google or Microsoft suggest that email client should ignore smtp setting and send all email to them by default, and compare that to current model that we use today where client talk securely to servers and server talk security between each other. When viewed like that, is it unfair to describe DoH as being a proxy and the model of just adding TLS as being end-to-end?