Centralised DoH is bad for privacy
blog.powerdns.com
blog.powerdns.com
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.
... 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.)
Maybe it is as simple as nobody having filed a complaint with a data protection agency yet.
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.
https://app.onetrust.com/app/#/webform/4ba08202-2ede-4934-a8...
It looks like they are exploring how to handle things in the EU and looking for partners there.
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.
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?
Multiplexing on what?
Light.
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.
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.
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.
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.
CF has a lot more privacy minded people to whistle blow on that if they were lying than your local ISP would.
People at Yahoo were monitoring e-mail on behest of the US government, and not even telling the company's CISO about it:
* https://www.reuters.com/article/us-yahoo-nsa-exclusive-idUSK...
* https://arstechnica.com/tech-policy/2016/10/report-fbi-andor...
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.
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]
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.
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.
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).
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.
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 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.
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.
What if you're in UK/CA/AU/NZ and running that particular language variant instead of the "correct" one?
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?
[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.)
http://www.legislation.gov.uk/ukpga/2017/30/contents/enacted
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.
* https://en.wikipedia.org/wiki/Platform_for_Internet_Content_... * https://en.wikipedia.org/wiki/Protocol_for_Web_Description_R...
Self-labeling could then perhaps help third-party software filter things.
> ... in your country.
In my country, they are legally required to be reprehensible in those ways...
Yay Australia... :-/
(Where I'm pretty sure my VPN use puts me own a list. Another list...)
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.
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.
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.
Nobody is going to manually reconfigure their resolver every time they change their network.
You can find it at https://odvr.nic.cz/doh.
Practically, no trust.
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.
Yes, for you Americans.
Please, go fix your politicians, rather than inflicting technical "solutions" to political problems on the rest of the world.
Not quite (as I understand things): it is for people with an "en_US" local.
If someone in the UK (or NZ, AU, CA) downloaded that particular language installer, then non-US residences can be hit by this.
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.
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.
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.
Last year, it was only experiment. Next year, it might be rolled out for everyone.
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.
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.
As for you claims about "astroturfing campaigns", — how do we know, that you aren't a part of one?
Using DoH increases your privacy attack surface, not reduces it.
DoH is strictly worse.
That's true, that will leak either way.
> DoH is strictly worse.
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.
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.
This is false if you have ESNI enabled. They see what IP addresses, not what web sites you are visiting. ESNI isn't on by default yet, but it will be.
Besides, it is not going to make it (South Korea already blocks it and others will follow).
And I'd prefer a solution that does not rely on trusting any single entity, irrelevant of how "trustworthy" that entity is.
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.
[1] https://www.theregister.co.uk/2019/09/24/mozilla_backtracks_...
You can have peace of mind about it, but I can't.
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.
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.
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.
It's not that I necessarily trust my ISP, I don't want to be forced to also trust Cloudflare (both for privacy and availability).
So no, I don't use 1.1.1.1, I run my own recursive name server.
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.
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.
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)
As is CF in the EU, no?
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.
https://github.com/systemd/systemd/blob/master/meson_options...
At least one major ISP owned by a German company does it. It's not that weird.
[0] https://github.com/getdnsapi/stubby/blob/develop/README.md
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.
https://github.com/chromium/chromium/blob/711b1ba2735f8af4bd...
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.
To add, this won't upgrade the encryption if the router is acting as a DNS proxy, as Google Wifi does.
https://www.reddit.com/r/vivaldibrowser/comments/a23071/how_...
https://techdows.com/2018/12/vivaldi-2-2-lets-you-disable-go...
> We also commit to documenting any government request to block access in our semi-annual transparency report, unless legally prohibited from doing so.
I guess it is not.
Till this changes, Mozilla DoH rollout will be US-only.
[0] Already 10% in 2018 according to this: https://www.wired.com/story/cloudflare-spectrum-iot-protecti...
I'd previously used Cloudflare's DNS because I trusted it more than my ISP.
Is disabling DoH going to enhance my privacy?
What action items can I take away from this article?
I see a lot of writing about how DoH is back, but rarely do I see the writers lay out a specific solution.
Depending on your threat model you could also run the iterative resolver locally.
Ideally iterative resolver - autheoritative nameserver traffic would also be encrypted, then we wouldn't have to "hide in the herd" (as much).
Or will the resolver somehow see the original IP?
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.
Also, I would argue that the most effective way for an organization that maintains a popular browser to impact DNS requests is at the browser level.
The article touches on this.
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.
Anyways most users use Mac and Windows not Linux. How can Mozilla fund the development of DoH on the network level?
Also on Linux, dnsmasq can be configured to use DNS over HTTPS.
At the end of the day. This is DNS is just looking up IP addresses in an address book.
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.
https://codeberg.org/crimeflare/cloudflare-tor/src/branch/ma...
> In total, between 22 September 2016 and 18 February 2017 we now estimate based on our logs the bug was triggered 1,242,071 times.
https://blog.cloudflare.com/quantifying-the-impact-of-cloudb...
Access to information is the first step. Privacy is a luxury after access.
- Your ISP analyzing your IP addresses
- Your ISP analyzing the names in your TLS certificates
- The website you're visiting selling your information. (ie, this identify belongs to this IP and browser cookie. See where else you find him)
- The advertising iframes doing the same as the website above. Tracking you everywhere, primarily by using cookies, canvas, etc.
I can see this is comes from a DNS-focused blog, but a little background info on the subject would really improve the quality of the article.
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.
Though one wonders if ISPs and countries can use the same strategy to mitigate any benefit of Firefox's strategy here.
DoH - DNS over HTTP(S)
DoT - DNS over TLS. Often meaning DTLS
ADD - Applications doing DNS, where the application is sending DNS queries instead of asking the OS resolver. Usually implied to be HTTPS as well.
> 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.
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.
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.
RFC 4033 defines a validating stub resolver. Some mention of putting it in glibc:
* https://lwn.net/Articles/664776/
I'm sure the systemD folks will get around to it.
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.
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.
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.
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.
I really don't know how I can respond to this comment any better than I already did, years ago:
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
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.
You haven't responded to his question. Do you consider Let's Encrypt security theater?
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.
Sorry for tangential rant :)
It's pretty clear they don't care about consent, since there is no opt-in to this.
It's also questionable as to whether they care about privacy, by funneling ALL of their users' DNS through one for-profit company.
"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.
And for more privacy, we will soon need DNS relays https://github.com/DNSCrypt/dnscrypt-protocol/blob/master/AN...
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.
make an EC2 instance.
Configure it as a VPN.
It's simple to do.
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.
https://stackoverflow.com/questions/42636711/google-chrome-i...
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.
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.
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.
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.
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.
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.
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.
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
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 :(
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.