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).
Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
21–30 of 63 posts
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#22Earlier quoted context omitted.
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.
To write the code from scratch, sure. But I'm thinking a few lines of nginx config to proxy http 1.1 to 2
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#23I 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.
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 option…
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#24Earlier quoted context omitted.
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/
Anything that doesn't provide raw access at the internet protocol layer (other than RFP to prevent spoofing) shouldn't qualify as internet provider .
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#25What libraries are ending support for HTTP/1.1? That seems like an extremely bad move and somewhat contrived.
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#26Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#27I think code to implement http/1.1 in whatever software stack they use would have been shorter than the blog post...
>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.
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#28I 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.
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.
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#29> 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.
Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025
#30I 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.
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 u…
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.