Hacker News new | past | comments | ask | show | jobs | submit login
Oblivious DNS: Plugging the Internet’s Biggest Privacy Hole (freedom-to-tinker.com)
124 points by sohkamyung on Apr 3, 2018 | hide | past | web | favorite | 54 comments

If the root servers and major .tlds would support dns-over-tls every home router could just run a full recursive dns resolver by itself, and we could be done with it. There would be no need for complicated architectures with proxies and stub resolvers, and nobody could see your queries. The root server would just see your NS lookup for .com, the .com would just see your NS query for google.com and the google.com NS would see your query for maps.google.com - but here you are in googles domain anyway, so it does not matter.

dns-over-tls would prevent your isp from snooping your queries to the .com/.org/.net/.club/... nameservers and we could close the case.

That would certainly be an improvement, but not the end of the story.

> 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.

That could be a next step.

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.

Wouldn't that quickly overload all the root servers?

Resolvers should aggressively cache the root zone. And the traffic shouldn't be any worse than what google or cloudflare resolvers are seeing.

> the traffic shouldn't be any worse than what google or cloudflare resolvers are seeing.

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.

No. The volume of traffic to the . content DNS servers would be largely unchanged.

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.

Every ISP offers DNS servers. Those DNS servers cache the requests, usually for hours if not a day, for all the requests they get.

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.

That is not the scenario that y0ghur7_xxx proposed. The scenario that y0ghur7_xxx proposed related to the headlined mechanism. What you describe does not.

> If the root servers and major .tlds would support dns-over-tls every home router could just run a full recursive dns resolver by itself

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 root server would just see your NS lookup for .com, ...

That's not how DNS works today so you're asking for a major re-architecture.

>> The root server would just see your NS lookup for .com, ...

> 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...

It's worth noting that privacy against ISPs, at least today, is hugely more important than privacy against DNS resolvers, and not just because first-world ISPs have a reputation of being less trustworthy than companies like Cloudflare (Google is more debatable).

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.

> You can always change DNS resolvers.

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.

> DNS: The Internet's Biggest Privacy Hole

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 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, only adds to the number of organizations that can monitor you. But is an important piece of a much larger puzzle that could, if completed, provide greater confidentiality.

I must be missing something here: "The ODNS server can thus return the answer to the client’s stub resolver directly, possibly over a confidential channel such as D-TLS."

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?

Yeah, the figure[1] on the side in the article seems to show something different, because there the response goes over the recursive resolver again. Maybe the text is wrong?

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...

My reading of it is that the DNS request gets encrypted on the client and sent to ODNS. ODNS doesn't know how to decrypt the request so it can't see what you are looking for, just that it is you that is looking.

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.

So is my thought. Surely they have yet to come up with something akin to an onion routing layer where the machine performing the lookup is not owned by the same entity as those who know its origin?

How is the middle path between current DNS and Tor-level anonymity defined, exactly?

> How does this not just move the trust problem to the ODNS server?

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?

How about running your own TLD DNS server? According to [1] the gtld zone files are 1.5GB so it would fit even on a phone. The problem is getting access to the zone files. Services like domainlists.io will sell you the data, or maybe you could figure out how to crawl for it yourself.


It's not only about getting the data, but also about ensuring the source is trustworthy as well as staying up-to-date.

Surprised there are no free data sets like this available - it seems to fit scans.io's idea. Are there projects that would help me crawl it with minimal effort?

I would also love to contribute to this if it exists.

If authoritative servers supported DNS over (D)TLS then running your own recursive resolver would plug most holes. The biggest remaining information leakage would be to the TLD NS operators, which could further be mitigated by spreading it to some sort of authoritative mirrors, maybe secured by dnssec?

Don't forget DNSCurve (thanks again djb!)

I've been reading up on this recently, and I've seen a few articles on DNSSEC vs DNSCurve, how would you weigh in?

DNSSEC (IETF standard) only provides authentication and integrity protection. DNSCurve can also provide confidentiality. DNSCurve does require the authoritative server to do crypto on the fly, so may require a lot more work for the root/TLD servers. DNSSEC is just signed DNS data, so the work can be done offline. So operators just do DNSSEC, very few operators deploy DNSCurve. Actually, most places do neither.

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.

Both are irrelevant in practice, but DNSSEC is de facto standard; it's what the root servers implement.

Not a good name. This is not an implementation of Oblivious Transfer, as one would asssume, see https://en.wikipedia.org/wiki/Oblivious_transfer

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.

Obliviousness is a property not just of OT; ORAM protocols are other "oblivious" protocols, for example.

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.

This is perhaps a stupid question. But, even if we had a real oblivious DNS, can't the ISP figure out what website I am connecting to by a reverse-dns lookup on the IP-address ?

Yes unless the websites are using a CDN with shared IP addresses. I wonder what % of the web that covers nowadays.

The article claims that is a joint project between CloudFlare and Mozilla. But the source it links to for that never mentions Mozilla.

Is this article better [1]? Mozilla has partnered with Cloudflare to provide direct DNS resolution from within the Firefox browser using the Cloudflare Resolver for Firefox. What this means is that whenever you click on or type a web address in the Firefox browser your DNS lookup request will be sent over a secure channel to the Cloudflare Resolver for Firefox rather than to an unknown DNS resolver, significantly decreasing the odds of any unwanted spying or man in the middle attacks.

[1] https://developers.cloudflare.com/

Does it mean Firefox will work without having DNS configured at OS level and just force you to use or what? Cannot find any information on mozilla.org

Only for DNS over HTTPS, which Firefox Nightly can deal with itself: https://www.ghacks.net/2018/04/02/configure-dns-over-https-i...

That just says that Firefox is going to use . But this Freedom to Tinker article is saying Mozilla helps operate and that Mozilla has partial ownership.

>Mozilla and Cloudflare are deploying their own DNS recursive resolver

>Mozilla/Cloudflare’s operate such open DNS recursive resolvers

Great, so all my internal DNS names just fail? Some of those override external names (e.g. dailymail.co.uk at home points to a holding page in case I accidentally click a link to that vile piece of trash)

And on my isolated network, which has no routed access to the internet?

At this point your best bet is to get it straight from the source https://bugzilla.mozilla.org/show_bug.cgi?id=1434852

> 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

hopefully there is at least an option to disable that.

I know that Mozilla just spent the past weekend doing a bunch of work on both their internal- and external-facing DNS infrastructure, but I don't believe it had anything to do with this.

WRT to the Cloudflare/Mozilla "partnership", see this discussion [0] from 11 days ago (spoiler: it's a "Shield study").

[0]: https://news.ycombinator.com/item?id=16653889

Will website name in certificate shared by server during handshake kill the DNS over https purpose?


Consider me confused.

See also "spam".

> Clients that you operate—including your browser, your smartphone, and any IoT device in your home—sends a DNS query for each domain name to a so-called “recursive DNS resolver”.On a typical home network, the default recursive DNS resolver may be operated by your Internet service provider (ISP) (e.g., Comcast, Verizon).

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.

>Nobody says 'recursive DNS resolver'

>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

Nobody should* say...

> Yes, because I never use my PIN Number

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.

Actually, it is a recursive DNS resolver, and that designation is not redundant. See RFC 1034 and RFC 1035.

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.

* http://jdebp.eu./FGA/dns-server-roles.html

I believe that they are making the distinction between a recursive DNS resolver and an authoritative DNS resolver.

Resolver vs Authoritative is the distinction. A resolver is recursive (it has to query other servers to get the answer); an authoritative DNS server is not (it has the answer).

I've never heard of anybody refer to an authoritative server as a "resolver" before. Even the article considers them separate:

> 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.

It means as distinct from a "stub" resolver. resolv.conf configures a stub (non-recursive) resolver.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact