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.

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.

Don't take it in some wrong way, but most programmers have no idea about networking; for them, IP addresses are just some numbers.

Yes, are explaining to our colleagues what IP address, subnet, route, or interface are.

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

--Someone with a decent understanding of networking

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.

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.

You're not alone. That said, I highly recommend reading and referencing "High Performance Browser Networking" by Ilya Grigorik^1, it's accessible, detailed, accurate, and useful in the extreme.

1 https://hpbn.co/

Fire up a Linux VM and check out the named howto. Not only will you learn a lot about dns, you'll have a working server by the end of it.

AFAIK, when one turns on DoH, Firefox's trr.mode defaults to 2. And that's the default behaviour most would want except for the ones using pi-hole et al.

In general, yes, that solves the problem for local domains. But anyone who needs to do anything at all complicated is going to have trouble with this, not just Pi-Hole users.

For example, take your average John Doe who uses Firefox. Not particularly technically competent. A new version of Firefox comes out, and all the Archive.is domains break. Who does he blame for that, and how does he solve the problem?

What's happening behind the scenes is that Firefox switched his DNS address on him without warning. And Cloudflare (the DNS endpoint used by Firefox by default) returns incorrect IP addresses for the Archive.is domains (because the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server).

Most people are using DNS provided by their ISP, so they haven't seen this problem before. I know about the problem, and my resolver (Unbound) is set to use Cloudflare over TLS for most requests, but sends Archive.is domains to Google's DNS instead. This solves the problem for me. Firefox switching to Cloudflare by default not only breaks sites like this for the average user, it even breaks my workaround that fixes the problem.

(I can't currently reproduce the problem, so maybe Archive.is caved and started sending working IP addresses. But it's the sort of problem that can happen when you start messing around with DNS. Your users will blame you if a site doesn't load in your browser, but works in other ones.)

> the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server

Why?

They have a beef with Cloudflare over Cloudflare removing EDNS Client Subnet for privacy reasons.

some prior discussion for context -- https://news.ycombinator.com/item?id=19828317

And if it happened to be that Archive.is actually had a beef with John Doe's ISP, who's to blame for that default getting picked?

Not Mozilla.

So in that situation, would Mozilla then be the good guys by adopting DoH and fixing the user's broken network level DNS?

So basically whether Mozilla is doing the right thing or not here is entirely dependent on who the archive.is operators decide to target?

What about all the services that will be fixed for users after Mozilla makes this change, due to poorly operated DNS from the provider?

Nah, the lesson is that users are going to blame you when you make low level arbitrary changes that break things when they're not capable of knowing about and fixing the technical problems that arise. The fact that a change might accidentally fix problems sometimes isn't a counter example to that general principle.

Even when the possibility of things getting fixed is substantially more likely than the possibility of things getting broken?

By default Firefox will fall back to the network resolver if DoH can't get the results, so the only way that a situation like this could happen is if someone purposely sabotages the DoH results like with archive.is.

Furthermore, what you are saying could basically be used to rationalize putting any kind of potentially breaking change behind an off-by-default configurable. Do you think the web would be the sophisticated application platform it is today if browser vendors actually had that philosophy? Would that actually be better for John Doe, to make them have to learn about the technical aspects of every new web technology before they are able to take advantage of them?

> the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server

Well, this explains why Archive.is never works...

Not sure about that; it will still send query to the open Internet first and only when it fails, it will query local resolver.

You have leaking internal hostnames there.

To be fair, it is difficult to make all parties satisfied there. I think that a bit more honesty during discussion would help.

That's a bit unfair, because this comment was obviously not addressed to the mere mortal. For you family member, a "how to" with a lot of screenshots and red arrows is probably more appropriate.

Considering the amount of people using library or Starbucks internet that needs you to use the local DNS (at least once you initially connect), maybe #2 should be the default? Or is there some risk in doing so?

If your OS doesn’t already detect the captive portal, Firefox will.

Perfect