▲ 79 points
back
66 comments
I really like this even though I think it only makes for a minimal increase in privacy due to either SNI[1] or quickly grabbing the cert of an IP revealing the hostname if no SNI is supported.
DNS-over-TLS and DNSCrypt are more about authentication than privacy. They are useful against the guy sitting behind you at Starbucks doing DNS injection.
They don't replace a VPN.
Doesn't TLS 1.3 fix this SNI hostname leak though?
Nope, they kept it because there weren't better alternatives.
SNI will show the hostname of the "DNS over TLS" server the TLS connection is made with but not the DNS queries made.
DNS isn't very useful unless you're actually planning to visit the IPs you just looked up. And as soon as you do that, you'll send the domain name in plaintext via SNI.
It will also show the hostname of the server I access after doing the DNS lookup.
I don't think so.
The purpose of SNI is to pass the domain name to the final destination server, so it can serve up the correct SSL cert where there are multiple domains hosted on the same IP
If anybody is interested for this on Desktop... here is a link to Dingo for Google's DNS: https://news.ycombinator.com/item?id=12514170
Please correct me if I'm wrong, but isn't this strictly worse than DNSCurve & DNSCrypt? Those protocols are secure even over a hostile network. The only traffic visible is an end-to-end encrypted DNS request.
I don't know much about DNS over TLS but one thing I like about DNSCrypt is the certificate pinning.
The one thing I don't really like about DNScrypt, or privacy-oriented DNS in general, is the lack of transparency of the remote end. I wish that more of the DNScrypt endpoints were run by organizations that I trust (EFF, etc) instead of by some random dude out on the internet. We need a highly transparent, non-commercial foundation for this.
Indeed, that would be neat.
If you need something that works everytime, you're stuck with http and https due to outbound firewalls. Even installing a dns recursor on your laptop might not work.
I'm tempted to setup a corporate-y network as a weekend project, I think I'm getting out of touch with what some people have to bear with.
A recursive DNS server on your laptop does next to nothing for privacy. It's still sending out the requests in plaintext to the root and authoritative nameservers. The only time it might help you is if the name is cached and it doesn't have to go to the wire to resolve it.
Your best bet is to set up your own DNScrypt service instance on your own public server running on a network that you trust.
Feels like placebo security to me. If the protocol is http, any attacker can still see the domain name through the host header. Plus it does nothing to stop them from intercepting/modifying the request/response. If the protocol is ssl/tls the domain name is in the sni. You'll inevitably have to disable it every time you use public wifi (to get the captive portal to show up). Using TLS adds latency, because of the tcp handshake required (unless they're using DTLS), and it exposes all the domain names you visit to google, so it's actually worse than regular dns.
> Feels like placebo security to me. If the protocol is http, any attacker can still see the domain name through the host header. Plus it does nothing to stop them from intercepting/modifying the request/response. If the protocol is ssl/tls the domain name is in the sni.
This is an interesting argument that people have been having over and over.
Whenever someone proposes to encrypt DNS someone will come up with "but SNI still leaks the host name". Whenever someone proposes to encrypt SNI then surely someone will point out "DNS still leaks the host name".
Yeah, you need to encrypt both. But that fact is no argument for not encrypting at all.
SNI works because it is not encrypted, that's the point why it was introduced in the first place. What key are you going to use to encrypt it?
> Using TLS adds latency, because of the tcp handshake required
TCP Fast Open gets rid of the TCP handshake latency, but even with TLS session ids-or-tickets there is still a round-trip for ServerHello — presumably because the standardization bodies don't trust that the client is ever capable of avoiding nonce reuse or generating a secure random number.
Keeping the TCP+TLS connection alive might be feasible but you will either have to spend a lot of energy transmitting frequent keep-alive packets or run into problems on IPv4 if the network provider discards NAT mappings faster than your send interval.
Unfortunately the adoption of both RFCs is really poor, with TCP Fast Open not working with Chrome on Linux (I have it set to enable in developer settings, and it does work in Firefox) and nginx still not supporting proper session ticket key rollover.
> You'll inevitably have to disable it every time you use public wifi (to get the captive portal to show up).
In my experience, captive portals use a MITM on HTTP connections, not a DNS hijack. If they hijacked the DNS request, the browser's DNS cache would keep the wrong response, breaking access to the real website even after login to the captive portal.
> Using TLS adds latency, because of the tcp handshake required (unless they're using DTLS), and it exposes all the domain names you visit to google, so it's actually worse than regular dns.
The TCP handshake latency would be only on the first request, the same connection can be reused for further queries, especially if you are using a single recursive resolver for all queries, which is the case if it "exposes all the domain names you visit to google".
Placebo for what? It is just another way to bring you some privacy about your DNS activity /like DNSCrypt does too) and a way for you as client to simply validate DNSSEC end-to-end.
your argumentation reads like the disadvantages of HTTP vs. HTTPS. Latency issues have been mostly resolved... it's not 1999.
This might be big for censorship circumvention. If DNS is over TLS, it can't be transparently proxied.
Fantastic, hopefully it will be enough to thwart the surveillance made mandatory in the UK recently, where ISPs have to keep a record of every website you visit for a year.
You won't be thwarting anything with a Google product.
How would transparent proxies prevented?
Proxy would need a cert trusted by the client. Not impossible, but raises the bar.
The article mentions preventing ISPs from knowing which websites you visit, but won't they still know the IP address of the server you access? Given that websites have relatively static IPs, doesn't that make it trivial to map back to a domain? Sorry if I'm completely misunderstanding the situation.
No, you are not misunderstanding it. (they don't even have to match the IP in most cases, since the domain is in the request you send)
The main value of protected DNS is in stopping the provider or some other middleman from changing the DNS responses you get, not in hiding your requests.
But if you're connecting to a site using HTTPS, would it even matter if a middleman changed the DNS response? If they respond with the IP of the wrong server, you'll just get a certificate error.
And if you're not using HTTPS, they don't need to mess with DNS responses; they can serve you any content they want over any URL.
DNSSEC does that too...
Yes, unless you are using a VPN or Tor, the IP of the site you're connecting to is present in every TCP/UDP/ICMP packet you send out.
For some sites that are hosted on big virtual host IPs with dozens/hundreds of sites being served from the same IP, it's slightly more vague. For big sites where there is a 1:1 relationship between website and IP, there is no question about what you're visiting.
Good thing, but what servers do use DNS over TLS?
To be honest I don't really know who manage DNS mirrors... Is there an existing RFC for encrypted DNS? Aren't ISPs the one who take care of mirroring DNS servers?
Conveniently, Google Public DNS.
"This does require the DNS you are using to have DNS over TLS support, though, but it’s a start. Users can switch to Google’s DNS if they wish to benefit from DNS over TLS."
Cut the ISPs out of the DNS data mining of Android users and encourage more users to switch to Google DNS which, I assume, Google can still mine even when using DNS over TLS because they are the provider.
Google claims they don't log any personally identifiable information (including IPs) long term or correlate with data from other services: https://developers.google.com/speed/public-dns/privacy
As with most things with Google... it first seems a benefit for the users but always helps them (Google).
They take the data away from someone but it actually helps them (Look at AMP pages). In this case it is highly likely all DNS requests will be onto 8.8.8.8 and 8.8.4.4 DNS servers - giving them more info on what you are doing when no on their own services.
https://dnscrypt.org/ is a fairly good source for servers that support the dnscrypt protocol (assuming this is what's being used - it may be a different protocol, but dnscrypt has been in the wild for some time). Not to be confused with DNSSEC
Uncensorer DNS supports it:
https://blog.uncensoreddns.org/blog/32-dns-over-tls-pubkey-p...
Those lucky ones to get updates are getting it.
Which currently means 0.2% of worldwide Android devices.
But most devices will have it in the next 3 years. It's better to start today than to never do it.
Outside US most people actually use their phones until they either die or get stolen.
We aren't in 3 yearly "gratis" renewal contracts.
Is there a way to do this on home router level?
In what way? Do you want your router to expose a DNSoTLS endpoint to your router's clients or do you want your router to use DNSoTLS to fetch its results?
Both are technically possible but probably a lot of work if it must run on off the shelf router because the firmware choices are pretty limited. It might be easier to run your own DNS server off a Pi (or something) and have your router point your clients there.
Alternatively install OpenDNS Umbrella which will do this with DNSCrypt to the OpenDNS servers
DNSCrypt finally wins
What?
"Users can switch to Google's DNS if they wish to benefit from DNS over TLS."
"If a different DNS service provider you decide to connect to does opt to enable DNS over TLS, they'll get your DNS traffic instead of your ISP. DNS requests will be encrypted, but the DNS over TLS server still gets to see your DNS traffic, though that alone might be a step above using your ISP's servers without TLS over DNS. At least this way, your ISP won't be able to attach your queries to the IP you've been assigned, and thus your name."
Author makes a plug for a third party DNS provider. Third party DNS provider also happens to sell web ads and data about users.
Author believes letting Google or other third party DNS provider see queries is "step above" letting ISP see them.
Assuming this is true (to avoid needless arguments) but wanting more, is there a "step above" letting a third party DNS provider log the queries?
IMO, yes, an obvious one. Running DNS cache and/or authoritative daemons on localhost. Using a custom root.zone can be helpful.[FN1]
Is that possible on a mobile phone? No idea. Maybe it should be.
Any other options? How about running a cache and/or authoritative daemons on a computer you can actually control. Set the mobile OS DNS settings to point to that computer. It works. I have been doing this for many years.
FN1. Per packet encryption for DNS is also available via DNSCurve. For example, I can make encrypted queries directly to the DNS servers for any website that support it. I have been using DNSCurve for years as well. It works. Only a small number of public websites have adopted it so far even though it is relatively easy to set up.
Although I personally do not care for third party recursive DNS service, third parties might provide a useful name lookup service over TLS. To illustrate, we can use Google DNS is an example.
What if we could make queries over TLS (using HTTP) but without using SNI?
To start, get the IP address for the third party provider.
dig dns.google.com
curl https://1.2.3.4/resolve?name=example.com.\&type=dnskey
The reason why I think this could be useful is that we can use HTTP pipelining to the http daemon. Example below. (No publicly available dns daemons accept pipelining AFAIK.) Thus one can do multiple lookups by sending only a single TCP packet.
I have never understood is why there are no publicly released DNS servers that can accomodate multiple queries in a single UDP DNS packet. If I recall correctly, the original DNS RFC contemplates this.
The DNS data returned via TLS (as JSON in the Google DNS example) might be useful for instance in emergencies when DNS service is unavailable or untrustworthy, or it might be inserted into HOSTS file or into custom zone files served by localhost daemons. It could be useful.
openssl s_client -tls1_2 -ign_eof \
-connect dns.google.com:443 -verify 9 <<eof
GET /resolve?name=example.com.\&type=dnskey HTTP/1.1^M
Host: dns.google.com^M
Connection: keep-alive^M
^M
GET /resolve?name=example.net.\&type=dnskey HTTP/1.1^M
Host: dns.google.com^M
Connection: close^M
^M
eof