TLS could be used in much the same way that a mining truck could be used by a letter courier service. You can, doesn't mean you should. With DNSCurve, when you

TLS could be used in much the same way that a mining truck could be used by a letter courier service. You can, doesn't mean you should. With DNSCurve, when you have a delegation from one authoritative server to another, the parent domain provides the name of the child domain's nameserver, which encodes its public key. Then you use the public key to communicate with the child nameserver. The key distribution is part of the protocol. To use TLS, you would either have to rely on the CA system with all its problems (any malicious CA can forge any name and many are operated by potential adversaries), or DANE, and then we're creating a dependency on DNSSEC rather than replacing it. Worse, you have to choose one or the other for everyone or else support both as options and have the worst of both worlds in combined complexity and lowest common denominator security. The overhead of DoT/DoH is also worse in the recursive case. Between the client and the recursive DNS server, creating a TLS session is expensive but at least then you can keep it active and use it for all your queries. In the recursive case the queries go to/from many different authoritative servers, each with low probability of reusing the connection such that keeping it active long is counterproductive. So you're moving from a single UDP request and reply to a full TCP handshake + TLS handshake for as little as a single query. This adds both computation and latency. Moreover, the one redeeming quality of DNS over TLS/HTTPS is avoiding interference by middleboxes, which exists almost entirely in the context of client devices on restrictive networks rather than the links between recursive and authoritative DNS servers.