NextDNS Joins Firefox’s Trusted Recursive Resolver
blog.mozilla.org
blog.mozilla.org
It sounds more like the work is to put Mozilla and their partners in control of users' data and privacy online.
Let's be honest. This is really a transfer of control from one third party, e.g., a company providing internet service (ISP), to another third party, e.g., a company/organization providing a browser (Mozilla, Google, etc.), not to mention their "TRR" partners.
Surely it is only a fortuitous coincidence, but DOH in the browser makes it easier to track users by device, which appears to be the Holy Grail of the internet ad industry.
Putting Mozilla (and their partners) in charge of user privacy is different from putting users in charge of their own privacy.
Also, the "back in control" language is interesting. It implies the author believes users were "in control" in the past.
Users never really had a reasonable (ie. non geek) opportunity to be in charge of their DNS privacy, and for most it's not something they can be bothered with.
Users can have end to end encrypted DNS and browsers shouldn't be hijacking it.
To put it another way, you don't want the people who only care about eyeballs (Google, Mozilla, etc.) picking your DNS provider.
> Your DNS data can reveal a lot of sensitive information about you, and currently DNS providers aren’t subject to any limits on what they can do with that data; we want to change that. Our policy requires that your data will only be used for the purpose of operating the service, must not be retained for longer than 24 hours, and cannot be sold, shared, or licensed to other parties.
https://blog.mozilla.org/netpolicy/2019/12/09/trusted-recurs...
https://wiki.mozilla.org/Security/DOH-resolver-policy
(Disclosure: I work for Mozilla, but not on this)
The Mozilla TRR policy states that the DNS provider must not filter any queries unless the user explicitly opts-in.
How would a user selecting NextDNS as a TRR indicate that she wants NextDNS to filter queries in order to block ads and tracking.
The TRR policy also states that the provider must not use the EDNS Client Subnet extension. It looks like NextDNS does use some modified version of ECS, at least in its plaintext DNS service.
The FAQ states users can submit a query with class CHAOS instead of IN to get some diagnostics, e.g.,
drill -t example.com @45.90.28.0 a chaos
On the other hand, the Mozilla Corporation clearly is desperate to find alternate sources of funding.
Some of the public transit I've been on disagrees strongly with VPNs because they do heavy traffic shaping and VPNs fall into the "make this really slow" category. Reasonably so.
I also disagree with this advice. For myself and the vast majority of people $5/month is not worth it for the negligible difference in security and privacy over https, and DNS over https. This becomes even more true with encrypted SNI.
In fact, a VPN is largely worse privacy wise because "random coffee shop internet with random MAC address" is pretty anonymous unless you sign into anything over http.
You don’t ? Why would you sign up with such an ISP ? My ISP has a very clear privacy policy, and they obviously have to comply with the GDPR as well.
In America there is a vast number of countries with varied service providers, and Internet and data protection laws.
I have to wonder: is anyone actually regularly auditing these companies to make sure they abide by their privacy policy?
I see lots of privacy policies all over the internet, but absolutely zero oversight.
And I will surely not allow some firm in a country with vague laws allow to do all my name resolution. Not to mozilla, not to google, not to cloudflare or anyone else (currently running unbind with caching on huge list of DNSs all over EU in random order).
ISP? They are obligated to follow the law in my country. Spying on its user would make it a criminal offense investigation, potentionally bringing their management behind bars. No, they wont even try, it is too dangerous for them.
I trust my ISP way more than mozilla. Based on law in my country. It is not DNS system to change (actually it is but convincing me that adding ssl layer on top of highly efficient protocol is worse than rolling everything trough https and changing all existing systems? I'll pass, sounds like a complex solution for simple non-problem, I am sick of looking on those in last decade), it is a law in YOUR country that allows your ISPs to spy on users and this is something that needs to change.
Incidentally, Mozilla is showing interest in embedding Tor in Firefox [1], but they haven't yet publicly commited to it [2].
[1] https://www.zdnet.com/article/mozilla-offers-research-grant-...
[2] https://www.techradar.com/news/firefox-isnt-getting-a-tor-pr...
The "putting users in control" phrasing is classic Mozilla doublespeak marketing; Mozilla wants you to think Firefox is the only web browser under your complete control, when a look at their bug tracker and their reaction to all the changes that users have vehemently opposed shows the complete opposite --- a small number of Mozilla employees are the ones making all the decisions. Maybe their interests align better with yours, but they are just as authoritarian-control-freaks as all the other big browser vendors (or indeed, it seems all software companies in general these days.)
DoH behaves like only tunneling DNS over a VPN, and I wouldn't mind Mozilla working on VPN software, but IMHO something like that should really be a separate product (and one that not only their browser can use --- like most other VPN clients in general.)
With Firefox 69, they broke 25% of the internet on Linux with a change to block what they call a MITM attack: Corporations and anti-virus software that add certificates to your computer to decrypt SSL traffic before passing it on to you. That's privacy-focused, I suppose?, but is a confusing change in comparison to more obvious victories such as blocking trackers and fingerprinters by default. Which they will certainly never do... until Google invents a technology that provides the same functionality with a different, less ominous name than "browser fingerprinting."
I run Unbound and Pi-Hole to do my own recursive resolving. Like a normal wireless router doing all the DNS lookups for its DHCP clients, Mozilla has no idea which particular device on my network is accessing duckduckgo.com. Once each browser happily sends requests to Mozilla, then on to NextDNS, there's a whole lot more data suddenly available to commingle in a data lake... The efficacy of browser fingerprinting means they won't even need cookies to distinguish between devices in those HTTP headers.
As far as I know, good ol' Insight Communications (then Time Warner, now Spectrum) made money from selling me access to its high-speed internet service, and running ads on failed-to-find-your-website DNS hijacks. Heck, most of its money probably came from upselling people to buy bundled VoIP landlines and premium cable packages--whatever tiny slice of revenue came from those lookups surely pales in comparison to tens of thousands of unused phone subscriptions.
For all the commenters here who think that Google and the other major tech companies are somehow more trustworthy than your ISP? Yeah, I just can't agree with those opinions.
Edit: Less trustworthy should have been more trustworthy.
Additionally, at least my ISP is doing business in my state/country, so there may be _some_ legal recourse if they screw me too hard.
Otherwise, you have much bigger problems than DNS.
As documented by Mozilla, I made my network's DNS have use-application-dns.net return NXDOMAIN to opt out.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
My unbound config line is:
local-zone: "use-application-dns.net." staticDisabling on a per-client basis probably has an about:config setting, and I just checked and saw a UI setting under Preferences -> Connection Settings -> Enable DNS over HTTPS.
The world is hella lot bigger than the US.
And Firefox runs in the rest of the world too.
But Firefox only enabled DoH by default in the US.
This is configurable via group policy.
That's Windows-only mechanism.
> Households (keep in mind we are only talking about people who knew enough to change DNS settings in the first place) can just change the setting on each of their five or so computers.
And not forget to do that for every new device they get. And after reinstalls. And occasionally just to be sure, as we know how software tends to "forget" user preferences sometimes. That's all only up until Mozillas' telemetry will show, that nobody changes the default anyway, so the preference will be removed entirely.
> And if you are using DNS as parental controls, that's not a great solution as nothing stops someone from getting the IPs out of band (ex. a website that does DNS lookups) and connecting directly to the blocked sites.
For the user, it's more complicated than that. He has to persuade the browser to send the right Host header when connecting to the obtained-out-of-band IP address. If you have rights to modify hosts file, you might change the DNS as well and spare the effort.
You are assuming a rather narrow use case for "parental controls". For many people it is less about draconian control and more about not wanting someone (whether a child or the individual themselves) from accidentally stumbling on porn or other unwanted content.
That means my network-enforced DNS preferences that block ad and malware sources are ignored, and I see more ads than I want to. It also means that when Google drops support for my Chromecast model like they did with the older Chromecast models, I'll be slightly less secure than I would be if I could enforce my own DNS preferences.
I have a Chromecast. I also redirect all port 53 traffic (DNS) back through my own DNS server at the firewall level (does not go to Google DNS). It works perfectly fine wihtout directly using Google DNS.
Yes, they do ignore the DNS set by DHCP, but that can be worked around.
If you're worried about your recursive DNS resolver spying on you, the correct solution is to run your own recursive resolver.
I've been running unbound(8) on my OpenBSD systems at home for most of 2019, and (except for the time that I experimented with turning on strict DNSSEC checking) there hasn't been even one time that it has caused me grief. It was as simple as "rcctl enable unbound".
And OpenBSD has recently introduced unwind(8), a dead-simple recursive resolver (using libunbound) that's suitable for any system (even laptops that sometimes use broken Wifi access points or networks that block outbound port 53).
It is simply unacceptable for a modern operating system to lack its own recursive resolver. By all means, allow the network administrator to configure the system to use a network-provided resolver if required, but the default ought to be an intelligent unwind(8)-style resolver provided by the OS itself.
Running your own recursive DOH server is a fine idea, and easy to do, but then you have little to be angry at Mozilla about, because they're the ones enabling you to do that.
The fact that no mainstream consumer OS runs a local recursive resolver should be a clear signal to you that people disagree with you about this; in particular, because doing so eliminates DNS caching, which is something most people want.
People are "extremely focused" on DOH because it works, and works without having to secure the cooperation of every DNS operator on the Internet, and with almost no configuration. It is a clean, easy win, unlike every other DNS security mechanism ever proposed.
Doesn't DoH eliminate caching as well? It means all your queries go out to some server on the internet with perhaps 20-50ms of latency, instead of a local cache potentially on your LAN with <1ms. A DNS cache on the LAN would also merge queries from multiple devices, concealing which device is making the query and in many cases preventing the query from having to be sent over the internet at all.
The best thing might be to have internet gateways run a DNS stub that itself makes queries via DoH/DoT/whatever and then caches them for every device on the LAN. The gateway is typically the DHCP server so it can hand itself out as the DNS and requires no configuration as well. And then it works across all devices and applications.
Why would it eliminate caching? If you resolve over DoH you can still cache. It's not like turning DoH on in FireFox forces it to stop caching.
DNS can have arbitrarily many levels of caching, because stub resolvers can be caches and can point to other stub resolvers.
For example, you might have a DNS cache in your OS so that if more than one process asks to resolve the same name (or the same process asks more than once because it doesn't have internal caching), only one query has to be made. That resolver may point to a DNS cache on your LAN (deduplicating queries between devices), which in turn may point to a recursive resolver on the internet, which may itself be caching data from the authoritative servers.
If you replace that with DoH between the application and the recursive resolver on the internet, all the intermediary caches are eliminated, even though they might have had significantly lower response times than the resolver on the internet.
And the problem isn't the protocol here, it's the choice of resolver. If the resolver on your LAN made queries using DoH instead of the application itself then your ISP still couldn't read them, but you would regain the benefits of local caching.
Firefox historically being slower than Chrome was for a long time one of main reasons cited by people who switched from Firefox to Chrome. DNS/proxy defaults were certainly not the only reason it was slower but all the little things add up.
And we shouldn't need to use user complaints to gauge performance impact when we can do so directly by measuring page load times etc.
Caching or not should never "break anything" unless you've seriously screwed up. It's always a matter of the performance impact. Which users will regularly gripe about without being able to articulate what's causing it.
The practical impact of this depends on the context. If your browser is running in a data center across the street from the DoH server with a 3ms round trip latency and you're making a single query, it'll be imperceptible. When your internet link has a 50+ms latency and you're making multiple queries (which may have serial dependencies), it quickly adds up to hundreds of milliseconds. And some people are on satellite links with 500+ms latencies where this matters a lot.
A properly-configured resolver (i.e. one that is doing QNAME minimisation) only reveals a very limited amount of information to each DNS server that it queries. It's akin to the fact that browsing a web site reveals my activity to that site's origin server. I'm not overly concerned about it.
The only threat that DoH protects against is the situation where an adversary is able to observe all of my outbound DNS query traffic. In this very specific scenario (essentially a compromised ISP), then yes, DoH offers better privacy protection. But it's a rather Faustian bargain to make, because in order to receive protection against a malicious ISP, I must instead put my full trust in whomever is operating the DoH resolver. Out of the kettle and into the frying pan, isn't it?
So DoH doesn't solve the problem. It merely lets users transfer their trust from their ISP (with whom they have a legal contractual relationship governed under the laws of their home country) to a large third-party organisation (with whom they do not have a legal contractual relationship).
If it came down to a matter of holding someone to account for a breach of my privacy, I'd sure rather be up against my local ISP as opposed to a faceless global entity such as Google, Cloudflare, or even the Mozilla Foundation.
I think Windows might do something close. DNS client requests are cached on a per-machine basis through the DnsCache NT service. But I do not think getaddrinfo() and friends talk to that service via DNS, so strictly speaking it is not a recursive DNS server, though the resulting behavior is largely the same as if it were.
The former lets the system reach out to an upstream resolver and caches the results. By contrast, a recursive resolver is responsible for starting at the root zone and recursing downward from there to resolve the requested domain (so when processing a query for “foo.example.org”, the recursive resolver queries “org”, then uses the NS records returned to query “org.example”, then uses the returned NS records to query “org.example.foo”)
Not saying it's bad to run unwind, just that if the scenario is that the router blocks access to root servers, and the local resolver spys on you - it (alone) won't help?
And with a spying local resolver, I'd assume the router logs plain text udp traffic anyway...
It becomes necessary to connect to some remote computer you control that can send traffic on port 53 just to send an authoritative DNS query. It is like having to pay two ISPs now instead of one.
What are the "free" workarounds. There are free-trial DNS "relocator" services and DNSCrypt resolvers running on ports other than 53 (I am not aware of any authoritative servers running behind dnscrypt-wrapper). Now there are also "DOH servers" running on port 443, serving resolver responses via HTTP. One unique feature of DOH -- for those doing bulk lookups -- is that one can query multiple names with a single packet. That is not possible using the DNS protocol.
For folks who are stuck with port 53 filtering, as a temporary solution, I would like to see more remote DNS servers, both recursive and authoritative, running on ports other than 53. They do not have to be "relocator" services, encrypted or served via HTTP. They just need to use ports other than 53.
Then, when running a local resolver, the user can set it to forward queries to a remote one listening on a non-standard port or she can query authoritative servers directly, e.g., root or .com servers, using stub resolvers.
It is every internet user's right to be able to query the authoritative servers for a domain's IP address -- whether from her own local resolver or from a stub, the same way it is to request access to a public zone file. Filtering port 53 is unacceptable. Otherwise, we are allowing third parties to become the absolute gatekeepers to the sources of authority for finding an IP address. Caches are not authoritative sources of DNS data.
In theory this is what DNSSEC is meant to provide: cryptographic proof that the cache is giving you unmodified data from the zone's authoritative server(s). Unfortunately... it's still very difficult to run a recursive resolver in a "hardened" configuration that strictly enforces DNSSEC validity, and that's without having a potentially-malicious cache in your query path.
The reality is that most networks blocking port 53 are also entirely unaware of DNSSEC, and in such a situation there's really no hope aside from a full-fledged VPN -- or DoH.
So I think DoH absolutely does have some use cases, such as clients using broken hotel/conference networks and laptops that are temporarily using insecure public WiFi access points. But it doesn't belong anywhere near my own, properly-configured home and work networks.
Then there are computers like Chromecasts with hardcoded DNS servers and Apple devices with inaccesible HOSTS files. This sort of design takes control from the user and puts it with the company. Net/Free/OpenBSD still offer a reasonable level of control for those users who want it.
The way it was introduced, DOH seems inextricably linked to one application. It is 100% browser-centric. I hope that will change. The internet is more than just a medium for a commercial web. Maybe people will start HTTP tunnelling more than just DNS.
As for DNSSEC, it only makes sense to me if one is sharing a cache with others. If it is not a shared cache, if the user has her own caching resolver that connects directly to authoritative servers, then IMO most of the reasoning behind using DNSSEC is gone.
What is interesting about some of these DOH comments is that it appears some folks do not want the operator of an authoritative DNS server to know they are sending a query. It seems they want to "hide" behind a third party cache, assuming that is even possible.^1 That sort of "privacy" is not something I care about. I want to cut out the third party DNS middleman. I prefer to query authoritative servers directly without using a recursive resolver (either local or remote), using custom programs I wrote; this is much faster than using a cold cache.
The issue for me is control not "privacy". That is the point of the original comment I made about the Mozilla press release. Even NextDNS' FAQ admits a user-managed solution (the example they use is a PiHole) is superior, in terms of "trust", to one managed by a third party, such as NextDNS.
1. I would bet some of the folks complaining about privacy leakage in DOH are using a third party cache that sends EDNS Client Subnet, like Google Public DNS. IMO, if someone is really intent on keeping their DNS lookups private, then the most effective way is to avoid making remote queries. Get the DNS data in bulk and put it in a HOSTS file, a local zone file, "local-data:" in an unbound.conf, etc. There are zone file access programs, public scans and now DOH (outside the browser, via HTTP/1.1 pipelining).
This seems like a win overall, and I'm glad that they're pushing to build a list of trusted resolvers. It sounds like they've got some sort of contract ensuring they don't use the data, so that's a positive.
That said, given that Windows 10 is going to going to start supporting DoH natively, I'm not sure I understand the reasoning to use Mozilla's chosen DNS providers, rather than the system default.
It seems a bit like enabling a proxy or VPN by default- Even if Mozilla trusts the proxy provider, routing traffic to unneeded third parties seems somewhat user-hostile.
> The following providers have contractually agreed to abide by these policy requirements: [Cloudflare, NextDNS]
Are these agreements made public?
In other words, I would add some canary that nobody forced them to break rules of those contracts.
That said, I'm surprised Mozilla doesn't look at the uptime metrics before partnering with TRRs. I've been using NextDNS ever since it was announced here [3] and have been subject to a fair share of "outages" including once when everyone at home thought the internet was down...but couldn't remedy it [4].
Cloudflare's data-plane availability with 1.1.1.1 is a tall-order to match for anyone that's not Google or AWS [5]. The NextDNS founders built DailyMotion, so I'm guessing they know a thing or two about high availability and hopefully fix whatever they need to before they GA with Firefox TRR.
I must point out that Adguard DNS [6] is a viable non-configurable free alternative, which is what I now recommend to folks not savvy/bothered enough to configure NextDNS. It would be wonderful to see them added to TRR.
[0] https://news.ycombinator.com/item?id=21543038
[1] https://news.ycombinator.com/item?id=21604825
[2] https://news.ycombinator.com/item?id=20851626
[3] https://news.ycombinator.com/item?id=20012687
[4] https://news.ycombinator.com/item?id=20785712
[5] https://aws.amazon.com/blogs/architecture/category/networkin...
I observe normals hitting same “WTFs/month” rate with AdGuard, NextDNS, Zscalar, Cleanbrowsing (built into Ubiquiti UniFi), as any other ad blocking DNS offering.
I personally had to give up on Warp+ and even 1.1.1.1 — which to be clear does not block ads or trackers — due to instability with enterprise, airline, and hotel portals.
By contrast, NextDNS shot up in reliability over past couple months across all kinds of connections, to where I’ve begun recommending that option to tech friends (not yet to normals).
I have had no issues with OpenDNS Umbrella now Cisco once I turned off their typo-squatting, but it also is a “security” product not anti-tracking.
I'm sure they've improved but I was bit by downtime as recently as a week ago. Due to their custom proxy-layer that enables the blacklisting magic, on top what seems like a multi-tenant DNS resolver backed by unbound, their anycast setup, redundant network paths, multi-region server deployments are not going to mitigate downtime due to software bugs. Imo, DNS resolvers must be low latency and zero-downtime, by design.
Adguard, I'm speculating, do not have the complexity that NextDNS does (no multi-tenant smart proxy fronting the actual DNS resolver), and so do have a better chance at getting availability and latency fixed sooner?
> I personally had to give up on Warp+ and even 1.1.1.1 ... due to instability with enterprise, airline, and hotel portals.
I'm curious, what instability? I have faced issues with (free) Warp where it can't / won't bypass government imposed censorship. And streaming apps like Netflix refuse to work.
Randomizing over three providers will give each of them one third of your requests, but they would just need more time to get a (near) complete list of the domains you resolve. Eg, if you resolve hackernews once a day, they'll each have that information in approximately three days.
whats to prevent a VC firm from just...quietly acquiring NextDNS (or any of the other DoH providers) and selling your browse history back to anyone who wants it?
edit: Yes, it is with contracts. https://wiki.mozilla.org/Security/DOH-resolver-policy#Confor...
I am appalled.
From their site: https://nextdns.io
> See what's happening on your devices with in-depth Analytics and real-time Logs.
> Protect your kids and control what they can access online.
Their pricing page is also extremely troubling.
> We may adjust this later on based on actual costs at scale, but it will follow this logic.
What the hell is this Mozilla... This is not a company you should be dealing with. They tell you up front that they log and monitor... They also aren't at scale, and have to learn lessons the hard way with outages.
Mozilla is dead to me now.
Edit:
As others have pointed out, Mozilla's own policies: https://wiki.mozilla.org/Security/DOH-resolver-policy
Transparency Requirements, section 2.
Where on earth is a transparency report for NextDNS? They were started in March, and I would think that Mozilla would check their requirements before giving the 'lets add them.'
Yes, god forbid some parents would like to have a little bit of control and the ability to protect their children from seeing obscene material when they're too young to handle it.
Evil! Mozilla needs to quash these terrible people! May they burn with Brendan Eich!
Still, if your goal is to block your kids' access to things, DNS is a good place to do it. Works across all your devices and doesn't require any install.
Good jumping off point for this.
How do you prevent the ISP from logging those requests to the root?
Or actually, they might still, using side-channel attacks, but it's significantly harder to accomplish, especially at scale.
We should be skeptical of aggresively-enforced DoH. In most cases, the vendor's interest in stopping ad blockers is stronger than their interest in protecting user privacy. Mozilla is slightly more removed, but as they're dependent on The Big G for revenue, we're basically just waiting for that shoe to drop.
That doesn't mean I want to raise bigots, it just means I want to do what I can to ensure the narratives being pushed on my children are wholesome ones that will help them to grow up to be useful, contributing members of society and parents as well.
Maybe you don't care about that for your own kids; that's on you, champ. I'm not arguing for anything censoring anyone else, or anyone censoring what any adult reads.
That's why companies have to exercise moral taste when they do a blanket ban on moral obscenity, and that's precisely the kind of product that people mean to purchase -- curation and tastefulness. It's also why it's interesting for people to fight over this, because they're fighting over a policy of scale as opposed to what goes on in one single home.
And presumably this company would later be interested in dealing with schools and other big institutions, which means their product takes on yet another critical dimension, which is the re-allocation of responsibility for making morally tasteful decisions.
In both B2C and B2B, the refusal to exercise moral perspective, taste, and curation is missing the soul of the product. But of course not all areas of tech is for everyone; some people don't wish to work with advertising companies, and that's fine too, but advertising companies likewise make policies of scale and must exercise moral and political taste.
I'm trying to bolster the point that they are promoting logs and more importantly, blocking DNS queries.
How can I trust the DoH endpoint if I know they have an active product whose purpose is to log and not give back the requested IP.
The pricing model is certainly troubling though.
> We may adjust this later on based on actual costs at scale, but it will follow this logic.
>We will accept credit, debit and prepaid cards, PayPal, cryptocurrencies and other popular payment platforms.
In what sense is it troubling? I have never looked at a DNS pricing page before today, but this looks reasonable...
Also I suspect that in that case NextDNS would just send you to their own page a la WIFI login page.
Their privacy policy is pretty straightforward: https://nextdns.io/privacy
Not saying this is going to be good, but at least I'm going to withhold judgement until I've got more data.
> They also aren't at scale, and have to learn lessons the hard way with outages.
Is that a reason you're upset about? Is that a certainty? I don't get it.
I value dry jokes such as this.