Oblivious DNS: Plugging the Internet’s Biggest Privacy Hole
freedom-to-tinker.com
freedom-to-tinker.com
dns-over-tls would prevent your isp from snooping your queries to the .com/.org/.net/.club/... nameservers and we could close the case.
What are you basing that on? How many people do you think are really using Google DNS or Cloudfare DNS? I think even if just Comcast changed their defaults, the root servers would see a order of magnitude more traffic than Google or Cloudfare see.
One of the reasons DNS is hierarchical is for load distribution (and performance). Taking this design principle and all of a sudden throwing it out the window would likely have major consequences for a system that was originally designed and scaled with it in mind.
In the existing system, each cache miss at a caching resolving proxy DNS server begins with a transaction with the . content DNS servers (and thence with each content DNS server for further domains as a series of delegations is followed).
In the proposed system, each cache miss is still only one transation to the . content DNS servers, the difference being that that transaction is encrypted.
For example, at the ISP I worked at for many years, we had ~30,000 customers. As an exmaple, Google specifies a SOa timeout of 10800 seconds (3 hours). Across the 4 resolving nameservers at the ISP, the most times they would request google.com in a day is (24 hours/day / 3 hours cached) * 4 servers. That's 42 requests a day, to service 30,000 people.
If all the customers were requesting it directly, it's a different story entirely. Say 80% of the customers access google regularly through email, or their phones, or whatever. Let's say they do it for an average of 8 hours a day (before work, after work, while sleeping and some random update/email comes in). In this case, the math is (8 hours/day / 3 hours cached) * (30,000 * 0.80). That's 64,000 requests a day to service 30,000 people (even though only 80% are actually visiting that domain).
That's over a thousand-fold increase, but it only gets worse if you look at larger ISPs, like Comcast and AT&T. Now, this is a pretty bad case, but there's plenty of very popular sites that are used by our devices on a regular basis, all day long. Doing direct requests from customer networks instead of using intermediary caching DNS servers is a horrible idea and would cripple the internet as the root servers fell over from massive load.
Emphasis mine. Every home router running its own recursive resolver instead of asking a large shared recursive resolver is exactly what I outlined.
If you interpreted it differently, perhaps you can provide some details as to how you did interpret it rather than just saying I'm wrong?
> the .com would just see your NS query for google.com
This would still create chokepoint for countries or generic TLDs where law enforcement could harvest data. For example they might be interested who visits say eff.org or stormfront.org
We still need to either blind or distribute the TLD NS servers to avoid presenting a singular target.
Having only the nameservers responsible for that zone see the query would already be a huge improvement to what we have now. And with tech that is already available and standardized.
That's not how DNS works today so you're asking for a major re-architecture.
> That's not how DNS works today so you're asking for a major re-architecture.
Actually that is how QNAME minimisation (on the resolver) works https://tools.ietf.org/html/rfc7816
unbound has some nice slides: https://ripe72.ripe.net/presentations/120-unbound_qnamemin_r...
You always have a choice of DNS resolver; you often don't have a choice of ISP. Especially outside of the first world, where the ISPs might be in the pocket of the government, like in the example from Turkey mentioned in Cloudflare's blog post, or in China. The ISP is the physical pipes, and if you can't get through the physical pipes, you're dead in the water. You can always change DNS resolvers.
This is still an interesting idea that's worth looking at. They just shouldn't minimize the significance of what Cloudflare is doing.
But you can't. First, it's technically hard for many or even most users. Some important platforms (mobile) may make this exceptionally hard even for savvy users.
Even if it's built in to the browser, the ISP can require you to use their proxy (some regimes already do this today) and then they can filter and/or alter DNS, even DNS-over-https.
Almost every packet on the Internet identifies the user's IP and the server to which they are connecting (with the exception of VPN traffic and Tor). DNS does not reveal much more than that.
I do agree that Cloudflare's 1.1.1.1 does almost nothing to improve end user confidentiality - there are so many other ways users are tracked, and in much greater detail than DNS can provide; and if your ISP is your DNS vendor, 1.1.1.1 only adds to the number of organizations that can monitor you. But 1.1.1.1 is an important piece of a much larger puzzle that could, if completed, provide greater confidentiality.
How does this not just move the trust problem to the ODNS server? Doesn't it now know both the requesting IP and the requested domain?
How is the middle path between current DNS and Tor-level anonymity defined, exactly?
All seems to hinge on the recursive resolver acting as a proxy, so a direct response from ODNS server to the client stub doesn't seem safe.
[1] https://s3.amazonaws.com/ftt-uploads/wp-content/uploads/2018...
That's how I read this as well. It does appear that a simple DNS proxy would accomplish the same goal without all the encryption. Are we missing something?
The ODNS resolver then sends the encrypted request to the DNS resolver on your behalf, and the DNS resolver decrypts the request and services it. This meanst that the DNS resolver knows what website you are looking for, but doesn't know that it is you that is looking for it.
The DNS resolver then encrypts the result and returns it to the ODNS, which then returns it to you.
It is basically decoupling the identity of the requester from the domain being requested.
There is the possibility to mix the two - use DNSSEC for root/TLD servers and then DNSCurve on the lower level or leaf zones. It would be hard to know when to switch over from DNSSEC to DNSCurve(other than try at the 2nd level and below). Query minimization may help in privacy protection at the root/TLD level.
Also, this is just using asymetric encryption for the communication between client to authorative servers, which would also overload the servers as they could not be distributed or cached as is done today.
In this case, as long as the ODNS root server is not colluding with the recursive server, the DNS system is "oblivious" to the identity of the user.
[1] https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
>Mozilla and Cloudflare are deploying their own DNS recursive resolver
>Mozilla/Cloudflare’s 1.1.1.1 operate such open DNS recursive resolvers
And on my isolated network, which has no routed access to the internet?
> Provides an optional resolver mechanism for Firefox that allows running together with or instead of the native resolver.
> "localhost" and names in the ".local" TLD will never be resolved via DOH.
> TRR is preffed OFF by default
WRT to the Cloudflare/Mozilla "partnership", see this discussion [0] from 11 days ago (spoiler: it's a "Shield study").
Nobody says 'recursive DNS resolver' - it's just a DNS resolver. See `man resolv.conf`.
DNS is inherently recursive. Saying 'recursive DNS resolver' is like saying 'ATM machine' or similar.
>Saying 'recursive DNS resolver' is like saying 'ATM machine' or similar
Yes, because I never use my PIN Number
Nobody is a very small set, and a very powerful word -- use it carefully, like Never, Always and Everyone
I get the point you're making, but that doesn't change anything:
Unix people (and devops people) don't say 'recursive DNS resolver'. I've met 0 people who do this in the last 20+ years. I'm using the term 'nobody' very deliberately.
I guess technical people are more specific - or like to keep things shorter - than the general public.
> any third party who can observe communication between a client and a recursive resolver, a recursive resolver, or an authoritative server
The "recursive" adjective is pretty clearly to distinguish between stub and recursive resolvers.
This terminology is difficult to get right, very few people actually do, and you are also demonstrating how it can be got wrong. A resolver is not what people in the overwhelming majority of cases think it to be, and they then reason to erroneous conclusions from this false concept.
This is why I explain DNS using the terminology of HTTP: content DNS servers, proxy DNS servers, and client libraries.