Mozilla's DNS over HTTPs - <AUTHOR> https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozillas-dns-over-https-doh/ <comment><USER3> As a resident of a country whose government and ISPs heavily and habitually censor the Internet for political reasons, I for one truly appreciate Firefox's DoH. They should also enable 'network.security.esni.enabled' by default because the censors here have upgraded from DNS to SNI-based blocking. I get it that better solutions are possible, but got to teach people to first walk before teaching them to run. AFAIK, Chrome still doesn't support this kind of simple user-friendly privacy options for the average non-technical user.

<comment><USER4> Chrome uses opportunistic DoT - it uses your system configured resolver, and if it supports DoT, it will use DoT, if not, it will fall back to 53/udp.

I like Chrome's approach much better; it doesn't force you to statically configure DNS server - it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.

<comment><USER5> > ...it is a PITA, especially when roamining and you want to resolve hostnames > available only in local networks.

Not really.

If you're _not_ blackholing traffic at the dns-layer via DoH, set Firefox's _trr.mode_ to _2_. Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise.

Ref: [https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....](https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.mode)

<comment><USER6> If I sit any family member down in front of this comment, their eyes would glaze over. Not only is what you mention a PITA, it's impossible for most people.

<comment><USER7> I'm a programmer and I have no idea what OPs comment means. I keep meaning to learn about networking stuff, but there is always so many other things to learn and since I don't work with devops or networking stuff it hasn't really been a priority.

<comment><USER8> Most of that comment is Mozilla BS and not networking stuff.

\--Someone with a decent understanding of networking

<comment><USER9> Agreed. Just looked up about trr nonsense and found this 'setting':

> network.trr.excluded-domains

> _Comma separated list of domain names to be resolved using the native > resolver instead of TRR. Users may add domains they wish to exclude from TRR > to this pref. This pref can be used to make /etc/hosts works with DNS over > HTTPS in Firefox. Setting network.trr.excluded-domains to include host names > from /etc/hosts will make them fall back to platform DNS, which will use the > rules in /etc/hosts._

So, rather than using the hosts file, network admins & devs now have to specify 'special sauce' in FF too?

I'm not buying DoH for this reason alone, because it throws out a lot of legacy (albeit always regarded as hokey) for no good reason. If FFox is doing it's own DNS stuff is MUST (at least) do hosts file resolution, imho. Otherwise it leaks names, which kinda defeats one of the main the purposes of DoH: which is to maintain critical privacy in places where it's being abused.

<comment><USER10> This is so true. FireFox is terrible at spaffing private info at search engines.

Breaking DNS is madness IMHO. Its just more sites that dont work on FF.

Broken is not more secure, its just broken.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I'm so sad to see Mozilla move forward with this massive attack on user privacy.

Firefox DoH is snake oil, plain and simple. It sends all the users DNS queries to Cloudflare, adding a new party which can surveil the user's traffic (and can be legally compelled to do so and not disclose this fact)-- providing a convenient choke point to save spies and hackers the trouble and exposure of extracting the data from tens of thousands of individual ISPs.

Simultaneously, it does not protect the user from monitoring by their ISP or parties situated there because the user's destination IPs remain unencrypted, as well as the hostnames via SNI (for cases of shared hosting, e.g. on cloudflare, where the IP alone wouldn't be enough).

At the moment you can disable this across your whole lan by blocking traffic to 220.127.116.11, 126.96.36.199, 2606:4700::6810:f8f9, and 2606:4700::6810:f9f9 and by DNS blackholing use-application-dns.net and cloudflare-dns.com.

iptables -t raw -A PREROUTING -d 18.104.22.168 -j DROP

iptables -t raw -A PREROUTING -d 220.127.116.11 -j DROP

ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f8f9 -j DROP

ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f9f9 -j DROP

And if you're using bind:

zone "use-application-dns.net" { type master; file "/etc/bind/db.empty"; };

zone "cloudflare-dns.com" { type master; file "/etc/bind/db.empty"; };

Or unbound:

local-zone: "use-application-dns.net" static

local-zone: "cloudflare-dns.com" static

But there is no guarantee that these mitigations will continue to work.

[Edit: Aside, this comment and many/most(?) comments on this thread were moved from a more recent thread with a headline "Firefox turns on DoH as default for US users". The new title which omits the on-as-default, is kinda burying the lead.]

<comment><USER12> Your ISP is literally selling this information right now in the US. What are you even talking about? Use google if you don't like CF, or just disable it!

Do a little threat modeling here please. Let's say CF sells this data, what do they know about you other than your IP and the sites you visit? While your ISP,employer,school,etc... Can tie that activity to you as a person. Being compelled legally? I did not know privacy meant breaking laws, suddenly law enforcement can't do the same thing with your ISP dns?

This is not adding a new party that can surveil you, this is reducing risk by separating who can see your DNS from who can see your traffic. The idea is to have eSNI ubiquity to where TLS traffic will conceal the sites you visit while DoH will conceal the traffic metadata. Oh, and beauty of DoH: you can run it through a web proxy, and if you have alot of users behind a NAT it becomes very hard to pin point which actual machine generated the DNS lookup.

<comment><USER13> Sorry for channeling the dude here but that is just, like your opinion man.

I think many of the critical voices now are coming from the EU. We have data protection laws. The ISP can't just sell browsing data. That has been illegal since before we had data protection laws, that is actually legally the same as opening other people's letters and reading them. So ... different threat model over here.

I am always using the US-EN Firefox version because frankly why would I use translated software when I can understand and use the original.

I hope you can see how it might be of concert to me whether Mozilla decides to give my browsing data to Cloudflare, whom I have about as much reason to trust as GCHQ or the NSA.

<comment><USER14> > I am always using the US-EN Firefox version because frankly why would I use > translated software when I can understand and use the original.

This is maybe not the topic of discussion, but the argument is that your computer is your tool, and the computer should speak your language and adapt itself to you, and not the other way around. For this reason I like and prefer software that speaks my native language! However, I don't have patience for bad translations, and in those cases I'll avoid the translated apps. Not a problem for Firefox!

<comment><USER15> From my point of view translated software often just means that googling errors is harder

<comment><USER16> It's worse than that. Some words did not exist in the target language (the computers are relatively new compared to the age of the language) so they had to be created. Nothing is more annoying than to search for words which make no sense.

<comment><USER14> Why do you think english is any different? Silly words were created for new concepts in computing (as in other fields) in English too.

You just don't notice how silly all the new words are (like bit and byte, and "gigaflop" and so on) because english is a prestige language and that it is a foreign language.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> I think this is generally a good thing. Two questions I've often seen surface on HN though weren't answered:

1\. Isn't this better implemented at the OS level?

2\. Isn't centralisation to two DoH providers more centralised than five large ISPs?

Others are probably better suited to answer, but the answers I can think of:

1\. Yes, but it is not, so this solution is second-best. If Operating Systems decide to tackle this problem at some point in the future, Firefox can always be changed again to use that.

2\. Given that Firefox doesn't own the full market, the net result is indeed less centralisation: five ISPs that handle traffic by other browsers, and two DoH providers that handle Firefox's. That said, the main factor here is that the track record of ISPs in the US is abysmal, whereas the current (and hopefully potential future other ones) DoH providers have committed to far stronger privacy protections.

<comment><USER17> The ISP can just check which IP you contact, so I don't see this increasing privacy.

<comment><USER18> That doesn't work anymore. ISPs are not going to block AWS IP ranges or Azure IP ranges, etc. The cloud killed IP blocking. The pirate bay is supposed to be blocked in UK _by court order_ , but because they use cloudflare it's still accessible and only DNS blocked.

<comment><USER19> > ISPs are not going to block AWS IP ranges or Azure IP ranges, etc.

Tell that to China, Iran, Turkey (?), etc.

<comment><USER20> Ok, authoritarian regimes not included

<comment><USER19> > Ok, authoritarian regimes not included

And yet this was/is one of the justifications for implementing this.

They're not doing it in the EU because (a) there are decent privacy laws, and (b) IP addresses are (IIRC) considered personal information and so Cloudflare DoH would be responsible for keep a whole bunch of data safe. They may not want that responsibility.

This seems to (currently) be US-only because of the sucky US privacy laws.

<comment><USER18> No the justification is to make it harder for non-authoritarian countries to block websites. If China or North Korea want to block the IP range of AWS+Azure+Google that's up to their respective autocrats.

Most democratic or even hybrid regimes are not prepared for that level of absolute chaos and consequent protest if half the Internet is shut down. You can only pull that shit in a dictatorship.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Questions I couldn't find answers to in the post or linked info about the Trusted Resolver Program:

What's in it for the Cloudflare & NextDNS?

Are they getting paid to handle this traffic or paying to have the opportunity to access this data?

Can users outside the US opt-in?

The comment about having "no plans" to enable this outside the USA seems a bit disingenuous. Hard to believe they built this program / feature and have no plan to eventually roll out to all users. Perhaps what they wanted to say was they have no fixed timeline for roll out to other locations.

<comment><USER22> > The comment about having "no plans" to enable this outside the USA seems a > bit disingenuous

The comment actually very clearly says "we do not have plans to roll out the feature in Europe or other regions _at this time_ ".

Also I have mixed feelings about this. On one hand yeah, encryption is great and someone sitting between me and my ISP will no longer be able to monitor my DNS queries. On the other hand I don't feel like this is protecting me from anything at this time. Instead of trusting my ISP, I have to trust Cloudflare. And in the meantime my ISP still knows where I am connecting to, between looking at the IP and the SNI (they mention ESNI but we're not there yet and it still just a partial fix).

DoH (in general, not Mozilla's problem) just enables any piece of software or hardware on my network to bypass any security controls I have in place. No more filtering DNS with things like PiHole, no more blocking DNS port on your firewall. This tends to work out great for Google and any random IoT device manufacturer. I could cover this with more enterprisey setups but that's the last thing I want to do at home.

So the average user probably sees no difference either way, nothing lost, nothing gained. But for me it's a clear regression because I lose the little control I had over that traffic and I just spread more data around to yet more companies. Some may even be in legal jurisdictions that are even less trustworthy than where my ISP is located.

<comment><USER23> > DoH just enables any piece of software or hardware on my network to bypass > any security controls I have in place.

I think this is an error in how you've thought about the problem. If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".

[ My local airport has a sign and a telephone so that if you've arrived with goods that are forbidden or without permission to enter the country you can call up the relevant authorities and have them come fine or arrest you. The telephone looks dusty. Do you think maybe people just decide not to call? ]

Mozilla does also have a programme [https://iot.mozilla.org/](https://iot.mozilla.org/) about how to design IoT devices that allow their owners to control them rather than trying to bodge things by hoping they use protocols you can intercept.

<comment><USER19> > _If your "security controls" depend upon other people volunteering to use > some protocol then those weren't "security controls" they were more like > "guidelines"._

It's not about volunteering. Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. (DNS queries over other ports could be caught doing packet sniffing.)

Now I have to worry about DNS queries going out via HTTPS. So if I want to monitor my network for malware contacting a C&C server I have to snoop HTTPS. Which means I now have to install a web proxy and perhaps do MITM.

Previously I could 'simply' monitor DNS look ups to see if anything was trying to connect to nefarious domains.

DoH has reduced visibility into my own network.

<comment><USER15> That is a good point, but it is also mostly independent from DoH, a VPN with an hardcoded IP would have worked in the same way (if you look into elusive VPNs you can also find some that work by injecting traffic into padding of another connection).

The only difference is if you are worrying about the traffic leaving your own browser and in that case you can just not enable DoH

<comment><USER19> My passive network sniffers may throw red flags on suspicious traffic which may end up being VPN. By disguising non-web traffic over the (until now) web- mostly HTTPS, it makes the job of someone who wants to be a responsible netizen and monitor their network that much harder.

<comment><USER15> I agree if the point is that this might increase the reach of such technologies. But if you are thinking about traffic coming from sources different than your browser then why would they be unable to open a connection on hardcoded IPs?

Also VPN sniffing can be arbitrarily hard, for example if I remember correctly tools like [https://www.softether.org/](https://www.softether.org/) are designed to work around the Chinese internet firewall.

From my point of view DoH add nothing outside the browser.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Doth protest too much.

People don't take issue with DoH, they take issue with an advertising supported browser like Mozilla's unicast (and now bicast) centralization of DNS traffic that was previously distributed.

We invented DNSCrypt. There's also DNS over TLS. Lots of ways to encrypt DNS without centralization.

They make this about DoH when really the primary issues are with how they went about it.

<comment><USER25> DNS over TLS and DNSCrypt both depend on servers... exactly as centralized as DoH. They are just different wire protocols that in the end do the exact same thing with a centralized DNS server.

<comment><USER26> In fact, the only meaningful difference between DoH and DoT is that DoT runs on a separate port, so network operators (and ISPs) can filter it. DoT is DoH with a kill switch.

<comment><USER27> DoH can be blocked by IP addresses, DNS canary and probably SNI, while DoT by IP addresses and port number. So "DoT is DoH with a kill switch." is again nonsense.

<comment><USER26> Virtually every router on the Internet has the built-in capability to block DoT with a single configuration change, but you can attempt to create a blacklist of DoH resolvers to try to stop that, so they're totally equivalent. That's the argument you've got.

<comment><USER4> Not quite.

Nothing prevents Google or Cloudflare to run DoH on the same IPs as their user-facing services. Unless you are willing to block Search, for example, you might be SOL without TLS-terminating proxy.

<comment><USER26> Yes, sorry if I wasn't clear, I think the idea that DoH is just as filterable as DoT is silly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> If you are a network administrator and want none of this, look at that:

[https://support.mozilla.org/en-US/kb/canary-domain-use- appli...](https://support.mozilla.org/en-US/kb/canary-domain-use-application- dnsnet)

Basically, make use-application-dns.net. return an error (any kind will do). Filter it in your recursor for example.

Having the browser change a fundamental behaviour that used to stand for decades is highly problematic. If nothing else, it is the network administrator who should have the final say on WHEN (if ever) DoH will get deployed inside their network.

<comment><USER29> >Having the browser change a fundamental behaviour that used to stand for decades is highly problematic.

No, this is far too broad of a statement. Browsers pushing for TLS, deprecating the old SSL versions and now the old TLS versions, deprecating SHA1 use in certificates, going from quirksmode to a living html standard (not without problems such as Google's over-influence), etc all have been a net positive, but there was breakage too.

Now, DNS - a really antiquated protocol written at a time when security played no role and everybody was assumed to be a good actor and (next to) nobody bought shit online or banked online or dated online or got medical advise online - is somehow the holy grail that MUST NEVER change? Because... "it works" (only superficially, without proper security) and status quo. I don't buy it.

We may discuss DNS and alternatives/add-ons (such as DoH, DoTLS, DNSSEC, DNSCrypt, etc) and their pros and cons, but rejecting any kind of innovation isn't something I am willing to do.

<comment><USER28> The elephant in the room is that many networks need to have content filtering, and you are proposing nothing useful. DoH torpedoes content filtering to its very core and, fortunately, the knob Mozilla provides can (hopefully) be utilized. That's all there's to it.

<comment><USER29> >The elephant in the room is that many networks need to have content filtering

First of all, we're talking about domain filtering, not content filtering.

And no, they _want_ domain filtering, hardly anybody needs it, and there are better solutions than NXDOMAIN, such as actual content filters.

>and you are proposing nothing useful.

Why would I need to provide "something useful"? mozilla already described the many ways this can be disabled, from browser preferences, to automated checks for known disable-me domains, etc.

<comment><USER30> I need domain filtering: if the domain serves malware I want to block it, not just the known malware coming from it. If a domain serves porn, I want to block it on my kids computers (and mine) not just the content that is recognisable as porn. If a domain is used by malware I want to block it, and probably use the domain to determine the server, and block that too (too because the domain can move IP).

<comment><USER31> All of that can be implemented on the client (e.g. as a browser extension) without breaking the Internet. That's the only reliable way to do it anyway. MITM DNS filtering is easily bypassed and only effective against _lazy_ malware.

</comment></comment></comment></comment></comment></comment><comment><USER32> My feeling on this is that it's a pretty imperfect solution but unsurprising that the browser manufacturers are pushing it forward given ISPs dragging their heels on DoT.

We saw the same problem with TLS. Until the browser makers started pushing it and Let's encrypt made it simple/free the take up of TLS was patchy at best.

This will have negative effects on tools that use DNS for blocking/monitoring, but then those were a hack at best. If you want to understand the traffic flowing over your network, you need to invest in interception and parsing.

<comment><USER33> > ISPs dragging their heels on DoT

WTH does DoT adoption by ISPs have to do with that?!

One can run their own DNS recursive resolver-cache perfectly fine on their own hosts, or at the network edge, without relying on ISPs.

Better yet: Since the Root zone and TLD zone DNS servers change only seldomly, you can prefetch and cache them locally just fine, and upon resolving a DNS skip two recursion steps.

Apart from doing DPS, then ISPs will not "see" DNS queries, thus bypassing the privacy concerns of that.

<comment><USER32> Most end users don't just "run their own recursive resolver-cache" They take whatever DNS server is provided by their ISP

I'd guess that 99+% of Internet users have no idea how to run their own DNS server, let alone set up DoT.

<comment><USER33> That's not a good counterargument. Why you ask? Because that's something that OS vendors could easily and trivially deploy with only minimal effort.

For example on Linux you could do this with running a localhost instance of unbound, and having a DHCP client hook script updating unbound's configuration for domain specific authorative DNS servers based on the DHCP options for nameserver and domain name.

Just put that as out-of-the-box setup into default Linux distributions' installation: Not only does this greatly enhance privacy. It also prevents enterprise information leakage, _and_ every program on the system is going to benefit from it. Not just the browser.

DoH is a clusterfuck of stupid. There's not one single redeeming quality about it. Everything positive it promises to do has been already solved in a far better manner by earlier developments. And it comes with the penality of concentration of failure points.

In the best case scenario it doesn't impair your privacy.

In the worst case scenario, all the DoH resolver operators in the U.S. will get FISA court orders – including a gag order – to install boxes helpfully provided by some three-letter-agency that monitor all incoming and outgoing traffic of their resolvers; getting the DNS queries/responses in the clear would be nice, but they don't really need it, for the resolvers provide some nicely observable traffic hub on where it's super easy to time correlate outgoing DNS resolver queries to incoming DoH requests.

And don't even believe that DoH requests would be indistinguishable from "regular" HTTPS traffic! Unless you're running into an DNS record that's been overloaded with everything DNSSEC offers the bandwidth requirements of DNS are fairly balanced in both directions. Plus, the amount of data transferred via DoH is more or less the net size of the final DNS query and request combined. So either you pad DoH for the worst case scenario size, or you have a pretty well readable side channel.

No matter from which angle you look at it, DoH makes no fucking sense whatsoever. It's just stupid, if not malicious.

<comment><USER26> I like how someone on HN tells you that ordinary users have no idea how to set up their own DNS servers and you respond with how Linux users can set up unbound. Like, well argued!

There is also something poetic about how the people that know how and are inclined to set up their own unbound servers on their laptops are getting worse security than everyone else. That sparks joy for me.

<comment><USER33> > you respond with how Linux users can set up unbound. Like, well argued!

I did write, that DISTRIBUTIONS should set this up by default, not the users.

And Microsoft could do the same for Windows, as could Apple (with almost zero effort) for MacOS-X

<comment><USER34> >For example on Linux you could do this with running a localhost instance of unbound

Not seeing _distributions_ there

<comment><USER33> Look again. Topmost paragraph. I'll quote myself:

>> Because that's something that OS vendors could easily and trivially deploy with only minimal effort.

"OS vendors" aka "distribution creators"

And then in the 3rd paragraph, I wrote (sic!):

>> Just put that as out-of-the-box setup into default Linux distributions' installation:

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> The underlying issue is that a DoH provider can craft the DNS answers individual users get if it wants to.

Think about it: a Firefox DoH user could get different DNS answers than other apps get on the _same machine_ using standard DNS on port 53, if Google or Cloudflare wanted to, because they're essentially talking to different versions of the internet.

Remember, all of the properties that allows HTTPS to be trackable—cookies, fingerprinting and the rest—is in play for DNS over HTTPS as well. DoT doesn't allow for that.

If all these providers wanted was encrypted DNS, they'd be pushing DNS over TLS, which is just standard DNS using TLS as the transport. Sure, it uses port 853, but given time, enterprises and other security-conscious organizations would have adjusted, especially if the entire DNS ecosystem got behind it.

But because Google, Cloudflare and NextDNS see an opportunity of some kind, they are pushing for DoH.

The DNS is an open, global, distributed hierarchical database; DoH starts to break this because apps can bypass most of this and that's not how the internet was designed to work.

The same way Gmail broke the model of federated SMTP servers to a large extent, there's the potential for the major DoH providers to do the same to DNS.

Imagine if Cloudflare decided to block certain DNS records from their users. Certain services that worked fine pre-DoH would break.

Take a look at the article _DNS Wars_ ; it's eye opening: [https://blog.apnic.net/2019/11/04/dns- wars/](https://blog.apnic.net/2019/11/04/dns-wars/)

<comment><USER36> > Think about it: a Firefox DoH user could get different DNS answers than > other apps get on the same machine using standard DNS on port 53, if Google > or Cloudflare wanted to, because they're essentially talking to different > versions of the internet.

How is that different than existing DNS servers?

<comment><USER37> There's no difference that a DNS server can see between a browser on your computer making a DNS request vs. any other app. But if the browser is using DoH and other apps don't, then it can tell.

<comment><USER36> Right, but that's just an argument for more applications and lower level networking stacks to support DoH.

<comment><USER38> Not really. It's an argument for the industry moving to something sensible; not "split braining" low level infrastructure by shoehorning some of it into HTTP, apps and a handful of centralised coporations who claim to play a little nicer than telcos.

</comment></comment></comment></comment></comment><comment><USER39> In order for Cloudflare (or anyone) to be a part of this program they have to comply with a particular set of rules.

 _Limiting 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._

Yes, governments can secret around this with intelligence orders, just like they can do with any of the ISPs that will keep all of the data indefinitely instead of for 24 hours.

<comment><USER40> > just like they can do with any of the ISPs

There is a 3rd option: Operating your own recursive resolver.

<comment><USER41> I've found this harder and harder over the years. My usual MOD was installing and configuring the caching-nameserver BIND package in rpm-based RHEL- downstream distros and MaraDNS in everything else. I've just kind of given up because reasons but I'm still very supportive of any of these kinds of efforts.

<comment><USER40> unbound is much easier to configure than BIND in my experience

</comment></comment></comment></comment><comment><USER42> Why are people so down on DNS over HTTPS?

DNS is _the_ primary way governments control and spy on web access.

<comment><USER43> I think part of the negativity you see is network admins working in businesses.

Their opinion is that it's a way for people to get around corporate firewalls. Kinda blind to the idea that if a browser can implement DNS over HTTPS then anything can.

Especially since there's some of ways that Mozilla have implemented for a local area DNS server to override its settings.

There's also another camp, if you remember the "internet villain of the year" award that Mozilla got for DNS over HTTPS from an ISP industry group.

Of course their argument was parental controls being made ineffective.

But of course it's transparent that this was a gambit to change public opinion so they can keep collecting browsing data to sell.

Interesting to note they went after Mozilla not Google who are also implementing it.

But really the messed up thing is that this improves privacy for the vast majority of users. Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse.

This kind of thing is a privacy improvement for millions.

And I find it shocking that people in Business IT care more about managing their corporate devices than the good of the majority of internet users.

<comment><USER44> I'm not a network admin working in a business, but I am the network admin of my home network, and I really do not want applications starting to effectively contain their own VPN clients and subverting my control.

<comment><USER43> DNS isn't a VPN nor really a security product. It's just a look up table.

The job blocking domains should be the job of a firewall. Of course this becomes more complex. But any application can implement DNS over HTTPS.

Malware could even just get a list of IPs from another IP.

An application can even just hard code IPs rather than using DNS and then they're in the same position.

<comment><USER44> Tunneling DNS inside HTTPS effectively forms part of a VPN already (and I wonder when Mozilla will decide to also stuff the rest of the traffic through...)

DNS-based blocking is not perfect, but is currently still very powerful for things like adblocking.

You're basically saying that Firefox is now behaving like malware, which I agree with...

Windows 10's telemetry is also another piece of software which has started to become hostile in this manner, hardcoding IPs and such.

<comment><USER45> Exactly. To control DoH we need to start to MITM all connections and block everthing else unless whitelisted.

<comment><USER46> For home network operators who value controlling the name resolution of devices they 'own' MITM won't be enough once embedded device manufacturers start using certificate pinning w/ DoH.

<comment><USER45> Obviously, there will be a choice not to buy them / keep them offline.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER47> Having just manually enabled DoH, it is pretty tricky to see that DoH is enabled (e.g. from padlock/shield). In the end I saw the necessary flags from: [https://www.bleepingcomputer.com/news/software/mozilla- enabl...](https://www.bleepingcomputer.com/news/software/mozilla-enables-dns- over-https-by-default-for-all-usa-users/)

Under about:config, it seems like network.trr.mode with values 2 or 3 are good choices, [https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....](https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.mode)

UPDATE: network.trr.mode with 3 is not working for me in Australia.

</comment><comment><USER48> Why isn't this being solved on an operating system level instead?

<comment><USER49> This question should be upvoted more.

Under unix in general (linux, bsd and, I assume, OSX) you can change your system resolver as you please. DoH is supported by several implementations to a various degree already. You can switch right now, for _everything_ running on your system if you wanted to!

But browsers nowdays basically live under the following assumptions:

\- the users are dumb, and "we know what's best for you" (well, to be fair this has been a consistent trend for everything in the industry) \- the OS cannot be trusted for anything, the baseline being the lowest common denominator of any old/broken version of android/osx/windows/linux they want to support \- the users _cannot_ change the system resolver even if they wanted to because the OS is locked down (android, ios, and windows with group policies)

I think all the above reasons are detrimental, but at the same time they're all sadly true. Because browsers essentially are now not far from operating systems, they abstract themselves above everything, including the resolver.

<comment><USER50> Well, in the context of DNS resolvers and general computer security the vast majority users _are_ dumb. Mozilla _has does_ know what's better for them. You, I, all of the readers of Hacker News - we're the minority.

And for better or worse, the average user's OS _is_ hostile to a user's privacy and security, with a few niche exceptions.

</comment></comment></comment><comment><USER51> Does the disable code still work in the about:config? I would rather not have the trusted providers see all our internal server names (which is wasted bandwidth and time) and our controls in the library work.

DNS resolution is the OS's job. This hijacking of function is a pain. Has no one at Mozilla ever had to deal with the realities of using their browser in an organization?

<comment><USER25> AFAIK the ESR (business release) does not have this on by default

<comment><USER51> ESR is extended support and we use the regular Firefox. Firefox was never required by any vendor we use to remain compatible so we didn't have to be on the ESR branch.

<comment><USER25> [https://support.mozilla.org/en-US/kb/canary-domain-use- appli...](https://support.mozilla.org/en-US/kb/canary-domain-use-application- dnsnet) You can use this if you run a DNS server

</comment></comment></comment></comment><comment><USER52> I have some unusual, from the normal browser user perspective, DNS stuff and this just leads to a bunch of questions.

My gateway has a bunch of static DNS entries for internal hosts, which are all in a fake top-level domain. How will resolving these work if the request goes to CloudFlare? CloudFlare obviously doesn't know about my internal domain. Currently my gateway resolves what it knows about and uses my ISP's DNS to resolve what it doesn't.

Pi-Hole is presents a similar problem.

Finally, if DoH is the future, how do I run my own DoH server which can resolve internal hosts? Does such software even exist yet? How do I point Firefox at this DoH server? The relevant Wikipedia article[0] points to a list of public DoH servers I can use, but offers no insight as to what software I'd use to run one for my own use.

[0] [https://en.wikipedia.org/wiki/DNS_over_HTTPS](https://en.wikipedia.org/wiki/DNS_over_HTTPS)

<comment><USER5> cloudflared, knot-resolver, stubby, unbound, CoreDNS can be run as DoH and/or DoT stub and/or recursive resolvers, locally.

The easiest stub resolver to setup would be nextdns' client: [https://github.com/nextdns/nextdns](https://github.com/nextdns/nextdns)

</comment></comment><comment><USER53> I'm gonna get some heat for this, but that's OK; it's my honest opinion.

I can't really think of a better way to hamper progress on an open specification then by delegating the problem to some private corporation; especially one that has a penchant for censorship.

If more than .0003% of people actually used Firefox, we would have to worry about Cloudflare taking over the entire Internet. So it's probably a good thing Mozilla ruined their brand over the past decade.

I would be willing to bet money that Mozilla is getting paid millions of dollars by Cloudflare for this.

In the meantime, this is the final straw for me. I'm done with Firefox for life. I haven't used anything but Firefox since 2007... 13 years...

</comment><comment><USER54> How does this work with hosts that are not resolvable outside your own network? If I tell firefox to go to internalsite.mycompany.com - <USER2> resolves internally, but not outside our network - how is firefox going to resolve it, if it's not using our DNS servers?

<comment><USER55> Correct.

In order to preserve compatibility, Firefox's implementation has a "fallback" where if it sees that it can't resolve a domain, then it will fail back to using the system-configured DNS provider.

<comment><USER56> You can also exclude specific domains but at this point they have to be written in about:config.

[https://support.mozilla.org/en-US/kb/firefox-dns-over- https#...](https://support.mozilla.org/en-US/kb/firefox-dns-over- https#w_excluding-specific-domains)

It looks like Firefox Policies can be used to enable, disable, or specify the DoH provider but cannot yet specify excluded domains.

[https://github.com/mozilla/policy- templates](https://github.com/mozilla/policy-templates)

</comment></comment></comment><comment><USER57> So now just one company will have access to all the data from 99% of firefox users? I don't see how giving so much power to just one entity is better for our privacy.

Previously if I used my computer at home, coffee shop, work, hotel etc it would be very hard if not impossible for one company to get all of my browsing history. And giving it all to one company is a better idea?

<comment><USER58> And many routers also cache local DNS requests. So unless someone can see every router that you were served by at every airport, hotel, coffeeshop, they really can't see where you've been browsing by examining DNS requests.

We're _much_ less safe having cloudflare know all.

</comment></comment><comment><USER59> Seems very marginal for privacy when people in the middle can still see the IP you're connecting to, just not which DNS record you may have retrieved the IP with.

<comment><USER60> Run wireshark on an ssl connection. The server certificate is sent in plaintext. It includes the DNS name of the server you connected to.

DoH would make sense in a world where that was fixed. (Though DNS over TLS is also a thing, and makes strictly more sense than DoH from what I can tell...)

<comment><USER61> > The server certificate is sent in plaintext.

Not with TLS 1.3, which moves the server certificate to the encrypted part of the handshake.

</comment></comment></comment><comment><USER62> Until recently, I was working at CZ.NIC and people who are working on Knot DNS resolver were in the next office. The easiest way to get them crazy was to mention DNS over HTTPS. They hated it passionately.

<comment><USER4> Many DNS folks hate it; [https://twitter.com/paulvixie/status/1053765281917661184](https://twitter.com/paulvixie/status/1053765281917661184)

</comment></comment><comment><USER63> I wish they wouldn't do this. I trust my ISP more than I trust Firefox and whatever company they chose for DNS over HTTP.

This "We know better than you" attitude is why I stopped using Firefox so many years ago. I switched back recently, to stop using Chromium, but I have a growing list of annoyances, and it might be time to give NeXt Browser a chance again, or see what else is out there.

<comment><USER64> "Firefox defaults to Cloudflare, though you can change this."

So it's whichever company you choose for DNS, rather than the company chosen by your ISP. Many of us were already choosing not to use the ISP's DNS, for reliability, but with this feature the ISP can't eavesdrop on that.

<comment><USER30> Most of us chose a company already, our ISP (or in my case a mixture of first + third party). Firefox are defaulting to their choice, no?

Presumably they give an option page on which to choose it - even they wouldn't be so egregious as to hide such a massive change without positive user consent, surely?

</comment></comment></comment><comment><USER65> The most important thing this prevents are DNS based MITM attacks where they intercept your request and send you an IP address they control.

<comment><USER33> DNSSEC anyone? Or DNSCurve, or DNSCrypt.

<comment><USER26> DNSSEC does nothing to provide DNS privacy, nor does it address MITM attacks between endpoints (your phone and laptop) and DNS servers; it's a server-to- server protocol. DNSSEC is moribund; practically no important sites run it.

DNSCurve/DNSCrypt are directly competitive with DoH, but in a post-DoH world, both are probably dead-letter standards.

</comment></comment></comment><comment><USER66> For people in Switzerland I recommend using the DNS/DoH services provided by the Digitale Gesellschaft [2]. There is no logging and no block list. [1]

[1] [https://www.digitale- gesellschaft.ch/2019/04/11/oeffentliche...](https://www.digitale- gesellschaft.ch/2019/04/11/oeffentliche-dns-over-tls-und-https-dns-resolver- neuer-service-der-digitalen-gesellschaft/)

[2] [https://www.digitale-gesellschaft.ch/dns/](https://www.digitale- gesellschaft.ch/dns/)

</comment><comment><USER67> I predict that DoH will break many enterprise infrastructures that rely on custom DNS servers. Unwary sysadmins that update Firefox will be in a lot of trouble when they switch this on by default.

We ourselves have a custom DNS setup with an only internally resolvable TLD as a security measure, so this change will break our infra for all Firefox users (thankfully we're in the EU so we're spared, for now).

Good thing that Cloudflare wants to centralize DNS and access control anyway, so those enterprises can just switch to their proprietary DNS service and VPN replacement, I guess ;)

<comment><USER55> Firefox by default is configured with a fallback option, where if resolution would fail, it will fallback to the system-provided DNS servers. So your internal TLDs are safe.

Additionally, if you've setup Firefox to be installed with Firefox for Enterprise, DoH is disabled by default and you've got nothing to worry about. DOH is able to be configured through GPO as well, allowing the use of a custom server.

<comment><USER68> And that is even more dangerous, it would mean that if for some reason an identical domain extists on the internet (or somebody registers it to do an attack) then all the hosts will connect to the malicious external domain and not the correct host in the internal network. Local hosts should be resolved FIRST.

Also cloudfare this way gets the DNS names of your internal hosts, you are leaking information that otherwise would be private, and system administrator will probably not think about that!

Also with that option is not really secure at all, if somebody wants to intercept your DNS requests he can simply block the IPs of Cloudfare DNS over HTTPS server and then read the DNS requests unencrypted.

<comment><USER69> You should only use a domain you own or something that isn't routable. You can't blame FF for that

<comment><USER70> That was an issue with .dev and then google acquired the TLD.

<comment><USER71> .dev isn't an rfc2606 reserved TLD, so it shouldn't have been used for internal domains in the first place

<comment><USER70> Replying to the part about 'something that isn't routable'

Not because something is not routable means that there won't be issues.

</comment></comment></comment></comment></comment></comment></comment><comment><USER72> I recently upgraded my home router to DNS over HTTP (pfSense now supports it pretty easily).

I started with Quad9 (18.104.22.168) and Cloudflare as a backup (22.214.171.124).

One thing I noticed right away was that my ping times to Cloudflare ended up being way faster (15ms) compared to Quad9 (50ms). Cloudflare seems to have a presence in my local area.

Now both are good, but adding a 50ms delay (+TCP handshake + TLS setup and teardown) seemed like a non-trivial amount. I ended up putting Cloudflare first.

There was a noticeable difference, something to think about if you decide to set this up.

<comment><USER5> > Cloudflare seems to have a presence in my local area.

In case you're interested in rolling out your own low-latency DoH: I run a DoH stub-resolver on Cloudflare Workers [0]. Their free-tier covers one device's worth traffic. You could do so on stackpath, too [1].

[0] [https://news.ycombinator.com/item?id=22208988](https://news.ycombinator.com/item?id=22208988)

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

</comment></comment><comment><USER73> Can someone please explain why there can't be a DHCP or RA option for which DoH server to use? Why are we going out of our way to make sure the sysadmin has to configure each and every piece of software on each and every single PC rather than just set it one in a centralized location, like every other networking option?

DoH will leave my machines unable to resolve all my internal domain names, right?

<comment><USER74> Is it a big deal to have your internal domain names accessible externally? Many (though not all) DNS server allow private IPs in DNS.

<comment><USER75> It creates a vulnerability for external devices -- they're trying to communicate with myhost.mydomain.com but really they're talking to whatever device has the same IP address on the network they're attached to.

Some DNS hosters disallow private IPs. Some public resolvers and consumer routers will filter out responses containing private IPs.

</comment></comment></comment><comment><USER76> A great step indeed for websites that use static IP for a single resource. Websites that uses Server Name Indication TLS extension for shared hosting force clients to send the hostname in plain-text during TLS handshake which could be sniffed. (Reliance Jio in India is already doing it [https://cis- india.org/internet-governance/blog/reliance-jio-...](https://cis- india.org/internet-governance/blog/reliance-jio-is-using-sni-inspection-to- block-websites)).

The Same thing OCSP Stapling (Online Certificate Status Protocol) extension which also sends the hostname.

Cloudflare crafted a solution for this by storing the public key of the target website along with the DNS record. So during DoH when the user asks for IP of a given host, it can also get the public key of the host. User then establishes the TCP, encrypt the SNI extension & OCSP with the public key and starts the TLS handshake.

Though ESNI doesn't seem to provide perfect forward secrecy it is a leap forward.

</comment><comment><USER77> If you're about to comment on how dumb this is because SNI isn't encrypted please halt and search "ESNI"

<comment><USER78> Draft only. OpenSSL doesn't support it - because it's still a draft. So as of now, ESNI does not provide anything.

<comment><USER77> It is moving forward, albeit slowly. With or without DoH/DoT, non encrypted SNI is a problem, and DoH/DoT have privacy improvements in their own right.

<comment><USER78> "moving forward" doesn't help anyone. Standards and more importantly, implementations count.

In every DoH/DoT discussion there is someone who mentions ESNI, but without major level support this is a vague promise. Of course DNS encryption is still useful even without ESNI.

</comment></comment></comment></comment><comment><USER79> What difference does it make? Even if the DNS queries are completely encrypted, subsequent HTTPS requests made after domain resolution will contain the destination domain (but not the path or request body) in the clear. What makes you assume that ISPs aren't already collecting this information?

<comment><USER80> The Host header is encrypted when using HTTPS and the SNI is encrypted when using ESNI. In the best scenario (DoH + HTTPS + ESNI), ISPs only get the destination IP, not the destination domain.

<comment><USER81> The how many IP does pornhub.com have?

<comment><USER80> Quite a few, I guess, but you'd probably be more concerned about how many other domains share the same IP addresses rather than about how many IP addresses this domain resolves to. And the answer seems to be thousands of domains — which in this case doesn't help much as they seem to all be related, but which in other cases might (eg. shared hosting, CDNs…).

</comment></comment></comment></comment><comment><USER82> We just published our proposal of a decentralized DoH resolution to address this exact problem of single-point-of-trust/failure. As Firefox is looking for more reliable partners for their "Trusted Recursive Resolver program", we strongly believe and hope that "K-resolver" will be seriously considered as an option to improve DNS privacy for not only Firefox users, but also the general Internet.

[https://twitter.com/NP_tokumei/status/1220802795512578048?s=...](https://twitter.com/NP_tokumei/status/1220802795512578048?s=20)

[https://arxiv.org/pdf/2001.08901](https://arxiv.org/pdf/2001.08901)

</comment><comment><USER83> The overhead of setting up and using an https connection is massive compared to DNS which can fit in a UDP transaction.

Do they establish a connection and leave it open for a long period? Supporting that would be a big commitment on the part of the resolvers.

<comment><USER23> _Small_ DNS queries and answers fit in one UDP packet, but larger ones don't and have to be retried as TCP.

HTTPS/2 over TLS 1.3 (which is the baseline you should assume for these relatively new services) is one TCP setup plus potentially 0-RTT TLS on all but the first visit.

0-RTT is safe here because a DNS query is just a question with no side effects. Replay attacks (the risk 0-RTT incurs) don't do anything:

Gumby: "What is the IPv4 address of news.ycombinator.com?" encrypted so that only DoH Server and you can read it

Server: "220.127.116.11" encrypted so that only Gumby and the DoH server can read it

Attacker: Replays Gumby's packet with no knowledge what it means

Server: Same reply, also unintelligible to attacker just like the original

For HTTPS/3 (over QUIC rather than TLS+TCP) it's UDP so the only "overhead" is from the crypto setup which is modest on even a relatively weak machine.

<comment><USER83> Thanks. I hadn't followed the development of 0-RTT which allows the server to tear down the connection.

</comment></comment></comment><comment><USER84> There aren't that many DNS names out there. Eventually we should be able to just replicate the entire DNS database (or large parts of it) to routers or even local devices. Then your lookups don't go outside of your network.

<comment><USER85> Well, it can be quite a lot of data for many network devices and then you may have outdated replication.

The current system using a cache works relatively well until you want privacy.

</comment></comment><comment><USER86> I may be late to this, but here [1] is some commentary on why DoH (DNS over HTTPS) may not be as affective as it is perceived. The article also talks about DoT (DNS over TLS) mechanism which is apparently less disruptive for network monitoring tools compared to DoH.

Can some security minded folks from the community chime in about the claims made in the linked article?

(Disclaimer: English is my second language)

[1]: [https://www.zdnet.com/article/dns-over-https-causes-more- pro...](https://www.zdnet.com/article/dns-over-https-causes-more-problems- than-it-solves-experts-say/)

<comment><USER87> The article has several good points but also some weak ones.

For example, it points out that DoH doesn't really protect privacy from ISPs because ISPs can still see what the users are doing because the ISPs route the traffic. Then, it claims that DoH weakens security because it would let users get around malware blacklists. However, this is mostly nonsense for the same reason. Malware (and other legitimate blacklisting) can and should be blocked even when hard-coded IP addresses are used.

The point about the logistics is very true, though. I won't use DoH at home because I operate my own DNS that contains intranet addresses not accessible from the outside Internet. DoH in Firefox would break those services.

</comment></comment><comment><USER88> I'm really looking forward to enable the feature on my personal computer. But as long as Firefox DoH ignores my /etc/hosts configuration, I won't use it.

I hope it's just a matter of time before they fix this :)

<comment><USER89> Yes please, I'm using /etc/hosts all the time when I setup new servers and to access some servers with no name on customer VPNs.

</comment></comment><comment><USER38> I'm getting pretty pissed off the with the arrogance of US internet tech companies sidestepping formal protocol design & industry adoption because it isn't moving "fast enough" for them. Without ESNI, DoH is essentially meaningless for the class of privacy invaders it is supposed to combat against. By the time ESNI is out, DoT would have had enough time to mature and gain wide enough adoption.

DoT is better because at least it's obvious if your ISP/Gov is blocking port 853 (at which point you install a VPN or run your own resolver somewhere and tunnel to it or swap provider or move country). Meanwhile you get all the usual benefits of decentralised DNS resolution and don't have to worry about the unforeseen overhead and bullshit DoH is going to spwan.

Firefox is an app for browsing websites. What business does it have pushing a half baked compromise solution that undermines core infrastructure, creates a false sense of privacy and introduces second order effects that will result in DNS lookups being centralised in to the hands of a few giant US corporations (at least changing to 22.214.171.124 or 18.104.22.168 was opt-in).

Also can't wait for the inevitable instances of Cloudflare deciding not to resolve certain domains (effectively becoming the de-facto arbitrator of what most FF users can and cannot see on-line). For a preview of that, try going to archive.is with 188.8.131.52 as your resolver.

Ultimately, all of this is moot anyway (even once ESNI arrives). Regardless of DNS, your device still needs to connect to an IP. Entities interested in where you are going will still be able to get reasonable insight by simply correlating IP addresses and CT logs ([http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity- is-...](http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-not- private/)). The only decent solution to this, and available right now, is a VPN (at which point DNS privacy is automatically solved for you).

If Paul Vixie thinks DoH is a bad idea then... it's a bad fucking idea: [https://twitter.com/paulvixie/status/1053765281917661184](https://twitter.com/paulvixie/status/1053765281917661184)

<comment><USER90> Seems to be a trend lately. Google recently announced they will start blocking downloads from http websites. Doesn't sound like a bad idea -- but isn't this more a discussion for IETF as well?

<comment><USER38> The discussion should be around improved UX/UI and better protocols rather than treating people like idiots and abusing your power to unilaterally force behaviour changes on web content providers and consumers.

The more I think about it the more I realise Microsoft's and AOL's instincts were right. Make the internet a walled garden and insert yourself as the gatekeeper.

Their mistake was to do this too early. ~25 years later and the people are now finally ready and willing to allow billion dollar coporates to overtly "manage" their on-line experience for them. Companies love this too because it removes yet one more unseemly shackle from their ambition (i.e. that of needing to work collaboratively with potential competitors) while at the same time providing them with a nice vector to defend their quasi monopoly.

</comment></comment></comment><comment><USER91> Cloud flare is American and we know since the PRISM scandal that US based tech companies are directly plugged into the NSA, and everybody in the chain will deny it under the threat of prison.

So, if this rolls out 'as-is' in any other country than the US, we will go from "all DNS requests are clear text, but dispatched among many entities" to "DNS requests are encrypted, but all read and controlled by american agencies".

We (may) have gain (some) privacy (maybe). But we also (certainly) gained a serious dependency.

<comment><USER92> NSA don't factor into my personal threat model _at all_ where random ISPs snooping and selling do. I would gladly give the NSA all of my traffic unencrypted in exchange for decent commercial privacy

<comment><USER91> I supposed not having a dictatorship regime in your country history book helps to see things that way.

Given the way my country went from freedom to "regime de Vichy" in a few years, during my grandpa time, I don't want a state level entity having that kind of power.

Since the US state level entities decided they could now ignore Habeas Corpus and legitimated torture, secret courts and declared impunity for them-self, I especially don't want them to have that kind of power.

<comment><USER92> If a malicious power takes over your country they'll hit you with a rubber hose until you give up your secrets much before they give a shit about your internet history, I suspect.

<comment><USER91> Quite the contrary, as shown by as most dictatorships across the world trying to control their piece of the internet. The biggest example being the Big Firewall of China.

This let them control how people think, communicate, consume and inform them- self. But also detects anyone that could oppose the regime. Or make a graph of all allies, suspects, etc.

Then you hit them with a rubber hose :)

</comment></comment></comment></comment></comment><comment><USER93> One point I haven't seen covered yet is split-horizon DNS where there are actually servers listening on both sides of the horizon (though possibly different ones).

Example #1: I have a personal server running at home that is reachable from the internet through a PageKite tunnel. It's reachable through a public address of the form [https://xyz.pagekite.me](https://xyz.pagekite.me). The connection is secured by a Let's Encrypt certificate, which means I _have_ to use this address to avoid HTTPS errors and the domain has to be reachable from the internet so I can fulfill challenges.

However, I'd also like to access the server from my LAN without an unnecessary round-trip through the internet: I might want to avoid unnecessary data costs or display certain content only available to LAN clients. So from the internet, the domain should resolve to the PageKite tunnel, but inside the LAN, the domain should resolve directly to the server's LAN address.

This is relatively easy to accomplish using traditional DNS: Just set up a local DNS server that serves the LAN address. However, how do you do that with DoH?

Example #2: You want to set up an internet router at home. The instructions ask you to connect to www.routerlogin.net to pull up the web interface. The domain is split-horizon: When requested through the router, it will resolve to the router's internal address and be served by the router's internal web server. When requested from the internet, it will point to a generic info page from the vendor.

Now with DoH, you'd always see the generic info page, even when connecting through the router.

</comment><comment><USER94> This is kind of a sub-issue but from the infographic in TFA:

>Q. Will DoH lead to a greater centralization of DNS, which will be bad for the Internet as a whole?

>A. We agree that centralization is bad for the Internet. Today in practice, DNS is >centralized because consumer devices are locked to the DNS service of the ISPs. >And just five companies control over 80% of the US broadband internet market.

For one thing, 5 independent providers _within the same country_ is not exactly centralized in my opinion. As far as I understand it Americans don't always effectively have the choice of which ISP they can use, but that's not a technological problem. You won't solve monopolistic and anti-competitive practices with a new layer 7 protocol.

Furthermore what does Mozilla mean by "locked to the DNS service of the ISPs", do they block DNS queries to other services? Here in Europe I can switch to a different DNS any time I want. Sure, it's easier to stick with the defaults and most people will do that but "locked" is a strong word which I suspect is inaccurate in this case.

By that definition of "centralized" you could argue that email is effectively centralized since most people just use the free service provided by a handful of providers.

>The immediate impact of Mozilla enabling DoH in Firefox will be less >centralization, not more because it shifts traffic away from large ISPs, and >provides users with more choice, while respecting enterprise DNS >configurations.

So 5 ISPs meant that the service was effectively centralized, but (at this time) two competing DoH services with Cloudflare selected by default is "less centralization"?

<comment><USER95> > do they block DNS queries to other services?

Some providers use MitM attacks on DNS queries, to do things like block content or replace NXDOMAIN with SPAM. (Probably obviously, this is not possible with DoH.)

</comment></comment><comment><USER96> Will /etc/hosts still work? I was surprised it is ignored completely after DNS over HTTPS is enabled. I don't see why it can't first consult this standard local source regardless of DoH. This is making development more painful. Similarly to how Android stopped supporting locally-installed custom CA certificates globally for all apps, making HTTPS debugging impossible. :(

</comment><comment><USER97> I guess most of the people against this change have been lucky enough to never live in a place where the internet is actively censored.

It must be nice living in a place where you don't have to worry about access. But for many of us, there's no point in privacy without access.

<comment><USER98> Why not make it opt in then?

</comment></comment><comment><USER99> Opera added the same option today too [https://blogs.opera.com/desktop/2020/02/r2020-opera67-tidy-y...](https://blogs.opera.com/desktop/2020/02/r2020-opera67-tidy- your-browsing/)

</comment><comment><USER100> [https://bugzilla.mozilla.org/show_bug.cgi?id=1614751](https://bugzilla.mozilla.org/show_bug.cgi?id=1614751)

Firefox won't bother checking the canary domain if the user clicked "OK" to the DNS-over-HTTPS question.

<comment><USER101> ITT: Some very annoyed sysadmins that didn't read the enterprise deployment guide and who apparently rely on "pretty please don't exfiltrate data" as their enforcement mechanism.

Are they surprised that a change made in the name of preventing your local network operator from slurping your DNS information doesn't create a way for local network operators to just ignore DoH and slurp DNS information?

</comment></comment><comment><USER102> If you want to control this via Group Policy, or system-wide, you can use the following policy:

[https://github.com/mozilla/policy- templates#dnsoverhttps](https://github.com/mozilla/policy- templates#dnsoverhttps)

</comment><comment><USER103> I want it to do something when stuff doesn't work. Replacing one thing with another might improve the situation (or not) but the real problem is failure imho.

To needlessly ramble on a bit: A simple header or html tag could "ok" all or specific alternative ways of distributing and provide conditions. Say, if my blog is unavailable for > 3 months you can p2p distribute it by [for example] fast, medium or supper slow means. Currently I look at articles I wrote long ago. I've carefully selected 10-30 links of which 20% still work(!?) I've picked them specifically because they are probably unfamiliar to those interested in the topic.

</comment><comment><USER104> So basically instead of hundreds of different DNS systems, all an unsupervised person in government or law enforcement has to do is search one or two distinct DNS services for all your queries over the past years.

They can claim all they want it's not logged or anonymized but that's like believing the same claims by your VPN service, you have no idea if they are operating under a silent security order from some agency.

And unless I am missing something, unless you are tunneling though VPN, proxy, etc. your ISP is well aware of every IP connection you do, they simply just rDNS if they want to know.

</comment><comment><USER105> I don't know why DNS over HTTPS breaks my brain.

I understand how DNS, HTTP, and most of HTTPS work at the wire level (a little fuzzy on how the decisions are made, though). It's just using a different transport strategy to acquire an IP address from a FQDN. Every step of that process has a logic to it, and none are mutually incompatible.

And yet... my brain keeps alerting, asking what kind of madman does the HTTP before the DNS. Maybe it's the "to make an HTTP connection, first you must make an HTTP connection" part that gets me. I can't say. But it just feels wrong, despite being more sustainable.

</comment><comment><USER106> Anecdata: I frequent a local café that only offers Facebook Wi-Fi, which requires you to "check in" on Facebook in order to receive Internet access.

I don't have a Facebook account but with Firefox TRR, 'google.com' is the only address that resolves just fine — so I search Google (or directly from the address bar) for a website, click through to the result, and the ensuing session is allowed. Rinse and repeat for each new tab.

Any direct attempt to browse otherwise (including to google.com with other browsers) always hits the FB captive portal.

</comment><comment><USER107> Does anyone know when something like this might come to Brave?

<comment><USER108> I know Brave is supposed to be a privacy-centric browser, but their plan for advertising seems at odds with that. Advertising is a slippery slope and I wonder how long before these promises are eroded or outright reversed.

> 100% of your ad spend is placed for active users that opt-in to a rewarding > private ad experience.

> Craft effective offers and provide captivating full-page experiences > directly with consumers in Brave's Private Ad Tabs.

> Brave uses local machine learning with the browser profile to only place ads > in optimal conditions. Ads are matched to opportunities, and users become > partners instead of targets.

> Private ad matching efficiently matches ads directly from the device, > without breaching personal information.

[https://brave.com/brave-ads-waitlist/](https://brave.com/brave-ads-waitlist/)

<comment><USER109> I think the only reason Brave wasn't immediately laughed out of the room on HN as a browser that literally shows you its own ads is because they brilliantly have their own cryptocoin (BAT) so that anyone who thinks their $10 investment will buy them a lambo one day will come out of the woodwork to mention the browser.

The same thing you saw happen to any other cryptocurrency. It basically kills all earnest conversation.

The Brave thought this was worthwhile makes the whole thing feel scummy to me. But we are way off topic.

<comment><USER110> BAT is necessary in order to allow decentralized payments from users to site operators with no intermediary. No centralized alternative system would be sufficient for Brave's use-case.

</comment></comment></comment></comment><comment><USER111> Bottom of the infographic appears to contain a new Firefox logo. Looking at their website, it appears this is actually the logo for the larger (and somewhat confusingly named) Firefox suite of products, to distinguish them from the Firefox browser. Which is nice I guess, but what most people see is the browser icon, and this logo would be far preferable to the current one in that capacity.

</comment><comment><USER112> Can someone at Mozilla explain why they present what is purely textual content as a PNG?

I mean, this is ridiculous: [https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna- ssl.com/net...](https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna- ssl.com/netpolicy/files/2020/02/Final-DNS-over-HTTPS-05-1.png)

<comment><USER113> It even seems to break inline links, like in the "split-horizon" section:

> System administrators can find relevant documentation here.

I'm pretty sure "here" should be a link, but of course that doesn't work when the marketing department uses a PNG instead of HTML.

I'm also surprised that Mozilla / the CDN don't optimize the PNG. `zopflipng` reduces the size from 285K to 153K.

And of course it's named "Final-DNS-over-HTTPS-05-1.png".

<comment><USER30> I clicked.

They could've used an image map. /s

</comment></comment></comment><comment><USER114> Oh well, I just hope this enforcing new third parties to my internet browsing doesn't catch on.

Guess I will disable it.

</comment><comment><USER115> how long does Cloudflare or NextDNS retain dns query logs?

<comment><USER116> Also, why limit the choices to just those two? If you're going to provide an app-based service for this, why not allow the user to use any DoH server they want to use? Did Mozilla make some kind of deal with Cloudflare and NextDNS?

<comment><USER117> The Firefox settings UI allows the user to set a custom DoH server. For example, Quad9 is yet another DNS provider that hosts DoH servers:

[https://www.quad9.net/doh-quad9-dns-servers/](https://www.quad9.net/doh- quad9-dns-servers/)

</comment></comment></comment><comment><USER118> More information about data retention requirements for DOH-resolver partners:

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

</comment><comment><USER119> This thing should never be on by default. Mozilla here has decided for me that it is an acceptable layering violation on my system/network. IMHO, this thing is bordering on malware.

</comment><comment><USER107> Does anyone know when Brave Browser might get something like this? I like the thing that on issues like this, folks at Brave and Mozilla are in similar pages (pun?).

</comment><comment><USER120> I'm wondering, is the US a phased roll out or is this in light of government mandated censorship in the UK, Australia, New Zealand, India, China, etc.?

<comment><USER121> The last entry at their FAQ posted today indicates that they're focusing on US-only and does not commit to worldwide plans. (But it's also buried in an image where I can't copy-paste, ugh.) Link to that FAQ:

[https://blog.mozilla.org/netpolicy/2020/02/25/the-facts- mozi...](https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozillas-dns- over-https-doh/)

<comment><USER122> I think OP's question is _why_ it is US only.

The only reason I can think of (or I can understand) is regulation and laws, but it doesn't seem to be the case.

</comment></comment></comment><comment><USER123> Is there a way to ensure the ISP opt-in parent control is not going to be abused, effectively turning it into a way to bypass DoH at all?

<comment><USER27> No, well, maybe, depending on your country. I know some countries have laws preventing ISPs from interfering with content, but even those laws do not apply to technical measures, like DoH, they are still completely free to block it.

</comment></comment><comment><USER124> I run my own DNS server. So I trust my own DNS way more than I trust Cloudflare. Is there a way to stop Firefox from using DNS over HTTP?

<comment><USER125> Yes, it supports custom resolvers, see the section "Switching Providers": [https://support.mozilla.org/en-US/kb/firefox-dns-over- https](https://support.mozilla.org/en-US/kb/firefox-dns-over-https)

</comment></comment><comment><USER103> How will courts blocking domains work after this?

<comment><USER11> Much more effectively: A single party to issue an order to instead of a great number.

<comment><USER103> My ISP was ordered to block the pirate bay and its mirrors. I just enabled DNS over https and I'm able to access it again.

</comment></comment></comment><comment><USER126> So all WiFi logins which abuse & hack DNS weaknesses like airports & hotels don't work with Firefox anymore?

</comment><comment><USER127> I think DoH itself is a good thing. What seems fishy though is hardcoding Cloudflare as the default DoH service.

<comment><USER128> It's absolutely not hardcoded.

<comment><USER127> Not technically, but you know what I mean.

<comment><USER128> In this forum, only you know what you mean until you write words. When you write a word like "hardcoded", which means a specific thing, is it not reasonable to expect people to think that you meant "not really hardcoded".

As one of my favorite people told me once: words mean things. The words we use matter, as humans do not have telepathy.

<comment><USER127> Yeah, you're right.

</comment></comment></comment></comment></comment><comment><USER129> Great. I already enabled it explicitly.

</comment><comment><USER130> What's to stop ISPs from simply setting the canary and turning off DoH?

</comment><comment><USER131> I wonder what the implications of DoH will be for TCP-over-DNS ...

</comment><comment><USER132> How likely is it that the other browsers will eventually do this?

<comment><USER133> Very likely. IIRC, it's working its way into Chromium, and once it's there it will be everywhere.

[https://www.chromium.org/developers/dns-over- https](https://www.chromium.org/developers/dns-over-https)

</comment></comment><comment> Funes- If I2P was widely used, we wouldn't need this.

</comment><comment><USER134> So FireFox will now not simply query my internal DNS server? Good luck with that, because I've disabled outbound DNS except from that server.

Guess I'm not using FireFox any more. :(

</comment><comment><USER135> Due to the Cloud Act, this is probably the end of Mozilla as a browser used in a business setting for non-US companies.

A naïve protocol capsuled inside a stupid and dangerous protocol.

</comment><comment><USER136> is this only on desktop ? i cant find this setting on android

</comment><comment><USER137> Can you disable this?

<comment><USER138> What are some reasons why someone would prefer to or need to disable it. Just curious.

<comment><USER139> I'm not sure if disabling it is the right way to go, but I do not plan on letting Firefox ship all my DNS queries to CloudFlare. I do not trust Cloudflare any more (and maybe a little less honestly) than my ISP.

I do want a container with my own DNS-over-HTTP running on my own hosted VM (or Digital Ocean, or Vultr or Linode or whoever) and I'll ship my DNS queries there.

<comment> hilbert- There is an interesting guide (in French) on best-practices to get DoH up and running with dnsdist ([https://dnsdist.org](https://dnsdist.org)) here: [https://www.bortzmeyer.org/doh-mon- resolveur.html](https://www.bortzmeyer.org/doh-mon-resolveur.html).

You might also be interested in looking at [https://dnsdist.org/guides/dns- over-https.html](https://dnsdist.org/guides/dns-over-https.html)

</comment></comment></comment></comment><comment><USER140> In an effort to further protect the privacy of its users online, Firefox has begun rolling out encrypted DNS over HTTPS (DoH) by default for US-based users.

To be honest I don't use Firefox that much compared to Chrome.

</comment><comment><USER141> Glad I don't use it.

</comment><comment> chupa-chups I just uninstalled firefox and switched to chromium for good (or bad).

</comment><comment> mike-cardwell Anybody have any stats on what percentage of websites and or percentage of global web-traffic hits websites that are hosted on their own personal unshared IP, vs those that are hosted on shared IPs?

Because if 90% of websites are hosted on unshared IPs, then this whole thing about DoH and/or ESNI providing some sort of privacy is complete bunk. An ISP can still see exactly what website you're visiting when connecting to an unshared IP by virtue of which IP you're connecting to. The methods for mapping a raw IP to a website when that IP is unshared, are numerous and effective.

DoH/ESNI only provide privacy if the vast majority of websites are on shared IPs.

DoH/ESNI only provides privacy if we have already (or are planning to) centralise web traffic behind a handful of gatekeepers.

<comment> mike-cardwell Multiple downvotes because I pointed out that the whole promise of DoH is that it stops ISP's from being able to see and sell which websites you're visiting, but ISP's will still be able to see and sell which websites you're visiting, unless we stick most websites behind shared IPs.

I guess that's step 2 in "advancing" the web.</comment></comment>