5 ms·
Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
- londons_explore 10mo agoI think code to implement http/1.1 in whatever software stack they use would have been shorter than the blog post...
- werdl 10mo agoprobably not - it can be quite poorly defined in places and the edge cases can be very fiddly. by pushing for http/2 it encourages more users to pick it up imo
- cenamus 10mo agohttp/2 surely not simpler?
- JoshTriplett 10mo agoHaving to support http/1.1 and http/2 is definitely not simpler.
- Joker_vD 10mo agoHTTP/2 is basically HTTP/1.1, just over some custom binary protocol bolted on on top of TLS.
- bawolff 10mo agoI feel like securing against request smuggling is simpler with http/2. That is of course only one aspect. Ultimately though, its not like this is getting rid of http/1.1 in general, just DNS over http/1.1. I imagine the real reason is simply nobody was using it. Anyone not on the cutting edge is using normal dns, everyone else is using http/2 (or 3?) for dns. It is an extremely weird middle ground to use dns over http 1. Im guessing the ven diagram was empty.
- wahern 10mo agoRequest smuggling is an issue when reverse proxying and multiplexing multiple front-end streams over a shared HTTP/1.1 connection on the backend. HTTP/2 on the front-end doesn't resolve that issue, though the exploit techniques are slightly different. In fact, HTTP/2 on the front-end is a deceptive solution to the problem because HTTP/2 is more complex (the binary framing doesn't save you, yet you still have to deal with unexpected headers--you can still send Content-Length headers, for example) and the exploits less intuitive. HTTP/1.1 is a simpler protocol and easier to implement, even with chunked Transfer-Encoding and pipelining. (For one thing, there's no need to implement HPACK.) It's trying to build multiplexing tunnels across it that is problematic, because buggy or confused handling of the line-delimited framing between ostensibly trusted end point opens up opportunities for desync that, in a simple 1:1 situation, would just be a stupid bug, no different from any other protocol implementation bug. Because HTTP/2 is more complicated, there's arguably more opportunities for classic memory safety bugs. Contrary common wisdom, there's not a meaningful difference between text and binary protocols in that regard; if anything, text-based protocols are more forgiving of bugs, which is why they tend to promote and ossify proliferation of protocol violations. I've written HTTP and RTSP/RTP stacks several times, including RTSP/RTP nested inside bonded HTTP connections (what Quicktime used to use back in the day). I've also implemented MIME message parsers. The biggest headache and opportunity for bugs, IME, is dealing with header bodies, specifically the various flavors of structured headers, and unfortunately HTTP/2 doesn't directly address that--you're still handed a blob to parse, same as HTTP/1.1 and MIME generally. HTTP/2 does partially address the header folding problem, but it's common to reject those in HTTP/1.x implementations, something you can't do in e-mail stacks, unfortunately.
- 1vuio0pswjnm7 10mo agoArgubaly, the complexity issue is not only the protocols themselves but also the fact that thanks to the companies pushing HTTP/2 and 3, there are now multiple (competing/overlapping/incompatible) protocols For example, people passing requests received by HTTP/2 frontends to HTTP/1.1 backends
- stingraycharles 10mo agoI think you’re severely underestimating the complexity of http/1.1. It’s definitely much simpler than http/2, but it’s a lot of code that needs to be maintained.
- londons_explore 10mo agoTo write the code from scratch, sure. But I'm thinking a few lines of nginx config to proxy http 1.1 to 2
- SahAssar 10mo agoNginx can't use http2 upstreams, some other reverse proxies can though.
- ori_b 10mo agoYes; the web server I use for my site is about twice the size of that blog post. Though, I think that if you drop the file-listing functionality you may be able to get it closer.
- MallocVoidstar 10mo agoAccording to the RFC: >The messages in classic UDP-based DNS [RFC1035] are inherently unordered and have low overhead. A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to achieve similar performance. Those features were introduced to HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of conveying the semantic requirements of DoH but may result in very poor performance. I'd bet basically all their clients are using HTTP/2 and they don't see the point in maintaining a worse version just for compatibility with clients that barely exist.
- dev_l1x_be 10mo agoI never understood DOH over DOT. It makes sense if you want to hide DNS lookups so that people cannot block the DNS queries to ad and other scam networks.
- itopaloglu83 10mo agoDOH prevents malicious network providers from blocking DOT traffic to enforce their own DNS services for “efficiency” reasons. Most ISPs just want to sell your data and with encrypted client hello and DOH they’re losing visibility into what you’re doing.
- toast0 10mo agoDon't you just intercept traffic to well know recursive resolvers? And then drop packets to ports other than 53?
- zamadatix 10mo agoThat's the beauty of DoH - you don't have to pick a resolver which uses a dedicated IP. You can even stand your own up behind a CDN and blocking it would mean blocking HTTPS traffic to the CDN.
- toast0 10mo agoIf I'm an evil monetizing ISP or a great firewall, I don't really need to catch 100% of the traffic I'm trying to prevent. If there's a handful of people who can circumvent my restrictions, that's fine. As long as I get all the people trying to use popular DNS, that's good enough. If I really do need to get that last bit, there's always other analysis to be done (request/response size/cadence, always talks to host X before making connections to other hosts, etc)
- zamadatix 10mo agoNot 100% of people need/care about such workarounds either though, so it works out. For true government level interest in what you are doing, it's a much harder conversation than e.g. avoiding ISPs making a buck intercepting with wildcard fallbacks and is probably going to need to extend to something well beyond just DoH if one is convinced that's their primary concern.
- 5d41402abc4b 10mo agoHTTP/1.1 is still heavily used in embedded system.
- jeroenhd 10mo agoBut is DoH? If your library is too old to support http2, what are the chances you've upgraded the DNS resolver to a DoH resolver? Luckily it's pretty easy to run your own DoH server if you're deploying devices in the field, and there are alternatives to Quad9.
- 5d41402abc4b 10mo agoIts not about age, its about complexity. HTTP/1.1 client is trivial to implement.
- advisedwang 10mo agoWe're talking about an HTTP/1.1 server here
- temp0826 10mo agoNextDNS has a DOH3 (as in, http/3) endpoint but afaict it doesn't seem to always use http/3.
- crimsonnoodle58 10mo agoMikrotik DoH user here. While I don't use Quad9, I do use 1.1.1.1. I hope they don't follow suit before Mikrotik get a chance to add HTTP/2 support (if ever).
- kingforaday 10mo agoYou should look into dnscrypt[0][1]. Easy and lots of options. jedisct1, cofyc, and many others have done a great job over the last decade here. 0. https://dnscrypt.info https://dnscrypt.info 1. https://www.dnscrypt.org https://www.dnscrypt.org
- hypeatei 10mo ago> However, we are reaching the end of life for the libraries and code that support HTTP/1.1 What libraries are ending support for HTTP/1.1? That seems like an extremely bad move and somewhat contrived.
- gfody 10mo agoI wonder too, for a DNS query do you ever need keepalive or chunked encoding? HTTP/1.0 seems appropriate and http2 seems overkill
- bawolff 10mo agoDNS seems like exactly the scenario where you would want http2 (or http1.1 pipelining but nobody supports that). You need to make a bunch of dns requests at once, and dont want to have to wait a roundtrip to make the next one.
- gfody 10mo agook multiple requests makes sense for keepalive (or just support a "batch" query, it's http already why adhere so tightly to the udp protocol) http/1.0 w/keepalive is common (amazon s3 for example) perfectly suitable simple protocol for this
- bawolff 10mo agoKeepalive is not really what you want here. For this usecase you want to be able to send off multiple requests before recieving their responses (you want to prevent head of line blocking). If anything, keep alive is probably counter productive. If that is your only option its better to just make separate connections.
- gfody 10mo agomakes sense but I still would prefer to solve that problem with "batch" semantics at a higher level rather than depend on the wire protocol to bend over backwards
- 1vuio0pswjnm7 10mo agoRFC 8484: "5.2. HTTP/2 HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH." One paper I read some years ago reported DoH is faster than DoT but for multiple queries in single TCP connection outside the browser I find that DoT is faster I use a local forward proxy for queries with HTTP/2. (Using libnghttp2 is another alternative). In own case (YMMV) HTTP/2 is not signifcantly faster than using HTTP/1.1 pipelining For me, streaming TCP queries with DoT blows DoH away