If you want [perfect forward secrecy](https://en.wikipedia.org/wiki/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 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.