Hacker News Reader

Comment by lovelearning | Hacker News Reader

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.

View on HN

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.

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

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

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.

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.

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.

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?

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

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

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

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

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?

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.

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.

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/

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.

Firefox has no issues with local domains and DoH. It makes a DoH request first and when that returns nothing it tries regular DNS.

That is an issue.

Apart from the wait.

Spaff hostnames to cloudflare, fail, then try harder.

Users expect

hosts: files,dns

Admins expect dns to work.

FireFox should not be fscking with network config.

If they do, they should try not to break users first.

Firefox is borken. Security is not improved. My DNS requests never leave the LAN.

Half of your comment doesn't make any sense but for the rest of it, its just incorrect. The change in firefox hasn't broken anything, security is certainly improved in combination with other efforts like encrypted SNI. And yes, your dns requests always leave your lan at least once. You can run your own DNS server locally but that dns server has to ask other servers for the data since it can't store a local copy of the entire dns system. A local dns server is just a cache but with a few users its likely not doing any more than your browser cache.

DoH breaks anything that is going on in your BIND or NSD server. It bypasses them, it has broken that. If it does DNS first, then if that fails does /etc/hosts, its broken that too.

If I, or my company, or ISP has anything special in hosts or DNS, e.g. load balancing, name mapping, breaking facebook.com, things like that get bypassed.

DoH over HTTPS is slower than a lookup to /etc/hosts, and probably slower than a lookup to a locally cached DNS resolver.

Security is not improved by FireFox bypassing my network admins DNS rules.

Most DNS queries do not go over the Internet, unless you have DoH or have set special DNS servers. My ISP provides IP access to the Internet and DNS, like almost all ISPs. It not to do with local caching (which does add security), if I query foo.com that query goes to my ISP, not via the Internet, my ISP knows I asked for foo.com and then then the routes my IP packets there.

My ISP has to lookup DNS on the Internet to resolve them if it is not in caches but that lookup is not associated to me.

When I connect to a corporate network all my DNS goes over VPN if any information is required from the Internet again that is not associated to me.

Cloudflare might be running a more secure DNS resolver at the other end than my ISP, but it might not, its rules have to apply to the whole world so they cannot be tuned for me and my security preferences.

After DoH, all DNS goes over the Internet, even quires that eventually are resolved locally. Cloudflare now know I'm going to foo.com and so does my ISP, or VPN provider, I don't see how security has improved. Its just sending information to a commercial partner of Mozilla's in addition to my ISP. Some informationits getting that before my ISP did not get.

Plus HTTPS is not infallible.

DoH is more secure than DNS in plain text over the Internet, but that is very rarely the case.

DNS is also not a significant risk to browser users. I have never had a DNS response faked, to any HTTPS site it would not work, so why bother.

There isn't much risk, its not more secure, and it breaks stuff.

Opportunistic security that can be disabled by attackers is not really security.

I've noticed some problems with eSNI so far unfortunately. Some domains like discordapp.com have some access points with eSNI enabled and some without, so when clients access the ones without eSNI, they believe that they are under attack. I cannot wait for it to be finished and implemented though, it would be a huge benefit for the privacy of millions.

Currently only Cloudflare implements it but that's due to eSNI still being a draft.

Wow, I had no idea encrypted SNI was a thing. That's very good news, because without it, DNS over TLS is pretty useless.

I wonder what the implications will be for TCP-over-DNS, which besides bypassing firewalls, can also provide anonymity in a different way.

TCP-over-DNS, together with the draft RFC for encrypted resolver to authoritative communication, altolows for more end-to-end style encryption. Clients could do their own secure resolving without relying on a central service.

> Clients could do their own secure resolving without relying on a central service.

So in other words: privilege escalation.

Notice that this page says they are only rolling it out in the US right now. I guess it'll be available elsewhere soon?

The features are available everywhere to everybody but are not enabled by default. The only difference for US users is that they're enabled by default.

My problem with FF's implementation of ESNI is that they tied it to DoH the last time I checked.

These are separate features and should be decoupled accordingly.

https://bugzilla.mozilla.org/show_bug.cgi?id=1500289

I'm surprised that they wouldn't block the DNS providers in your country though?

Just 2-3 years ago, normal DNS to CloudFlare or Google DNS were enough to bypass my ISP's DNS redirection. Then those got disabled and while I switched to DoH, many others switched to paid VPNs. Now they've moved up to SNI blocking. They may catch on to the trend and block DoH IPs too if DoH becomes popular.

Frankly, if your ISP is that aggressive, your best bet is a VPN. DoT and DoH will always offer imperfect privacy even with widespread ESNI.

It's for bypassing banned sites

VPNs are routinely blocked in China and elsewhere.

Which country are you in/which countries do you see this happening in if you don’t mind me asking?

Won't help if cloudflare sticks the resolver on the same IP range as regular cloudflare sites. Countries would have to choose to block most of the internet.

I think China has demonstrated that countries are willing to do that.

China is a special case though. They're large enough to populate their own internet with things. Most countries aren't that large.

If the ISP (or Nation) is willing to block google or cloudflare IP-ranges then you will have to be a moving target. Using tor and similar. For normal shitty ISPs thats not an option

Cloudflare and Google's dns resolvers got a lot of adoption bc they provided a way for normal people to get around censorship, but they're inherently censorable bc they're run by centralized companies. There are new initiatives aiming to create a distributed dns layer which are promising like https://handshake.org.

And the distributed DNS layer will get censored soon enough if it gets traction. If you need proof, look at how TOR is doing in china.

Security is not binary, it's a spectrum based on cost. It's the same for censorship-resistance. If Handshake increases the cost of internet censorship for every country in the world, then it will have succeeded even if it's still possible for countries like China to censor it.

China was a special case. There are smaller countries seeking to do the exact same thing now. Russia, for example.

Building your own infrastructure seems viable even for small countries.

Reply on news.ycombinator.com