9 ms·
Why can't you just send DNS messages over an SSL/TLS socket? What's the value add for http and REST?
by joshAg 10y ago
Why can't you just send DNS messages over an SSL/TLS socket? What's the value add for http and REST?
- LukeShu 10y agoI 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.
- eggnet 10y agohttp 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.
- LukeShu 10y agoDefinitely. 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.
- pprx 10y ago> 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.
- joshAg 10y agothat'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.
- comex 10y agoWeb applications can't initiate raw TLS connections.
- peburrows 10y agoThat'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.
- sneak 10y agoThen all billion of us on the web have "chose[n] the wrong language".
- regularfry 10y agoThis is painfully accurate.
- nilved 10y agoIndeed, it's quite unfortunate
- mort96 10y agoThe 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.
- kuschku 10y ago> Browsers purposefully don't allow you to create raw TCP connections Which is ridiculous, as it literally brings zero advantage to restrict that.
- 10y ago
- paulddraper 10y agoBecause HTTP is the new narrow waist of the internet.
- hrjet 10y agoCorporate proxies / firewalls.
- mseebach 10y agoIt'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.
- chris_wot 10y agoWhat, resolving using a socket is now considered ridiculous?
- nothrabannosir 10y agoThe 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.
- ddalex 10y agoBecause Google thinks by default in terms of HTTP and browsers, and can't think that not everything is on Web.
- acdha 10y agoGiven 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)