Both Google's [1] and Cloudflare's [2] DNS privacy policy prohibits them from storing personally identifiable information or from correlating DNS information with other Google data coming from the same IP/account but it does allow them to store information about which domains are popular, from which locations and from which type of device.
TLS (and therefore HTTPS) provides a very useful fingerprint based on accepted cipher suites, extensions, compression methods...
[1] https://developers.google.com/speed/public-dns/privacy
[2] https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
[3] https://devcentral.f5.com/articles/tls-fingerprinting-a-meth...
Cloudflare runs the largest authoritative DNS server for their customers. The best way to make the DNS server faster is to make users query it directly.
For Cloudflare-hosted domains, instead of:
User → ISP's DNS resolver → ns.cloudflare.com.
User → [ 1111 → ns.cloudflare.com. ]
1.1.1.1 runs on our existing hardware deployed around the world, it costs us very little. When you use it it improves performance for the 8 million or so sites we sit in front of, that's our actual business.
Cloudflare is in the business of running websites really fast and subsidize a free offering through paying customers.
Which of those has a conflict of interest in running a DNS server while promising to protect privacy?
Whats worse, is everyone and their dog is using them. What happens when they push a bad config to their core routers, or foobar their anycast?
Even if DDoS was their main business driver, what you're saying is similar to "doctors don't make any sense to me. what possible incentive do they have for keeping people healthy? they have incentive for promoting bad health."
As someone who works in security, believe me, there are plenty of cyber attackers out there that will easily keep companies like Cloudflare in business, no "promotion" of bad behavior required.
https://www.pcmag.com/news/351962/cloudflare-leak-exposed-da...
It is not hard to put a dns-over-https frontend in place for my clients which pulls queries from my own trusted bind9 servers.
Any ISP with a clue can do the same.
I know Google and CF claim they don't track this DNS information, but why even use them when you can run your own. Keep in mind CF did have a software bug that spewed SSL traffic and passwords all over the Internet[1], and they took down a website once because their CEO didn't like it[2].
[1] https://blog.cloudflare.com/incident-report-on-memory-leak-c...
[2] https://fightthefuture.org/article/the-new-era-of-corporate-...
* DNSCrypt
* DNS over TLS
* DNS over HTTPS
DNSCrypt is the one with better client support and a long list of providers available. If you pick DNS over TLS or DNS over HTTPS you will be restricted to 3 or 4 major players (google, quad9, cloudflare and cleanbrowsing). If you trust them, you are good.
For example, this is the list of providers with DNSCrypt support: https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-...
For DNS over (HTTPS|TLS), there is very little client tools available for troubleshooting. The best one I found was these 2 in PHP:
https://github.com/dcid/dns-over-tls-php-client https://github.com/dcid/doh-php-client
It doesn't require sessions (uses UDP by default, like regular DNS, but prevents amplification), enforces safe cryptography and pinned certificates, is trivial to implement, doesn't need OpenSSL, implements padding without inventing yet another DNS extension, and can use unique keys for each question (so that DNS providers can't fingerprint clients, unlike other options due to TCP sessions and TLS tickets).
Because if not, any requests made by non-browsers are still susceptible and will only give users a false sense of security.
"But this doesn’t mean you have to use Cloudflare. Users can configure Firefox to use whichever DoH-supporting recursive resolver they want. As more offerings crop up, we plan to make it easy to discover and switch to them."
Only defaults matter. Your average web user wont be interested in knowing about or configuring this, no matter how simple the explanation/choice is made.
This does not contain any sort of proprietary or non free software. People are free to ignore the content delivery Network provided recursive resolvers, and set up their own.
Also note that DNS is one of those dinosaur protocols like email and usenet that have persisted from the early days of the internet, back when we could buy interoperable services from decentralized parties. Every service we buy today is centralized or even walled garden only, see Slack, Facebook, App Stores, AWS, etc. We currently just don't know how to build successful distributed ecosystems.
I agree that immediately promoting CF doesn't seem like the best genuine idea for those who are still a part of the Firefox/Mozilla community.
Do not select any default. Randomize the selections.
At the time my only real recourse was to pump my whole house through a VPN, as even Google's DNS (8.8.8.8) was being hijacked, but ONLY when it was coming from my home IP. (Full disclosure, i'm not very well versed in the networking stack. I know enough to get myself in trouble, but not much more. This was what I understood to be happening, but I could be way off base. However it was happening on multiple devices, multiple OSs, multiple verizon IPs, multiple DNS servers, both with and without a router, and would stop instantly if any of those machines were pointed at a wireless hotspot, or a VPN was turned on. At one point I even sent my router's WAN connection through my phone's hotspot and the problem went away)
After talking with verizon many times and each time having to spend an hour or so trying to get through to someone that knew even remotely what I was talking about, all they were able to do was reset my IP, which fixed nothing.
Now that DNS-over-HTTPS is becoming more common, i'm going to use it everywhere I can. Yes, DNSSEC might be a "better" solution, but I can use DoH right now to protect myself on all sites and (hopefully soon) all devices.
Just the other day I discovered Intra [0] a (still unreleased) app by Google for android which has your whole android phone use DNS-over-HTTPS.
I've been running it the last few days and i'm quite pleased with it. Does anyone know of a way to force all DNS queries in windows to use DoH?
[0] https://play.google.com/store/apps/details?id=app.intra&hl=e...
I think you could use pi-hole to do this. https://docs.pi-hole.net/guides/dns-over-https/
A similar setup to mine could be deployed at your network edge, and it could then force all of your port 53 DNS requests to go over a more secure protocol. Of course you would have to figure out how to set this up, and it wouldn't protect your devices anywhere except your home network.
It wasn't FIOS doing it, the IP was in Israel and was known as a malware serving IP.
Most of DNS-over-HTTPS' interesting use-cases start coming into play when you're using the same HTTPS session as the one being used to serve the site you're visiting. Otherwise, DNS-over-TLS is sufficient for the same level of privacy.
At that point though, DNS-over-HTTPS has a provenance issue that I don't fully grok how we're going to avoid. What I mean by that: if the site you're visiting supports DNS-over-HTTPS, where requests to that site for DNS records are requested, what happens when they decide to issue custom responses to DNS requests that ignore or supplement actual data in a zone? Won't that lead to a bifurcation of the DNS network, where web-sites can start issuing custom response to DNS queries?
Cloudflare, and Quad9, both offer DNS-over-TLS, this will be preferable for non-HTTP use-cases. Some of the points in the article imply that DNS when using DNS-over-HTTPS can't be used for tracking you, but really that just means you're passing that trust to Cloudflare, Quad9, or Google. I suppose the choice is open to you at that point.
I was under the impression that DNS-over-HTTPS was nothing more than just an alternative DNS protocol just like DNS-over-TLS, where you perform an HTTPS request in order to query for a DNS name, and that DNS-over-TLS was just plain old DNS wrapped in TLS.
You seem to be implying that DNS-over-HTTPS would enable sites themselves to deliver DNS records. I don't see how that is possible, because connecting to HTTPS with a hostname requires resolving a DNS record. Am I misunderstanding?
s/privacy/&, autonomy/'
Case in point about autonomy is on HN front page at present: https://news.ycombinator.com/item?id=17196888
The author cites a hypothetical example where a user shopping at Megastore is blocked from accessing her preferred source of DNS data in order to prevent her from checking a price.
Extending this hypothetical, imagine if in response to her request for an unbiased price quote the user was shown unwanted ads with inflated, customised pricing (informed by data gathered about her through tracking).
Choice of DNS data is an effective way for users to block advertising and tracking.
The issue with user control over DNS also arises with mobile and other devices (e.g. Chromecast/Google Cast/Google Home) that discourage or prevent a user from using her preferred source of DNS data, forcing her to use a commercially-oriented source which may block certain lookups.
This is relevant with any computer that connects to the internet.
It is an issue of autonomy.
There is a long tradition of HOSTS files and later non-commercial DNS where users can autonomously determine where on the network they want to "go". They have the final control over the source of DNS data the computer will use. They can delegate DNS service to someone else, however, following that long tradition, they still retain the autonomy to choose the source of the DNS data, whether it is another third party, their own DNS servers or perhaps /etc/hosts in place of DNS.
When an organization (e.g. running an "app store") seeks to circumvent the ability of the user to choose her own DNS data source on her own computer, that is an attack on autonomy.
The author mentions that Firefox will allow users to choose their own "DOH DNS" servers. If so, this respects users' autonomy.
(No one seems to be mentioning one obvious advantange of DOH DNS for browsers: bulk DNS "prefetch" lookups. One can use HTTP/1.1 pipelining to retrieve the IP addresses for every hostname contained in an HTML page, with a single HTTP request, instead of numerous, simultaneous DNS requests. As for privacy problems with TLS fingerprints, HTTP requests can be secured by CurveCP as an alternative to TLS - example is in my profile.)
The resolving is not only done for user-initiated action, but is being done by many programs, even which you might not want to do it. For the same reason, many users use a local firewall to block outcoming connections, like Little Snitch.
(Sidenote: if you are using MS Office 2016 for Mac, and are not satisfied with the choice of telemetry that Microsoft offered you in the last update, and you are interested in third option, "None", the hostnames to block are nexusrules.officeapps.live.com and nexus.officeapps.live.com)
With apps using DoH and ignoring the local resolver, that firewall will now have a problem, especially if multiple, separate hostnames resolve to the same IP. Until now, Little Snitch used a guess (last resolved hostname that matches the IP); now it won't have that chance.
That's why, if the user wants to have a chance to who their local processes talk to, they must be forced to use a local resolver under user's control, not implement their private resolver. And of course, on non-public networks, it should be supplie-able by DHCP or RA.
So everytime you want to make a query, you have to wait several RTTs before getting a response.
The connection need to be open for as long as possible, at least 5 minutes.
I used stubby as forwarder with idle_timeout: 6500000, the idle timeout in ms. The connection gets closed by the remote party, not by stubby.
I'll argue that the TCP and TLS handshake take more processing power then keeping the connection open.
Website won't load without allowing a call out to googleadapis.l.google.com
Yeah, you're right they are growing.
Notes 1: I have NO idea if Chrome (or any other random application) accesses DNS-over-HTTPS already since I have not paid too much attention to it.
2: At least Chrome (on OSX) likes to access 8.8.8.8 & 8.8.4.4 & your configured DNS server on port 53 (happy eyeball protocol). This might only be on flaky networks like mine, where I tend to make all sorts of configuration experiments.
and of course defaults matter a lot, but you will be able to select your preferred DoH endpoint (or not use it at all). Firefox wouldn't lock something like that down.
I think encrypting DNS transport is as important as the next guy (though DoH is bad), but am super unhappy about Mozilla apparently signing on with Cloudflare's ongoing fairly successful attempts to centralize the internet. Sure, they say they'll delete your data "within 24 hours" (they shouldn't be keeping it at all), but pretty soon they'll get a Nat'l Security Letter like everyone else does.
In any case, it would be unreasonable to require logging for more than that... even a week would be too much data for many ISPs. Also, they have to have some logging to be able to even try and troubleshoot a problem.
And what about SNI that shows domain name in clear text for HTTPS connection? Please do something with it too.
Having an opt in security mechanism is easy to deploy as in keeping the http version of a site available while running https on a new port for clients that want to use it.
But there are alternatives, DNS over TLS (essentially the same without HTTP) and dnscrypt which uses UDP.
You can connect using an IP address. At least to bootstrap the process. This is where DNS Stamps come in handy https://github.com/jedisct1/dnscrypt-proxy/wiki/stamps
Well there goes the interest I had in this.
(also, 1] dns leaks are worse than sni leaks as typically more people are exposed to the dns query and 2] HTTP/2 can carry more than one hostname on a connection so some hostnames that appear in dns are never leaked through sni.)
I don't see any way to have encrypted SNI without paying a price of one additional round trip. That's a fair price for something you must have, but for anybody to benefit we must insist everyone use it always, or adversaries will simply block it. And a round trip is a high price for users who don't (believe they) need this.