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.
I think 1 is about OS defaults, not stuff users must know to do. People knowledgeable about privacy could always bolt things on, and that's quite orthogonal to this discussion. Rather, this is all about the people who do no installation/configuration beyond an OS and a browser.
In addition to (2), I imagine it's easier to set up a completing DoH service and get it included in Firefox than an ISP that can reach a similar number of users. So it may not always be so centralized.
> DoH providers have committed to far stronger privacy protections.
What about DNS tampering? In many countries there are different rules for taking down a website. My ISP applies different rules than 8.8.8.8, which is handy when required by law in France but not in USA.
Effectively, government-mandated tampering will be applied with much less granularity because of centralization (or bi-centralization).
DoH doesn't need to provide extra privacy to make sense (although it is a mandatory stepping stone to good privacy). It also provides a difficult to block security upgrade (as opposed to DoT, which is easy to block).
We've seen regular US ISPs hijack unencrypted DNS to insert content or replace sites entirely. We've also seen bad actors do far worse on public WiFi.
So acting like DoH is a waste of time unless every part of the privacy puzzle is online is wrong-headed. It is a huge step in the right direction for privacy, increase their costs, and will be much needed when eSNI is online. In the meantime "all" we get is a huge security improvement.
Except, not really. If you're worried about DNS tampering, DNSSEC already exists all the way up to the root servers.
If you're worried about ISPs snooping on what sites you visit, they'll continue to be able to do this even with widespread DoH/DoT and ESNI adoption. You still need to connect to an IP and TLS certs still have unique serials (most of which appear on public CT logs). Correlated over a large user population, that's more than enough to get a pretty decent, aggregate view of what sites you're browsing (certainly enough to tailor ads/marketing towards you).
As for random third party networks (e.g. Starbucks wifi), if you're not using a VPN then I don't see what expectation of privacy/security you had in the first place.
Ultimately, if you don't trust your ISP (or whatever network you happen to be connected to), the only meaningful option is a VPN. Encrypting your DNS traffic to a resolver (whether with DoH or DoT) is, at best, a very incremental improvement in the arms race. It protects users against some of the most egregious ISP abuses (assuming said ISP doesn't also spoof the cert...) at the expense of potentially misleading them into thinking they have more privacy than they actually do. In the case of DoH it will also likely inadvertently end up centralising a huge chunk of DNS lookups in to the hands of a few large corporations thanks to it being opt-out rather than opt-in. At least DoT avoids that (and offers server-to-server encryption).
Much better for users who want unfettered internet access and privacy to encrypt the whole lot with a VPN and use a resolver that validates DNSSEC. If the chain of resolvers were all DoT enabled that would definitely be a nice extra but hardly essential.
Alternatively, if you're in a country with a healthy ISP market (and government you're not afraid of), there's always the option to simply move to a provider that doesn't tamper with and monetise user traffic.
In TLS 1.3 everything sent by the server, including its certificate, is encrypted.
This is possible because of a re-ordering of considerations. It used to be that the conversation starts like this:
Client: "Hi, I want to talk to Server?"
Server: "Here's a certificate for Server, which is me"
Client: [ "Secret is 123456" encrypted using the Public Key from the certificate for Server ]
Server: [ "See, it's me" encrypted using the secret 123456 ]
But in TLS 1.3 it starts like this:
Client: "Hi, I want to talk to Server and I used ECDHE to pick this number 123"
Server: "I used ECDHE and I picked 456..." [ "I am Server, here's a Certificate for Server, and here's a signature proving the conversation we're having right now is with me, Server, which you can verify using the Public Key in that Certificate" encrypted using the secret 987654 ]
ECDHE allows Client and Server to agree the secret key 987654 even though the information they publish to agree on it (123 and 456) is public for anyone to see. Its predecessor Diffie Hellman is easier to understand if you never got past high school mathematics, so research that if you've never seen this trick before.
You'll notice this is also less round trips (so better performance over high latency links) as well as being more secure and more future-proof.
This is addressed in TFA: The fact that there are multiple problems and solving any one of them doesn't help much until they're all solved, should not be an excuse to refuse to solve any of them.
So you have a "solution" that doesn't really solve the problem, and also create a new privacy problem (now cloudflare has your data too). Hence it's actually a privacy loss.
For some (large, especially) sites, the IP address maps to the entity you're trying to contact. For others (small, especially) sites, the IP address is shared among many entities... not just shared origin hosts but also the massive reverse proxies of the world (Cloudflare, etc.).
There is an actual research on this. More than 90% of alexa's top 1 million websites (more like 95% or so) are uniquely identifiable just by IP addresses you connect to when you visit them. This is not a single IP address per website, but multiple, because websites include subresources with other IP addresses to connect to.
On top of that, there is a pressure on CDNs and clouds to make websites stick to specific IP addresses and make them blockable by IP addresses without affecting other customers. So far they have proven to not go against this pressure and even made technical solutions to aid governments to identify websites by IP addresses, in particular by fixing L7 routing layer to block domain fronting (which is important, because ESNI is basically domain fronting, but crappy, and the pressure didn't go anywhere, so there is the same pressure to make sure ESNI doesn't interfere with identification of websites you are visiting).
Also, Cloudflare does give Business and Enterprise customers their own IP addresses (although often rotated) so that these sites work with old non-SNI browsers.
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.
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.
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.
Okay fair but they are two sides of the same coin. Blocking is active snooping. If an ISP knows what site you are visiting they can block the connection. In both cases the way to prevent it is to extinguish privacy leaks.
For 2, the one thing that's missing from here is that we _know_ many ISPs are selling your data. I'm really uncertain why people are so determined to villify Cloudflare - who don't really stand to gain that much more useful info about you from this than they already have - and give a totally clear pass to their ISP despite years of proven bad behaviour. Yeah this (by default) uses CF's DoH service - note that you can change this if you want - but in my view that's strictly better than continuing to allow your ISP to to sell your browsing history.
In other words - a bit of by-default centralisation is in my view an acceptable price to pay for the increases in privacy and security (especially as it's trivial to switch away from CF if they behave badly).
A good solution would be to do DoH upgrade to their existing provider if the user already has DNS set to a non-ISP resolver (eg. Google, openDNS), only using CF as a default for ISP dns. That or racing multiple DoH providers for the first few queries to choose the fastest one for the user.
Internet gateways commonly give out the gateway's IP address as the DNS and then forward requests upstream from there. How does the application know which DNS the gateway is configured to use?
In [currently only] Chrome, it doesn't upgrade if the DNS advertised is the router. This proposed Firefox system then would default to CF [or default to the fastest one].
>who don't really stand to gain that much more useful info about you from this than they already have
that is absolutely untrue. Today they only have data for websites already using CloudFlare Services.
DoH they can info on ALL websites users for FF visit. and while their "contract" with mozilla requires they "anonymize" the data, they are admitted to collecting aggregate data which is VERY valuable in itself, plus I never trust companies when they say they will "anonymize" the data
Further I have not see what if any penalties are imposed on cloudfare for any violations of the "contract" they have with Mozilla, if there are no penalties then the contract is pointless and not an assurance of anything
As to why people villify Cloudflare, it is what CloudFlare represents that is a problem for people like me. The Internet is best serviced by decentralization. in the last 10 to 20 years we have seen and continue to see MASSIVE centralization of core infrastructure.
FF move here represents another step on that path. CloudFare already has too much of the net behind their infrastructure.
They are an inherit threat to the free and open web
Or in other words, DoH works better on hostile networks because it looks like just one more HTTPS connection.
That's an intentional design feature. You're attempting to intercept traffic, and any mechanism you could use to do so "transparently" could be used by any hostile network to do so.
You can still intercept traffic from cooperating devices if you want, just not transparently. That's a feature, not a bug, and the Internet will be better for it.
Right, but I do think this is better handled at the OS layer. Hardcoding everyone to route through Cloudflare is a hardly a net win, and might be better or worse than your ISP depending on who and where you are.
But Mozilla's justification tables around making security better for all users by dictating default settings that are expected not to change. So, defaults need to achieve the goals.
There are dozens, and yet Mozilla chooses the same company that forces Google captcha on site visitors that try to protect their privacy by using a VPN or Tor?
My main gripe is that before DoH, setting a custom DNS via DHCP was enough to get all devices on a network and all applications on these devices to use a custom DNS.
Now we are headed to a future where each software vendor decides how to make DNS queries. I can predict that all of them will apply their own custom heuristics to detect things like split-horizon.
We are headed toward that future because the broader network has proven that it cannot be trusted; it should come as no surprise that user agents would develop defense mechanisms. If this is another step toward ensuring that ISPs are nothing but dumb pipes, I welcome it.
It started with PCI compliance. Next up was Corporate IT making sure idiots weren't signing up for Dropbox with their LAN password. Schools: Well, they always used proxies with no expectation of privacy whatsoever so traffic inspection was nothing new.
In 5 years TLS-recryption -- whether through software or a hardware middlebox -- will be as ubiquitous as a NAT firewall is now. The only question is if the keys will be in the hands of the consumer or in escrow with Big Gov.
The idea that anyone in their right mind would allow uninspectable traffic to egress their network is beyond ridiculous. I'm glad that DoH is making people realize that.
> before DoH, setting a custom DNS via DHCP was enough
That ship had already sailed. You also have to run your own DNS, allow DNS egress only from your own DNS, and DNAT the rest back to yours in order to un-break all the things with hard-coded resolvers.
Same with NTP surprisingly. Literally everything I have talks to a NTP server once in a while, but only Linux machines actually ask the network's NTP servers.
Lots of embedded Linux devices have hardcoded NTP servers. Was caught by surprise at this after I'd segregated a bunch of stuff to have no Internet access.
DNS is something network operators (and not just governments and ISPs) has managed and controlled in their own networks for decades.
It has been part of the network stack, with a clear hierarchy in how it is governed:
- network operator - network default
- operating system - application default
- end-user override - when the defaults doesn't work
When something has not worked, you could reliably assume this was the stack used. And you could rely on it being used consistently across all applications.
Needed to deploy internal applications? Great: Just override the (local, internal) DNS. Need to access servers or machines on internal servers? Use DNS!
Now if you make some random applications and decide to flat out ignore the established stack and just ask the internet about DNS...
You're effectively breaking the network and the conventions which has been established to build them.
Ofcourse people are going to hate you. That's a given.
> end-user override - when the defaults doesn't work
To my mind, the lack of privacy of classic DNS does indeed count as the the defaults failing to work. Yes, it would be more ideal to solve this at the OS level, but until OS vendors start providing solutions I don't begrudge applications that care about privacy for taking matters into their own hands.
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.
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.
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.
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.
> I wonder when Mozilla will decide to also stuff the rest of the traffic through
Mozilla has recently begun offering an integrated VPN with Firefox, though unlike DoH that has a monthly subscription fee (hell, I don't blame them for wanting to diversify their revenue). The partner in that case is Mullvad.
> You're basically saying that Firefox is now behaving like malware
This is hyperbole. End users should look out for their own best interests by using any means necessary, which includes hiding as much as they can from the network. If the network doesn't like that, then it has the choice not to allow that user to attach a device to the network.
It's the inherent problem of your network position being between a device and the outside internet, the same position that browser activity-selling, website blocking ISPs are. The only difference is that previously, DNS would be unencrypted so you could DPI dns and/or block DNS requests going outside of your custom resolver. If an attacker wanted to hide DNS previously, they would need a hard-coded IP address to send encrypted requests to; now they can use big providers like CF/Google for DoH.
If you don't want DoH, you are not forced to use it. Yes its enabled by default, but it doesn't mean you cannot go into the settings menu and deactivate it.
Hmm, unless you're trying to control what comes in/out your home network .. in which case you're screwed. But you can switch it off in your own browser.
I was a happy pihole user. I could choose to allow DNS lookups, and blacklist using OpenDNS. If I install Firefox at home, then I can't block problematic sites; and Cloudflare will use this to sell the idea to advertiser for TVs and such, so it looks like Google/Cloudflare just used Firefox to obviate ad blocking.
I also use PiHole at home, and lets be honest, if we know how to setup a PiHole, deactivating Firefox DoH is not going to be a problem for us.
DoH is not meant for us, it is meant for the average people who have no tech background. Just because it will cost us a few minutes to configure, we shouldn't deny the overall benefit it will bring to most.
> 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.
Thats not the problem. If more application folow Firefox, and do DNS on their own, corporate applications and sites will stop working, and IT will get the blame.
Now that it's just firefox, ok, but if other app will follow the lead, we will constantly have to play whack a mole, why someone doesn't resolve correctly.
How do I debug problems ?
Is there a tool (something like dig), i can use to see, how will Firefox resolve a domain ?
Where i work we don't block anything on our firewall, but we have plenty of services only exposed on internal DNS. Not to mention, we have to a lot of times replicate environment that is similar to clients, so I often create zones, where people can VPN in, and have similar DNS resolution as the target. Each app doing its own DNS will make that harder.
> Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse
That would be true, if Mozilla rolled this out worldwide, but its US only.
Also right now there are bazillion ISP with bazillion DNS servers.
There are very few DOH DNS providers that Mozilla endorses, so if majority of "privacy" conscious people will start using them, it will become that more valuable for various bad actors to compromise them.
Right now there are so many ISP's with their own DNS's that even if all of them were selling the data, just finding them all and buying their data would be huge task.
This is another centralization of previously decentralized service. (like it happened with email)
Honestly I think that in the long run, this will be worse for privacy that we have now.
For one, it’s ironically first being deployed in countries where DNS manipulation by the government isn’t happening (US first generally), but Google has competitive concerns with ISPs getting ad targeting data. I feel like defending against oppressive governments is being used more as an excuse than a driving motivation. The primary concern seems to be that Google really wants to protect its monopoly, and Firefox, as a major benefactor of Google money, has fallen in line.
And second, as an IT admin, I’m annoyed web browsers keep trying to develop new ways to bypass my network security.
Decades of experience have told me that whenever some big organisation wants to do something in the name of "security", it's almost always an excuse to remove freedom and force their control over everyone.
Yes, that includes oppressive governments too... but I hardly think that even more centralisation is the solution.
The old security vs freedom quote is surprisingly relevant in so many situations today.
This argument can be applied to the encouraging the rollout of HSTS and HTTPS by firefox and google, which cant be disabled very easily by administrators.
1) Instead of proposing changes to the C resolver or a caching resolver the user might run they modified their application to ignore the operating system configuration which is just kind of crappy. Its probably the easiest and most reliable way to block things you don't like and now it doesn't work in firefox.
2) They are the singular (maybe there's one other now heh) resolver operator whereas with DNS anyone (even you) could (and did) run a recursive resolver.
3) I don't think anyone cares so much about this but http is probably the wrong protocol. The DNS protocol was pretty elegant in its efficiency and simplicity (IMO.) Yeah the compression was slightly complex (it's really not) but I've written clients without anything other than a socket library. HTTP on the other hand can do all kinds of complex things and has plenty of room for weirdness and tracking and unintuitive behavior that just isn't necessary for resolving names.
TL;DR: DoH is an unimaginative hack that has a lot of problems from a technical perspective but the social problems are much worse.
As for 1, if you're choosing to use a special resolver to do content filtering, you can disable DoH yourself. That's suboptimal but in my opinion it's better than not dealing with the broken DNS of the general public.
As for 2), it's not hard to run a DoH server yourself. In fact, it's much safer because it doesn't allow for amplification attacks like traditional DNS. The same goes for DNS over TLS (over TCP).
I agree with you on your third point though. I'd much rather have seen DNS over TLS being built into Firefox, especially as most DoH providers built into Firefox also provide DoT. DoT is easier to set up as well because you don't need any specific DNS server software (just have an nginx proxy the TCP connection to your existing DNS, it's about 10 lines of config).
I discovered that Android's "private DNS" functionality uses DoT. I feared they'd use DoH but luckily I was proven wrong.
I am not down on doh, I'm down on the possibility of Mozilla sending my DNS queries (ie my entire browsing history) to a company I haven't signed a contract with.
And I say the possibility because I'm not American so that's not enabled here (yet). But I trust my ISP and my government much more than I trust Cloudflare (zero) and I will be very disappointed (even more than I already am) at Mozilla if they enable it in the rest of the world.
> DNS is the primary way governments control and spy on web access.
And DoH will enable every device you own to continue spying on you for the benefit of corporations.
DNS is the last bastion of preventing devices I can't sufficiently control from spying on me. I use DNS filtering to block their tracking domains. I use my firewall to prevent devices from accessing DNS resolvers I don't control.
DoH takes those options away from me. Ridiculously, in the name of privacy. Ha!
Unfortunately, the battle was lost the moment someone created a DoH implementation. It hardly matters what the browsers do. All the other things I don't want to have DoH will eventually implement it. And they won't respect use-application-dns.net or whatever other frameworks Mozilla comes up with for controlling DoH at the network level.
(Also, does anyone really believe that governments, ISPs, and public DNS resolvers aren't going to disable DoH with use-application-dns.net? I'm sure whomever came up with DoH in the first place had great intentions but the end result is a disaster that will cause more harm than benefit)
So your point is that your attack model was that makers of malwareApp would try to connect to malwareapp.net instead of a random IP?
If you are worried about traffic in the browser you can not enable it, it you are worried about anything else then VPNs were already a thing since some time ago.
I suppose my model is that every connected device and app, every web site someone visits, is malware. My household is full of things collecting data and passing it on to entities I don't wish to share that data with.
How do I stop that when my ability to control what happens on my own network has been been reduced to Can access the Internet over 443, or not?
My question is how does DoH contributes to that in practice/theory. If a malicious/incompetent app/device wants to access random servers with DoH they would need to include a DoH implementation and then DoH offer nothing more than VPNs. In this context I do not understand if you are worried to have wireguard installed on your connected devices.
If you are talking about Firefox itself, then disable it.
I sympathize with wanting more control, but I do not understand how DoH changes things in a household settings.
(I am assuming your is not a corporate point of view, in that case I agree that DoH might cause significant headaches)
> I do not understand how DoH changes things in a household settings.
Imagine you run a PiHole or use a service like OpenDNS. It doesn't matter what you've chosen to use or block, what matters is that you've made a choice to utilize DNS filtering for certain things.
You soon discover that some apps and devices don't respect your DNS decisions. They make money or derive other value through communications that are blocked by certain DNS-based filters, so they query 8.8.8.8 or some other DNS directly. You figure out how to make them respect your choice, through a combination of restricting DNS egress and DNAT at the router, and all is well again.
Mozilla and Chrome come along with DoH. That's alright. You can configure them not to. There's the canary domain, so you don't even need to configure browsers manually, tho I expect the canary will eventually go away -- it is destined to be "abused" by every entity in a position to get away with it.
What's going to come next is real the problem: Every entity which can benefit from being able to bypass DNS filters is going to move to DoH. It's in their best interests to do so. They don't need to respect the canary. You won't even be able to tell what they're doing because everything is encrypted with TLS and have pinned their certificates.
App will do it. Embedded devices will do it. Actual malware will do it.
This outcome is inevitable and that is my objection to the mere existence of DoH.
My question is how is DoH different from contacting 1.1.1.1 over https and asking for DNS information without the DNS protocols.
I understand why people do not want this and want control over their own network, I find that a commendable goal. I do not understand how DoH specifically introduces anything new since you could already get DNS data from HTTPS API
It added yet another thing I have to implement, test and maintain through whatever changes they decide to make.
Nothing like adding extra work for every enterprise IT team to make new friends.
There are also some massive security issues with making all https traffic blind that making only the data blind didn't create - like the ability to blackhole known unsafe domains as they appear.
The problem I have with DNS over HTTPS is that it's something implemented in the browser, that ignores the DNS configuration of your PC and your local network. That has some implication, for example you are unable to access local hosts on your network by their hostname (for example https://fileserver). Also you have a solution that works only on one program, while the rest of the system DNS requests remain unencrypted, that is bad.
Browsers shouldn't implement DNS theirself, and should use operating system APIs to do all the DNS queries. That is how networks work, and doing that differently creates problems (imagine if every program has its implementation of DNS over HTTPS, you have to configure correctly the DNS server in each of them, and good luck debugging it when one implementation is broken...)
As a technical motivation, HTTPS in an high level protocol, and using it for DNS is kind an overhead. We already have DNS over TLS that is a standadized protocol, that can be used, and that the operating systems are starting to implement.
I use DNS over TLS in my local network, but rather than having configured all the computers to use it I have configured a local DNS server that encrypts the requests, for every host in the network, and also filters trackers and ad servers. Thus I don't want Firefox to mess aroung with my local network configuration that is fine.
I'm not against DOH but there are definitely some downsides. For example, your token does not get reset on network changes. This means your DNS provider can track your DNS requests across networks, including VPNs.
With normal DNS anyone in the request chain can see a stream of DNS requests but there is no context. By the time the request is one or two hops from you it will be interwoven with tens of thousands of other requests making it impossible to know which one came from who.
With DOH the DNS provider will have a unique identifier to correlate requests back to a specific system/user. Google offers one of the most used DNS services, with DOH they will be able to track all DNS requests you make even if you turn on a VPN.
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.
>> We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
Ummm so what’s the downside then? Are those services arcane and hard to use and utterly forbidding blackest black magic, like almost all crypto stuff?
If you’re thinking browser users will just do this then that then this and x and y and z to “get dns crypto going”, then I’ll take Mozilla’s “it just works” approach.
It’s a much much better approach for the browsers to implement it rather than wait for everyone’s operating system to implement secure dns because that’ll happen .... well I can’t imagine any time in the future you could say everyone’s OS is using crypto DNS, whereas if browsers implement it for themselves, instant massive adoption.
Not sure what any of your reply means. Adding OS support isn’t required. People just run a local resolver that supports these things. No different than any other application. Nothing arcane. Certainly no more than HTTP and SSL.
>> People just run a local resolver that’s support’s these things.
Nowhere do “people just run a local resolver”. Grandma and aunty Beryl certainly don’t, nor does any other ordinary person. If you want secure DNS you have to build it in to the browser.
Only systems people think that this is the sort of thing that ordinary people do.
Not true. In the default case, Grandma's wifi router is just passing along -- via DHCP -- the IP address of the cable company's DNS resolver to Grandma's computer. Which the wifi router itself probably obtained via DHCP or a similar mechanism from the modem. This is in no sense a "local DNS resolver."
If Grandma has a grandchild that knows how to set up a PiHole, it's a different story. But that's certainly not the majority of Grandmas or the majority of wifi routers.
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.
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.
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.
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.
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.
So one is easy to block and the other is hard, requiring maintaining a blacklist and or deep packet inspection. I'll take the hard one please.
Just increase the cost/difficulty of a thing makes that thing less common. In this case that "thing" is ISPs selling highly accurate web histories to anyone who will pay. Please make that harder/more expensive, every cent of cost to the ISP is welcomed.
This is not the full picture if we are being honest with ourselves. When DoH is default on in all browsers, the masses will be talking to 2 or 3 companies. Sure, they can change what server they talk to, but we all know that most people won't even think about it. DoT implemented on all DNS servers would keep control as distributed as it has been up until now. Until the root serves support DoT, which I doubt they ever will, there will always be weak links. This includes from Cloudflare, Mozilla and others talking to the root servers. I am not trying to convince anyone of anything. This is a very polarizing topic and has been every time it is discussed here and other news aggregators. The best I can do is educate people that I care about so they can make an informed decision.
While that is true, it would be much easier to get DoT deployed at scale. During DNS Flag Day of 2019 [1] a significant number of recursive DNS servers around the world started properly supporting EDNS0 and several other modern features of DNS. In most cases, it was just application version updates or configuration changes. Most of the popular and widely deployed recursive DNS servers already support DoT, which means that a similar effort could be made to enable DoT. AFAIK none or few of the popular recursive DNS servers support DoH today natively. It would be significantly easier to get DoT enabled en-mass. People are much more open to making a configuration change if that is the least path of resistance.
People keep talking past each other on this because somehow DoH got conflated with Cloudflare.
DoH is a protocol. It has better security than unencrypted DNS. (So do several others, like DNSCurve, DNSCrypt, or routing your DNS queries over a VPN.)
The objection people have is not that it's encrypted, it's that Mozilla implemented it in the browser instead of the OS and thereby ignores the DNS you configured in your OS. And even that is fine as a setting you can enable, but it's problematic as the default. Both because it's administratively burdensome to change a setting in every application on every device if you want to use your own, and because of the second order effect of that, which is that hardly anybody will change it and then DNS becomes centralized to whatever is the default in the browsers.
If you're worried about your ISP snooping on you and tampering with DNS records, the tools we have today already offer better privacy and trust than DoH, DoT, DNSCurve or DNSCrypt.
Just use a DNSSEC capable resolver in combination with a VPN. All other options today are effectively theater.
DNSSEC is the least useful of the lot. It only authenticates, doesn't encrypt, so it's not enough on its own, you have to use it in combination with a VPN. But the VPN would be enough on its own between the client and the recursive DNS, since it does both.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.
You're conflating privacy with trust. DNSSEC gives you trust, the VPN gives you "last mile" privacy. DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled). Over time you can hope for DoT to gain wider adoption so more and more of the upstream resolver chain is encrypted.
DoH mitigates the "ISP selling your DNS data" threat, which practically everyone in the US faces, without forcing all your traffic onto a VPN, which not everyone wants. Meanwhile: practically no important zones are signed, so apart from the fact that DNSSEC does nothing to improve privacy, it's also not useful. DNSSEC is moribund; taking steps to enable it is a waste of time.
DoT would also mitigate it in a similar fashion. In both cases mitigate doesn't really have much meaning since, sans VPN, ISPs that are inclined to do so will quite happily continue to find ways to infer where you're browsing to (IP address and CT log correlation being the obvious choices). Ergo, if last mile privacy is you're issue, the best bet is a VPN or some improved regulation so that consumers have a choice if they want an ISP that doesn't spy on them.
DoT and DoH have virtually identical service models. The practical difference between the two is that DoT deliberately runs on a nonstandard port, so that network operators can filter it. It's not an exaggeration to say that DoT is simply DoH with a network kill switch.
When was the last time port 995 or 993 were blocked? If the same adoption happened with DoT, ISPs wouldn't have the option - customers wouldn't accept it.
Confidentiality and authentication are two different things, but the things that provide confidentiality here also provide authentication. DNSSEC only provides authentication, so then you need something else to provide confidentiality at every point in the path. At which point you would also have authentication at every point in the path, so what does that leave for DNSSEC to do?
> DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
This is true. DoH isn't the one to use between recursive and authoritative DNS servers.
> Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
DoT has a similar drawback as DoH between recursive and authoritative servers. The session establishment is expensive (more round trips, higher latency). That's not so bad for the link between the client and the recursive DNS, because you create a session once and use it for all your queries. It stinks between recursive and authoritative servers because the recursive server would need a new session for each authoritative server -- and a single recursive query can often require contacting three or more authoritative servers.
Fortunately DNSCurve has lower latency and can be used between any pair of recursive and authoritative servers that support it.
The root not supporting DNSCurve is an issue, but it has an obvious long-term solution (have the root start supporting DNSCurve), and in the meantime the recursive resolver could validate only the root with DNSSEC. The lack of privacy is much less impactful for TLD queries -- a query for your-local-oncologist.com tells an observer much more than a query for .com. Then if DNSCurve is used for the rest of the chain after the root, you have one authentication or the other for the full chain and privacy for all but the TLD query. You also then don't need any large DNSSEC records in the authoritative servers that support DNSCurve, which would otherwise be a DDoS vector.
> So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled).
I still don't see what that's even supposed to be adding over the VPN right now. The VPN handles the link between the client and the recursive resolver. You can only get authentication between recursive and authoritative servers for domains whose authoritative servers support some authentication, but hardly any of them support any authentication right now, and if you're going to add one it makes more sense for it to be DNSCurve than DNSSEC because it provides confidentiality in addition to authentication and isn't a DDoS vector.
DNSCurve sounds quite nice (I'm not at all familiar with it tbh). I agree something along those lines with DNSSEC for the last hop to the root would do it.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
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?
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.
Since Mozilla makes a browser it was natural they'd try to solve it at the application level and not wait until M$ and other privacy loving OS vendors solve the problem.
If operating systems had taken care of the problem already then Mozilla might not have to. I'm glad Mozilla isn't waiting around for them to protect my privacy.
Isn't this gonna cause a bunch of headaches though? What about people who connect to VPN and rely on the local DNS server to resolve non-public hosts? It'll work in everything but Firefox? Seems confusing.
> Why isn't this being solved on an operating system level
> instead?
It probably should be, but the undertaking is massive (cross platform) and browsers want a quick turn around. A lot of people would think that VPNs solve such issues, but it just pushes the problem further up the network.
In my opinion Linux would be a good candidate for such an initial implementation - but you wouldn't pick DoH, you would likely offer DNSCrypt or DoT.
That would be the best outcome, but until then Mozilla is making an effort to fill the gap until OSes supports DoH, DoT or DNScrypt out of the box and by default.
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.
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.
What is the state of the art for Linux resolvers doing encrypted DNS? It looks like systemd's resolver isn't quite ready yet. I found a couple of other things on a quick Google; stubby and dnss.
Is there some simple thing I can apt install on my Ubuntu system?
The fun part is that this seems to have been copied from an HTML FAQ and a link "see relevant documentation here" has simply disappeared in the process.
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?
You have twenty different applications using DoH for “increased security” and you need a custom profile for each? Why not a single line in resolv_doh.conf?
On Windows, you can probably do this via GPOs. How does one configure a fleet of Mac or Linux machines? How does one do it with BYOD or on a campus of students' machines?
Perhaps some thought as to service discovery should have been done:
If Mozilla is going to re-invent the wheel (OSes already do DNS look ups), they perhaps should have asked the DNS folks (e.g., DNS-OARC) about some of the corner/use cases IMHO.
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.
I'm not sure how firefox could implement this entirely on their end. There would need to be cooperation on the OS (or dhcp client) side to expose that option somehow.
We're in this mess because OSes haven't acted and Mozilla has had to take matters into their own hands. Unfortunately any solution that requires cooperation from other software is going to take a lot longer to land.
I do hope it happens eventually, and I'm sure that when it does Mozilla will change Firefox again to respect that.
I don't think so. Someone like Mozilla can "claim" a DHCP option code and say "this is what we are going to use, operating systems can climb aboard if they want."
It can get even more complicated when you have multiple connections on your machine, each with a different DNS server. You'd need to match the DNS server determination algorithm of the operating system to remain consistent, which is one hell of a task.
There's also the fact that there's no DHCP option reserved for DoH/DoT/DNScrypt (yet) which requires some standardisation work.
There's various APIs to read the current DHCP configuration for a network interface so technically it shouldn't be too hard (at least not when it comes to Windows or macOS where there's standard APIs, as opposed to Linux whose modular layout makes finding a standard location for DHCP config difficult).
If you have multiple connections, each of those DNS servers should return the same answers.
If they do not, they should be marked as forwarders for their respective domains. Something like `Add-DnsClientNrptRule -Namespace "domain.com" -NameServers "1.2.3.4"`
The operating system will have this information; an application, like browser, won't.
Firefox is still falling back to local DNS settings if it can't resolve stuff using the currently set DoH provider, as I can access resources in Firefox on my university's network that cannot be resolved outside it.
It's very frustrating to be constantly downvoted for saying that Firefox's DoH implementation leaks information without any of the downvoters saying why.
Seriously, do you disagree that it leaks information? Do you agree that it does, but believe it is less problematic for two companies to have this information than having it sharded across all ISPs? Do you agree that it's more problematic but you don't care for some other reason? Do you agree that it's problematic and care but don't like how I express my point? Do you agree, care and like my expression but think it adds no value to HN?
In prefer the approach Google is taking with Chrome and Microsoft is taking with Windows 10 which is to use the system defined DNS servers and if they support DoH to use it and if not to fallback to using them with normal DNS.
There is no need to configure individual applications and no need to develop a new means of distributing DoH server information.
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.
If they do that, Mozilla will probably immediately update the check or remove it all together.
I don't understand why systems administrators don't just use their existing policy management to disable DoH if it really causes an issue. There's a group policy specifically for DNS over HTTPS [1]
The only reason I can think of is that they can't because of BYOD or Firefox being part of the company's dark IT. The DNS workaround doesn't help much in those cases because the underlying problem is a lack of oversight, not an issue with Firefox.
I'd guess that the overwhelming majority of Mozilla's users do not have a "network administrator" looking after issues like this for them. All they have is an ISP, and the ISP is not on the user's side.
My point is that the definition of "network administrator" is wider than the corporate network administrator vision the phrase evokes.
A quick search shows me a number of parental control features in routers that use OpenDNS. All of the parents using those features would be "network administrators", too.
I think more people are "network administrators" than the average HN reader realizes.
This logic makes no sense to me. Can you imagine if AT&T or Spectrum made a statement like this?
The “network administrator” is an untrusted 3rd party who should have basically 0 say in how my device operates.
The device administrator, ie the owner of the machine, is the one who should have the final say over when DoH is used. The use-application-dns record is for businesses that want an easy way to stop DoH on machines they administer. If random “network admins” start deploying it as you say then Mozilla will have no choice but to ignore the record entirely.
So what if I run a Pihole at home as a DNS server and want to stop being able to resolve various domains? I would like to know how to stop all devices (actually worse, individual applications!) on my network deciding to DoH of their own accord (and therefore bypassing my local DNS server).
This kind of centralised ability to block DoH is very useful to me.
* On devices that you own and control you don't need a network level control like this except for convenience. This is when you should be applying the override record.
* On devices that you do not own or control (family/friends/guests) disabling DoH makes you the malicious network operator. Connecting to your Wi-Fi doesn't make you trusted in any sense of the word.
* On devices that you own but do not control (Google Home/Alexa) you make a valid point that techie types have been able to take some level of control by exploiting the fact that DNS is an unencrypted "hole" in the security of the device. You would have a lot more control if the HTTP traffic they sent was unencrypted and inspectable/modifiable but that doesn't mean devices shouldn't be allowed to use HTTPS without your approval.
Thanks. Not to be argumentative, but I find it odd/interesting that guests connecting to my WiFi and using my DNS set up makes me a "malicious network operator" in your eyes. That's a very odd view of the world in my opinion, as it is my WiFi and DNS set up.
That's like saying that me stopping guests taking photos of my daily activities (showering, using the toilet) whilst in my house is a malicious behaviour too. I suppose I should let them post the photos off to whomever they choose?
If someone is in my house and using my WiFi, I don't want their device looking up domains that I choose to block. How do I know that their device is not recording its surroundings and sending them off to the said domain? How do I know that my guest is not up to nefarious/illegal activity using domains that I have blocked? I would be the one prosecuted due to the IP address = a person approach by the law in most circumstances (should they ever deduce the requested domains from the DoH set up). Being that the DoH provider is under law, I am pretty sure that the DoH will have to hand over any records they have, which will lead it back to me and my network.
And then once again we are stuck in a situation where I cannot control what domains are being looked up by devices and applications on my network. My devices are no longer mine. I have handed off control to some company the other side of the planet with employees I will never meet.
How do I stop the 5+ tracking domains that the Instagram app uses on my wife's iPhone, for example? Am I a malicious network operator for stopping that garbage being sent off?
> I cannot control what domains are being looked up by devices and applications on my network.
This is kinda the point. For devices you own you have that control by the virtue of being the device admin. Other people's devices are a different story. You are free to have an acceptable use policy on your own network and require traffic to flow through a proxy or whatever but if you do it without their knowledge or consent you're the bad guy.
How pissed would you be if Xfinity just up and blocked random sites like this?
(sibebar: Just from a politeness perspective why would you give your guests anything other than a clean path to the public internet ?)
> That's like saying that me stopping guests taking photos of my daily activities
Having a rule that applies to your guests -- totally cool. Silently disabling their camera without their consent once they come through your door -- not cool.
> Am I a malicious network operator for stopping that garbage being sent off?
I mean you're modifying the traffic coming off of someone else's device without their knowledge or consent. I would be pissed if by husband did something like this without asking -- leaving me to debug why some sites are mysteriously broken.
I'm _maliciously_ stopping my kids Android apps from connecting to tracking and malware domains. What a tyrant I am - I should have over control to a third-party for profit company??!?
Of note: PiHole supports DoH, so you point your DoH supporting applications at it. If your OS gets around to adding DoH support you can point your entire OS at it and disable DoH in applications, but until then you'll have to do things the hard way.
At present though devices on the network all for DNS and my network says "use pihole" but applications that implement DoH never ask the network, so I have to have access to all the applications (including those from bad actors).
I block MS telemetry domains for example, where's the config for me to stop them using DoH; what about the trackers on my TV?
Now I need to configure every device - that's capable of using Firefox - rather than configuring the network. Presumably in short shrift there'll be no way to block Google advertising. I guess Google will get their return on funding Firefox.
AT&T and Spectrum do not administer your home network, you do. You have the freedom to configure whatever DNS settings you want; if you wish to use their DNS servers you may; if you wish not to, then you may not.
DoH is a non-solution to a non-problem which makes privacy strictly worse by leaking information to Cloudflare in addition to one's ISP.
You are a client on AT&T and Spectrum's network. Just because you turn on a router and set up NAT doesn't make this fact any less true. At some point your internet traffic is going to flow AT&T's network where they are the administrators and are free to apply whatever network policy they see fit.
DoH and DoT is a solution to the problem of sending your DNS requests unencrypted, leaking them to everyone in the process, and then opening the door to any malicious network operator in between you and your DNS server the ability to modify the response in-flight.
Your ISP can and should provide DoH servers. Your local network is free to do the same.
I agree with you: your local network is free to set up a resolver using DoH (or DoT, which is far more sane than an entire HTTPS connexion). That's the correct place for it to live, or possibly at the individual device level.
It is 100% not the place of an application to meddle with network services, particularly not by default.
>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.
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.
>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.
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).
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.
How about wanting to filter advertising, or filter content for myself - I block imgur via DNS for example, or block domains used by trackers and malware creators?
> but rejecting any kind of innovation isn't something I am willing to do.
I don't think the post you're replying to is really saying "no innovation". I think it's more subtle.
The "problem" with DoH is that you need to look at it with several different hats, and I feel very few people make it clear how they're complaining about DoH.
* From a consumer perspective DoH is a good thing (mostly)
* From an traditional/enterprise/business-like environment perspective it's inserting itself in the middle of the stack and may cause headaches with a few things (not limited to leaking internal names to external resolvers), unless it's just blanket disabled/forced to a local server (which may not always be practical for different reasons) - currently
Ultimately who do we have to blame for this but ourselves? Organisations have tried to get encrypted DNS off the ground in traditional DNS infrastructure and clearly failed to meet the required timeline.
I personally feel like the problem, just like with IPv4, is that traditional DNS infrastructure is "fine" (i.e. it works). We don't have a great motivation but we do have fear of breaking the many many many boxes which are un-upgradeable/critical.
Has anyone verified that this actually works? My company's DNS administrators have already made this change. use-application-dns.net returns SERVFAIL when I run "dig" on my machine on the corporate network.
But if I enable DNS over HTTPS in Firefox, it very clearly still uses the Cloudflare resolvers. We have some split-horizon zones set up (resolve to 10.x IP's internally, and public IP's externally). When I tick the DoH box, Firefox starts resolving the public IP, verified in the Dev Tools network pane.
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.
Yes, if you press the network and proxy settings in the preferences page, you will see a DNS over HTTPS setting. You can also use this to set your own resolver in case you dont trust cloudflare.
> 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.
> 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/ 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.
So I should block outgoing TLS requests to be able to stop DoH?
Seems a bad idea....
At least with DNS I could run a local DNS server and block outgoing port 53 from anything else. Now I no longer have this option and each app gets to look up what it wants, when it wants. Sure, it's great that my ISP cannot see what's in these requests but nor can I! And it also means that any application (eg. any Google product) can query for advertising/tracking domains without me being able to do a thing about it.
It isn't solving a problem - it's creating a far, far worse one (for me).
If I have got this wrong, or there is a method around this - what is it???
Don't put devices on your network if you don't want to give them network access. And don't block technologies and protocols that help people protect themselves just because they also help devices protect themselves from you MITMing their connections. If you want to run a device reverse-engineering lab you have more work to do to break the security of a device.
Also remember that if you can break the security of a device, so could an ISP router. The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile.
How many people are using custom local plaintext DNS as a measure to analyze local devices on their network? How many more people are having their whole network's DNS usage analyzed by their ISP and anyone their ISP sells data to? The defaults are designed to be the right choice for people who don't change the defaults.
"The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile."
Thanks for this - I had not thought of that.
Looks like I'll be keeping my "smart" TV off the network forever then (my old LG used to send a network request whenever I pressed any button on the remote)! And all my Android devices, Windows 10 devices and my Apple TV and MacBook too. (This is only partially sarcasm - I can't really trust anything these days it seems...). The amount of dialling-out they all do is astronomical. The only solution appears to be going full 1980s and not being on the network. The dream is over.
At least my Raspberry Pi can be trusted. Other than the GPU chipset...
This is precisely why many of us use Linux and put up with some of the inconveniences or doing so - it’s more trustworthy. (And it gets more convenient as more people start using it.)
They sure do, but it’s a Linux instance that the manufacturer has control over rather than the user. (Which is the real problem, more than just what tech is being used.)
The problem is that the device (or website) also treats the owner and legitimate user as untrusted and obfuscates the content of the traffic in a way that makes everything completely opaque for them. The device/site only trusts its manufacturer which makes any device that completely obscures its traffic from its owner feel more like a Trojan horse. This is how you end up with questionable telemetry and data leaks for example.
What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.
What I want is a key to my own house, not an open door. Right now using a lot of software and IoT devices feels like buying a house but the builders keep the only key.
> Don't run devices on your network you don't trust.
This advice is about as practical as "Do not use ISPs and their forwarders that you don't trust.". Which is to say, not much. Let us know about your experience with smart TVs and similar devices, and how much you trust them.
> Don't run devices on your network you don't trust.
Oh, is that all?
How about I trust the devices until a secretary clicks on a (spear)phishing link that runs a zero-day. Then what? The host is compromised so I can no longer trust any end-device monitoring software on it, and now the network traffic is opaque.
And that doesn't even get into things like academia where students and visiting researchers bring devices of unknown providence. If if they're on DMZed networks, they could be spewing garbage onto the Internet and getting my CIDR range blacklisted.
If anything hits port 53 on the outgoing gateway, and it's not from our recursive servers, then we know that network element needs to be looked at: either it's mis-configured or malicious.
Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.
Then your security strategy definitely needs improvements, since malware often uses hardcoded IPs to bypass DNS proxying/forwarding that corporate networks use. Seriously, this argument could be used to say we should be using HTTP instead of HTTPS, but anyone doing security knows if they really need that level of introspection they need to MITM HTTPS traffic with a MITM proxy. If you care that much, you also need to MITM DoH/DoT traffic.
Given that Cisco has a major product, Umbrella, that is sold as a part of enterprise security strategy I'd say that more than the OP is considering DNS filtering / monitoring as part of a network security strategy.
> treat the intermediate network between them and the servers they talk to as hostile
Unfortunately they also treat the user as hostile and untrusted. Your phone, browser, OS, or TV treat you as hostile when they send data to the manufacturer and give you no way of assessing yourself or actually controlling this. We have standards and protocols that ensure the data is kept perfectly secure and inscrutable between your device and the manufacturer but absolutely nothing is put in place to give you any control over this. Your choice is binary: use it or not. Every security decision seems to work out better for those companies than for the user.
In this case both DoH and DoT provide the required security for the users but one of them takes a little bit of control away from them.
> 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.
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
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.
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/ are designed to work around the Chinese internet firewall.
From my point of view DoH add nothing outside the browser.
> Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. ... Now I have to worry about DNS queries going out via HTTPS.
That confidence would have been misplaced. DoH offers a standardized protocol, but it's not exactly difficult to put together a one-off interface for performing occasional remote DNS lookups over HTTPS. One could even use existing HTTPS sites for the purpose (e.g. https://ping.eu/nslookup/).
> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines"
> Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. [0]
Of course it's a security control. Not a perfect one but a security control nonetheless. And every security control of today might become useless tomorrow so I don't get your point. Is a firewall a "guideline" just because I can tunnel some illegitimate traffic through an accepted port? Are your house and car door locks "guidelines" because a thief has to "volunteer" to not break/pick them or go in through the window? So you'll take them all out until you have "real" security controls? I guessed not...
As for your airport example, given that illegal activities go unnoticed and items are smuggled through customs every day you could argue that there are no security controls in place and that the airport relies on people volunteering to not break the law. But you'd be using the wrong definition and understanding of what a security control is.
As far as home security goes having DNS filtering adds a layer on top of the "nothing" you normally have. And it's a pretty good and accessible way to achieve this extra bit of security. "Not perfect" does not equal "no security". And it's not even just security: ad-filtering, parental controls, privacy, etc. are all impacted. DoH all but guarantees that you lose this control and unfortunately there's nothing ready to take its place.
> 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 isn't really a matter of security controls. Anything has always been able to create an encrypted tunnel on TCP/443 and send whatever over it.
The issue is administrative cost for cooperative applications. You have a local DNS that e.g. blocks known malicious domains and has the local names for other devices on your LAN. The user of each device doesn't want to prevent this, the application developer doesn't want to prevent it, but making that happen when applications default to using a third party DNS goes from setting the DNS via DHCP to changing a separate setting in every application on every device.
The suggested solution to this is to have the local DNS resolve a canary domain in a particular way which Firefox takes as a request not to use DoH by default. That basically works, but I still don't know what they intend to do when adversarial upstream DNS servers start resolving the canary domain that way. It would also work a lot better if there was a standard canary domain instead of every application making up their own.
You may find noteworthy that my comment had 2 points. One where I don’t feel like DoH will bring much benefit in the browser today, and one where DoH in general will just give you, the user, even less control over what you’re sending out. I can’t imagine everyone giving you the option to switch, all the TRRs being actually trusted, or even being able to pick the TRR in most setups (IoT? Your random Google product?).
Why? If you know how to run your own pihole, you know how to turn off DoH? You're not being forced into this, a default setting is getting flipped and you're entirely free to go "no thanks" and flip it back, so if you trust whoever owns the IP that you're using as real, unencrypted DNS server, then just keep using that. Same as for folks who want to keep using unencrypted emails "because encrypted mail isn't fully encrypted anyway and just makes things harder".
As tech changes, solutions change, but at least for the foreseeable future your DNS intercept will keep working just fine until everyone switches over to DoH and stops offering an opt-out.
Parsing the text helps with understanding it. And the fact that Mozilla allows me to flip back says nothing about those general cases. I do not expect everyone to give you the choice.
That's one thing, sure, but that doesn't affect the majority of sites. CF's DNS POPs are likely more dense than the great majority of service providers POPs. So using the subnet of the resolver is about as good (if not better) than having ECS info for practical purposes. (Because the client is normally going to hit the closest DNS POP to them in BGP network distance.)
I'm not a CF fanboi, in fact I think they are evil. But let's not make weak arguments. That said, yeah suppression of ECS info is a deliberate anti-competitive choice by CF. They probably have convinced themselves its about privacy, but it isn't.
The real benefit to them is, as the CDN, they get the benefit of even lower latency and even better control. With a penalty to everyone else.
It's a disgusting arrangement, and a net loss in privacy. Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
I'd find it more palatable if these so-called TRR providers were required to be DNS-only. Maybe DNS + registrar.
>Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
Then why were the big ISPs lobbying against this plan when proposed by Google originally? Because they truly were concerned for the welfare of the Internet as they claimed? This is a concern they've never exhibited in the past, their only demonstrated concerns have been related to their revenue streams.
Running a public DNS service allows Cloudflare and NextDNS to provide faster and smoother DNS updates to their B2B customers by avoiding third-party DNS resolvers and caches.
curious, can see the case for the capability giving advantage, but how do you think running the public service would? or do you mean competitive advantage in marketing their products?
Collect data of course. Mozilla is very naive to trust that they won't collect data (be it personal or otherwise). Neither they nor the enduser can ensure that.
it's probably because cloudflare and friends went "we want to see what hit we're taking if we do this for free for you, by only enabling this by default for the US first" or something.
Mozilla was founded in USA, which may be of relevance for why USA was selected as the country of launch. I don’t know anything specific about their decision, though.
I'm amazed noone else is asking this. CF's whole business model centres around the concept of denying website access to minorities they classify as "bots". Some big actors can afford to practice the notion of reciprocity by blocking access to Cloudflare in return — https://news.ycombinator.com/item?id=21155056 — try doing that now when you might end up blocking access to your site for all Firefox users.
After eSNI becomes mainstream, network level ad blocking will be extremely difficult. My guess is there will be a huge ad blocking subscription play in the future.
They’re usurping control and calling it a privacy enhancement so they can sell the control back to us with per user per month pricing.
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: "209.216.230.240" 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.
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.
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 :)
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.
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.
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.
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 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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Since they're apparently using Cloudflare, there will likely be censorship, too. It'll just be censorship that is deemed politically correct in the US / Western world, like cutting off sites like the Daily Stormer, 8chan etc.
> Cloudflare does not block or filter content through the Cloudflare Resolver for Firefox. As part of its agreement with Mozilla, Cloudflare is providing only direct DNS resolution. If Cloudflare were to receive written requests from law enforcement and government agencies to block access to domains or content through the Cloudflare resolver for Firefox, Cloudflare would, in consultation with Mozilla, exhaust our legal remedies before complying with such a request. We also commit to documenting any government request to block access in our semi-annual transparency report, unless legally prohibited from doing so.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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-...).
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.
776 comments
[ 4.3 ms ] story [ 381 ms ] thread1. 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.
https://www.dnscrypt.org/
Optional for menu icon:
https://getbitbar.com/ and https://github.com/jedisct1/bitbar-dnscrypt-proxy-switcher
The .org is not legit.
What about DNS tampering? In many countries there are different rules for taking down a website. My ISP applies different rules than 8.8.8.8, which is handy when required by law in France but not in USA.
Effectively, government-mandated tampering will be applied with much less granularity because of centralization (or bi-centralization).
We've seen regular US ISPs hijack unencrypted DNS to insert content or replace sites entirely. We've also seen bad actors do far worse on public WiFi.
So acting like DoH is a waste of time unless every part of the privacy puzzle is online is wrong-headed. It is a huge step in the right direction for privacy, increase their costs, and will be much needed when eSNI is online. In the meantime "all" we get is a huge security improvement.
If you're worried about ISPs snooping on what sites you visit, they'll continue to be able to do this even with widespread DoH/DoT and ESNI adoption. You still need to connect to an IP and TLS certs still have unique serials (most of which appear on public CT logs). Correlated over a large user population, that's more than enough to get a pretty decent, aggregate view of what sites you're browsing (certainly enough to tailor ads/marketing towards you).
As for random third party networks (e.g. Starbucks wifi), if you're not using a VPN then I don't see what expectation of privacy/security you had in the first place.
Ultimately, if you don't trust your ISP (or whatever network you happen to be connected to), the only meaningful option is a VPN. Encrypting your DNS traffic to a resolver (whether with DoH or DoT) is, at best, a very incremental improvement in the arms race. It protects users against some of the most egregious ISP abuses (assuming said ISP doesn't also spoof the cert...) at the expense of potentially misleading them into thinking they have more privacy than they actually do. In the case of DoH it will also likely inadvertently end up centralising a huge chunk of DNS lookups in to the hands of a few large corporations thanks to it being opt-out rather than opt-in. At least DoT avoids that (and offers server-to-server encryption).
Much better for users who want unfettered internet access and privacy to encrypt the whole lot with a VPN and use a resolver that validates DNSSEC. If the chain of resolvers were all DoT enabled that would definitely be a nice extra but hardly essential.
Alternatively, if you're in a country with a healthy ISP market (and government you're not afraid of), there's always the option to simply move to a provider that doesn't tamper with and monetise user traffic.
In TLS 1.3 everything sent by the server, including its certificate, is encrypted.
This is possible because of a re-ordering of considerations. It used to be that the conversation starts like this:
Client: "Hi, I want to talk to Server?"
Server: "Here's a certificate for Server, which is me"
Client: [ "Secret is 123456" encrypted using the Public Key from the certificate for Server ]
Server: [ "See, it's me" encrypted using the secret 123456 ]
But in TLS 1.3 it starts like this:
Client: "Hi, I want to talk to Server and I used ECDHE to pick this number 123"
Server: "I used ECDHE and I picked 456..." [ "I am Server, here's a Certificate for Server, and here's a signature proving the conversation we're having right now is with me, Server, which you can verify using the Public Key in that Certificate" encrypted using the secret 987654 ]
ECDHE allows Client and Server to agree the secret key 987654 even though the information they publish to agree on it (123 and 456) is public for anyone to see. Its predecessor Diffie Hellman is easier to understand if you never got past high school mathematics, so research that if you've never seen this trick before.
You'll notice this is also less round trips (so better performance over high latency links) as well as being more secure and more future-proof.
On top of that, there is a pressure on CDNs and clouds to make websites stick to specific IP addresses and make them blockable by IP addresses without affecting other customers. So far they have proven to not go against this pressure and even made technical solutions to aid governments to identify websites by IP addresses, in particular by fixing L7 routing layer to block domain fronting (which is important, because ESNI is basically domain fronting, but crappy, and the pressure didn't go anywhere, so there is the same pressure to make sure ESNI doesn't interfere with identification of websites you are visiting).
Tell that to China, Iran, Turkey (?), etc.
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.
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.
For 2, the one thing that's missing from here is that we _know_ many ISPs are selling your data. I'm really uncertain why people are so determined to villify Cloudflare - who don't really stand to gain that much more useful info about you from this than they already have - and give a totally clear pass to their ISP despite years of proven bad behaviour. Yeah this (by default) uses CF's DoH service - note that you can change this if you want - but in my view that's strictly better than continuing to allow your ISP to to sell your browsing history. In other words - a bit of by-default centralisation is in my view an acceptable price to pay for the increases in privacy and security (especially as it's trivial to switch away from CF if they behave badly).
that is absolutely untrue. Today they only have data for websites already using CloudFlare Services.
DoH they can info on ALL websites users for FF visit. and while their "contract" with mozilla requires they "anonymize" the data, they are admitted to collecting aggregate data which is VERY valuable in itself, plus I never trust companies when they say they will "anonymize" the data
Further I have not see what if any penalties are imposed on cloudfare for any violations of the "contract" they have with Mozilla, if there are no penalties then the contract is pointless and not an assurance of anything
As to why people villify Cloudflare, it is what CloudFlare represents that is a problem for people like me. The Internet is best serviced by decentralization. in the last 10 to 20 years we have seen and continue to see MASSIVE centralization of core infrastructure.
FF move here represents another step on that path. CloudFare already has too much of the net behind their infrastructure.
They are an inherit threat to the free and open web
DNS is the primary way governments control and spy on web access.
DNS is the most openly insecure aspect of the entire internet. It’s wide open.
2) to implement this canary, you have to break DNSSEC on entire .net root domain. Great.
That's an intentional design feature. You're attempting to intercept traffic, and any mechanism you could use to do so "transparently" could be used by any hostile network to do so.
You can still intercept traffic from cooperating devices if you want, just not transparently. That's a feature, not a bug, and the Internet will be better for it.
There are a few dozens of DoH services out there [1] and nothing prevents anybody else from running their own.
[1] https://github.com/curl/curl/wiki/DNS-over-HTTPS
Now we are headed to a future where each software vendor decides how to make DNS queries. I can predict that all of them will apply their own custom heuristics to detect things like split-horizon.
It started with PCI compliance. Next up was Corporate IT making sure idiots weren't signing up for Dropbox with their LAN password. Schools: Well, they always used proxies with no expectation of privacy whatsoever so traffic inspection was nothing new.
In 5 years TLS-recryption -- whether through software or a hardware middlebox -- will be as ubiquitous as a NAT firewall is now. The only question is if the keys will be in the hands of the consumer or in escrow with Big Gov.
The idea that anyone in their right mind would allow uninspectable traffic to egress their network is beyond ridiculous. I'm glad that DoH is making people realize that.
That ship had already sailed. You also have to run your own DNS, allow DNS egress only from your own DNS, and DNAT the rest back to yours in order to un-break all the things with hard-coded resolvers.
Why don't they ask DHCP for a nice stratum 1 server instead, I don't know, maybe someone here does?
It has been part of the network stack, with a clear hierarchy in how it is governed:
- network operator - network default
- operating system - application default
- end-user override - when the defaults doesn't work
When something has not worked, you could reliably assume this was the stack used. And you could rely on it being used consistently across all applications.
Needed to deploy internal applications? Great: Just override the (local, internal) DNS. Need to access servers or machines on internal servers? Use DNS!
Now if you make some random applications and decide to flat out ignore the established stack and just ask the internet about DNS...
You're effectively breaking the network and the conventions which has been established to build them.
Ofcourse people are going to hate you. That's a given.
To my mind, the lack of privacy of classic DNS does indeed count as the the defaults failing to work. Yes, it would be more ideal to solve this at the OS level, but until OS vendors start providing solutions I don't begrudge applications that care about privacy for taking matters into their own hands.
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.
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.
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.
Mozilla has recently begun offering an integrated VPN with Firefox, though unlike DoH that has a monthly subscription fee (hell, I don't blame them for wanting to diversify their revenue). The partner in that case is Mullvad.
> You're basically saying that Firefox is now behaving like malware
This is hyperbole. End users should look out for their own best interests by using any means necessary, which includes hiding as much as they can from the network. If the network doesn't like that, then it has the choice not to allow that user to attach a device to the network.
I was a happy pihole user. I could choose to allow DNS lookups, and blacklist using OpenDNS. If I install Firefox at home, then I can't block problematic sites; and Cloudflare will use this to sell the idea to advertiser for TVs and such, so it looks like Google/Cloudflare just used Firefox to obviate ad blocking.
DoH is not meant for us, it is meant for the average people who have no tech background. Just because it will cost us a few minutes to configure, we shouldn't deny the overall benefit it will bring to most.
Thats not the problem. If more application folow Firefox, and do DNS on their own, corporate applications and sites will stop working, and IT will get the blame.
Now that it's just firefox, ok, but if other app will follow the lead, we will constantly have to play whack a mole, why someone doesn't resolve correctly.
How do I debug problems ?
Is there a tool (something like dig), i can use to see, how will Firefox resolve a domain ?
Where i work we don't block anything on our firewall, but we have plenty of services only exposed on internal DNS. Not to mention, we have to a lot of times replicate environment that is similar to clients, so I often create zones, where people can VPN in, and have similar DNS resolution as the target. Each app doing its own DNS will make that harder.
> Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse
That would be true, if Mozilla rolled this out worldwide, but its US only.
Also right now there are bazillion ISP with bazillion DNS servers.
There are very few DOH DNS providers that Mozilla endorses, so if majority of "privacy" conscious people will start using them, it will become that more valuable for various bad actors to compromise them. Right now there are so many ISP's with their own DNS's that even if all of them were selling the data, just finding them all and buying their data would be huge task.
This is another centralization of previously decentralized service. (like it happened with email)
Honestly I think that in the long run, this will be worse for privacy that we have now.
They can block the canary domain[1].
> Of course their argument was parental controls being made ineffective.
DoH is disabled on Windows and macOS if parental controls are enabled[1].
[1] https://support.mozilla.org/en-US/kb/configuring-networks-di...
And second, as an IT admin, I’m annoyed web browsers keep trying to develop new ways to bypass my network security.
Yes, that includes oppressive governments too... but I hardly think that even more centralisation is the solution.
The old security vs freedom quote is surprisingly relevant in so many situations today.
2) They are the singular (maybe there's one other now heh) resolver operator whereas with DNS anyone (even you) could (and did) run a recursive resolver.
3) I don't think anyone cares so much about this but http is probably the wrong protocol. The DNS protocol was pretty elegant in its efficiency and simplicity (IMO.) Yeah the compression was slightly complex (it's really not) but I've written clients without anything other than a socket library. HTTP on the other hand can do all kinds of complex things and has plenty of room for weirdness and tracking and unintuitive behavior that just isn't necessary for resolving names.
TL;DR: DoH is an unimaginative hack that has a lot of problems from a technical perspective but the social problems are much worse.
As for 2), it's not hard to run a DoH server yourself. In fact, it's much safer because it doesn't allow for amplification attacks like traditional DNS. The same goes for DNS over TLS (over TCP).
I agree with you on your third point though. I'd much rather have seen DNS over TLS being built into Firefox, especially as most DoH providers built into Firefox also provide DoT. DoT is easier to set up as well because you don't need any specific DNS server software (just have an nginx proxy the TCP connection to your existing DNS, it's about 10 lines of config).
I discovered that Android's "private DNS" functionality uses DoT. I feared they'd use DoH but luckily I was proven wrong.
And I say the possibility because I'm not American so that's not enabled here (yet). But I trust my ISP and my government much more than I trust Cloudflare (zero) and I will be very disappointed (even more than I already am) at Mozilla if they enable it in the rest of the world.
And DoH will enable every device you own to continue spying on you for the benefit of corporations.
DNS is the last bastion of preventing devices I can't sufficiently control from spying on me. I use DNS filtering to block their tracking domains. I use my firewall to prevent devices from accessing DNS resolvers I don't control.
DoH takes those options away from me. Ridiculously, in the name of privacy. Ha!
Unfortunately, the battle was lost the moment someone created a DoH implementation. It hardly matters what the browsers do. All the other things I don't want to have DoH will eventually implement it. And they won't respect use-application-dns.net or whatever other frameworks Mozilla comes up with for controlling DoH at the network level.
(Also, does anyone really believe that governments, ISPs, and public DNS resolvers aren't going to disable DoH with use-application-dns.net? I'm sure whomever came up with DoH in the first place had great intentions but the end result is a disaster that will cause more harm than benefit)
If you are worried about traffic in the browser you can not enable it, it you are worried about anything else then VPNs were already a thing since some time ago.
How do I stop that when my ability to control what happens on my own network has been been reduced to Can access the Internet over 443, or not?
If you are talking about Firefox itself, then disable it.
I sympathize with wanting more control, but I do not understand how DoH changes things in a household settings.
(I am assuming your is not a corporate point of view, in that case I agree that DoH might cause significant headaches)
Imagine you run a PiHole or use a service like OpenDNS. It doesn't matter what you've chosen to use or block, what matters is that you've made a choice to utilize DNS filtering for certain things.
You soon discover that some apps and devices don't respect your DNS decisions. They make money or derive other value through communications that are blocked by certain DNS-based filters, so they query 8.8.8.8 or some other DNS directly. You figure out how to make them respect your choice, through a combination of restricting DNS egress and DNAT at the router, and all is well again.
Mozilla and Chrome come along with DoH. That's alright. You can configure them not to. There's the canary domain, so you don't even need to configure browsers manually, tho I expect the canary will eventually go away -- it is destined to be "abused" by every entity in a position to get away with it.
What's going to come next is real the problem: Every entity which can benefit from being able to bypass DNS filters is going to move to DoH. It's in their best interests to do so. They don't need to respect the canary. You won't even be able to tell what they're doing because everything is encrypted with TLS and have pinned their certificates.
App will do it. Embedded devices will do it. Actual malware will do it.
This outcome is inevitable and that is my objection to the mere existence of DoH.
I understand why people do not want this and want control over their own network, I find that a commendable goal. I do not understand how DoH specifically introduces anything new since you could already get DNS data from HTTPS API
Also, turns out that malware has already jumped on the DoH bandwagon.
https://www.google.com/search?q=doh+dns+malware
It added yet another thing I have to implement, test and maintain through whatever changes they decide to make.
Nothing like adding extra work for every enterprise IT team to make new friends.
There are also some massive security issues with making all https traffic blind that making only the data blind didn't create - like the ability to blackhole known unsafe domains as they appear.
Browsers shouldn't implement DNS theirself, and should use operating system APIs to do all the DNS queries. That is how networks work, and doing that differently creates problems (imagine if every program has its implementation of DNS over HTTPS, you have to configure correctly the DNS server in each of them, and good luck debugging it when one implementation is broken...)
As a technical motivation, HTTPS in an high level protocol, and using it for DNS is kind an overhead. We already have DNS over TLS that is a standadized protocol, that can be used, and that the operating systems are starting to implement.
I use DNS over TLS in my local network, but rather than having configured all the computers to use it I have configured a local DNS server that encrypts the requests, for every host in the network, and also filters trackers and ad servers. Thus I don't want Firefox to mess aroung with my local network configuration that is fine.
With normal DNS anyone in the request chain can see a stream of DNS requests but there is no context. By the time the request is one or two hops from you it will be interwoven with tens of thousands of other requests making it impossible to know which one came from who.
With DOH the DNS provider will have a unique identifier to correlate requests back to a specific system/user. Google offers one of the most used DNS services, with DOH they will be able to track all DNS requests you make even if you turn on a VPN.
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.
Ummm so what’s the downside then? Are those services arcane and hard to use and utterly forbidding blackest black magic, like almost all crypto stuff?
If you’re thinking browser users will just do this then that then this and x and y and z to “get dns crypto going”, then I’ll take Mozilla’s “it just works” approach.
It’s a much much better approach for the browsers to implement it rather than wait for everyone’s operating system to implement secure dns because that’ll happen .... well I can’t imagine any time in the future you could say everyone’s OS is using crypto DNS, whereas if browsers implement it for themselves, instant massive adoption.
I think you have some reading to do.
Nowhere do “people just run a local resolver”. Grandma and aunty Beryl certainly don’t, nor does any other ordinary person. If you want secure DNS you have to build it in to the browser.
Only systems people think that this is the sort of thing that ordinary people do.
If Grandma has a grandchild that knows how to set up a PiHole, it's a different story. But that's certainly not the majority of Grandmas or the majority of wifi routers.
How many people do you know that running local resolvers? How would this even work on Windows?
The world doesn’t need another encrypted dns solution that only works on Linux
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.
Just increase the cost/difficulty of a thing makes that thing less common. In this case that "thing" is ISPs selling highly accurate web histories to anyone who will pay. Please make that harder/more expensive, every cent of cost to the ISP is welcomed.
[1] - https://dnsflagday.net/2019/
DoH is a protocol. It has better security than unencrypted DNS. (So do several others, like DNSCurve, DNSCrypt, or routing your DNS queries over a VPN.)
The objection people have is not that it's encrypted, it's that Mozilla implemented it in the browser instead of the OS and thereby ignores the DNS you configured in your OS. And even that is fine as a setting you can enable, but it's problematic as the default. Both because it's administratively burdensome to change a setting in every application on every device if you want to use your own, and because of the second order effect of that, which is that hardly anybody will change it and then DNS becomes centralized to whatever is the default in the browsers.
Just use a DNSSEC capable resolver in combination with a VPN. All other options today are effectively theater.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.
Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled). Over time you can hope for DoT to gain wider adoption so more and more of the upstream resolver chain is encrypted.
Confidentiality and authentication are two different things, but the things that provide confidentiality here also provide authentication. DNSSEC only provides authentication, so then you need something else to provide confidentiality at every point in the path. At which point you would also have authentication at every point in the path, so what does that leave for DNSSEC to do?
> DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
This is true. DoH isn't the one to use between recursive and authoritative DNS servers.
> Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
DoT has a similar drawback as DoH between recursive and authoritative servers. The session establishment is expensive (more round trips, higher latency). That's not so bad for the link between the client and the recursive DNS, because you create a session once and use it for all your queries. It stinks between recursive and authoritative servers because the recursive server would need a new session for each authoritative server -- and a single recursive query can often require contacting three or more authoritative servers.
Fortunately DNSCurve has lower latency and can be used between any pair of recursive and authoritative servers that support it.
The root not supporting DNSCurve is an issue, but it has an obvious long-term solution (have the root start supporting DNSCurve), and in the meantime the recursive resolver could validate only the root with DNSSEC. The lack of privacy is much less impactful for TLD queries -- a query for your-local-oncologist.com tells an observer much more than a query for .com. Then if DNSCurve is used for the rest of the chain after the root, you have one authentication or the other for the full chain and privacy for all but the TLD query. You also then don't need any large DNSSEC records in the authoritative servers that support DNSCurve, which would otherwise be a DDoS vector.
> So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled).
I still don't see what that's even supposed to be adding over the VPN right now. The VPN handles the link between the client and the recursive resolver. You can only get authentication between recursive and authoritative servers for domains whose authoritative servers support some authentication, but hardly any of them support any authentication right now, and if you're going to add one it makes more sense for it to be DNSCurve than DNSSEC because it provides confidentiality in addition to authentication and isn't a DDoS vector.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
Explain that to me?
There are 40 publicly available servers listed on https://github.com/curl/curl/wiki/DNS-over-HTTPS from large and small players.
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?
[1] https://www.digitale-gesellschaft.ch/2019/04/11/oeffentliche...
[2] https://www.digitale-gesellschaft.ch/dns/
Since Mozilla makes a browser it was natural they'd try to solve it at the application level and not wait until M$ and other privacy loving OS vendors solve the problem.
> instead?
It probably should be, but the undertaking is massive (cross platform) and browsers want a quick turn around. A lot of people would think that VPNs solve such issues, but it just pushes the problem further up the network.
In my opinion Linux would be a good candidate for such an initial implementation - but you wouldn't pick DoH, you would likely offer DNSCrypt or DoT.
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.
And for better or worse, the average user’s OS is hostile to a user’s privacy and security, with a few niche exceptions.
Is there some simple thing I can apt install on my Ubuntu system?
I mean, this is ridiculous: https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com/net...
> 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".
They could've used an image map. /s
DoH will leave my machines unable to resolve all my internal domain names, right?
There is. You configure your DNS resolve this "canary" domain to disable it.
At the moment, Mozilla wants to push this for users where DoH just works, for people it doesn't providing options to disable it.
Once resolv_doh.conf becomes a thing for all platforms (Linux, OSX and Windows) they can use that.
Perhaps some thought as to service discovery should have been done:
* https://tools.ietf.org/html/rfc6763
If Mozilla is going to re-invent the wheel (OSes already do DNS look ups), they perhaps should have asked the DNS folks (e.g., DNS-OARC) about some of the corner/use cases IMHO.
Some DNS hosters disallow private IPs. Some public resolvers and consumer routers will filter out responses containing private IPs.
We're in this mess because OSes haven't acted and Mozilla has had to take matters into their own hands. Unfortunately any solution that requires cooperation from other software is going to take a lot longer to land.
I do hope it happens eventually, and I'm sure that when it does Mozilla will change Firefox again to respect that.
There's also the fact that there's no DHCP option reserved for DoH/DoT/DNScrypt (yet) which requires some standardisation work.
There's various APIs to read the current DHCP configuration for a network interface so technically it shouldn't be too hard (at least not when it comes to Windows or macOS where there's standard APIs, as opposed to Linux whose modular layout makes finding a standard location for DHCP config difficult).
If they do not, they should be marked as forwarders for their respective domains. Something like `Add-DnsClientNrptRule -Namespace "domain.com" -NameServers "1.2.3.4"`
The operating system will have this information; an application, like browser, won't.
Seriously, do you disagree that it leaks information? Do you agree that it does, but believe it is less problematic for two companies to have this information than having it sharded across all ISPs? Do you agree that it's more problematic but you don't care for some other reason? Do you agree that it's problematic and care but don't like how I express my point? Do you agree, care and like my expression but think it adds no value to HN?
I can't learn if we don't discuss the issue.
(I agree with what you've said here, FYI)
There is no need to configure individual applications and no need to develop a new means of distributing DoH server information.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
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.
I don't understand why systems administrators don't just use their existing policy management to disable DoH if it really causes an issue. There's a group policy specifically for DNS over HTTPS [1]
The only reason I can think of is that they can't because of BYOD or Firefox being part of the company's dark IT. The DNS workaround doesn't help much in those cases because the underlying problem is a lack of oversight, not an issue with Firefox.
[1] https://github.com/mozilla/policy-templates/blob/master/READ...
A quick search shows me a number of parental control features in routers that use OpenDNS. All of the parents using those features would be "network administrators", too.
I think more people are "network administrators" than the average HN reader realizes.
The “network administrator” is an untrusted 3rd party who should have basically 0 say in how my device operates.
The device administrator, ie the owner of the machine, is the one who should have the final say over when DoH is used. The use-application-dns record is for businesses that want an easy way to stop DoH on machines they administer. If random “network admins” start deploying it as you say then Mozilla will have no choice but to ignore the record entirely.
This kind of centralised ability to block DoH is very useful to me.
* On devices that you own and control you don't need a network level control like this except for convenience. This is when you should be applying the override record.
* On devices that you do not own or control (family/friends/guests) disabling DoH makes you the malicious network operator. Connecting to your Wi-Fi doesn't make you trusted in any sense of the word.
* On devices that you own but do not control (Google Home/Alexa) you make a valid point that techie types have been able to take some level of control by exploiting the fact that DNS is an unencrypted "hole" in the security of the device. You would have a lot more control if the HTTP traffic they sent was unencrypted and inspectable/modifiable but that doesn't mean devices shouldn't be allowed to use HTTPS without your approval.
That's like saying that me stopping guests taking photos of my daily activities (showering, using the toilet) whilst in my house is a malicious behaviour too. I suppose I should let them post the photos off to whomever they choose?
If someone is in my house and using my WiFi, I don't want their device looking up domains that I choose to block. How do I know that their device is not recording its surroundings and sending them off to the said domain? How do I know that my guest is not up to nefarious/illegal activity using domains that I have blocked? I would be the one prosecuted due to the IP address = a person approach by the law in most circumstances (should they ever deduce the requested domains from the DoH set up). Being that the DoH provider is under law, I am pretty sure that the DoH will have to hand over any records they have, which will lead it back to me and my network.
And then once again we are stuck in a situation where I cannot control what domains are being looked up by devices and applications on my network. My devices are no longer mine. I have handed off control to some company the other side of the planet with employees I will never meet.
How do I stop the 5+ tracking domains that the Instagram app uses on my wife's iPhone, for example? Am I a malicious network operator for stopping that garbage being sent off?
You can attempt to block and filter things, but there will always be a way for something malicious to bypass it.
This is kinda the point. For devices you own you have that control by the virtue of being the device admin. Other people's devices are a different story. You are free to have an acceptable use policy on your own network and require traffic to flow through a proxy or whatever but if you do it without their knowledge or consent you're the bad guy.
How pissed would you be if Xfinity just up and blocked random sites like this?
(sibebar: Just from a politeness perspective why would you give your guests anything other than a clean path to the public internet ?)
> That's like saying that me stopping guests taking photos of my daily activities
Having a rule that applies to your guests -- totally cool. Silently disabling their camera without their consent once they come through your door -- not cool.
> Am I a malicious network operator for stopping that garbage being sent off?
I mean you're modifying the traffic coming off of someone else's device without their knowledge or consent. I would be pissed if by husband did something like this without asking -- leaving me to debug why some sites are mysteriously broken.
You're kidding, right.
I block MS telemetry domains for example, where's the config for me to stop them using DoH; what about the trackers on my TV?
Now I need to configure every device - that's capable of using Firefox - rather than configuring the network. Presumably in short shrift there'll be no way to block Google advertising. I guess Google will get their return on funding Firefox.
DoH is a non-solution to a non-problem which makes privacy strictly worse by leaking information to Cloudflare in addition to one's ISP.
DoH and DoT is a solution to the problem of sending your DNS requests unencrypted, leaking them to everyone in the process, and then opening the door to any malicious network operator in between you and your DNS server the ability to modify the response in-flight.
Your ISP can and should provide DoH servers. Your local network is free to do the same.
It is 100% not the place of an application to meddle with network services, particularly not by default.
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.
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.
FWIW, my entire peergroup grew up without anyone installing content filters on their computers, and porn was already widely available back then.
What use cases do people have in mind?
* State censorship. Totalitarian.
* "Parental controls". Child abuse. Learn how to build trust in your children instead.
* Corporate filtering. Find other ways to motivate your employees than blocking Facebook.
The problem with this implementation is that it doesn't go far enough. I want software to actively fight against the idea of content filtering.
I don't think the post you're replying to is really saying "no innovation". I think it's more subtle.
The "problem" with DoH is that you need to look at it with several different hats, and I feel very few people make it clear how they're complaining about DoH.
* From a consumer perspective DoH is a good thing (mostly)
* From an traditional/enterprise/business-like environment perspective it's inserting itself in the middle of the stack and may cause headaches with a few things (not limited to leaking internal names to external resolvers), unless it's just blanket disabled/forced to a local server (which may not always be practical for different reasons) - currently
Ultimately who do we have to blame for this but ourselves? Organisations have tried to get encrypted DNS off the ground in traditional DNS infrastructure and clearly failed to meet the required timeline.
I personally feel like the problem, just like with IPv4, is that traditional DNS infrastructure is "fine" (i.e. it works). We don't have a great motivation but we do have fear of breaking the many many many boxes which are un-upgradeable/critical.
But if I enable DNS over HTTPS in Firefox, it very clearly still uses the Cloudflare resolvers. We have some split-horizon zones set up (resolve to 10.x IP's internally, and public IP's externally). When I tick the DoH box, Firefox starts resolving the public IP, verified in the Dev Tools network pane.
Curious if the issue lies with us or Mozilla.
https://bugzilla.mozilla.org/show_bug.cgi?id=1614751
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.
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.
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/ 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.
Seems a bad idea....
At least with DNS I could run a local DNS server and block outgoing port 53 from anything else. Now I no longer have this option and each app gets to look up what it wants, when it wants. Sure, it's great that my ISP cannot see what's in these requests but nor can I! And it also means that any application (eg. any Google product) can query for advertising/tracking domains without me being able to do a thing about it.
It isn't solving a problem - it's creating a far, far worse one (for me).
If I have got this wrong, or there is a method around this - what is it???
Also remember that if you can break the security of a device, so could an ISP router. The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile.
How many people are using custom local plaintext DNS as a measure to analyze local devices on their network? How many more people are having their whole network's DNS usage analyzed by their ISP and anyone their ISP sells data to? The defaults are designed to be the right choice for people who don't change the defaults.
Thanks for this - I had not thought of that.
Looks like I'll be keeping my "smart" TV off the network forever then (my old LG used to send a network request whenever I pressed any button on the remote)! And all my Android devices, Windows 10 devices and my Apple TV and MacBook too. (This is only partially sarcasm - I can't really trust anything these days it seems...). The amount of dialling-out they all do is astronomical. The only solution appears to be going full 1980s and not being on the network. The dream is over.
At least my Raspberry Pi can be trusted. Other than the GPU chipset...
What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.
This advice is about as practical as "Do not use ISPs and their forwarders that you don't trust.". Which is to say, not much. Let us know about your experience with smart TVs and similar devices, and how much you trust them.
Oh, is that all?
How about I trust the devices until a secretary clicks on a (spear)phishing link that runs a zero-day. Then what? The host is compromised so I can no longer trust any end-device monitoring software on it, and now the network traffic is opaque.
And that doesn't even get into things like academia where students and visiting researchers bring devices of unknown providence. If if they're on DMZed networks, they could be spewing garbage onto the Internet and getting my CIDR range blacklisted.
Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.
* https://en.wikipedia.org/wiki/Domain_generation_algorithm
* https://en.wikipedia.org/wiki/Botnet#Domains
If malware is connecting to hard-coded IPs then there's nothing we can do about that.
So yes: monitoring DNS for suspicious activity is part of our security strategy.
Unfortunately they also treat the user as hostile and untrusted. Your phone, browser, OS, or TV treat you as hostile when they send data to the manufacturer and give you no way of assessing yourself or actually controlling this. We have standards and protocols that ensure the data is kept perfectly secure and inscrutable between your device and the manufacturer but absolutely nothing is put in place to give you any control over this. Your choice is binary: use it or not. Every security decision seems to work out better for those companies than for the user.
In this case both DoH and DoT provide the required security for the users but one of them takes a little bit of control away from them.
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.
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
Also VPN sniffing can be arbitrarily hard, for example if I remember correctly tools like https://www.softether.org/ are designed to work around the Chinese internet firewall.
From my point of view DoH add nothing outside the browser.
That confidence would have been misplaced. DoH offers a standardized protocol, but it's not exactly difficult to put together a one-off interface for performing occasional remote DNS lookups over HTTPS. One could even use existing HTTPS sites for the purpose (e.g. https://ping.eu/nslookup/).
> Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. [0]
Of course it's a security control. Not a perfect one but a security control nonetheless. And every security control of today might become useless tomorrow so I don't get your point. Is a firewall a "guideline" just because I can tunnel some illegitimate traffic through an accepted port? Are your house and car door locks "guidelines" because a thief has to "volunteer" to not break/pick them or go in through the window? So you'll take them all out until you have "real" security controls? I guessed not...
As for your airport example, given that illegal activities go unnoticed and items are smuggled through customs every day you could argue that there are no security controls in place and that the airport relies on people volunteering to not break the law. But you'd be using the wrong definition and understanding of what a security control is.
As far as home security goes having DNS filtering adds a layer on top of the "nothing" you normally have. And it's a pretty good and accessible way to achieve this extra bit of security. "Not perfect" does not equal "no security". And it's not even just security: ad-filtering, parental controls, privacy, etc. are all impacted. DoH all but guarantees that you lose this control and unfortunately there's nothing ready to take its place.
[0] https://en.wikipedia.org/wiki/Security_controls
It isn't really a matter of security controls. Anything has always been able to create an encrypted tunnel on TCP/443 and send whatever over it.
The issue is administrative cost for cooperative applications. You have a local DNS that e.g. blocks known malicious domains and has the local names for other devices on your LAN. The user of each device doesn't want to prevent this, the application developer doesn't want to prevent it, but making that happen when applications default to using a third party DNS goes from setting the DNS via DHCP to changing a separate setting in every application on every device.
The suggested solution to this is to have the local DNS resolve a canary domain in a particular way which Firefox takes as a request not to use DoH by default. That basically works, but I still don't know what they intend to do when adversarial upstream DNS servers start resolving the canary domain that way. It would also work a lot better if there was a standard canary domain instead of every application making up their own.
You may find noteworthy that my comment had 2 points. One where I don’t feel like DoH will bring much benefit in the browser today, and one where DoH in general will just give you, the user, even less control over what you’re sending out. I can’t imagine everyone giving you the option to switch, all the TRRs being actually trusted, or even being able to pick the TRR in most setups (IoT? Your random Google product?).
As tech changes, solutions change, but at least for the foreseeable future your DNS intercept will keep working just fine until everyone switches over to DoH and stops offering an opt-out.
Parsing the text helps with understanding it. And the fact that Mozilla allows me to flip back says nothing about those general cases. I do not expect everyone to give you the choice.
It gives them a competitive advantage in DNS industry against other B2B providers, such as NS1.
Surely the only way that's possible is if they derive data about users, which they can then sell .. which is what Mozilla claim to be preventing.
I'm not a CF fanboi, in fact I think they are evil. But let's not make weak arguments. That said, yeah suppression of ECS info is a deliberate anti-competitive choice by CF. They probably have convinced themselves its about privacy, but it isn't.
The real benefit to them is, as the CDN, they get the benefit of even lower latency and even better control. With a penalty to everyone else.
It's a disgusting arrangement, and a net loss in privacy. Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
I'd find it more palatable if these so-called TRR providers were required to be DNS-only. Maybe DNS + registrar.
Then why were the big ISPs lobbying against this plan when proposed by Google originally? Because they truly were concerned for the welfare of the Internet as they claimed? This is a concern they've never exhibited in the past, their only demonstrated concerns have been related to their revenue streams.
Running a public DNS service allows Cloudflare and NextDNS to provide faster and smoother DNS updates to their B2B customers by avoiding third-party DNS resolvers and caches.
We've seen the "don't be evil" free stuff thing turn sideways before.
> We intend to publicly document violations of this Policy and take additional actions if necessary.
I believe that those "additional actions" will prevent providers from violating the policy. If not, they will be removed from Firefox.
[1] https://wiki.mozilla.org/Security/DOH-resolver-policy
Other countries have censorship (China, UK, New Zealand, etc) whereas there is none in the US.
I wonder if that’s why?
I'm amazed noone else is asking this. CF's whole business model centres around the concept of denying website access to minorities they classify as "bots". Some big actors can afford to practice the notion of reciprocity by blocking access to Cloudflare in return — https://news.ycombinator.com/item?id=21155056 — try doing that now when you might end up blocking access to your site for all Firefox users.
They’re usurping control and calling it a privacy enhancement so they can sell the control back to us with per user per month pricing.
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.
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: "209.216.230.240" 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.
I hope it's just a matter of time before they fix this :)
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.
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....
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.
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.)
Why?
Well, this explains why Archive.is never works...
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?
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?
Yes, are explaining to our colleagues what IP address, subnet, route, or interface are.
--Someone with a decent understanding of networking
> 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.
Breaking DNS is madness IMHO. Its just more sites that dont work on FF.
Broken is not more secure, its just broken.
1 https://hpbn.co/
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.
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.
So in other words: privilege escalation.
Yes, I'm consciously spending karma on this answer.
Cloudflare has already done that before.
https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
These are separate features and should be decoupled accordingly.
https://bugzilla.mozilla.org/show_bug.cgi?id=1500289
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.
When they roll out in the EU, I will pay close attention to how they are doing it, what partners they use under what jurisdictions etc.
Gotta also make sure I don't get a US Firefox build somehow.
But good point, now I am curious how they detect US-ness. Probably a combination of using the en-US and some geo lookup?
But to make things more honest, I'll edit my comment.
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.
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 :)
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.
I guess that's step 2 in "advancing" the web.
The current system using a cache works relatively well until you want privacy.
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.