Skip to content
DNS
Naked Security Naked Security

How ODNS keeps your browsing habits secret

"Oblivious DNS" keeps your DNS traffic private without retooling the internet

In computing, popular ideas have a way of becoming part of the bedrock and, once petrified, they’re extremely difficult to dislodge.
It doesn’t matter how good or bad an idea is, how well or how poorly something is coded or how insecure it is, if something is widely adopted it’s not going anywhere fast.
For example, despite its inherent insecurity email remains central to our lives, and Flash, despite a ready replacement and countless should-have-been-fatal wounds, is dying as if there’s an Oscar on the line.
Finding new ideas is easy but replacing or retooling old ideas is hard.
That puts a premium on solutions that make things better, faster or more secure by working with, or adding to, what’s already there with minimal disruption.
And that’s why ODNS (Oblivious DNS) is such an interesting idea.
ODNS is the latest entrant to an increasingly crowded field of solutions looking to address the privacy problems of the global DNS (Domain Name System).

The trouble with DNS

DNS maps human-readable names for computers and services, like nakedsecurity.sophos.com, into the numeric IP addresses that computers need in order to communicate with each other, like 192.0.79.33.
Unfortunately DNS has a privacy problem – an adversary who can see DNS queries can tell who is browsing where, even if those people are taking care to encrypt the precise details of their browsing with HTTPS.
DNS traffic can be read in two ways: on-the-wire, as it passes over the internet, or when it arrives at its destination.

How DNS works

Let’s say you want to visit www.example.org with your web browser. In order to reach that site your computer has to know its IP address, information it can get via DNS.
It does this by asking the question “what’s the IP address for www.example.org?” of a recursive resolver, which might be operated by your ISP or perhaps a third party service, like CloudFlare’s 1.1.1.1 or Google’s 8.8.8.8.
In turn the recursive resolver consults the server that knows about  .org addresses, which passes it on to the server that knows about .example.org addresses, which passes it on to the authoritative server that knows about www.example.org.
The authoritative server answers the original question, and sends the IP address 93.184.216.34 to the recursive resolver, which sends it back to your computer.
All this traffic is visible on-the-wire to anyone on the same network as you and to your ISP (or your VPN provider) as it passes through their network.
It’s also visible at a number of destinations. The most useful vantage point is the DNS resolver but traffic is also visible at the authoritative server and, often, at the other servers the recursive resolver consults too:

This information can be visible to a 3rd party eavesdropping on the communication between a client and a recursive resolver, or even between a recursive resolver and an authoritative server. As this information is sent to each DNS server, DNS operators can also see clients’ information.

Securing DNS

There are a lot of schemes afoot to deal with DNS’s privacy issues but most solutions only tackle a part of the problem and some require the kind of retooling that could make adoption slow.

  • DNS Query Name Minimisation reduces the amount of information that recursive resolvers share with some DNS servers. Snooping at or between the resolver, ISP or authoritative server is still possible though.
  • DNS-over-TLS and DNS-over-HTTPS require retooling of existing systems to encrypt DNS traffic and prevent snooping on-the-wire. They solve that problem at a cost but do nothing to prevent traffic being monitored at the resolver or other destinations.
  • Recursive resolvers built for privacy, like 1.1.1.1, tackle the resolver problem by promising not to monitor you or keep logs of your activity hanging around. It’s nice, but privacy and security requires stronger underpinnings than assurances of “you can trust us”.

Enter ODNS.

Oblivious DNS

Oblivious DNS attempts to tackle spying on-the-wire and snooping at the resolver, or other destinations, without significant retooling.
Your computer still asks the question “what’s the IP address for www.example.org?” but this time it’s sent to a local ODNS resolver on your computer.
That local resolver creates a session key, encrypts the domain with it and then adds .odns to the end, giving you a completely unrecognisable domain name, like 9fab9405429045fe5.odns.
The session key is then itself encrypted using a public key provided by an the authoritative server for the .odns TLD (Top-Level Domain). Anyone can encrypt something with the public key but only the authoritative server can read it (you’ll see why in a few paragraphs).
The encrypted session key is added to the DNS query and it’s sent on to a normal recursive resolver, such as the one operated by your ISP.
Snooping between you and the resolver, or at the resolver itself, is foiled because a voyeur can identify who’s making a request but not what the request is for, since the domain name is encrypted before leaving your computer.
Just as it would with any other domain, the resolver then identifies the authoritative server for 9fab9405429045fe5.odns and asks it for the corresponding IP address.
On receiving that request the specially equipped authoritative server uses its private key to decrypt the session key, and then uses the session key to decrypt 9fab9405429045fe5.odns, revealing www.example.org.
The authoritative server then acts like a recursive resolver: consulting the server that knows about  .org addresses, which passes it on to the server that knows about .example.org addresses, which passes it on to the authoritative server for www.example.org, which provides the IP address.
The IP address is then passed back down the line to your computer.
Spying on-the-wire during this phase, or at any of those destinations, is foiled because, although a voyeur can now see what domain the requests are for, they can’t see who made them since all the requests appear to start at the .odns server rather than your computer.
Right now ODNS is only a prototype and according to the research team there’s work to be done:

…we have some future work to continue in this direction. We have implemented a prototype of ODNS to evaluate its feasibility and to measure its performance overhead in comparison to current DNS performance.

This puts it a way behind some other DNS privacy solutions but, as I said at the beginning, solutions that require existing systems to change have a way of rolling out really, really slowly.
ODNS’s ability to work with DNS as it is, rather than as we wish it to be, could give it head start, even though it’s starting from behind.

15 Comments

Does the ODNS server not know who is asking for the domain name to be resolved? If it does, then it’s just another case of “you can trust us.”

Reply

Apologies if my question below repeats yours…I must have been typing mine in while yours was being approved :-)

Reply

As far as the ODNS server is concerned all of the requests start at the resolver so an attacker on the ODNS server can see what domains are being requested but not by whom.
There is a possible exception to this. The EDNS0 extension to DNS can be used to pass the client subnet on to authoritative servers (the content written about ODNS also mentions client IP addresses being passed along in this way, not just subnets, but we’re at the limits of my DNS protocol knowledge so I can’t confirm this).
This is how IP information sometimes ends up at the authoritative server and why the resolver, which always has the full IP of the client, is a better place to observe traffic.
If EDNS0 is used in that way then it’s possible that some, possibly all, of a client’s IP will be visible at the ODNS server. I have written to the researchers to clarify this point, and to see if the client’s local ODNS resolver has a role to play here.
Thanks for asking and watch here for updates…

Reply

The researchers responded to say that the ODNS stub resolver that issues the DNS request does not include the client’s subnet (no EDNS0 Client Subnet option) in the DNS query.
The only other time that a client’s subnet could be inserted into a DNS query is at the recursive resolver. According to the researchers it’s still unclear how common it is for recursive resolvers to do this and how many even support it, but they are trying to measure it.
They recommend that clients should use a recursive resolver that does not add a client subnet and hope that their research will shed light on how many open recursive resolvers actually do this.

Reply

Couldn’t a snoop see the IP addresses returned since they don’t appear to be encrypted? Or are they?
Granted, a single IP address could be associated with any number of domains but it could still be revealing, no?

Reply

The IP address you connect to is visible to your ISP anyway. You’d need VPN to avoid that.

Reply

The ISP knows that it asked an authoritative server for .odns and which IP address is associated with it.
A snoop at the ISP could look for other requests from people not using ODNS and match their DNS lookups to IPs returned with ODNS. That would probably work well for popular sites where there’s a one-to-one mapping of IP to domain but because of name-based virtual hosting one IP can host thousands of different websites on different domains, so it’s probably much less effective for smaller sites.
Using a VPN just turns your VPN provider into your ISP effectively – you share everything with them instead.

Reply

Does ODNS aim to solve the assurances of “you can trust us” problem too?
Does the ONDS network use a Tor-like random-routing process to prevent the ODNS proxy itself from knowing where the request originated, or does/could each ODNS server end up with a list mapping “who asked” to “what they asked for”?

Reply

Good question, and one that was at the back of my mind writing this. The written material on ODNS was ambiguous on this point so I wrote to the researchers to ask – see my answer to the first comment.

Reply

What About HTTPS’s SNI issue. Does ODNS fixes that as well?

Reply

To explain, that’s where the setup part of an HTTPS connection has to tell the web server it’s visiting, up front and unencrypted, which domain name it intends to access. (Many servers host many different virtual websites, all with different names, at the same place, so the server needs to know which HTTPS certificate to send back to start te encryption process. Thus the website name, but not the whole URL, leaks out in the clear first.)
I can’t see how ODNS could deal with that issue, because it’s [a] a different protocol [b] at a different time [c] and doesn’t even need a DNS query first – the HTTPS connection setup could be directed at an IP number, given that the Server Name Indication (SNI) specifies the wanted name.

Reply

ODNS is a common acronym for OpenDNS (which uses dnscrypt). Gonna be confusing having two different ODNS out there.

Reply

The .odns TLD isn’t yet officially recognised, as far as I know, and if this gets close to production I imagine OpenDNS’s lawyers will be quite keen to raise the same point you’re making :-)

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!