SoylentNews is people
SoylentNews
The Domain Name System (DNS) is a plain-text service that lets anyone who can see “the wire” capture a user's DNS traffic and work out whether they're asking for naughty.com or nice.com. So to help enhance its privacy a group of researchers has proposed a more "Oblivious DNS” protocol.
However, as the group explained here, even encrypted DNS (for example, DNS over TLS) is still exposed at the recursive resolver (that is, the DNS component most directly connected to the client), because that server decrypts the user request so it can fetch the IP address of the site the user wants.
In other words, whether you use your ISP's resolver, or one provided by a third party like Google or Cloudflare, at some point you have to trust the resolver with your DNS requests.
[...] To get around this, Oblivious DNS is designed to operate without any change to the existing DNS. As its designers write, it “allows current DNS servers to remain unchanged and increases privacy for data in motion and at rest”.
Instead it introduces two infrastructure components that would be deployed alongside current systems: a resolver “stub” between the recursive resolver and the client; and a new authoritative name server, .odns at the same level in the hierarchy as the root and TLD servers (see image).
In this model:
- The stub server accepts the user query ("what's the IP address of foo.com?"), and encrypts it with a session key/public key combination;
- The recursive name server receives the request (with .odns appended) and the session key, both encrypted;
- The .odns tells the resolver to pass the request up to the ODNS authoritative server, which decrypts the request and acts as a recursive resolver (that is, it passes requests up the DNS hierarchy in the normal fashion);
- The ODNS encrypts the response and passes it back down to the stub, which sends the response to the client.
The authors explained that this decouples the user's identity from their request.
The recursive resolver a user connects to knows the IP address of the user, but not the query; while the ODNS resolver can see the query, but only knows the address of the recursive resolver the user connects to, not the user.
Similarly, an attacker with access to a name server never sees the user's IP address, because the request is coming from the ODNS server.
The group has posted a conference presentation from late March here [PDF], and emphasises that Oblivious DNS is a “work in progress”.
(Score: 2, Interesting) by dwilson on Wednesday April 11 2018, @08:34PM (1 child)
I disagree with a lot of what you said.
My network consists of the machines running in my home, connected to my (openwrt-running) router, which is connected to the wider internet via an adsl connection to my local isp. I'm not worried about attackers on my local network. I imagine the vast majority of people are in the same boat.
Perfect is the enemy of good. If this solution helps mitigate anyone outside my network knowing my dns requests, that's a Good Thing. Address the edge cases as they come up, don't wait for a perfect solution for everybody. Sure, that's biased towards my needs and my setup. What other metric would I use. realistically?
That sounds like a valid concern.
- D
(Score: 2) by insanumingenium on Wednesday April 11 2018, @09:46PM
The placement of the stub, they don't explicitly define, and this isn't a matter of edge cases, if the stub is placed on an untrusted network, this proposal provides less than zero benefit. At least without it you are potentially aware you are totally unprotected.
The first half of my previous response was not a technical critique, but a complaint that their writing was unclear bordering on deceptive. To be clear, I also didn't explicitly state that I wasn't referring to The Register's story (which I didn't read when an academic link was available) but to the linked source [princeton.edu] and sublinked slideshow [princeton.edu]. Admittedly, someone else already pointed out there is an extension to add subnet information to DNS requests which I was unaware of, but I can't imagine the same is true of the MACs. Even given the subnet extension I am not clear on how this proposal would interact. Do these guys at Princeton not have any professors acting as advisors to point out that their summary sucks? Am I wrong to expect clarity from academic publications?
I normally will be the first person shouting that perfect is the enemy of good with you, but if you can't write a coherent proposal, how is anyone supposed to support it?
Security has to be well thought out, suggesting a vulnerability that doesn't exist absolutely discredits these authors. My comment wasn't that this isn't viable (though to be honest I don't see it being so at scale), but that making a security proposal that is unclear is a terrible mistake. I would personally demand anything dealing with security to be defined totally and transparently, I have seen too many implementations of well defined standards get details slightly different in ways that put people at risk.