But I'm thinking a few lines of nginx config to proxy http 1.1 to 2
>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.
What libraries are ending support for HTTP/1.1? That seems like an extremely bad move and somewhat contrived.
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."
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.
If someone can tell you're using HTTPS instead of some other TLS-encrypted protocol, that means they've broken TLS.
Most ISPs just want to sell your data and with encrypted client hello and DOH they’re losing visibility into what you’re doing.
If I'm wrong then please provide some examples of servers that support ECH
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.
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
For me DoH makes it harder to filter the internet.
"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
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.