I would assume being able to reuse the connection for multiple requests. Setting up the TLS connection is quite a bit more expensive than raw TCP, and especially UDP (most DNS happens over UDP). For longer connections, the additional overhead is minor, but for the extremely short DNS messages, I would imagine that a TLS connection per DNS request would be some pretty substantial overhead.

Edit: The page mentions that this allows web applications to make their own DNS requests, possibly looking up things other than A/AAAA records that the browser normally requests.

http and rest are not the only ways to reuse a socket. You could just write the packet to the TLS stream, raw, and keep the socket open.

Definitely. But then you need to define an envelope to mark where an individual message begins and ends (with UDP DNS, it's a single datagram; with TCP DNS, it's the entirety of the transmission). There are infinite ways to do this, and countless many already specified in various standards (many of which are already implemented in browsers, which is surely the the primary application Google had in mind). HTTP provides one such envelope.

> with TCP DNS, it's the entirety of the transmission

DNS Messages have a two-byte length prefix when transmitted over TCP. Multiple envelopes can and often are sent over a single circuit.

that's what ssl tickets are there for.

heck you can even do that over udp with dtls, if you don't want to deal with setting up and tearing down tcp connections.

Web applications can't initiate raw TLS connections.

That's not true. Sure, many languages require you to drop down to a lower-level API to create a vanilla TCP connection, but if the language you're using doesn't provide a way to open a TCP socket and do the TLS negotiation dance, then you've probably chosen the wrong language.

The language is entirely uninteresting; what's interesting is what the runtime allows you to do. Browsers purposefully don't allow you to create raw TCP connections, yet JavaScript can in many other contexts (e.g node.js) create raw sockets perfectly fine.

> Browsers purposefully don't allow you to create raw TCP connections

Which is ridiculous, as it literally brings zero advantage to restrict that.

Well I think it's a good idea to prevent web pages from just opening up a socket to some server, speaking whatever protocol they like. It could be easily abused to spam, etc.

There is, however, https://www.w3.org/TR/tcp-udp-sockets/ - see section 10 for an example.

Considering the move proposed in this thread to move even SMTP to HTTP, how would preventing connecting to SMTP prevent spam when one can still POST to SMTP-over-HTTP?

"We need to restrict this to prevent abuse."

-- time passes --

"We need to change everything in order to accomplish a task under these restrictons."

Then all billion of us on the web have "chose[n] the wrong language".

This is painfully accurate.

Indeed, it's quite unfortunate

Because HTTP is the new narrow waist of the internet.

Because Google thinks by default in terms of HTTP and browsers, and can't think that not everything is on Web.

Given how successful they've been at that, I'm curious why you seem to view that as an aspersion on them rather than something to learn from? Shouldn't that tell us something about deploying internet-scale services?

(and, to be clear, the answer is yes, namely that a custom protocol has to deliver a lot of value to make up for having to deal with the deployment headaches inherent to anything less supported by firewalls, NAT boxes, etc. than HTTP/HTTPS)

It's an API that returns a document. Nothing fancy, no bells and whistles. If, for literally anything else, someone had suggested building such a service using raw sockets, they'd rightly be laughed out of the building.

Twilio isn't implemented using AT commands either, and for the same reason.

What, resolving using a socket is now considered ridiculous?

The comparison with Twilio is unfair.

DNS latency is an entire round trip added to every single fresh domain lookup you make. That's a lot of times, and we want those to be as fast as possible. At that point, the raw sockets vs full blown HTTP over TLS over TCP debate matters.

Twilio, on the other hand, is used in situations with comparably laughable latency requirements. At least two orders of magnitude.

Not saying it's doa, but the question has merit.

Corporate proxies / firewalls.