
OpenBSD Disabled DoH by Default in Firefox - katzeilla
https://undeadly.org/cgi?action=article;sid=20190911113856
======
lucb1e
As a European, I also find it very weird to enable this globally by default. I
really don't want to send my traffic to a third party on some other continent
that gives me a service for free. I pay my ISP good money to do this for me.

No idea how common this is in other countries, but my ISP doesn't sniff or
sell my traffic. I've only ever heard about that on HN or Reddit, which are
USA-centric. I guess it also happens in other countries, but in the EU such a
thing would have to be made known to the user because it processes personal
data.

Somehow, adding a Pocket button is bad but sending all visited websites to
Cloudflare is good. The top two comments (and many others) on the thread about
Pocket can be applied here as well if you just replace the name "Pocket" with
"Cloudflare":
[https://news.ycombinator.com/item?id=9667809](https://news.ycombinator.com/item?id=9667809)

~~~
Santosh83
Indian here. My ISP does inject ads into plain HTTP traffic, so based on that
user-hostile behaviour I assume that they also record my DNS queries and/or
sell them. Also whether or not they do that, they are mandated by govt to keep
DNS query records for at least 18 months (last I looked) and then anonymise
them. Under the current authoritarian leaning govt, I wouldn't be surprised if
rules have been revised mandating indefinite recording.

~~~
mtsr
But the proper solution for that is DNS-over-TLS and picking or running your
own recursive DNS resolver.

~~~
CogitoCogito
Is it not possible to have a recursive DNS resolver with DNS over HTTPS? I.e.
are their more differences between DoH and DNS over TLS than just the port
number?

~~~
mercora
i think DoH is DNS wireformat via http over TLS whereas DNS over TLS is the
plain wireformat over TLS.

EDIT: so for DoH you would need to speak HTTP but for DNS over TLS you only
need to wrap TLS around for example by using stunnel or something.

~~~
CogitoCogito
Sorry if I'm dense, but that would mean that the two protocols _are_ the same
except for port number for practical purposes right? I mean there's no reason
why the same actions could be taken when running straight wireformat vs over
http right?

edit: In response to your edit :)

So is the main objection to this that it breaks traditional layering then?
E.g. here's a post in a thread that I found a bit helpful:

[https://old.reddit.com/r/privacy/comments/89pr15/dnsoverhttp...](https://old.reddit.com/r/privacy/comments/89pr15/dnsoverhttps_vs_dns_overtls_vs_dnscrypt/dwzk7g3/)

(The rest of the thread is interesting as well.)

I guess one downside with DoH is that now there's a larger incentive to break
through your https in general?

~~~
mercora
i was only responding to your question whether there is any difference between
the two beside the port number used which there is, in a significant way. You
can not point a DoH client to a DNS over TLS server or vice versa. That said
there is no reason a DoH server could not be recursive or consult a
traditional (probably recursive) resolver for its response.

I think the only benefit of DoH is that is unlikely to be blocked. Otherwise
it feels more like a hack and at least i am not concerned about OSI models ;)

Actually, i tried to setup a DNS over TLS server some weeks ago but while it
worked like intended i had a hard time to get reasonable response times even
after somewhat serious fine tuning for the session setup (i used haproxy at
server side). But this was mainly caused by the fact that systemd-resolved
established a new connection for each and every request and i did not find a
stub resolver that did not either.

~~~
CogitoCogito
> i was only responding to your question whether there is any difference
> between the two beside the port number used which there is, in a significant
> way. You can not point a DoH client to a DNS over TLS server or vice versa.
> That said there is no reason a DoH server could not be recursive or consult
> a traditional (probably recursive) resolver for its response.

> I think the only benefit of DoH is that is unlikely to be blocked. Otherwise
> it feels more like a hack and at least i am not concerned about OSI models
> ;)

Thanks for the response, but I'm still a little confused. If you live in the
DoH stack you must stay there sure, but the same apparently applies to the DNS
over TLS. What to you exactly is hacky about the DoH method if you don't care
about the layering violations?

------
bureaucrat
DoH should be supported on the OS network stack, if needed.

I can’t understand this move. Firefox should retreat from this default.

~~~
swiley
The problem with this is that the language runtimes now have to have an http
client implementation. DNS isn’t super simple but I would argue it’s _much_
simpler than http. DoH is a very good idea and we need the security it
provides but I think using http as the protocol is probably a mistake and will
prevent it from being widely adopted.

~~~
asveikau
So perhaps the right solution is to run a plaintext DNS server bound to
localhost, and it calls out using whatever encrypted protocol deemed
necessary, systemwide.

~~~
mtsr
Exactly. And Mozilla could easily offer this instead and benefit other
applications the user has.

------
artemiszenk
I don’t see anything sinister here. Many of us who care about utilizing DoH
may already have an appliance that performs this task, but leaving it as an
option users can eventually opt into is a good thing.

If Google was the one offering DoH, and Otto made this change basically
saying, “We don’t want all our traffic going to Google,” I think it would add
perspective.

~~~
Faark
There are arguments against Mozilla's current DoH rollout. DNS should be an OS
setting and it should not default to a single commercial company. Both are
totally valid and I hope be addressed as DoH matures.

Or do you mean nothing sinister in this OpenBSD move? Well, it is kind of
ironic to downgrade Firefox defaults to unencrypted DNS, since the absence of
any modern & encrypted DNS on OSes was likely the only reason Mozilla felt the
need for the switch in the first place. And this move doesn't seem to address
this underlying issue of unsafe defaults caused by OSes like OpenBSD and thus
feels a lot like some "no, shut up, everything is fine" reaction to criticism.

~~~
windexh8er
Agreed. But I do see it as very similar to preloaded/preselected search. We're
numb to that feature of browsers and sometimes fail to remember we don't need
them. In many regards DNS in the browser gives back control to the end user.
As governments and service providers encroach DoH and DoT are leveling the
playing field.

Also keep in mind there are different modes DoH in Firefox can operate in. [0]
Ultimately I welcome the feature and hope we see more not-for-profit options
as defaults in Firefox.

[0]
[https://wiki.mozilla.org/Trusted_Recursive_Resolver](https://wiki.mozilla.org/Trusted_Recursive_Resolver)

------
Jonnax
DNS over HTTPS is great for the average user.

Anyone who needs some other configuration, clearly is knowledgeable enough to
change the behavior.

~~~
zrm
It's not a matter of knowledge. If each application ignores the OS DNS
configuration in favor of its own, it's no longer possible to make a system-
wide change to it. You have to change each application individually, and then
go back and do it again for each one that updates to a version that adds its
own support for DoH.

You also then end up with each application using its own implementation, but
DoH is a complex protocol (DNS+TLS+HTTP), so that's a lot of attack surface.
Better to have one high-quality up-to-date implementation in the OS than
dozens of applications that each get their own chance to screw it up.

It also breaks all of the usual things that make local DNS work. Your local
DHCP server provides your local DNS server which includes entries for the
local names with RFC1918 addresses that are only accessible on the local
network. Move to DoH via some default external provider and that breaks and
requires touching every application on every client to fix it.

~~~
m45t3r
> It also breaks all of the usual things that make local DNS work. Your local
> DHCP server provides your local DNS server which includes entries for the
> local names with RFC1918 addresses that are only accessible on the local
> network. Move to DoH via some default external provider and that breaks and
> requires touching every application on every client to fix it.

This is not true, Firefox will fallback to your OS configured name resolver if
it can't find a name. You can also set it to strict mode so it will only use
DOH, but this is not the option that Firefox set by default.

[https://blog.mozilla.org/futurereleases/2019/09/06/whats-
nex...](https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-
making-dns-over-https-the-default/)

~~~
zrm
Better, but still broken because in many cases the names also exist in the
global DNS but should have different addresses, e.g. because they have port
mappings from public addresses but you don't want to have to use hairpin NAT
for local connections, or the local router doesn't support that.

It also implies that you're sending all queries for local names to an external
provider when that otherwise wouldn't be happening.

~~~
m45t3r
This is also covered (mostly) by Firefox. In enterprise configurations DOH
will be disabled by default, and this should cover most of the cases above.

[https://blog.mozilla.org/futurereleases/2019/09/06/whats-
nex...](https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-
making-dns-over-https-the-default/)

~~~
zrm
That's really the opposite of those cases. If you're using group policy then
Mozilla's default doesn't matter very much because you can set it to whatever
you want using group policy anyway. Where the default really matters is on the
devices where it has to be changed via high friction individualized action,
e.g. BYOD.

I completely understand why they want to support DoH. And then Firefox users
with untrustworthy DNS providers would have a solution to it which is no more
complicated than a single checkbox to enable it. But what is really being
gained over that, which is worth all the trouble of making it _the default_
even for all the people whose existing DNS providers are no less trustworthy
than Cloudflare and far less centralized?

~~~
m45t3r
> But what is really being gained over that

Try to explain for a common person what benefits DOH brings to them, or why
their DNS provider is unstrustworthy.

> [...] which is worth all the trouble of making it the default even for all
> the people whose existing DNS providers are no less trustworthy than
> Cloudflare and far less centralized?

A small number of people will actually have those "trouble" that you speak,
and for most of them the case is so specific that they probably are power
users that can figure out themselves.

------
aloknnikhil
[https://en.wikipedia.org/wiki/Zooko%27s_triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle)

There have been attempts at solving this through P2P DNS resolution. But, it's
just hard to store all those records locally and keep them up-to-date
regularly. Perhaps, we could cache and update records for the "popular"
domains regularly and reach out to Cloudflare/other DoH or DoTLS providers
when the tier 1 lookup fails?

------
karmakaze
Possible Future abuses aside, I much prefer knowing who I'm trusting Mozilla
and CloudFlare with a public reputations to preserve than ISPs that make no
assertions and regularly voilate privacy.

------
ysleepy
Instead of using a different DoH server than the user set DNS servers, Firefox
should test if the user supplied DNS servers support DoH and opportunistically
switch over to that.

------
dontbenebby
Does anyone know a good resource for someone who hasn't done a deep dive on
networking in a while, but wants to brush up on the technicals of how DoH
works?

~~~
katzeilla
How about this APNIC blog post?

[https://blog.apnic.net/2018/10/12/doh-dns-over-https-
explain...](https://blog.apnic.net/2018/10/12/doh-dns-over-https-explained/)

