If you want perfect forward secrecy, you must negotiate a separate session key for each connection (or short-lived group of connections, depending on the implementation). It is not possible to negotiate an ephemeral session key with a "dumb" DNS nameserver (in fact, the DNS protocol doesn't even provide the necessary primitives for it without a lot of folding and mutilating). Furthermore, even if we assume the DNS nameserver is somehow negotiating a session key with the end user, that key still needs to be propagated to the actual content server in order to do TLS termination. Ephemeral keys are meant to be ephemeral; they should not be leaving RAM, let alone traversing the network in this fashion.
The keying round trips are unavoidable, unless you are willing to give up forward secrecy. Giving up forward secrecy is seriously undesirable given the Snowden revelations (which showed among other things that the NSA had an actual practice of storing encrypted communications in the hope of eventually decrypting them) and the likelihood of similar behavior by other adversaries.
That leaves us with just saving the certificate download. But the reality is that serving a certificate (or any large-enough file) over TCP (the transport layer used by HTTP(S)) is likely to be faster and more efficient than serving it over UDP (the transport used by DNS). UDP requires the application to manually re-send any lost chunks, and to manually fix up packet reordering or duplication. UDP also requires the application to manually break files up into packets (which may need to be extremely small depending on the network) and reassemble them. TCP does all these things automatically, and typical TCP implementations are heavily optimized for file transfer (e.g. TCP automatically resizes packets to best fit the congestion of the underlying network link). UDP still makes sense for best-effort transfers of very short messages such as DNS queries, but transferring an entire signed certificate would likely be slower over DNS than HTTP/HTTPS.
Of course, there is also the problem of caching and indirection. It is extremely common for users to communicate with non-authoritative DNS nameservers (for example, those provided by their ISP). In theory, these nameservers are supposed to return the same results as their authoritative counterparts, either by directly querying them (recursively if needs be) or by caching the results from previous queries up to a configurable time-to-live (TTL). In practice, they often deviate from the standard, for example in any or all of these ways:
- NXDOMAIN hijacking (returning a "fake" IP address instead of an error for nonexistent domain lookups, which usually results in the user seeing ads vaguely related to the domain name).
- Not respecting the TTL (caching for longer than they are supposed to).
- Ignoring, dropping, or serving errors for requests which are not commonly issued by regular web browsers (e.g. requests for TXT records).
- Support for and actual use of DNSSEC varies substantially by ISP and by region.
It is difficult to put into practice any "clever DNS hack" when half the standard is not correctly implemented by a substantial portion of your clients.