It's bad for privacy in theory because you centralize DNS requests through Cloudflare. In practice ISPs are almost universally reprehensible in how they collect, track, and sell your data. Cloudflare on the other hand has a great reputation for respecting user privacy and they do thrid-party audits on a regular basis so you can have peace of mind about it. Encrypting your DNS requests so your ISP (and other hops on the Internet) can't snoop on it is a huge privacy win.
I'd much rather trust Cloudflare than my ISP. Doubly so when I'm out of the house or traveling abroad.
> In practice ISPs are the almost universally reprehensible in how they collect, track, and sell your data
... in your country.
For me it's the other way around; i'd rather trust my ISP because privacy laws in my country/EU are much better vs the US.
I interpret the move by Mozilla as hostile in regards of privacy, and i can't understand why EU politics don't intervene when a US company starts hijacking all Firefox users DNS requests (opt-out instead of opt-in.)
The Cloudflare DNS servers you connect to are in the EU and are subject to EU regulation just like your ISP. You don't have 11 ms (or anything sub-~90 ms) latency to the US.
One thing to consider also is that unencrypted DNS means that virtually anyone can read (and modify) those requests, not just your ISP. That can be before the data enters your ISPs network, or at any point that isn't physically or technically well protected. Or, in the case of state actors, at any point really.
> The Cloudflare DNS servers you connect to are in the EU and are subject to EU regulation just like your ISP.
Yeah, sure:
> Primarily the CLOUD Act amends the Stored Communications Act (SCA) of 1986 to allow federal law enforcement to compel U.S.-based technology companies via warrant or subpoena to provide requested data stored on servers regardless of whether the data are stored in the U.S. or on foreign soil.
The CLOUD Act would do nothing in this case because Cloudflare doesn't store data related to your requests and claims they are regularly audited to prove that.
CF has a lot more privacy minded people to whistle blow on that if they were lying than your local ISP would.
Yes, the Core Secrets leak said the "FBI" would "compel" companies to "SIGINT-enable" their networks if in America. In the Lavabit case, the judge was cool with FBI's proposal to compromise all the users, not tell them about it, and business owner's revenue would be fine. If overseas, there was a spy/soldier group that would take espionage-style action against them. That's if a payment didn't work.
I assume they backdoored all of them, including Apple, with them instructing the companies to hide that fact. They then use parallel construction for the important cases. The less-important cases would go through the regular system. The FBI made a big deal about that one phone to try to expand the All Writs Act to make their access easier. At this point, they probably have access to a lot of it but want their legal, observable powers to be expanded.
That's how it works in a Dual State: a police state with a regular government you can defend against running side-by-side with a more powerful, secret government that can do whatever they want to many targets with secrecy and criminal immunity. Unlike previous Dual States, they restrict the targets and methods of the Deep State more to make its damage invisible to most voters. They think it won't hurt them, just deserving people. Meanwhile, they gradually shift more power previously afforded by the Deep State to the Public State while Deep State collects and passes more information over time to the enforcers of the Public State.
The Snowden leaks confirmed both Deep State activities and the collaboration between the two with denials built in.
Going by the Apple example, they refused to create new code to do something they were not in the past. That limit made the courts agree with them that they could not be compelled to create something new.
Yahoo / ISPs already have the data so they have to comply with the law by providing that data upon request.
> Yahoo / ISPs already have the data so they have to comply with the law by providing that data upon request.
Data is being sent to CF: can they be forced to raise the logging level from "INFO" to "DEBUG"? See also Lavabit:
> Lavabit is an open-source encrypted webmail service, founded in 2004. The service suspended its operations on August 8, 2013 after the U.S. Federal Government ordered it to turn over its Secure Sockets Layer (SSL) private keys, in order to allow the government to spy on Edward Snowden's email.[2][3][4][5]
I imagine that at its scale, CF could legitimately claim technical limitations prevent them from collecting data at the volume of traffic that 1.1.1.1 gets.
I think it's important to realize that this is basically shifting the whole discussion. What DoH is supposed to provide is privacy from your ISP. It's not claiming to provide privacy from the government, and most people don't expect to have DNS privacy from the government (that's not to say it's not desirable). So this point is basically just misdirection.
If your adversary is the United States government, then no, DoH isn't great for you if you're not in the United States and if the US can't get to your ISP / DNS provider anyway, and if your only DoH endpoints are owned by US companies. You also have much bigger problems than DoH is attempting to solve.
> The Cloudflare DNS servers you connect to are in the EU and are subject to EU regulation just like your ISP.
In my (non-EU) country, ISPs are subject to relatively strict regulations, and Cloudflare doesn't fall under those regulations.
> One thing to consider also is that unencrypted DNS means that virtually anyone can read (and modify) those requests
Not "virtually anyone", it would require physical access to the GPON fibre between my home and the MSAN/CO/Exchange (non-trivial, scales really bandly), or the MetroEthernet backhaul from the MSAN to the BNG (where they would trip alarms and the last-mile provider would investigate). From the BNG onwards traffic is encrypted on-the-wire (MPLS with group encryption as far as I know) until it is handed over to the ISP. My ISP co-locates caching DNS with their hand-over routers, so here it would require tapping the fibres in their data-center (not happening without their knowledge).
Also, someone who is just mass-collecting my DNS requests without any other identifying data, and no ability to correlate IP address to users, has limited privacy exposure.
A centralised third-party, who can correlate source IP addresses with user-identifying browser cookies from other HTTP requests in the same time window seems like a much bigger privacy concern.
Americans, please sort out your last-mile provider+ISP monopolies (e.g. lobby your politicians for regulations that enforce competition), so that you can stop forcing unnecessary technical solutions on the rest of the world, who doesn't have this problem (if ISPs do anti-customer things, they lose business).
> or at any point that isn't physically or technically well protected
Kind of off topic, but I was wondering if ISPs use any encryption whatsoever between the home and their IX/servers. Could you theoretically attach something to the wire in the ground, or monitor a satellite-based internet signal, and observe the HTTP/unencrypted data?
There's no additional encryption layer if that's what you're asking. There will still be multiplexing and whatnot, but if you can recover a particular stream from that, it'll be the same stream that the endpoints see.
Optical fibres can move _way_ more data than actual households need, so you use one fibre to move data for, say, 16 endpoints until you get closer, and split it later, saving the cost of 15 long fibres.
You can do everything so that there are no active components out in the field where it's annoying except at the customer site, a passive splitter is quite capable of shoving frequencies A-A' to Alice, B-B' to Bob and so on, it's not just solid state it's completely passive, no more likely to need maintenance than, say, the fibre itself.
Not sure how that is relevant to OP's question then. You're describing PON, ONT-OLT communication is typically encrypted as well which makes the response make even less sense.
Wouldn't say that the cost benefits are from that, majority of the cost is going to be from putting fibre into the ground or on poles, same cost for 1 or 200 pairs. The real benefit is that you don't need any active equipment like in an ethernet distribution network.
> ONT-OLT communication is typically encrypted as well
Is it? I guess that's conceivable though it looks _optional_ to me, but I have no statistics as to how widely the option is taken up.
Nevertheless the G.948 work basically doesn't care about eavesdroppers. The threat model they've engineered around is that Eve lives next to Bob, and so if she tweaks the ONT (which legally belongs to her ISP but is on her property) she can see Bob's messages, whereas we're talking about a fibre tap to receive everybody's messages and then we'll root through that for Bob's messages.
G.948 as amended makes random keys in each ONT and sends them to the OLT, knowing Eve can't see the key chosen by Bob's ONT (it passes upstream not downstream). But as an eavesdropper with a fibre tap we do see both directions so this countermeasure doesn't inconvenience us.
Good on them for spelling out a threat model, and to me their model seems reasonable (if Alice buys Premium Sports for $180 per month we don't want Bob to watch Premium Sports free by pirating Alice's data) but it doesn't stop bad guys snooping this traffic.
Anyone with physical access can read unencrypted traffic if the ISP has not implemented any link layer encryption. All you need is to slightly bend a fiber and it will leak light.
There is a perfectly good alternative which is encrypted DNS or DNS-over-TLS. That should be implemented instead. Sure it’s harder, because it’s decentralized, but that’s the whole point of DNS.
It's an untested legal situation: EU claims authority (GDPR for European customers) AND US claims authority (various snooping acts binding for US companies even when working abroad). At least in public there's no resolution at this point in time.
I reached out to Mozilla, and they've confirmed that DoH is being enabled by default only for installations inside US.
So, if you are in the EU, Firefox won't switch you to DoH. You can still enable it if you wish, but your DNS queries will reach your local resolver unless you change it.
> I reached out to Mozilla, and they've confirmed that DoH is being enabled by default only for installations inside US.
How do they know? What is the likelihood of them getting it wrong?
What protections do they have in place for their geo-location, to ensure that they don't leak unnecessary information when determining whether a user is in the U.S. or not?
In Czechia, ISPs are forced to block certain websites, but exact method is not speficied. Today, they just block it on DNS level, as that is simplest and effective enough (although easy to circumvent). If ordinary users were using DoH, then ISPs would be forced to use IP based blocking
This was one of the concerns brought up at the UKNOG panel:
Currently there is DNS blocking (e.g. gambling sites in Poland), and it handles most cases. If (too many?) people start circumventing that, will a government start insisting on more invasive measure (e.g., DPI)?
The government wrote a white paper about this because they proposed yet more blocking (for the whole anti-pornography thing where they want you to go buy a "pass" to look at porn) back in 2018.
The ISPs are not inclined to pay for DPI or whatever other nonsense, even if they believe it could be effective, which it probably can't be. Government does not want to take on a major budgetary extra to pay for something that's already unpopular. So that leaves it not getting done. Much hand-wringing.
The government already acknowledges that Tor completely defeats all existing attempts to censor the Network, but they supposed that DNS blocking is affordable and good enough. So, we make it no longer "good enough" and then too bad for their stupid policy.
First, these things are generally country specific. Is there an EU Directive that makes it continent-wide?
Second, given countries in the EU are fairly democratic, this is done via acceptance of the voting public because they elected the representatives. They can always have the law changed if they don't like it.
Depends where in the EU. In the UK, DNS snooping by ISPs is universal, and in fact required by law under the pretext of blocking minors' access to porn.
> ... in fact required by law under the pretext of blocking minors' access to porn.
[citation needed]
Which law specifically? I was under the impression that this was currently being done voluntarily by the ISPs so that the government wouldn't start drafting legislation.
(I could be wrong; I just want a referenced/definitive answer either way.)
The idea was, Porn sites need to obey UK government rules, if they /don't/ (and why would, for example, a Canadian porn site obey those rules?) then a censor (the BBFC that took on this role for video got that job) directs that ISPs should block the offending site using DNS blocks.
In practice it keeps getting pushed out because it's hopeless from all angles.
If you have a laptop and configure your DNS automatically, you are using whatever DNS is configured by hotels, airports, coffee shops, etc. You have no privacy whatsoever when it comes to DNS requests and you have no control over this until you manually configure your DNS (which most users don't even know how to do). The default configuration of laptops is to use whatever they are told to use automatically. In most places the only safe assumption is that multiple nation states are actively monitoring and aggregating every single DNS request you make and the practical reality is that that is actually exactly what happens.
The sad reality is that ISPs in most places don't lift a finger to protect the privacy of their users and actively facilitate policing, censoring, and monitoring of their user's DNS traffic; even when they are not required to (which they are in most places). Your trust in them is completely misguided.
I live in Germany. I know that my ISP works with the German government to help them censor me accessing certain websites by blocking DNS. I also know that they collaborate with lawyers going after individual p2p users. And I know it has a history of serving advertisements on domains that don't resolve (something I opted out of years ago). I also know DNS traffic data is routinely shared between different nation states and that this practice has little or no oversight.
In so far they are not actively sharing data (which they are), they can also be relied apon to be generally incompetent when it comes to operating and securing their infrastructure and you'd have to assume that foreign intelligence agencies have been actively helping themselves to whatever information they can extract that way for decades.
If you are wondering, my ISP is O2. I'd switch but Germany has a state protected ISP oligarchy and the other ISPs are not really much better.
Mozilla protecting users from their privacy being violated like this by default is a net improvement in most places in the world. Anyone who cares about their privacy enough already configures their DNS manually and probably also uses a VPN and can continue to do so. But for those not capable of figuring this out, this is a massive improvement of their default level of privacy. The status quo for that is that they have none whatsoever in most places when it comes to DNS. It's hard to do worse than that.
> I know that my ISP works with the German government to help them censor me accessing certain websites by blocking DNS.
Citation on o2/Telekom/etc blocking domains?
> I also know that they collaborate with lawyers going after individual p2p users.
Kind of hard not to do if you're legally obliged. But not per se a privacy violation and not a matter of snooping on content.
> And I know it has a history of serving advertisements on domains that don't resolve (something I opted out of years ago).
> Ok but again not really a major privacy leak, just stupid/bad/user-hostile practice.
> I also know DNS traffic data is routinely shared between different nation states and that this practice has little or no oversight.
And who is the main party spying on/in Germany? Snowden leaks tells us the NSA, with active but idiotically unaware cooperation by the BND. So you're giving data directly to a US cloud provider instead.
Parties, plural. A better question would be who isn't spying. I live in Berlin. The Chinese, Russians, North Koreans, US, UK, Iranians, etc. all have big embassies here and there is a lot of diplomatic traffic and it of course features frequently in popular fiction on espionage. Also, there are lots of political refugees from all over the world living in Berlin. E.g. Ai Weiwei lives somewhere in my area and I've seen him on the street a couple of times. I live a kilometer away from the HQ of the German secret service.
I have no illusions about Cloudflare. However, unlike my ISP they are big, pretty competent, generally under a lot of scrutiny, and have a very big incentive to not get caught with their pants down contradicting what they say they do in their contracts, terms of use, etc. Not exactly ironclad, I know, but definitely a step up from O2's combination of indifference, incompetence and tendencies towards actively not caring one bit about their users privacy.
Interesting question... How would I file a complaint against Mozilla?
Their privacy policy is only available in English and lists Mozilla Corporation in Mountain View as the legal entity.
They probably don't conduct many business activities in the EU.
However, it looks like they are providing a website for "data subject access requests" which means they might fall under EU regulation as it sounds like a GDPR compliance thing.
So I also live in EU and, regarding DNS, I trust NA way more than the ISP of my country.
Your local intelligence agency and local ads network can probably way more easily and legally look into the local DNS records of the same country than the records stored on another continent.
What's more, I don't mind the USA having my browsing habits because they can't easily use it against me, as EU is a different market.
It's all about splitting the data about yourself to different competing entities, rather than trusting only one entity with everything.
DoH is a vendor-neutral protocol. There are already many DNS providers beyond just Cloudflare offering it, and there's no reason that every existing DNS provider couldn't offer it in the future. DoH is simply DNS transmitted over a secure encrypted medium, whereas existing DNS is transmitted over an insecure unencrypted medium. It's very similar to HTTP vs HTTPS.
Somehow, groups that stand to gain a lot by continuing to be able to read and intercept DNS traffic have led a successful astroturfing campaign against DoH by conflating it with one specific implementation in Firefox that happens to use Cloudflare as default provider (though of course with the ability to choose other providers, as you can for search engine). This is not a good argument against DoH in general, for obvious reasons.
But there are still gaps regarding discovery of DoH servers.
> DoH is simply DNS transmitted over a secure encrypted medium, whereas existing DNS is transmitted over an insecure unencrypted medium.
I think you're confusing DoH and DoT.
> It's very similar to HTTP vs HTTPS.
No, it isn't.
1)It is common to HTTP-redirect to HTTPS, and none of the DoH proponents have proposed/standardised discovery of DoH, as far as I can tell.
2)DoH means that suddenly many "features" of HTTP infect DNS, such as cookies. The RFCs allow for cookies, the question is, what cookies does Mozilla send in DoH requests, and what does Cloudflare do with them?
> Somehow, groups that stand to gain a lot by continuing to be able to read and intercept DNS traffic have led a successful astroturfing campaign against DoH by conflating it with one specific implementation in Firefox that happens to use Cloudflare as default provider (though of course with the ability to choose other providers, as you can for search engine).
Not only "groups that stand to gain", but users who stand to lose more privacy by exposing their DNS requests to Cloudflare by default.
DoH may be good (I think DoT would be better), and surely Mozilla could do a better job of encouraging DoT and/or DoH support by working to get better discovery of DoH and/or DoT instead of forcing all DNS traffic (for users it has identified are in the U.S., and by the way, how does it do that without additional privacy concerns) to a (to me) un-trusted third party.
Actually, I think in my country, if they do this, Mozilla would fall afoul of traffic interception laws.
If I understand it right, the current rollout is US only.
I know some folks outside the US trust their ISP more than a US company. Right now it appears the rollout isn't hitting you unless you opt in. Mozilla recently clarified this to politicians in Britain [1]
US ISPs are all subject to NSL and the US gov the same way Cloudflare is.
What's different is privacy. When I'm at a coffee shop or some other place my DNS traffic is normally unencrypted. ISPs have gotten a reputation for doing shady monitoring. This doesn't stop all of it but removes a method to watch things.
For US folks the question becomes, do you trust Cloudflare under a special agreement negotiated with Mozilla with a goal of protecting privacy or do you trust your ISP and the ISPs of all the places you connect?
For folks outside the US I'd wonder if or when this would come to me.
If I'm incorrect on something please let me know. I'm just now learning about the reach and implications.
I am not a US citizen, your practice isnt mine. That also goes for many here and many more of the people who use the internet. I cant trust a US company with my DNS requests because lacking US citizenship or residency I lack any rights or protection whatsoever when it comes to my data. For my local ISP on the other hand, there are clear rules and regulations in place on how they are allowed to use and share my data.
I would say i have more trust in my ISP but trust is not the issue here, its jurisdiction. Routing my DNS requests through another jurisdiction where i lack any rights or protection is just a horrible "screw you" to anyone not living in the US.
It might be the tinfoil, but looking at this move by Mozilla after disabling addons silently via an out of date cert a few month ago (screwing over every last Tor user in the process) I am hard pressed not to assume malice on their part.
Keep in mind that Cloudflare is US company. US government is infamous for secret subpoena and gag orders toward the US companies. Also US government is infamous for serious and illegal spying. They also holding known vulnerabilities information from public for greater good(for them).
There's also no trust with ISPs. They've already all lobbied at the Congressional level to legally sell our data. The NSA already captures/stores everything that comes out of any of their datacenters. So whose DNS do we use? A shitty company's, or another shitty company's?
>They've already all lobbied at the Congressional level to legally sell our data.
And succeeded! And even as they did it and succeeded, claimed that they didn't want or need that ability and /totally/ wouldn't take advantage of it if/when it did pass.
it's also a business. As soon as they find it advantageous to start selling that information, they will, and will ride on their reputation for privacy to make as much as possible from that information
Cloudflare and their servers are also based in a country where secret court orders can force CF to collect and stream out request logs, lie on their privacy policy, and force "third-party audits" to say everything is OK with basically zero checks and balances.
I don't give a triangular fuck if local ISP X is selling DNS statistics to marketing corp Y. If they're getting something useful from the 101 domains every web page load seems to contact nowadays, power to them. But I'm not okay with some shadowy alphabet-soup-esque mire of "public servants" building a profile about me from a conflagration of data sources, and using it against me when they feel like it.
> * In practice ISPs are the almost universally reprehensible in how they collect, track, and sell your data.*
This means it would be an enormous leap forward in privacy for vast amounts of people.
I never understood the “perfect or nothing” approach to security that manifests itself in circles of the tech elite. Football is won by getting 1st downs, not throwing touchdowns every time.
Your ISP can see the endpoints you are connecting to regardless. So you get a strict reduction in privacy.
Has cloudflare ever gone to court to fight an administrative subpoena? More than a few ISPs have.
DoH seems like fine technology. Tying it to cloudflare is kind of shocking, since many technologists have long suspected that cloudflare is regularly being used to intercept traffic.
Am I the only one who remembers "Cloudbleed"? I can't understand why people are so eager to trust Cloudflare with more and more of their HTTPS traffic.
This would only be true if your ISP couldn't otherwise violate your privacy. Which they can. That they don't see your DNS requests is an extremely low barrier. They see all the subsequent traffic.
Using DoH increases your privacy attack surface, not reduces it.
I think you misunderstand. I'm not talking about the contents of the packets. I'm talking about the IP address destinations. You know -- the part that DNS tells you. The ISP has that info anyway as they transit the traffic for you.
Still waiting for your argument for how it's worse. The way I see it it's at the very least no worse, but in practice much better for most people. I have an open-mind on the subject, convince me.
I'm confused, because I've already presented my argument. Here it is again:
Hiding your DNS requests from the ISP is pointless. The ISP sees where your traffic is going. This the result of those DNS requests. It doesn't matter that they didn't see the actual DNS request; they see what the answer was. They know what sites (DNS addresses) you are visiting.
So sending your DNS requests to a 3rd party (multiple ones in the recent RR version proposed!) simply spreads wider the folks that can profile your traffic. As unrelated 3rd parties, those people would otherwise have had no idea where you, private citizen, were sending traffic. Now you have explicitly told them. You have given up privacy, not enhanced it.
Please keep in mind, I'm not arguing against DoH wholesale. Just that it is worse for privacy. The primary consensus argument in favor of DoH is about privacy, which is flat out wrong.
They see the destination IP you are connecting to, usually behind one IP is only one web site. ESNI doesn't matter unless you are connecting to a site on a shared host.
No it's not, that kind of attitude is how you end up with people trying to replace the DOM API with sed or awk. In practice there's quite a lot of DOM queries that can be replaced with awk until you need certain things that become very hard. Theory would have warned you about that from the beginning.
I don't even know where to start with this. The idea of using sed or awk instead of the DOM is ridiculous in both theory and practice.
All I'm saying is how things are in reality is more important than how things are in theory. I'm curious if you can find an instance where that's not true, but regardless it's a good rule of thumb.
How things are in practice matters, but there's risk that you're misreading the situation. Theory can speak not just to how you think it is, but also to how it might be - particularly in security, where hostile actors are trying to change how it is.
You can still set 1.1.1.1 as your DNS resolve in your DHCP server if you want to trust your ISP.
If enough people switch to DoH (as would be needed for DoH by default to have a measurable effect) and the data is even slightly valuable, unscrupulous ISPs could still use SNI, or even just reverse IP lookups to track your movements.
Well, you can only trust a third-party audit as much as you trust the third party auditor, which usually isn't very much. What good does it really do that company X, which I know very little about, said that Y does such and such?
The quality of my ISP and coffee shops isn't relevant. I was talking about "peace of mind" when using Cloudflare, not about the alternatives. Even if Cloudflare is the best option, that doesn't automatically mean I can relax about it.
That said...
Coffee shops or other open WiFi APs don't enter into it, since I use my own VPN server when I'm out and about.
His question is not relevant to my statement, though, so I answered it to the best of my ability without changing subjects: even if Cloudflare is the best available option, that does not mean I can have "peace of mind" about using it.
Spectrum still takes over NXDOMAIN and points it to a Yahoo search page when using their DNS, meaning you now have exposed the browser to all of the oath trackers and pushed it to AdChoices, meaning targeted ads. Not every DNS provider/ISP does this, but when you have one that does, it's probably a net positive to instead beam it to CF which makes guarantees about logging and gets audited[0].
Does this apply even when you are not using Spectrum's DNS? I.e. do they modify the DNS responses of other DNS providers?
I am not a customer of theirs, nor have I been a customer of an ISP that engages in such practice.
As a EU citizen I am much more concerned about sending my data to a US company which I am not a customer of. ("if it's free, you are the product") At least my ISP is subject to European regulation and I'm paying them to provide the service.
It does only happen with their default DNS servers, and their router interface (at least on newer routers) makes it easy to change DNS, but the users Mozilla is targeting by making it the default likely don't know how to change DNS or why they would want to do so.
I moved recently and let my ex keep my network gear and went with the default Spectrum cable modem and WiFi access point.
The new modems not have user-facing access pages to check connection status and signal levels. Additionally the bundled WiFi access point let you change everything you want except for the DNS settings your routers local DHCP pushes out.
They are actively forcing users to use their DNS unless you buy your own equipment. Its too bad because its actually a pretty decent WiFi router (1+ Gbps AC, 4 gigabit ports, no crashes with excessive usage, etc)
The CLOUD Act is extraterritorial and in direct conflict with GDPR. On a more practical level, how would the EU even know a violation occurred given the systematic practice of adding a gag order to national security letters?
It's pretty unusual for ISPs to do this. But Spectrum is big enough that it's a still a valid concern.
Especially now that more and more people are using mobile networks from people like AT&T and Verizon, and these companies are effectively scum of the earth.
The real solution is to have the OS itself deal with DNS privacy concerns, not the browser. Localhost DNS resolver with DNSSEC enabled that will bypass the default DNS settings and go out to 'trusted' DNS servers when DNSSEC fails. Maybe even use DoH if ISP blocks normal DNS traffic.
From my understanding there is no reason a OS level resolver library can't support DoH, I am surpised we haven't seen whatever Linux uses add support for it. Or maybe it did and I missed it.
Just a reminder that DNSSEC doesn't do much of anything to protect Internet privacy --- all it does is sign queries, it doesn't encrypt, and the signatures are with keys effectively escrowed to the owners of the TLDs (most frequently, world governments).
I do not think a full local resolver is necessary. E.g. stubby [0] can be set up to use a remote resolver via DNS over TLS (simpler than DoH, less of a hack, all the same crypto guarantees). That remote resolver can be CloudFlare, Quad 9/101, or self-hosted unbound instance. Then only the remote resolver has to worry about caching and DNSSEC, etc.
I suppose its good that DoH is addressing the privacy issues with DNS, but I think I agree with the point this article is making overall. If its only one vector of privacy, making it a default this early on (less than a year old?) seems a bit presumptuous. If someone is looking for your DNS traffic, but you're using DoH; they'll likely find what they're looking for using another method.
In my opinion, this kind of goes against what I would expect a browser to do as well. I don't like the idea that it just bypasses the OS settings. I understand that there are guidelines for enterprise users, and people who want to disable it; but I feel that a prompt when they globally enable the setting isn't enough. Most average users will probably just click "Yes" on the dialog that asks if they want it enabled.
The idea of DoH seems like a good one, but I would prefer if they figured out a better way to implement it. Probably a huge majority of people are just using their ISP's DNS servers, but I don't know that pointing them to Cloudflare's DoH implementation is necessarily better.
This is a significant improvement over what Mozilla is doing, but still retains a big issue: It doesn't account for network requests sent outside the browser.
I'd far rather these developers focus on getting DNS-over-HTTPS support built directly into operating systems and then properly using the OS's network stack.
This is still very experimental. I think doing the experiments in applications makes more sense than potentially breaking every network request on the system at once.
So, let's be clear about this--if Chrome detects your DNS server is on one those lists, it will automatically switch to using DoH with the same provider?
Does the agreement have teeth? Is it even enforceable in the face of NSLs?
> We also commit to documenting any government request to block access in our semi-annual transparency report, unless legally prohibited from doing so.
Mozilla is only rolling out DoH to users in the US whose ISPs would already be subject to NSLs. Presumably they will wait until non-US DoH providers are available before rolling it out elsewhere.
There is one counterpoint for those concerned about all their DNS queries going through Cloudflare: since more and more[0] websites use Cloudflare (CF) service, the traffic goes through CF regardless of DNS lookups. I'm not saying its good, just pointing out that in more and more cases CF will know about a visit to a website whether their DNS/DoH is being used or not. In such a scenario using anything else than CF would actually harm the privacy as this would spray the information over other entities/providers. (If a website is behind a CF revproxy, CF "knows" about a visit to that website, if then a non-cf DNS service is used, that DNS provider becomes a second entity to have that information).
Of course as of now majority of websites are NOT using CF, but apparently their market share is growing and this may become a larger issue in the future.
To extend your idea, if that "resolver located somewhere" would be shared by more than one user then mapping a dns query to a specific user/IP would be much harder, hence further improving the privacy
Then you're back to where they have to trust the operator. The purpose of this exercise is to reduce the number of parties that have to be trusted, not increase them.
Ideally iterative resolver - autheoritative nameserver traffic would also be encrypted, then we wouldn't have to "hide in the herd" (as much).
I get the "trust the operator problem", I was thinking about sharing this for several devices I own or possibly with family assuming that "trust the operator" would not be an issue then, while increasing privacy a bit by disabling the ability to match a DNS query to specific user/IP. If this was to be shared publicly then of course you are right and this not only solves nothing but makes it worse as it introduces another node to be "trusted"
I was accused of having a hidden agenda and then blocked by the Senior Director of Browser Engineering at Mozilla for suggesting that building DoH into Firefox and bypassing the OS network stack was a significant concern. This person expressed some bizarre lack of understanding of how DNS works, how OSes work, etc. for such a position, as they seemed to suggest that the only way Mozilla could impact DNS requests is at the browser level, and that implementing it at the OS level wouldn't protect people from ISPs snooping?
Not only will Firefox's approach cause significant breakage, but the fact that it doesn't protect non-browser traffic means users may mistakenly be protected when they are not. Mozilla may be putting lives at risk here, and what's truly irritating, is that Mozilla's said engineering director, didn't seem to realize Mozilla could've built something that integrates with the operating systems' network stack properly.
Mozilla should've invested in improving DoH support at the OS-level or built a VPN client, again, that worked at the OS level to protect all DNS requests and/or network traffic, rather than trying to shoehorn in a way to redirect your DNS queries to their partner into your existing install.
I have nothing inherently against Cloudflare, but Cloudflare should not want to be associated with this bad hack solution to DoH, and Mozilla should rethink implementing it.
Either way, I would welcome confirmation and/or elaboration on how DoH makes things worse than the status quo, not worse than a theoretical ideal that doesn't exist.
On the contrary, because it's tcp and encrypted you can tunel your queries safely over tor.
Of course, there are some things to take care of even if you do that, because privacy is not a simple binary switch you enable.
If you own some not so popular domains, you also should make sure to exclude them from the queries, so that who you are not easily deanonimized by your query patterns.
Both is easy relatively easy to do with dnscrypt-proxy.
It's not enough by itself, but DoH enables ways to get secure DNS queries to your chosen provider anonmously and securely.
This article doesn't do a good job of explaining the censorship-resistant benefits of DoH. The author conflates privacy and access as the same thing. They are entirely different.
Access to information is the first step. Privacy is a luxury after access.
From my understanding, it uses HTTPS to perform dns lookups.
This has the benefit of encrypting your dns lookups so that people reading packets can't read them.
However, your pc and the DOH provider still can read/store/analyze/sell your dns lookups.
Your isp is probably selling your dns lookup data. So do you trust cloudflare more than your isp?
The primary issue is that this bypasses the normal dns mechanisms built into your local network. No more blocking sites using DNS. Presumably, ad block in your browser will still work. But things like pi-hole will suffer.
It's right there in the article... which you read... right?
> DNS over HTTPS meanwhile encrypts DNS queries going over the network, which means that no one between you and the DoH server can see your DNS queries or modify the DNS responses.
The article includes a summary of what DoH is at the top and also has links to more information. Not sure what else could be done before the article is about DoH itself.
It's standard practice to define acronyms prior to first use, such as DNS over HTTPS (DoH), rather than assuming people have a priori knowledge or that they'll click on the right links in the content to figure it out.
If Mozilla cares about privacy and consent, it'd be nice they would have also implemented DNS-over-TLS and let people choose what to use.
Also, their idea of "use-application-dns.net" is half-baked: it breaks DNSSEC because one has to override the responses from the .net folks--which are signed. One suggest I head (by the author of the linked article) was to use something like "use.application-dns.net" instead. So you are overriding the responses of a particular domain instead of a TLD.
Further, once you have 'access' to ".applicaiton-dns.net" there are other things that can be done:
* check for use-doh for DNS-over-HTTPS desirability
* check for use-dot for DNS-over-TLS desirability
It seems to me that Mozilla didn't bother talking to any DNS experts (e.g., DNS-OARC), and now everyone is scrambling.
Most people aren't against encrypted DNS, but it just needs to be implemented properly.
It's not clear to me why any user of Mozilla would care about DNSSEC (which Mozilla doesn't support anyways). For that matter: while it's obvious why Mozilla users would want to choose which resolver they trust (Cloud Flare, or something else), it's not at all clear why they'd actively want DoT, whose only real "benefit" over DoH is that it can be actively filtered by network providers who don't want users encrypting their DNS queries.
On my network's (both home and work) I definitively want to block, any other DNS than the ones I set up.
It was easy and effective way, to block sites, ads, and make sure that internal sites resolved correctly.
Trying to play whack a mole with DOH servers blacklists, sounds like a loosing game.
Not exactly sure what solution there will be. Because in combination with ESNI, you will essentially have to block whole cloud flare, if you just want to block a single site.
And since a lot of ad networks use cloud flare ...
This gives more power to individual clients (both good ones like firefox, and chrome and bad ones like malware, trackers, other crap), but takes away power from centrally managing your own network.
I definitively see reasons on both sides, why this is good or bad.
> It's not clear to me why any user of Mozilla would care about DNSSEC (which Mozilla doesn't support anyways).
So you talk to Cloudflare via DoH: how do you know that CF isn't manipulating the results? (Perhaps by government coercion.)
> ... it's not at all clear why they'd actively want DoT, whose only real "benefit" over DoH is that it can be actively filtered by network providers who don't want users encrypting their DNS queries.
Mozilla may want to support it because it could prevent them from being banned from corporate environments that may need to monitor queries for regulatory reasons. It doesn't have to be the default, but being able to enable it via a GPO could be useful.
First, almost nobody signs their zones. DNSSEC has practically no meaningful adoption (lots of tiny zones in Europe are signed because their registrars do it automatically, but break zones down by usage and you'll see a very different story). But, more importantly, DNSSEC is a server-server protocol; it doesn't protect end-systems at all. If you're using any external resolver, the "SEC" part of DNSSEC is a single bit in the header saying "some other resolver checked signatures". You'd have to trust Cloud Flare either way.
More importantly, 91% of TLDs are signed. See http://stats.research.icann.org/dns/tld_report/ Because only the most esoteric of domains lack DNSSEC at the TLD level, this means you can prevent your domain from being hijacked for anyone who cares by simply signing your own zone. Who would care to validate DNSSEC at 25% deployment? Providers of ridiculously centralized DoT and DoH DNS proxies, like Google and Cloudflare.
> But, more importantly, DNSSEC is a server-server protocol; it doesn't protect end-systems at all.
It's trivial for systems to run their own recursive DNS service locally, while also making use of intermediate caching nameservers. systemd supports this, for example, and OpenBSD almost shipped with a local resolver service that enforced DNSSEC by default (some last minute hiccups caused them to disable it before release).
Chrome and Mozilla are shipping entire bespoke client DNS transports. Adding recursive resolution support with DNSSEC verification to their in-browser resolver is trivial by comparison. I've written a recursive DNS stub resolver, so know first hand. In fact, CNAME chaining requires client stub resolvers to already support recursive lookup logic as intermediate recursive, caching resolvers don't always include CNAME chains in their responses, especially for out-of-bailiwick chains or when chains can't be resolved from the local cache. Going from CNAME recursion to recursion on authorities is trivial. Likewise, DNSSEC verification is trivial compared to the nightmare that is TLS and X.509 certificate parsing and constraint checking.
Those numbers are based on random zones nobody cares about largely being auto-signed by registrars, which is security theater. Instead, look at popular/major sites, and count how many of them are signed. Look at sites run by actual security teams and note that virtually none of them except for Cloud Flare, which sells DNSSEC services, sign their zones.
Obviously people can stop using DNS servers altogether and run recursive resolvers (and, of course, expose all their queries to their ISP, which is precisely the problem DoH is trying to solve). And, as you know, effectively nobody does this. Obviously, browsers can add support for DNSSEC. But they've done the opposite thing: they've piloted it --- at Apple, at Mozilla, and at Google --- and then later withdrew support.
DNSSEC is a dead letter. It has no operational relevance today; the root keys could be Pastebinned and no site on the Internet would be compromised. And after 25 years of pointless effort, no meaningful adoption has occurred; rather, it has been un-adopted from the few places that tried.
> auto-signed by registrars, which is security theater
Do you consider Let's Encrypt security theater?
> And after 25 years of pointless effort, no meaningful adoption has occurred; rather, it has been un-adopted from the few places that tried.
For a long time the zone enumeration "problem" plagued DNSSEC. Everybody thought it was a fatal flaw, and it even led to a redesign that added complexity in an attempt to mitigate it. This made DNSSEC seem unnecessarily costly, a potential insecurity, and substantially hurt deployment.
Fast forward two decades and best practice is to put all your corporate resources on the public network, hosted by third parties. The refrain from those advocating for Google and Cloudflare DoH proxies is that organizations should be moving away from hidden domains. Well, if you don't have hidden internal networks and don't care about leaking your subdomains, then DNSSEC is simple and easy to deploy when self-hosting DNS, and a trivial upgrade to DNS hosting providers.
I get that you're a long-term opponent of DNSSEC. Well, I'm a weak opponent of QUIC, especially QUIC outside the kernel. That doesn't mean I don't appreciate and recognize the benefits, or actively try to oppose it. I try not to be inconsistent.
If you think Let's Encrypt is great, and you advocate for centralized DoH, then the major objections to DNSSEC cannot be sustained. That's different than affirmatively advocating for DNSSEC, but I just don't get the fierce opposition. To say that DNSSEC is, on balance, worse for the Internet (e.g. security theater) seems preposterous to me.
As you'll see, I have multiple reasons to believe DNSSEC is a powerful net negative for the Internet. The simplest one to communicate is that unlike LetsEncrypt, whose nuts-and-bolts security DNSSEC does not improve on, DNSSEC also escrows out authority to world governments. But there are other arguments that are actually more meaningful to me, such as the clunky, 1990s design of its cryptography and the near-certainty that its installed base will be RSA-dependent for the protocol's entire lifespan, be it 1 year or 20.
That piece goes into a lot more detail that I won't belabor here.
My point on this thread though is simple and factual and descriptive: an ordinary user of the Internet --- in fact, even an ordinary software developer on HN --- can expect to interact with the Internet at length without ever once coming into contact with a website on a DNSSEC-signed zone. You see DNSSEC brought up on these threads as if it was an important operational security concern for people setting up Pi-Holes and whatnot, and you know as well as I do that's simply false. You probably assume at first blush that I'm snarking when I say the DNSSEC root keys could be Pastebinned to no real ill-effect, but if you think about it for a few minutes I think you'll find that I'm not snarking at all. You want DNSSEC to work, and you're right, I don't, but neither of us can kid each other about the fact that it's not working now.
Still, as someone who works in IT, I'm happy to implement DoT/DoH internally--just don't go around overriding the settings I want my desktops to use. We're already noticing breakage in our testing due to split-horizon DNS and hairpin NAT.
Is there a stub resolver you're aware of that is in mainstream use anywhere that sets CD and does its own validation? My belief is that the answer is "no", but you might know better.
"DNS over HTTPS" - it does put this in the description of "what DoH does", it's a little hard to find. There is a pattern that is popular to use a phrase and then abbreviate it, i.e. "DNS Over HTTPS (DoH)" which is perfect for this sort of scenario. By pairing them, the users that search for "DoH" will find it next to the phrase very early in the page.
It's not a great idea to bury the full phrase somewhere on the page, and omit the abbreviation next to it.
In a hypothetical Internet of the future where almost all websites and web-apps are also served from a handful of huge cloud providers, would DoH not increase privacy since now ISPs (and potentially some govts) will have a very hard time figuring out which site or app you are visiting?
Cannot Mozilla reasonably say that currently there's only one acceptable DoH provider; it hopes to vet more soon and once there are more than one it will select the default provider through some reasonable algorithm (random, perhaps).
> And for actual privacy on untrusted networks, nothing beats a VPN, except possibly not using hostile networks.
Except that using a VPN then funnels _all_ of your traffic through a single server which is ideally placed to monitor your browsing activity. And, VPN providers tend to be quite hard to evaluate for their trustworthiness.
Is it possible for me to run my own DoH at home? I can setup a DNS server, however I can't find any details on how I can get a full DNS copy which avoids the specifics of which website I'm looking up.
No such thing exists. Even if it did, the TTL of records and creation of new ones would make it out-of-date almost immediately. The only way to get all sub domains (and many domains) is to crawl or enumerate all permutations.
I'm probably missing how other DNS servers update and propagate changes. I update my website's registration with Google, it's not clear how other copies are notified (or poll?) About my updates with Google.
I've said this before and I'll say it again. If you don't like the fact that DoH is centralized in the hands of Cloudflare, all you have to do is offer a competing service. Especially if you're a DNS company in the first place. It's your domain of expertise. Build something. Ship it. Once there are a number of alternatives, Mozilla et al. will have no reason to insist on using a single provider.
Right now, for a lot of people in a lot of countries, a choice to use any resolver that isn't controlled by their ISP/government is a step in the right direction. So please stop trying to drag down other people who are doing their best to make progress. If you don't like the direction that they're headed, build an alternative, write an RFC, or do whatever you can to show us how you think it should be done instead. Show us the code or GTFO.
The main point of the article is not that CF is evil and is now getting all your DNS data; it is that CloudFlare gets that data AND none of those that had access to it already are going to lose it after you migrate to DoH.
That is not true. Several middlemen are now going to not be able to see your data. Most people that used public resolvers were sending plain text UDP queries over their ISP. This could be redirected, hijacked, etc. If you had a connection that wanted you to use their filtering software, they could/would block outgoing port 53. That is not possible with DoH, they can no longer see what domain you are querying. They may be able to block 1.1.1.1, but as more places get DoH, it will be harder to block using other DNS providers.
That’s not really the issue. The hard problem isn’t making a bunch of DoH competitors but getting OS level support so that browsers can drop their own logic.
An app running on the system needs to be able ask the OS for an encrypted DNS lookup or where it should perform such a lookup and get be able to decide what to do when it can’t.
The UI needs to be there to accept DoT or DoH networks from DHCP on trusted network profiles but the a user-chosen default on untrusted networks.
It is well known that OS vendors move slowly. How long will it take for all major OSes to standardize on an encrypted DNS protocol? I'm pretty sure it won't happen before 2030.
Should application vendors simply do nothing until then, even when they can do something now? Should programmers always wait for the perfect solution to come along and only then ship the definitive version? What happened to building what we can now and incrementally improving over time?
There isn't even a consensus on how best to implement encrypted DNS. How do we decide which proposal to standardize on if we're so reluctant to test them in the wild? Without successes and failures to learn from, there is even less chance that OS vendors will deviate from the status quo.
Absolutely not! I'm firmly in the camp that browsers should do this until OS support arrives.
However, the "centralization problem" isn't solved by more competitors existing because widely deployed applications will still have to choose a single option for all but a tiny segment of users that will change it.
If the default comes from the OS vendor then we're in a slightly better place since the default for macOS and iOS will be Apple's servers, Windows will be MS, Android will be Amazon or Google. Competition in this space comes from the people who decide what DNS service to use, not the people standing up the service.
I dunno, I would much rather retain the ability to download a new browser that promises improved privacy (i.e. by integrating with their own DNS service that includes pi-hole) than be limited to one of four well-known American OS vendors.
Alternatively, I see no reason why someone can't write a small application that runs a resolver on localhost, adjusts your hosts file accordingly, and forwards queries to any third party or distributed network of your choice. Wait a sec, I already have dnsmasq and/or systemd-resolved doing this on some of my machines. It can be done right now with no need to wait for the OS vendor to change things.
You really wouldn't be limited, it would be no different than time.microsoft.com being the default on Windows or rhel.pool.ntp.org being the default on RHEL.
The local resolver that proxies DoH or DoT is nice (I'm using it right now too!) but it doesn't solve the problem of applications wanting to be sure they're getting an encrypted connection.
> If you don't like the fact that DoH is centralized in the hands of Cloudflare, all you have to do is offer a competing service.
You seem to be presuming that a single "service" is necessary. "Alternative" centralized services are still a centralized service. The solution to Cloudflare being able to log everything isn't to hand that same power to someone else.
I run my own recursive resolver. Only the first request for a domain's NS record goes to a centralized service; every other request goes to the domain specific nameserver. Asking ns.example.com for the A/AAAA record for www.example.com doesn't tell example.com (collectively) much more than they will learn from the HTTPS request that usually follows.
Yes, ".com" can log that I asked for the authoritative nameserver for "example.com", but this is usually cached. The centralized nameservice doesn't see most of the DNS traffic.
Yes, the communication with each domain's authoritative nameserver is often unencrypted. This is unfortunate, and I strongly support an encrypted replacement protocol for all communication with nameservers.
Using DoH sends all of the above to one entity... which then likely sends it unencrypted to the authoritative nameservers. The ISP learns about the result regardless right after the domain name has been resolved to an A/AAAA record, when the browser sends the TCP+SYN packet to start HTTPS.
> for a lot of people in a lot of countries, a choice to use any resolver that isn't controlled by their ISP/government is a step in the right direction
Providing this as an option for people in those situations is great. That doesn't mean it will be a benefit for everyone. For many people, DoH is a significant loss of privacy.
> So please stop trying to drag down other people who are doing their best to make progress.
Please stop using this cheap appeal to emotion that presumes one solution will help everyone.
> Show us the code or GTFO.
We don't need to when the existing DNS situation was already a better option. Please learn about the diverse way that DNS is actually used in practice. Also, please consider the damage that is done by encouraging apps to bypass OS-control of DNS. This takes a lot of control away from the user, and will piss off a lot of people that use DNS-based adblocking.
>The ISP learns about the result regardless right after the domain name has been resolved to an A/AAAA record, when the browser sends the TCP+SYN packet to start HTTPS.
not necesarilly. With HTTPS the ISP will see the IP being connected to, not the domain. Since there can be multiple domains behind a single IP address, the ISP cannot know the exact domain. On the other hand since more and more websites use cloudflare revproxy service, quite often all the ISP will see is one of cloudflare IPs being connected to, whereas Cloudflare will know the exact domain (and URI) your browser is requesting. And Cloudflare will get that information regardless of the way you look up DNS record
> You seem to be presuming that a single "service" is necessary.
A fully distributed alternative can just as well be considered a "service" if it can be plugged into a browser or OS to replace the default resolver.
> The ISP learns about the result regardless right after the domain name has been resolved to an A/AAAA record, when the browser sends the TCP+SYN packet to start HTTPS.
Cloudflare is working hard on closing that loophole. Thanks to their evil monopoly, hundreds of hostnames resolve to the same set of IP addresses. The only clue as to which of them a person is trying to visit is in the SNI header, which requires some serious deep-packet inspection to figure out. Even that is going to be encrypted soon.
> That doesn't mean it will be a benefit for everyone.
> Please stop using this cheap appeal to emotion that presumes one solution will help everyone.
Who is this "everyone" that you keep talking about? Last time I checked, everyone and their cat was using Chrome. Chrome is planning to enable DoH in a future version only if it detects that you are already sending DNS queries to a service that supports DoH. No change of privacy there. The one browser that's planning to go full-time DoH with a partnership with Cloudflare is Firefox, an underdog with only 4% market share.
So "everyone" is NOT being forced to adopt the same solution. People who want DoH can switch to Firefox. People who don't want it have several other browsers to choose from. It's a free market. Let companies experiment, and let people vote with their feet. Use something else or build something new if you don't like what's available. That was my whole point.
There's so much negativity around the issue, one would have thought that somebody got caught red-handed colluding with the NSA or something :(
I would like to see Firefox make the choice of which DoH provider to use as easy as they make changing addressbar search engines.
Its easy to change from Google to DuckDuckGo on that preference page. A similar user accessible option to change providers (or disable DoH functionality entirely) would go a long way to soothing the community.
I'd much rather trust Cloudflare than my ISP. Doubly so when I'm out of the house or traveling abroad.
Practice > theory. Every time.