ODoH is an emerging protocol being developed at the IETF. ODoH works by adding a layer of public key encryption, as well as a network proxy between clients and DoH servers such as 1.1.1.1. The combination of these two added elements guarantees that only the user has access to both the DNS messages and their own IP address at the same time. |
There are three players in the ODoH path. Looking at the figure above, let’s begin with the target. The target decrypts queries encrypted by the client, via a proxy. Similarly, the target encrypts responses and returns them to the proxy. The standard says that the target may or may not be the resolver (we’ll touch on this later). The proxy does as a proxy is supposed to do, in that it forwards messages between client and target. The client behaves as it does in DNS and DoH, but differs by encrypting queries for the target, and decrypting the target’s responses. Any client that chooses to do so can specify a proxy and target of choice.
Maybe it’s just me, but it starts to look overcomplicated.
Basic DoH made sense, I may not want ISP, hotspot operator, or anyone on the way sniffing in my queries, either just seeing them or in worse case blocking or changing them. That happens. Some do it because they like to, some are forced to do it by censorship loving governments (*), … whatever the reason is, I as a user don’t want it, and DoH can solve this problem for me.
But now the point is what? Hide that I’m using DoH resolver? Sure, if it’s some well-known one, access to it can be blocked, that’s a valid concern. But if I depend on some well-known resolver (instead of e.g. deploying private hidden one on some cloud-hosted website about kittens), I’ll probably depend on well-known proxy that will be blocked too. Or I may have problem with DoH resolver operator knowing that it’s me, who is sending some queries. It looks like another level to me, because if I don’t trust the operator, I probably shouldn’t use that resolver. But ok, maybe someone takes over it without me knowing. In that case, ODoH would save me. But what if they take over the proxy too? Wouldn’t it be safer to have more chained proxies to lower the chances that all will be taken over? Or maybe we could skip this and just invent DoHoT (DNS-over-HTTPS-over-Tor)? I thought it was completely original idea of mine, but the article actually mentions it.
(*) I’m anxiously waiting to see how they deal with it. They usually lag five to ten years behind, so it may take a while, but it will be interesting. It’s hard to believe that they would just give up.
I second the feature request. I believe the point is to allow you to not need to trust the DoH provider to maintain your privacy. As it stands, I personally trust CloudFlare not to track my requests, but by adding an HTTPS proxy between me and their DoH server, is that they will not even know my IP address .. and the HTTPS Proxy provider will not know the contents of my request. In other words, it would require collusion between the two providers, or an attacker to compromise both providers.
Overall I think it’s a great feature to add. The second poster makes great points about limitations of trying to implement ODoH when you have less control over your connection to the Internet, but for people who are using MikroTik devices on their organization or home networks, they won’t encounter those obstacles.
