4 ms·

ODNS: Oblivious DNS (2018)

ignoramous 6y ago
Also see u/jedisct1's Anonymized DNS [0] which is works in a similar manner where the stub knows who's the client but doesn't know what's the query, and the resolver knows what's in the query-packet but doesn't know who the client is (kind of a DNS NAT?). [0] https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-DNS https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-D...
- Retr0spectrum 6y ago
  What happens if the stub and the resolver are controlled by the same entity?
  - CyberDildonics 6y ago
    Wouldn't that just be how it works now?
  - musicale 6y ago
    For ODNS the stub runs on the client, and the recursive resolver and ODNS resolver need to maintain secrecy from each other and from third parties. For ADNS the relay and resolver need to maintain secrecy from each other and from third parties.
deleted 6y ago
[deleted]
HerraBRE 6y ago
This is neat! DoH/DoT over Tor will provide stronger security and privacy guarantees across the board, but a well run .odns (anycast, good caches) could probably provide better performance. The .odns anonymity is strictly weaker than DoH-over-Tor because the .odns operator can see which recursive resolver is in use, and not all such resolvers serve large enough audiences to provide strong anonymity. The .odns requests are also very easy to identify, monitor and block, and it's likely that metadata (query size, timings) will still leak a fair bit of information, especially if correlated with other network activity.
- toast0 6y ago
  You can make query size non snoopable if you include padding, and say, always pad to 512 bytes. I didn't read the article closely, but if this is via TLS, TLS 1.3 includes optional padding in all application data, so should be doable (depending on tls api design).
mateus1 6y ago
This is one of those ideas so great they seem obvious. Anyone knows if there are any stable implementation?
eat_veggies 6y ago
Who can we trust to operate an ODNS server? If the organization that runs it also runs a recursive DNS server (or has ties to one, or has been compromised by the same gov agency), then the privacy guarantees go away.
- musicale 6y ago
  The design seems to depend on the recursive resolver and ODNS resolver maintaining secrecy from each other and third parties. It also depends on the private key of the ODNS resolver not being compromised. With DoH you are trusting a single DNS service (e.g. cloudflare or nextdns) entirely; with ODNS can could split that trust between two services: a recursive resolver (cloudflare) and an ODNS resolver (nextdns.) Privacy-focused web browsers could implement a local ODNS stub that requires that the two services be run by independent organizations (to the best of its knowledge at least.)
bawolff 6y ago
I somehow thought this was going to use oblivious data structures, but seems to just be encrypting the query
aaravchen 6y ago
Their "solution" just seems to be a way to introduce a trusted stub server in the middle of a DNS lookup request that can anonymize your queries. That's identical to just trusting your initial recursive resolver to provide that service and using DNS-over-TLS. That's what most privacy focused VPN providers, Cloudflare, etc include. So why would we break existing DNS implementation to support ODNS?
musicale 6y ago
DNS privacy is a nice idea, but every web page still has a facebook "like" button on it.
artjomb 6y ago
> The authoritative server [of .odns] decrypts the session key with his private key, and then subsequently decrypts the requested domain with the session key. So this basically means that the .odns operator is yet another entity that can scoop up some domain names. The one privacy advantages that I see in comparison with using Cloudflare or others as DoH providers is this: .odns operator can only group the domains that they see to a resolver of the ISP of the user. Cloudflare could group domains by IP address of the user.

Also see u/jedisct1's Anonymized DNS [0] which is works in a similar manner where the stub knows who's the client but doesn't know what's the query, and the resolver knows what's in the query-packet but doesn't know who the client is (kind of a DNS NAT?). [0] https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-DNS https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-D...

Retr0spectrum 6y ago
What happens if the stub and the resolver are controlled by the same entity?
- CyberDildonics 6y ago
  Wouldn't that just be how it works now?
- musicale 6y ago
  For ODNS the stub runs on the client, and the recursive resolver and ODNS resolver need to maintain secrecy from each other and from third parties. For ADNS the relay and resolver need to maintain secrecy from each other and from third parties.

deleted 6y ago

[deleted]

HerraBRE 6y ago

This is neat! DoH/DoT over Tor will provide stronger security and privacy guarantees across the board, but a well run .odns (anycast, good caches) could probably provide better performance. The .odns anonymity is strictly weaker than DoH-over-Tor because the .odns operator can see which recursive resolver is in use, and not all such resolvers serve large enough audiences to provide strong anonymity. The .odns requests are also very easy to identify, monitor and block, and it's likely that metadata (query size, timings) will still leak a fair bit of information, especially if correlated with other network activity.

toast0 6y ago
You can make query size non snoopable if you include padding, and say, always pad to 512 bytes. I didn't read the article closely, but if this is via TLS, TLS 1.3 includes optional padding in all application data, so should be doable (depending on tls api design).

mateus1 6y ago

This is one of those ideas so great they seem obvious. Anyone knows if there are any stable implementation?

eat_veggies 6y ago

Who can we trust to operate an ODNS server? If the organization that runs it also runs a recursive DNS server (or has ties to one, or has been compromised by the same gov agency), then the privacy guarantees go away.

musicale 6y ago
The design seems to depend on the recursive resolver and ODNS resolver maintaining secrecy from each other and third parties. It also depends on the private key of the ODNS resolver not being compromised. With DoH you are trusting a single DNS service (e.g. cloudflare or nextdns) entirely; with ODNS can could split that trust between two services: a recursive resolver (cloudflare) and an ODNS resolver (nextdns.) Privacy-focused web browsers could implement a local ODNS stub that requires that the two services be run by independent organizations (to the best of its knowledge at least.)

bawolff 6y ago

I somehow thought this was going to use oblivious data structures, but seems to just be encrypting the query

aaravchen 6y ago

Their "solution" just seems to be a way to introduce a trusted stub server in the middle of a DNS lookup request that can anonymize your queries. That's identical to just trusting your initial recursive resolver to provide that service and using DNS-over-TLS. That's what most privacy focused VPN providers, Cloudflare, etc include. So why would we break existing DNS implementation to support ODNS?

musicale 6y ago

DNS privacy is a nice idea, but every web page still has a facebook "like" button on it.

artjomb 6y ago

> The authoritative server [of .odns] decrypts the session key with his private key, and then subsequently decrypts the requested domain with the session key. So this basically means that the .odns operator is yet another entity that can scoop up some domain names. The one privacy advantages that I see in comparison with using Cloudflare or others as DoH providers is this: .odns operator can only group the domains that they see to a resolver of the ISP of the user. Cloudflare could group domains by IP address of the user.