
NextDNS Joins Firefox’s Trusted Recursive Resolver - inception44
https://blog.mozilla.org/blog/2019/12/17/firefox-announces-new-partner-in-delivering-private-and-secure-dns-services-to-users/
======
3xblah
“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.

~~~
fabrice_d
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.

~~~
devit
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.

~~~
sciurus
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://blog.mozilla.org/netpolicy/2019/12/09/trusted-recursive-
resolvers-protecting-your-privacy-with-policy-technology/)

[https://wiki.mozilla.org/Security/DOH-resolver-
policy](https://wiki.mozilla.org/Security/DOH-resolver-policy)

(Disclosure: I work for Mozilla, but not on this)

~~~
3xblah
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.,

    
    
       drill -t example.com @45.90.28.0 a chaos
    

Unfortunately, someone who ISP is filtering port 53 cannot make this query.

------
thayne
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.

~~~
morpheuskafka
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.

~~~
vetinari
> 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.

------
heavyset_go
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.

[1]
[https://news.ycombinator.com/item?id=19170671](https://news.ycombinator.com/item?id=19170671)

~~~
slenk
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.

~~~
yegle
AFAIKT, you can block Google DNS and all your Google Cast devices should
fallback to DHCP assigned DNS.

~~~
slenk
Oh, good to know. I just let it think it's using Google and like redirecting
it behind the scenes

------
kiwidrew
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.

~~~
tptacek
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.

~~~
zrm
> 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.

~~~
pvg
_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.

~~~
zrm
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.

~~~
pvg
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'?

~~~
zrm
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.

~~~
pvg
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.

~~~
zrm
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.

~~~
pvg
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.

~~~
zrm
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.

~~~
pvg
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.

~~~
zrm
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_.

------
slipheen
> 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.

------
cj
Interesting, I wasn't aware of Mozilla's Trusted Recursive Resolver program
([https://wiki.mozilla.org/Security/DOH-resolver-
policy](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?

~~~
comboy
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.

------
ignoramous
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](https://news.ycombinator.com/item?id=21543038)

[1]
[https://news.ycombinator.com/item?id=21604825](https://news.ycombinator.com/item?id=21604825)

[2]
[https://news.ycombinator.com/item?id=20851626](https://news.ycombinator.com/item?id=20851626)

[3]
[https://news.ycombinator.com/item?id=20012687](https://news.ycombinator.com/item?id=20012687)

[4]
[https://news.ycombinator.com/item?id=20785712](https://news.ycombinator.com/item?id=20785712)

[5]
[https://aws.amazon.com/blogs/architecture/category/networkin...](https://aws.amazon.com/blogs/architecture/category/networking-
content-delivery/amazon-route-53/)

[6]
[https://news.ycombinator.com/item?id=18788410](https://news.ycombinator.com/item?id=18788410)

~~~
Terretta
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.

~~~
ignoramous
> 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.

------
captn3m0
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.

------
jtbayly
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?

~~~
giancarlostoro
Or an option to randomize it per request with the ability to remove /
blacklist specific partners. Now that would be great.

~~~
kardos
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.

~~~
tomatocracy
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.

------
nimbius
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?

~~~
LamaOfRuin
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...](https://wiki.mozilla.org/Security/DOH-resolver-
policy#Conforming_Resolvers)

------
colmmacc
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.

~~~
sp332
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...](https://support.mozilla.org/en-US/kb/dns-over-https-doh-
faqs#w_how-does-firefox-handle-split-horizon-dns)

------
cremp
I never heard of NextDNS.

I am appalled.

From their site: [https://nextdns.io](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](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.'

~~~
core-questions
> 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!

~~~
saagarjha
"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.

~~~
core-questions
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.

~~~
icebraining
> 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?

~~~
autoexec
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?

~~~
icebraining
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.

------
tatersolid
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.

------
tech234a
Duplicate of
[https://news.ycombinator.com/item?id=21811739](https://news.ycombinator.com/item?id=21811739)

------
smitty1e
"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.

