NextDNS Joins Firefox’s Trusted Recursive Resolver
blog.mozilla.org“For most users, it’s very hard to know where their DNS requests go and what the resolver is doing with them.” said Eric Rescorla, Firefox CTO. “Firefox’s Trusted Recursive Resolver program allows Mozilla to negotiate with providers on your behalf and require that they have strong privacy policies before handling your DNS data. We’re excited to have NextDNS partner with us in our work to put people back in control of their data and privacy online.”
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.
I could never think of why Mozilla and friends are so aggressively pushing DoH, but I think you nailed it when you pointed out they can tie a specific device's DNS requests to its other data.
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.
> For all the commenters here who think that Google and the other major tech companies are somehow less trustworthy than your ISP? Yeah, I just can't agree with those opinions.
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.
Your country can also put other obligations on your ISP, such as censorship and data logging.
My country, as most democracies, do that because we the people want them to do it.
Otherwise, you have much bigger problems than DNS.
DoH is only available in the U.S. for Firefox users as far as I'm aware, so all of the people who might be "screwed too hard" have legal recourse.
It's available everywhere; it's just only enabled by default in the U.S.
No it's available everywhere. It's a pref. The default if you haven't set the pref differs in the US.
For now.
> I run Unbound and Pi-Hole to do my own recursive resolving.
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." staticIf Mozilla were actually serious about giving users control, they'd make this easier to configure.
I think this is pretty easy and appropriate for what it does. (Since my home DNS server is offered via DHCP to the LAN, it disables for the entire network without having to configure each client.)
Disabling 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.
It's about trust: would you rather trust your ISP, or Mozilla's choice of DoH partners?
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.
I am mozillas diehard fan as firefox goes but I DO NOT trust them. I still remember some company with best search engine that got vapirised over the years and I am not prepared to trust anyone. Mozilla has some shady practices with their "research add-ons" and I am blocking their domains from firefox and using another browser to download addons.
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.
This is the wrong dichotomy and it's a false one perpetuated by Mozilla.
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.
So disable DoH in Firefox, or change the provider? If you know enough to choose a DoH provider, the browser defaults are not very relevant, presumably.
That's great for the handful of people that read Hacker News and understand DNS, it's a trash solution for the rest of the world. Defaults matter because they are rarely changed.
Right now the defaults are unencrypted DNS handled by ISPs which in the US have explicit legal permission to sell your data.
My ISP, since I have a contract with them, I can switch to another ISP anytime, and they are bound to lots of data protection laws.
On the other hand, the Mozilla Corporation clearly is desperate to find alternate sources of funding.
You have a contract with your ISP not to collect and monetize your DNS queries to their DNS servers? Are you in the US on a mainstream ISP? If so, you surely do not, unlike with the Mozilla TRR program, where you in fact do.
> You have a contract with your ISP not to collect and monetize your DNS queries to their DNS servers?
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, at least, there are only one or two high speed ISPs in any area: and so, unless you want to use DSL or satellite or something and deal with latency/speed issues, you basically pick whoever is fastest for the best price
The DSL & satellites are also monetizing your DNS traffic in most cases.
s/America/the USA/.
In America there is a vast number of countries with varied service providers, and Internet and data protection laws.
"My ISP has a very clear privacy policy"
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.
Often, I don't have a contract with my ISP. Since my ISP is a random coffee shop, the public transit provider, or so on.
You should be using a VPN in a random coffee shop anyway, not that I particularly like how falsely advertised those are, and their security (Nord cough cough), still it's usually better than nothing.
It doesn't matter what I should do, it matters what a random firefox user who finds themselves in a coffee shop is doing.
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.
Probably the ISP, since it already has a working business model unrelated to selling your DNS query data and doing so is probably illegal in several countries.
The terms of the Trusted Recursive Resolver program explicitly disallow selling your DNS query data.
> 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)
NextDNS purports to be a DNS provider that will use public blocklists and filter queries and block ads and tracking like a PiHole.
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.,
Unfortunately, someone who ISP is filtering port 53 cannot make this query.drill -t example.com @45.90.28.0 a chaos
If you're in the US, read your ISP's privacy policy sometime: part of their business model involves selling the data about the sites you visit.
Having a steady revenue stream has not stopped many companies from also selling user data. See: ads in Windows, smart TVs, cell carriers selling location data, etc. The list goes on... Why would ISPs be any different?
Also, the "back in control" language is interesting. It implies the author believes users were "in control" in the past.
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.)
I didn't fully understand the cognitive dissonance and Orwellian doublespeak going on in Mozilla until I began researching the jabs n-gate's author embeds into everything he writes concerning the company. Beacons, Google's Safe Browsing lists, etc.: None of those defaults line up the company's actions with its branding.
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 think the endgame is to route everything through Tor or a similar anonymizing layer, nothing else will suffice in the face of pervasive tracking.
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...
I was under the impression this work was already underway. https://wiki.mozilla.org/Security/Tor_Uplift
Brave has a better track record and Tor built-in: https://brave.com/
I'm not sure how I feel about Firefox's strategy for DoH. On the one hand, moving DNS out of the hands of ISPs that (at least in the US) have no real incentive to respect user privacy is probably a good thing. On the other hand, circumventing the system DNS will cause problems for anyone who has explicitly configured DNS, such as corporate networks, schools, households that use DNS for security/adblocking/parental controls, etc. I realize firefox has some heuristics to try and detect these cases, but heuristics aren't perfect.
It's probably a good thing? US ISPs actively collect data from DNS lookups. They're an actual according-to-Hoyle threat actor in the IETF's supposed threat model.
> It's probably a good thing? US ISPs
The world is hella lot bigger than the US.
And Firefox runs in the rest of the world too.
> And Firefox runs in the rest of the world too.
But Firefox only enabled DoH by default in the US.
Is it only enabled in the US, or is it only enabled in the en-US build? How does firefox actually know what country I'm in? If I downloaded firefox in Washington and then drive up into BC, does Firefox disable DoH? How does it know?
It's also a lot bigger than the EU.
Enterprise use cases can easily manage this through Group Policy. 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 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.
> Enterprise use cases can easily manage this through 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.
> 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
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.
> circumventing the system DNS will cause problems for anyone who has explicitly configured DNS, such as corporate networks, schools, households that use DNS for security/adblocking/parental controls, etc.
This is configurable via group policy.
Sure, if all the machines you care about are windows boxes managed with Active Directory. There are ways to configure it on linux and mac too by putting a json file in the firefox installation folder, but it is one more thing IT needs to worry about. I don't know of any IT professional that would be excited at the prospect of having to configure DNS for individual applications.
They can just configure their internal DNS server to return NXDOMAIN for use-application-dns.net, which is a canary domain that Firefox checks before using DoH: https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
I'm a fan of DoH, but I'm also a Chromecast owner, so I get to experience the downsides of application-level DNS resolvers. Chromecasts will ignore the DNS servers set by DHCP, and will cease to function if they cannot communicate with Google's DNS servers[1].
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.
That's more of a result of the fact that Chromecast is a locked-down, proprietary platform that doesn't allow you to reconfigure it. In fact, it's not really application-level DNS if the entire Chromecast system uses it, it's just hardwired to servers that you can't change because its not an open platform.
What Chromecast devices did they drop support for? I have a Gen 1 Chromecast and it still works just fine.
Gen 1 Chromecasts will not receive any new updates from Google, but will continue to function.
Oh wow I did not know that.
I believe you are referencing possibly old data.
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.
AFAIKT, you can block Google DNS and all your Google Cast devices should fallback to DHCP assigned DNS.
Oh, good to know. I just let it think it's using Google and like redirecting it behind the scenes
This is accurate. I drop all of my google gadgets access to google DNS services and they use my local DNS.
Which model Chromecast do you have?
2nd gen
This extreme focus on DoH is really concerning me.
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 non-DOH recursive server does absolutely nothing to protect your queries from snooping; in fact, it increases your exposure, because every single step in the recursive queries you run are now in plaintext on the wire and each attributable to your server.
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.
> 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.
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.
Doesn't DoH eliminate caching as well?
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.
In that sense neither would putting a recursive resolver in your OS.
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.
I'm not quite following all of this but before I try to sort it out in detail, is the fundamental objection here 'a DOH-using app is not using the OS resolver'?
That is effectively what causes the issue. The local resolver in the OS or on the LAN may have the name cached (because some other application or device requested it previously) and is thereby able to respond in <1ms, but if the application doesn't use them it has to take a round trip to the internet.
Ah I see. I don't find it particularly convincing as a thing leveled at DoH specifically because apps have been doing this for years. Browsers, Electron apps, Unity apps, whatnot. All have lived happy and successful lives without lookup latencies or the internet-as-we-know-it suffering any obvious ill effects. It's not a meaningful critique of DoH because we know the problems the critique warns of haven't really been problems.
You're naming some things that have notoriously bad performance. Being slow doesn't guarantee failure but it sure isn't a feature.
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.
They don't have 'notoriously bad performance' because of DNS or lack of some sort of global DNS caching. That just isn't the case. Firefox also didn't honour systemwide proxy settings for a decade+, nobody really cared because it fundamentally didn't matter. If the DNS thing was that important, somebody would have complained about it before. Nobody (statistically) ever did, any more than they did about the proxy thing.
Sure, they had notoriously bad performance for a plurality of reasons. Which also explains the lack of specific complaints. People can tell you that it's slow, that doesn't mean they can tell you every reason why.
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.
I mean, we started with 'does DoH break caching' to which the answer I think is quite clearly 'no' and we're now on to 'do apps doing their own resolving break anything materially important' to which the answer I think is also 'no' and yours is a pretty unspecific 'maybe'. I don't think these are bad or unwarranted questions (a lot of the anti-DoH arguments are significantly worse) but I'm fairly confident they have a straightforward, empirically-supported negative answer.
We started with "does running your own recursive resolver break caching" to which the answer is yes, because it removes intermediary caches that can really improve query latency. It doesn't have to remove 100% of all caches to make caching much less effective. But having the browser bypass local caches and query directly to the internet (entirely regardless of DoH or not) does much the same. The last level cache on the local network is particularly significant because it should have the best hit rate of any cache before the query latency gets multiplied by a factor of 50 or more by going out to the internet.
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.
Running a recursive resolver does protect against one very specific kind of threat: a malicious recursive resolver that has decided to log all of my queries. DoH absolutely does not protect against this specific threat, because it's just a different protocol for speaking to a third-party recursive resolver.
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.
> no mainstream consumer OS runs a local recursive resolver
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.
I think there’s a differentiation here between a local DNS cache (which does exist on some consumer operating systems) and a local recursive resolver.
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”)
Yeah ok, that's a difference I hadn't thought of. In most local caching servers the next hop is going to be the ISP or similar, rather than going to the root.
If the user is sitting behind a filtered port 53, e.g., at a hotel, running her own resolver will not solve the problem. This filtering of port 53 may be growing in popularity among ISPs. If it is, then that means users cannot easily choose their own source of DNS data.
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.
> 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.
Building DNS resolution into applications, bypassing the OS, is not something I like as a user. It robs me of control. Chrome started down this path and then withdrew. However Golang seems to encourage building applications that do their own DNS resolution.
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).
Hm, looks like unwind just falls back to letting the local recursive resolver spy on you in case port 53 is blocked, though? I guess it + local recursive resolver between them might have bit of a cache - but the browser could also cache dns more aggressively (not that I think that'd be a good idea).
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...
> Our trusted recursive resolver program aims to standardize requirements for three areas: limiting data collection and retention from the resolver, ensuring transparency for any data retention that does occur, and limiting any potential use of the resolver to block access or modify content.
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.
Interesting, I wasn't aware of Mozilla's Trusted Recursive Resolver program (https://wiki.mozilla.org/Security/DOH-resolver-policy).
> The following providers have contractually agreed to abide by these policy requirements: [Cloudflare, NextDNS]
Are these agreements made public?
Gov agencies requests still take precedence over any such agreements don't they?
In other words, I would add some canary that nobody forced them to break rules of those contracts.
Congratulations NextDNS! You've been relentlessly executing on every front [0] with super-novel solutions [1] that a few, if any, incumbents have matched [2].
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...
It’s not clear to me AdGuard’s uptime avoids the “is the internet down?” scenario either.
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.
> By contrast, NextDNS shot up in reliability over past couple months across all kinds of connections
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.
Mozilla is yet to announce an actual application process for becoming a TRR. I've been trying ever since they announced CloudFlare, but they only have a policy - no application process.
Is there going to be an option in FF to select which “trusted partner” to use? And an option to use a provider not in their list?
Or an option to randomize it per request with the ability to remove / blacklist specific partners. Now that would be great.
Not sure that randomizing is going to do anything useful.
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.
You could deal with this by splitting requests based on the domain to be looked up on a deterministic basis, so that the same lookups always go to the same server. You'd ideally do that in such a way that related lookups (eg everything under google.com and all of Google's other related domains) also go to the same server.
There already is in advanced network options I think?
yes. And "trusted partner" just means they have preconfigured settings in the drop down. It's also possible to specify a custom DoH provider (or disable DoH).
So im curious to know, what is stopping Mozilla from selling "Trusted Recursive Resolver" positions to private companies just like they sell search engine placement in their browser?
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?
Possibly contractual obligations? That's what Mozilla did with Pocket before simply acquiring it themselves.
edit: Yes, it is with contracts. https://wiki.mozilla.org/Security/DOH-resolver-policy#Confor...
How do these DoH partnerships work with DNS split views? If folks are running an internal copy of "something.company.com" and it's expected to resolve to RFC3330 space "on the company network" ... that depends on folks computers and devices using the corporate DNS. If Firefox is going to a public DoH endpoint, they'll get the public IPs instead and connect to the wrong copy of the service, or it might not even resolve if it's an internal-only record.
They expect that Firefox will be configured by the enterprises where this would be an issue. But if a domain simply fails to resolve via DoH it will fall back to plain DNS. https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs...
I never heard of NextDNS.
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.'
If not specifically requested by the user, no data is logged. Some features require some sort of data retention. In that case, our users are given the option, control, and full access on what is logged and for how long.
> Protect your kids and control what they can access online.
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!
"Protecting your kids" is often "we log everything and have complete visibility over how people are using our service, and we're willing to share a bit of that with parents to spy on their children". It's a valid concern to have unless there's evidence to the contrary.
I assume every single DNS provider is logging and, if possible, selling my data. Why wouldn't I? This is actually why I use my own DNS server and resolve against the root, like anyone else who cares about privacy ought to be doing.
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.
> This is actually why I use my own DNS server and resolve against the root, like anyone else who cares about privacy ought to be doing.
How do you prevent the ISP from logging those requests to the root?
I can't speak for them, but I do the same thing and use a VPN to resolvers on numerous VPS providers. Those talk upstream to the root servers. Between the min-ttl cache at each layer and the large number of resolvers, correlation of my DNS requests is non trivial. I also ensure that client subnet EDNS is blocked.
Unless you're connected to a VPN 100% of the time wouldn't your ISP already have access to see every domain you browse to?
They do via the SNI header, but Firefox already includes support for encrypted SNI. So if the server supports that, all the ISP gets is the IP of the server you're connecting to. If that IP only hosts a single domain, then they can still tell, but in other cases (think sites behind Cloudflare, or using shared load balancers), they can't.
Or actually, they might still, using side-channel attacks, but it's significantly harder to accomplish, especially at scale.
Hey, good point. I guess there's not much I can do about that yet, without DNSSEC or whatever.
DNSSEC does nothing whatsoever to prevent your ISP from logging your requests.
I’d be interested to get to any links/descriptions on how you run your own DNS server and the monetary and time costs of it.
Thanks. I have heard of pi-hole and know what it does (though I haven’t setup one myself). I’ll take a shot at it. I was wondering what stack the GP was using, where it was hosted and what the costs were.
Further, any mention of homosexuality is often considered to be inherently and unmistakably morally obscene, such as by the One Million Moms group, or as described by various state GOP platforms. This would include the narratives on whether lesbian or gay parents exist.
One of the positives of DNS-level blocking is that it's relatively rough-grained. You can block pornhub.com, but you can't block out every mention of homosexuality at the DNS level without blocking any site that may potentially mention it, which would include any news site, discussion forum, social media, etc.
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.
Technology should not be inserting itself into the private lives of people and determining the values they can raise their children with. This is something parents should have as a tool. If you don't like it, tough; go raise your kids the way you want to. There's no reason why someone with traditional values shouldn't be afforded the ability to selectively block things they find obscene.
Nobody is fighting over whether you're going to be doing site-by-site blocking, because that's too exhausting and people know that.
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.
Yes, so one should expect that religious sites describing the healthy mode of heterosexuality should remain visible, while sites discussing homosexual parenting ought be stricken via DNS. Is the positive you're talking about summed up as "it's not that bad"?
It's well within any parent's rights to block content like that, yes. If I can prevent my children from seeing obscene and objectionable things until they're old enough to have reasonable conversations about it, I will.
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.
I'm not saying that the product doesn't have it's use, but it is not how DoH should work.
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.
Wow, you're pretty easily upset. Was Mozilla alive for you before this?
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.
the monitoring and blocking features are not enabled by default.
The pricing model is certainly troubling though.
> Completely free during the beta, then free up until about 300,000 DNS queries/month — $1.99/month for unlimited queries.
> 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...
Firefox will need a new error page ERR_DNS_NEEDS_PAYMENT
Do you think that it could be possible to fix their monetization strategy?
Also I suspect that in that case NextDNS would just send you to their own page a la WIFI login page.
Consistent hashing by gTLD with a random local seed instead of simple randomization then. I’m sure 1/3 of your data is still valuable but 1/10 or less probably not. A sort of K-anonymity for DNS.
Duplicate of https://news.ycombinator.com/item?id=21811739
"For more than 30 years, DNS has served as a key mechanism for accessing sites and services on the web."
I value dry jokes such as this.