Quad9 DOH HTTP/1.1 Retirement, December 15, 2025 • Hacker News Board

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#51

Post by toast0 » Wed, Dec 03, 2025, 10:21 PM UTC

zamadatix wrote: post #49

toast0 wrote: post #38

Earlier quoted context omitted.

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

That'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.

If 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)

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#52

Post by bawolff » Wed, Dec 03, 2025, 10:45 PM UTC

gfody wrote: post #46

bawolff wrote: post #33

Earlier quoted context omitted.

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.

ok 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

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

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#53

Post by zamadatix » Thu, Dec 04, 2025, 10:12 AM UTC

toast0 wrote: post #51

zamadatix wrote: post #49

Earlier quoted context omitted.

That'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.

If 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…

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

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#54

Post by itopaloglu83 » Thu, Dec 04, 2025, 2:45 PM UTC

toast0 wrote: post #51

zamadatix wrote: post #49

Earlier quoted context omitted.

That'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.

If 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…

Well, that’s T-Mobile for you.

They force you to stay behind their NAT and recently started blocking VPN connections to home labs even.

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#55

Post by 1vuio0pswjnm7 » Thu, Dec 04, 2025, 5:54 PM UTC

hypeatei wrote: post #39

EE84M3i wrote: post #37

Earlier quoted context omitted.

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

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.

There is an argument HTTP/2 was created by CDNs for CDNs (reverse proxies)

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#56

Post by 1vuio0pswjnm7 » Thu, Dec 04, 2025, 6:01 PM UTC

dev_l1x_be wrote: post #7

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.

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

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#57

Post by 1vuio0pswjnm7 » Thu, Dec 04, 2025, 6:06 PM UTC

itopaloglu83 wrote: post #9

dev_l1x_be wrote: post #7

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.

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.

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

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#58

Post by gfody » Thu, Dec 04, 2025, 8:35 PM UTC

bawolff wrote: post #52

gfody wrote: post #46

Earlier quoted context omitted.

ok 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

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

makes 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

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#59

Post by itopaloglu83 » Thu, Dec 04, 2025, 10:25 PM UTC

1vuio0pswjnm7 wrote: post #57

itopaloglu83 wrote: post #9

Earlier quoted context omitted.

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.

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

ISPs and other networks operators are continuously losing insights into the traffic they carry with each privacy oriented technology improvements and they just don’t want to become commodity providers because they can make billions of dollars selling everything from information to prioritized traffic etc.

Re: Quad9 DOH HTTP/1.1 Retirement, December 15, 2025

#60

Post by bawolff » Fri, Dec 05, 2025, 3:35 AM UTC

gfody wrote: post #58

bawolff wrote: post #52

Earlier quoted context omitted.

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

makes 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

The problem with batch semantics is you do have to know everything up front. You cant just do one request and then 20 ms later another.

For DNS this might come up in format parsing. E.g. in html, First you see tag, fire off the DNS request for that, and go back to parsing. Before you get the DNS result you see an tag for a different domain and want to fire off the DNS result for that. With a batch method you would have to wait until you have all the domain names before sending off the request (this might get more important if you are recieving the file you are patsing over the network and you dont know if the next packet containing the next part of the file is 1ms away or 2000ms).