Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

https://quad9.net/news/blog/doh-http-1-1-retirement/

by pickledoyster • 8 months ago

103 61 8 months ago

I think code to implement http/1.1 in whatever software stack they use would have been shorter than the blog post...

werdl• 8 months ago

probably 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• 8 months ago

http/2 surely not simpler?

stingraycharles• 8 months ago

I 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_explore2• 8 months ago

To write the code from scratch, sure.

But I'm thinking a few lines of nginx config to proxy http 1.1 to 2

ori_b2• 8 months ago

Yes; 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• 8 months ago

According 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_be2• 8 months ago

I 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.

itopaloglu833• 8 months ago

DOH 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.

toast03• 8 months ago

Don't you just intercept traffic to well know recursive resolvers? And then drop packets to ports other than 53?

1vuio0pswjnm77• 8 months ago

Except encrypted client hello (ECH) is just a draft and isn't being used server side on the public www

If I'm wrong then please provide some examples of servers that support ECH

junon• 8 months ago

It's both. In oppressive countries (Iran, China, Russia) where all traffic is filtered, DOH is supposed to help keep things concealed, too.

zamadatix4• 8 months ago

DOT picked an odd port, DOH uses 443. Otherwise they both have the benefits of TLS.

wongogue2• 8 months ago

My ISP (my area is serviced by 1 more but they offer lower speeds) blocks the DoT port. They cannot block 443. If they start blocking popular DoH domains, I can use any of the mirrors or run my own over https://wongogue.in/catpics/

the8472• 8 months ago

Anything that doesn't provide raw access at the internet protocol layer (other than RFP to prevent spoofing) shouldn't qualify as internet provider.

zokier• 8 months ago

DoQ is better than either dot/doh

1vuio0pswjnm77• 8 months ago

DNSCurve is better than DoQ

jeroenhd2• 8 months ago

Thanks to the ossification of the internet, every new protocol or protocol extension needs to be over HTTPS.

DoT works fine, it's supported on all kinds of operating systems even if they don't advertise it, but DoH arrived in browsers. Some shitty ISPs and terrible middleboxes also block DoT (though IMO that should be a reason to switch ISPs, not a reason to stop using DoT).

On the hosting side, there are more options for HTTP proxies/firewalls/multiplexers/terminators than there are for DNS, so it's easier to build infra around DoH. If you're just a small server, you won't need more than an nginx stream proxy, but if you're doing botnet detection and redundant failovers, you may need something more complex.

arbll• 8 months ago

though IMO that should be a reason to switch ISPs, not a reason to stop using DoT If you have that choice, there's many countries that really want to control what their citizens see and can access at this point. If we had DoH + ECH widely adopted it would heavily limit their power.

ori_b2• 8 months ago

Thanks to the ossification of the internet, every new protocol or protocol extension needs to be over HTTPS.

If someone can tell you're using HTTPS instead of some other TLS-encrypted protocol, that means they've broken TLS.

josephcsible2• 8 months ago

Because if you're on the kind of malicious network that's the reason to use encrypted DNS at all, then your connection attempts on port 853 will probably just get blocked wholesale. DoH is better since it looks the same as all other HTTPS traffic.

And you can still block ad and scam domains with DoH. Either do so with a browser extension, in your hosts file, or with a local resolver that does the filtering and then uses DoH to the upstream for any that it doesn't block.

dev_l1x_be2• 8 months ago

And you can still block ad and scam domains with DoH.

How?

There are certain browsers that ignore your DNS settings and talk directly to DoH servers. How could I check what is that the browser requesting through a SSL session?

Do you want me to spoof a cert and put it on a MITM node?

These are my nameservers:

   nameserver 10.10.10.65
   nameserver 10.10.10.66

If the browser plays along than talking to these is the safest bet for me because it runs AdGuardHome and removes any ad or malicious (these are interchangable terms) content by returning 0.0.0.0 for those queries. I use DoT as uplink so the ISP cannot look into my traffic and I use http->https upgrades for everything.

For me DoH makes it harder to filter the internet.

1vuio0pswjnm77• 8 months ago

Anyone who has their DNS filtered, e.g., by ISPs that redirect DNS port numbers, like hotels, can use DoH to work around the problem

5d41402abc4b2• 8 months ago

HTTP/1.1 is still heavily used in embedded system.

jeroenhd2• 8 months ago

But 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.

5d41402abc4b2• 8 months ago

Its not about age, its about complexity. HTTP/1.1 client is trivial to implement.

temp0826• 8 months ago

NextDNS has a DOH3 (as in, http/3) endpoint but afaict it doesn't seem to always use http/3.

crimsonnoodle58• 8 months ago

Mikrotik 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• 8 months ago

You 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

1. https://www.dnscrypt.org

hypeatei2• 8 months 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.

gfody4• 8 months ago

I wonder too, for a DNS query do you ever need keepalive or chunked encoding? HTTP/1.0 seems appropriate and http2 seems overkill

bawolff4• 8 months ago

DNS 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.

EE84M3i• 8 months ago

HTTP versions less than 2 have serious unresolvable security issues related to http request/response smuggling and stream desynchronization.

https://http1mustdie.com/

hypeatei2• 8 months ago

If you're using a reverse proxy, maybe. I don't think it's sufficient to kill a whole version of HTTP because of that.

Sohcahtoa82• 8 months ago

I have an alternative...

Rather than throwing HTTP/1.1 into the garbage can, why don't we throw Postel's Law [0] into the garbage where it belongs.

Every method of performing request smuggling relies on making an HTTP request that violates spec. A request that sends both Content-Length and Transfer-Encoding is invalid. Sending two Content-Lengths is invalid. Two Transfer-Encoding headers is allowed -- They should be treated as a comma-separated lists -- so allow them and treat them as such, or canonicalize them as a single header if you're transforming it to something downstream.

But for fuck's sake, there's literally no reason to accept requests that contain most of the methods that smuggling relies upon. Return a 400 Bad Request and move on. No legit client sends these invalid requests unless they have a bug, and it's not your job as a server to work around their bug.

[0] Aka, The Robustness Principle, "Be conservative in what you send, liberal in what you accept."

1vuio0pswjnm77• 8 months ago

RFC 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

Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

Related Stories