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.
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.
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
I 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.
>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.
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.
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).
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.
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.
> 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.
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/
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.
I think code to implement http/1.1 in whatever software stack they use would have been shorter than the blog post...
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.
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.
To write the code from scratch, sure.
But I'm thinking a few lines of nginx config to proxy http 1.1 to 2
Nginx can't use http2 upstreams, some other reverse proxies can though.
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
http/2 surely not simpler?
I 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.
Having to support http/1.1 and http/2 is definitely not simpler.
HTTP/2 is basically HTTP/1.1, just over some custom binary protocol bolted on on top of TLS.
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.
> 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.
HTTP versions less than 2 have serious unresolvable security issues related to http request/response smuggling and stream desynchronization.
https://http1mustdie.com/
I wonder too, for a DNS query do you ever need keepalive or chunked encoding? HTTP/1.0 seems appropriate and http2 seems overkill
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.
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).
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
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.
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.
> 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.
> If someone can tell you're using HTTPS instead of some other TLS-encrypted protocol, that means they've broken TLS.
Lots of clients just tell the world. ALPN is part of the unecrypted client hello.
> 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.
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.
Well…some countries (and some regions) don’t get a choice. We do what we can.
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.
Don't you just intercept traffic to well know recursive resolvers? And then drop packets to ports other than 53?
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.
> And you can still block ad and scam domains with DoH.
How?
DOT picked an odd port, DOH uses 443. Otherwise they both have the benefits of TLS.
DoQ is better than either dot/doh
[dead]
It's both. In oppressive countries (Iran, China, Russia) where all traffic is filtered, DOH is supposed to help keep things concealed, too.
HTTP/1.1 is still heavily used in embedded system.
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.
Its not about age, its about complexity. HTTP/1.1 client is trivial to implement.
NextDNS has a DOH3 (as in, http/3) endpoint but afaict it doesn't seem to always use http/3.