
DNS-over-HTTPS Policy Requirements for Resolvers - jvehent
https://blog.mozilla.org/security/2019/04/09/dns-over-https-policy-requirements-for-resolvers/
======
kodablah
> Our plan is to select a set of Trusted Recursive Resolvers (TRRs) that we
> will use for DoH resolution in Firefox. Those resolvers will be required to
> conform to a specific set of policies that put privacy first.

So can I manually set one myself to my local pi-hole instance? I have already
been setting the TRR about:config values (ala [0]), will that remain?

I am wary of Mozilla becoming the arbiter of acceptable DNS providers for me,
so I should be able to override it if I want.

0 - [https://blog.stackpath.com/serverless-dns-over-https-at-
the-...](https://blog.stackpath.com/serverless-dns-over-https-at-the-edge-doh)

~~~
foobarbazetc
Think of this more like which CA roots browsers include by default instead of
a nefarious plan to stop you from doing whatever you want.

~~~
EvanAnderson
It's not a nefarious plan to stop me from doing what I want in a FOSS browser
on a PC where I can compile and run what I want. It _will_ be used that way,
however, on locked-down devices users pay for but don't actually own.

~~~
shawnz
Then don't buy such a device which clearly doesn't meet your needs. Why should
every personal computing device on the planet be tailored to your
requirements, at the cost of safety for the majority of other users? Most
people don't use PiHole, they use Adblock or uBlock which are not affected by
this. It's not as though they are taking away your ability to use adblocking
technology.

~~~
EvanAnderson
Macro-level view: The Mozilla Foundation may think that DNS-over-HTTPS is
about "safety", but they're unwittingly furthering the agenda of those who
would profit from the Internet not being decentralized. A decentralized
Internet filled with devices that end users can control, should they choose,
is a good thing for society, I'd argue. DNS-over-HTTPS is another piece of
technology that can be used to eliminate that. It is not necessary to hand
over freedom in exchange for "safety" or "security".

Micro-level view: I'm a sysadmin for my Customers, my family, and some of my
friends. Inevitably I will have to deal with these awful devices. So will
countless other sysadmins. I'm dreading having to deal with devices that
invade my users' privacy, thwart my attempts at detecting bad actors on the
network, and that just generally act like the person who paid for them doesn't
actually own them.

~~~
shawnz
Regarding your second point, this change will improve privacy for your clients
and make it harder for bad actors to take advantage of your network. So what's
not to like? Just because your old tooling won't work anymore doesn't mean
that this change is a bad thing for clients.

~~~
vetinari
If it improves privacy for the clients, it also improves privacy for the
malware, and you won't be able to monitor or be alerted of it.

~~~
stirfrykitty
Most modern firewalls can decrypt/re-encrypt all traffic on the fly. The end
user doesn't even notice. I've done this at my last two jobs.

More here:
[https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?...](https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClEZCA0)

~~~
syshum
That works by Man in the middle attacks of SSL

and Only works on Enterprise Networks for devices owned by the enterprise
because the Enterprise Installs their own Root Certs on all devices that
"tricks" the browsers into believing they are "google.com" not the real
google.com

~~~
shawnz
Right, which is exactly how it should be. If you want to perform a purposeful
man in the middle attack on your clients, then you SHOULD be required to
install your root cert on their workstations. With unencrypted DNS, it just
means that you can perform the same attack with NO specific approval by the
client workstation. How is that better?

~~~
snazz
You get an HTTPS error if someone performs a DNS MITM and you’re not set up
specifically to trust their certificate. It’s equivalent to performing an
HTTPS MITM without the root cert installed.

------
nykolasz
I replied sub-thread, but adding here to give some more visibility to some of
the issues DoH is causing and will cause:

I work at a k12 school and I am involved on many k12 IT communities.

Some schools already removed Firefox from the students computers because it
was being used as a "VPN" by some elementary students to access porn - at
school. Guess what this VPN was? Just DNS over HTTPS.

There is a fine line between protecting yourself from your ISP and local
network operators that NEED to apply some security policies to their traffic.
Even Google offers "Safe Search" for schools and libraries that removes porn
content.

Unfortunately, on our school network, we also allow BYOD (students with their
own laptops and ipads), so we will have to have some strict rules to block
DoH, the same way we block proxies and vpns.

The only other option is going to full HTTPS MITM, forcing a root SSL cert to
all computers that use our network, which is the last thing that anyone wants
to do.

 _Summary: This may lead to more HTTPS MITM or schools forbidding BYOD AND
removing Firefox from their computers._

~~~
Avamander
Don't worry. Soon Chrome will also implement DoH and ESNI, then you actually
have to either forbid BYOD or actually start teaching students manners, how
browsing porn is not okay in school context. I'm really quite annoyed by the
connotation that kids should rather be helicopter-parented (by tech or by
people) than actually taught what's okay and what's not.

The very least the new tech provides is that any silent helicopter parenting
is becoming more visible and I'm grateful for that. Kids deserve internet
privacy just as much as real-life privacy.

~~~
AlexandrB
> Soon Chrome will also implement DoH and ESNI, then you actually have to
> either forbid BYOD or actually start teaching students manners...

If you think that this is how it will go, you're very naive. If schools and
parents can't block porn anymore, prepare for more legislation that blocks
porn by default at the ISP unless you pay some kind of fee - like what the UK
has proposed. Also look for a return of "content standards" for sites that
want to be kept off the "porn list", like the old broadcast TV content
standards.

~~~
Avamander
Thankfully I don't live in the USA where asinine things like that would work.
Pretty sure there isn't a single school here try and enforce a web filter
other than "Let's agree not to visit pages that are not allowed [OK]". I'm
hope I'm not naive, maybe just not super-accustomed to the "tHinK oF tHE
ChiLDRen"-narrative for pushing filters (or other things) trough.

------
rmdoss
Note that with DoH on Firefox, your intranet domains do not work. Had issues
with it before and had to disable DoH just to access our company printer. Also
causes issues with DC.

That goes into the argument that DNS (domain name lookup) should be a system
and network-level setting, not an App-based setting.

~~~
MayeulC
That's not entierely true. If the domain doesn't resolve via DoH, Firefox will
fallback to the system DNS server.

    
    
        network.trr.mode
    

Needs to be set to 2 (fallback), 1 (pick faster), or 0 (dissable DoH) for this
to happen. 3 disables the system resolver.

~~~
protomyth
So, the internal domain names leak to Mozilla unless I disable this totally?

~~~
cpeterso
Not to Mozilla, but to whichever DoH service Firefox is configured to use, by
default or by the user. Mozilla isn't running a DoH service.

~~~
protomyth
What is the default?

~~~
moosingin3space
Cloudflare 1.1.1.1 is the default.

~~~
protomyth
So, when the user types in internal.mydomain.com, it gets sent to Cloudflare
then they query my public domain server which doesn't have the entry so it
falls back to checking the DNS the system has listed. Is Firefox going to
cache the IP like the OS does?

~~~
moosingin3space
The behaviour depends on a few preferences:

* network.trr.mode can be set to 0 (disabled), 1 (race native vs TRR), 2 (TRR first, OS DNS as fallback), 3 (TRR only), 4 (run native and TRR in parallel but use native results, save TRR timings for telemetry), or 5 (off by choice)

* network.trr.uri configures which DoH endpoint is queried

Firefox does maintain a DNS cache, even if you use the native DNS resolver.
You can view the cache at about:networking#dns.

~~~
protomyth
So, I really need to set 5 because 0 will probably later become default
consent to use DNS-over-HTTPS.

------
EvanAnderson
I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened
to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS
was discussed:

[https://youtu.be/OxFFTxJv1L4?t=2799](https://youtu.be/OxFFTxJv1L4?t=2799)

After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator
perspective I'm a lot more wary of the protocol.

~~~
majke
(full disclosure: I'm affiliated to Cloudflare, but opinions here are my own
of course)

Thanks for posting this. I knew Paul is against DoH, but never understood his
specific arguments. He has great comment about DoT (dns over TLS) couple of
minutes before the linked youtube (I agree with him on that).

Personally I'm not an "owner" of the networks I'm connecting to. My home
router is managed by my ISP, I don't run pi-hole. Network at work is managed
by yet-someone-else. I often use my mobile carrier (LTE tethering), and often
use WiFi at coffee shops.

For all of these cases I would prefer to not expose my DNS traffic. Heck, I'm
100% sure that my dns traffic today is being re-sold! I have couple of unique
domain names that I have open in my browser which have unique and non-
guessable DNS names, which are crawled by some bots today. Even though I never
shared them in any way with anyone! The only way they could be exposed for
crawling is by my DNS provider leaking the DNS traffic to some shady third-
party.

Many DNS people are opposed DoH, but I think this train has passed. As a user
of the internet I really do want encrypt everything these days.
[https://tools.ietf.org/html/rfc8404](https://tools.ietf.org/html/rfc8404)

If my corporate boss, or my ISP can mine less data about the malware I'm
running - so be it. For me this is an acceptable cost of measurably improved
privacy.

~~~
zzzcpan
Your ISP doesn't really need DNS traffic to know things about you, IP
addresses alone leak a lot of information, add to that SNI, response sizes,
active probing, clear text traffic, etc. and you should realize that the only
thing DoH does is letting one extra party to know what you are doing in
addition to your ISP. DoH is net negative for privacy. You need at least a VPN
to get to net positive, so that your ISP can't get that much data.

~~~
sroussey
SNI is getting encrypted soon too

~~~
the8472
Only if you go through big, centralized cloud providers fronting the traffic.
You're just replacing your ISP with the the CDN.

~~~
Spivak
The person who wrote your application stood it up using that CDN though. There
are two parties we're concerned about: you and the entity you're communicating
with.

You trust your device and the entity, and the entity trusts the infrastructure
and services they're using. Everything else is the enemy. So moving the
barrier to a CDN which the entity trusts is actually an improvement over
intermediate ISPs which neither of you trust.

~~~
the8472
They may simply not care and only "trust" the CDN in so far as it bypasses
local resolvers. I.e. they might be using it for reasons not aligned with my
interests and not vet the CDN at all.

------
bluejekyll
I’ve begun to think that differences of opinion on the benefits and/or
negatives of DoH come from two different perspectives on what DNS is for.

What I perceive from the debate is generally that people who dislike DoH tend
to perceive it as a network plane protocol, one that is designed for network
operations and nothing more (layer 3/4 if you will).

Whereas people who tend to want privacy and the other features of DoH,
perceive it as an application level concern (layer 7). In this context
connectivity and discoverability of services is the aim, and knowing that the
information for establishing connections to those services is correct is
important to the foundations and guarantees of applications being built to
utilize DNS.

In the application and services context, you may not even want a single set of
recursive resolves or authorities for the system. And the reasons are to help
ensure the data is focused on what you need in different contexts.

I believe that the network level concerns over DoH are a little disingenuous,
and this is because there are many ways to circumvent DNS, DoH isn’t
necessary, you don’t even need DNS to establish layer3/4 connections. Fighting
over DoH for security that can’t truly be enforced in DNS, seems misguided.

~~~
tlrobinson
I can think of 3 main use-cases for DNS blocking on a network level:

1\. content policies: blocking porn, censorship, etc (already easily
circumvented by changing DNS or using a VPN)

2\. preventing malware command and control: blocking domains that malware
phones home to (already easily circumvented by including their own resolver,
etc)

3\. preventing malware infection: blocking domains serving malware (you might
lump "ads" in this category too, e.x. Pi-hole)

IMHO the 3rd is the only use-case worth trying to solve with DNS blocking,
because the user isn't actively trying to circumvent it.

Applications using their own resolvers do make that difficult to do. It seems
like it would be best if operating systems implemented DoH at the system
level, including DHCP support, so devices could use the network's DoH resolver
which might do malware blocking.

Applications like Firefox could fall back to their own DoH resolver if they
had a way to detect the system was not using DoH. This would also encourage
network operators to support DoH.

~~~
josteink
> It seems like it would be best if operating systems implemented DoH at the
> system level, including DHCP support, so devices could use the network's DoH
> resolver which might do malware blocking.

They already do that. It’s called DNS.

~~~
tlrobinson
Of course, but it's not encrypted.

------
3xblah
"To that end, today we are releasing a list of DOH requirements, available on
the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The
requirements focus on three areas: 1) limiting data collection and retention
from the resolver, 2) ensuring transparency for any data retention that does
occur, and _3) limiting any potential use of the resolver to block access or
modify content._ "

I sometimes use a local resolver bound to localhost that blocks ads by
pointing to a custom root.

If someone aiming to be on the TRR list sets up a remote resolver that blocks
ads (or replaces them with blank images) perhaps using the same technique, it
could allow Firefox users to get ad blocking by default, by using DOH.

I wonder if that would violate Mozilla's requirements?

Are ads considered "content"?

There is of course precedent for blocking undesirable content via DNS as a
"service".

Third party DNS service, for example the famous one that starts with "O", has
been used to block certain content, e,g, at schools.

This was offered as a fee-based service.

If I remember correctly they also offered "free" service which was subject to
redirection of NXDOMAIN to paid placement "search" results/ads.

~~~
topranks
I’d be fairly certain this would be against Mozilla’s requirements.

~~~
3xblah
Any idea of the reasoning behind that choice?

------
subwindow
This has negative implications for security. For instance, one reason why DNS
resolvers might block or modify requests is to blacklist domains used for
malware operation (botnet C&C domains). Other things like DNS sinkholing and
poisoning are also frequently used as tools to disrupt malware communication.

In addition, collection and analysis of below-the-recursive DNS traffic is one
of the primary ways in which security researchers discover the infrastructure
of botnet networks.

Overall DoH is probably a net positive, but I don't see downsides like this
being discussed.

~~~
judge2020
You can currently customize the trr address in firefox, so assuming you trust
a network box's single HTTPS certificate, it can also run a DoH server.

------
AnaniasAnanas
Still no explanation on why dns-over-https rather than the already widespread
dnscrypt or the lesser known dnscurve, dns-over-quic, and dns-over-tor.

~~~
danyork
DNSCrypt and other solutions typically involve changes to the DNS resolver in
the underlying operating system. That's a lot harder to get changed and
deployment can take a long time.

DOH can be implemented directly inside of the web browser application, since
those browsers are obviously already doing everything over HTTPS. So the
browser developers just have to build in a DNS client. From their perspective,
I would see that being much simpler. And deployment is as easy as the next
browser application update.

~~~
jedisct1
Yandex has been shipping support for DNSCrypt in their web browser since 2016.

------
kylek
(It's been a long time since I've actually set up a DNS server and am pretty
fuzzy on some details - so I'm going to state this like a real nooby to
hopefully get an ELI5 answer)

If I were to set up my own DoH server, would its queries to upstream (root??)
servers (and subsequent recursed servers) be encrypted? (Simpler: does running
a DNS server "on-premise", or even in the cloud, actually protect you from
anything?)

~~~
topranks
No, DoH only deals with client to resolver encryption.

Recursive lookups from the resolver to authoritative DNS servers from the root
down are not encrypted.

Really what you are doing is switching between telling your ISP all the
domains you look up to telling Google/Cloudflare. Except your ISP can still
see SNIs so you’re really just telling Google/Cloudflare in addition to your
ISP.

~~~
kylek
Seems all for not :|

I don't suppose there are any proposals to replace how SNIs are transmitted?
(sans-vpn/tor, that is)

Does QUIC/HTTP[23] do anything different?

------
tptacek
Notice something they're not requiring? Mozilla will trust resolvers that
don't check DNSSEC. Stick a fork in DNSSEC.

------
LinuxBender
Has anyone started contributing lists of all the public DoH resolvers on any
of the block-lists? e.g. [1] [2]

[1] - [https://iplists.firehol.org/](https://iplists.firehol.org/)

[2] - [https://github.com/firehol/blocklist-
ipsets](https://github.com/firehol/blocklist-ipsets)

~~~
topranks
Someone has a list here:

[https://github.com/curl/curl/wiki/DNS-over-
HTTPS](https://github.com/curl/curl/wiki/DNS-over-HTTPS)

------
darkhorn
Also you can encrypt SNI in Firefox, just enable

network.security.esni.enabled

[https://blog.cloudflare.com/encrypt-that-sni-firefox-
edition...](https://blog.cloudflare.com/encrypt-that-sni-firefox-edition/)

------
zelly
No data collection? Watch 8.8.8.8, 1.1.1.1, etc. suddenly end their services.

~~~
ionised
I'm totally supportive of that.

------
protomyth
What is the justification for an app to resolve domain names differently than
the services the operating system provides? I am really curious why this is a
thing.

~~~
darkhorn
Windows doesn't provide privacy when it comes to DNS queries. It still uses
old fashion, plain text DNS. Firefox is trying to protect its users from
prying eyes.

~~~
protomyth
Then complain to Microsoft, ship VPN software like Cloud Flare, and quit doing
things in the browser that aren't browsing. This attitude that "I can suck
functions into the browser" that do not take into account all the scenarios
that OS vendors already have to deal with is a pain in the butt.

------
nykolasz
Glad that they allowed resolvers that filter content based on the user request
in there. So good news that Quad9 and CleanBrowsing will be able to make the
list.

------
lazylizard
I hope it can respect nsswitch?

------
localhostdotdev
pretty cool, I wished chrome did that. firefox is probably going to choose
cloudflare (1.1.1.1).

I wonder how this plays out with local DNS (e.g. my ISP has some custom
domains for me to use, and internal company network addresses)

~~~
afiori
You can set firefox to use the normal DNS as a fallback

~~~
teddyh
One could reasonably wonder why “normal” should be a fallback.

~~~
afiori
I have two reason to like DoH: public wifi blocking sites and ISPs blocking
sites. I understand that it is "wrong" from the perspective of a network
stack, but for my use case that is far from being even a weak issue.

------
slim
tl;dr

Firefox will ignore your DNS settings and use his own (DoH)

~~~
bzbarsky
Nothing in the article says anything about that.

The article talks about Firefox behavior when DoH is enabled. It's not enabled
by default. The article doesn't say it's getting enabled by default, or under
what conditions it might get enabled by default.

~~~
JohnFen
At the very start of the linked article, it says this:

"Over the past few months, we’ve been experimenting with DNS-over-HTTPS (DoH),
a protocol which uses encryption to protect DNS requests and responses, with
the goal of deploying DoH by default for our users."

~~~
bzbarsky
That's correct, but the requirements that need to be met for it to be enabled
by default are still being determined.

