zlacker

DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP.

And hey, maybe one day advertisements will be served directly via IP addresses, not domains:)

>>mmsc+(OP)
> DoH uses UDP, not TCP.

It uses TCP.

>>mmsc+(OP)
> DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP.

There's actually two protocols DNS over QUIC https://datatracker.ietf.org/doc/rfc9250/ which has a specific port 853. This can be blocked.

Then there is DNS over HTTP3 https://security.googleblog.com/2022/07/dns-over-http3-in-an...

>>mmsc+(OP)
There's nothing stopping you just making your own REST API and responding over HTTPS that returns hostname records for any service you build or run - it doesn't even need to use an existing DoH standard. These are exactly the sort of tricks stuff like IoT devices are already using to ensure they can phone home regardless of your network's DNS settings.

DoH is literally just "DNS over HTTPS" (hence the TCP a lot of the time) and you can build this a ton of different ways, including as a basic RESTful API. Local javascript on the page could literally just call any old HTTPS web API to get hostnames resolved, and thanks to HTTPS is much harder to detect, inspect and interfere with than traditional DNS. Fundamentally, a DNS request is a really basic API to implement.

This is why DoH is so hard to conclusively block - its by design to look like "normal" web traffic so bad actors are prevented from manipulating your DNS responses, and the implementation can be done pretty much anyway you want - there are a million different ways to pass a message over HTTPS, and to a firewall they all look like the exact same normal HTTPS traffic if you don't explicitly block the IP or domain serving the DoH.

>>dngray+0z
While these are two common standards, you can easily implement DoH almost anyway you want if you are building a service or device. Its just replying to a request for a hostname record over HTTPS fundamentally - it can be as simple as an extra REST API you run. The number of "protocols" here is effectively limitless. I cant stress enough how simple it can be - check the specs you linked, the example HTTP request/response for the DNS over HTTP3 example is really basic - you could build your own in less than an hour if you really wanted and understand how traditional DNS works.

There is no such thing as right or wrong way to do DoH so long as the DNS messages are passing over HTTPS - the standards are largely to help make it easier to deploy and avoid common pitfalls of course (simpler to integrate to browsers and other software "for free" if the message response body format is standardised), but devices, apps and even javascript in the browser are free to solve this anyway they want, with whatever kind of message payload they can dream up.

DoH is just an HTTP request over SSL in most implementations, nothing more, with the record usually in the payload body in a JSON message or similar.