While I don't particularly trust Google all that much anymore, the fact that ISPs even have an opinion on this is a smoking gun that they're doing sketchy things with DNS data. There is no actual technical reason why they should care if you use their DNS servers or something else, even a private, encrypted DNS service.
They definitely are. I know for a fact that they are running massive Hadoop clusters storing information on DNS records involved in their customer traffic. If I recall correctly they mirror a lot of the traffic to analytics environments.
Netflow data, DNS capture, enrichment of cell tower access data (location), reporting on non-usage (idle time, tracking), Bill and household information, credit account usage, etc. SPs are huge sellers in this market.
We still need to encrypt the accessed resource and DNS queries everywhere.
Even once that’s done, things like opencaching will be used by SPs to gather tons of data where they participate.
I'm guessing we're just trusting Google here (and Cloudflare 1.1.1.1 who now also does 10gb free VPNs) + the good will of engineers with access to this information within Google.
If you are not using gmail or google search, and are using adblockers, Google shouldn’t really have any information on your IP, so it is anonymised data. Your ISP knows even your bank details.
But the limits of using google DNS (or even encrypted DNS) is that most commercial websites aren’t sharing IP addresses, so I bet the ISP can pretty much reconstruct the data it would get from DNS with very little effort just by looking at your IP traffic and mapping IP addresses to domains from other users DNS queries.
i suspect they somehow throttle this traffic -- i used to use 1.1.1.1 for a while and had to repeatedly switch out b/c my dns resolution times would be terrible after a while
I wonder why someone who knows how to do any of that, would think it is a good idea or go along with implementing that. The shitbirds who actually want to do this type of thing are not smart enough to execute it.
Engineers are people who come in all ethical flavors. I used to know one whom I consider evil, in the actively, knowingly malicious sense. I've known a whole lot more who generally just don't think about these questions.
Thinking knowledge, intelligence or capability correlates with ethics is a category error.
It's more an industry error, I suspect. The University I went to forced all the Software Engineers to do some of the traditional Engineering papers, including courses on ethics. The professional institute that accredits the University's ability to call their course an Engineering course required those courses.
Courses like that don't fix unethical people, but they make the rest of us aware that ethical concerns exist. Software/Computer Science is such a young discipline that, industry-wide, I don't think we've learnt that one from the other industries yet.
I question the amount that such ethics courses actually help. Business majors have had ethics courses for as long as I can imagine, and yet you don't have to go far on HN (even in this very thread) before you see people saying business majors are unethical.
The bigger problem, IMO, is that many tech companies have started handing out kool-aid that data collection and analytics is ethical. They justify it by saying that it helps people avoid spam, or get better advertisements, or whatever, and then the engineers think they are being ethical and beneficial to society by building these systems.
Saying that business majors are full of unethical people is like saying that politics is full of unethical people, it is the job that attract those characteristics.
The objective of those ethical classes is to move the neutral/good majority in hope in hope to counterbalance the unethical minority.
> Business majors have had ethics courses for as long as I can imagine
I took a business ethics course in undergrad, and it was surprising how many students advocated all sorts of (to me) aberrant ethical views. (Note I’m pretty traditional, morally speaking. The environment was strongly postmodern, and this was before all the modern insanity about “free speech is bad because some people say bad/offensive things”.)
Not that I minded personally, but it was a strong lesson to me that teaching people categories and how to think won’t give them a desire to respect any particular brand of morality.
He is speaking of the developers and engineers who have the technical expertise and should know it's a bad idea but still agree to implement it regardless of their moral compass.
I've worked on questionable projects at a big telecom. I refuse to run ISP provided modems/routers at home, i refuse to use my isps dns and use dns-tls etc etc based on what i have seen.
The devs have often said things bad idea and raise concerns unfortunately you generally have no power, the decision to implement something is made above you. Generally the people making the decisions know things are questionable but you need to make your KPIs / get promoted / earn more money for the company etc etc.
If you don't follow a direct order and refuse to work on a piece of work in reality you will be fired.
That leaves you with the option of looking for a new job yourself or being forced to find a new job as you was kicked out.
While some people can take the moral highground, outright refuse and resign, others have to deal with life issues such as paying the bills and supporting a family which makes it extremely hard to pick a fight refusing to do something. We do not like to think it but we are just another cog in the wheel and dispensable.
Nice point. I've been considering changing my router for a while out of privacy concerns. Do you have a suggestion? I was wondering whether i could use my raspberry pi 3b+ for it.
Why the implication that devs/engineers who have such technical expertise "know it's a bad idea"? There are plenty of devs and engineers who would have no moral issue with mass data collection and analytics. You don't magically become a paragon of morality just because you got a CS degree. Just ask Zuckerberg.
I’m working at a company and they want to do a massive amount of logging from our companies IOS app. Basically log everything in the name of security. I made the statement today what does legal think about the data we would be now storing? It has user locations, gps coordinates, all the other fun stuff you can get from a users phone. They all looked at me like I was crazy for even asking that question. And I don’t think a single person in the room the devs included had even though about the personal data we were going to be able to collect. And if we SHOULD be collecting it.
To be even more fair, I feel pretty sure Zuckerberg would be happy to agree that "you don't magically become a paragon of morality just because you got a CS degree".
I’m not sure why anyone cares about Zuckerberg’s opinions on morality. The point that a CS degree does not impart a higher moral code is not controversial. My comment only pointed out that Zuckerberg was a bad example because he doesn’t have a CS degree.
Google and FB are doing the same thing with their data (and worse) and the engineers they employ don’t seem to care that much, even though they are pretty smart.
Seriously browse through the who's hiring thread... some engineers may see it as an easy way to get their foot in the door in the data analytics industry. Hopefully they just focus on bettering their portfolio.
> I wonder why someone who knows how to do any of that, would think it is a good idea or go along with implementing that
Modern silicon valley is built off people implementing similar pervasive tracking, without it there is no google, facebook and many other startups. Not to mention online newspapers and everyone who makes money indirectly from the tracking.
I agree it's a bad thing, but that ship sailed long ago and things like the GDPR are only just starting to bring it back.
Personally I have absolutely zero qualms with implementing any system to collect mass analytics. I just don’t give a shit, at these scales users are cattle.
given the volume of data, i don't care as much on an individual level since each person is a drop in an ocean, but knowledge is power, and this is too much knowledge for ISPs, advertisers, and government agencies.
I assume that all US TLAs have (or could have) access to all data that my ISP logs (or could log). That's just how it is. Given government ~monopoly on force.
And that's why I use VPN services. But the same is true for VPN services, regarding US and/or other TLAs. So I use nested VPN chains, to make it harder to get complete data.
And when it really matters, I add Tor to the mix. Even if it's heavily infiltrated by US TLAs, there's at least the chance that it's also heavily infiltrated by TLAs of US adversaries. So, Dog willing, maybe they cancel each other out, at least somewhat.
Perhaps because downloading Tor (or even searching for it / visiting its website) demonstrates an active interest in thwarting surveillance.
Almost by definition, that means you're worth taking a closer look at.
Once you're under the microscope, you'd better hope your opsec is flawless or that your activities are completely boring, or else the $TLA knows exactly what you've been up to, TOR or not.
Disclosure: my activities are completely boring, and I don't use Tor, VPNs, or anything like them.
Except that you don't need to trust anyone, entirely.
That's the point of nested VPN chains. Let's say that you have three different VPN services in the chain. The first VPN knows your ISP-assigned IP address, and the IP address of the second VPN server. The second VPN knows the IP address of the first VPN server, and the IP address of the third VPN server. The third VPN knows the IP address of the second VPN server, and the IP address of the site that you're accessing.
An adversary would need information from all three VPNs, or from their data centers and/or ISPs.
You're still vulnerable at the operating system and hardware level. It doesn't matter what you do after booting up if you're computer has already successfully been infiltrated from the Hardware/BIOS/OS initialization that always happens before.
I mean routing traffic to Tor entry guards through VPN services. The Tor Project does indeed not recommend that. They argue that using a VPN service is risky, because it can log everything. Where access to entry guards is blocked, they recommend using bridges (of one sort or another) run by Tor volunteers.
I don't agree with that argument. Because ISPs can already do that. And for most people, their ISP is far more likely to be cooperating with their local adversaries than some random VPN service is.
And for what it's worth, one of Tor's inventors (Paul Syverson) has agreed publicly that there are reasons to access Tor through VPNs. Basically, when you don't want your ISP to know that you're using Tor. Indeed, if I were a CIA agent using Tor in Iran, I probably wouldn't want the ISP to know that I was using Tor.
But I don't trust VPN services either. So I use nested VPN chains. That's basically the same approach that Tor itself uses, routing traffic through multiple (three) relays. So no one relay (or for me, VPN service) knows both who I am, and what I'm doing online.
There's also the issue of trusting the Tor network. Some argue that it's compromised by US TLAs. So with a nested VPN chain between me and entry guards, I'm less concerned that some TLA is running them. But even if that's just paranoia, there have been bugs that deanonymized users.
For example, some years ago, CMU researchers exploited the "relay-early" bug to allow malicious entry guards and exit relays to exchange information, and so learn that they were routing the same circuit. That allowed said CMU researchers to deanonymize Tor users. The FBI learned of this, and subpoenaed the data. And lots of people went to jail over it. Mostly drug dealers and child pornographers, but whatever.
However, routing VPN services through Tor is a totally different matter. If you do that, your anonymity depends entirely on how anonymously you've obtained, paid for, and used the VPN service. If you used an email address that's linked to you, you're screwed. If there's a money trail in paying for the VPN service, you're screwed. If you ever use the VPN account without Tor, you're screwed.
And even if you manage all that anonymously, the very fact of using a VPN through Tor decreases your anonymity. That's because Tor by default switches circuits at ten minute intervals. But when a VPN is connected through a Tor circuit, that circuit is pinned. So by using a VPN through Tor, you've blocked one way it increases anonymity.
It seems you take your privacy very seriously. But isn't it futile? I mean, the common layman response to privacy issues is something on the lines of "I'm not a criminal terrorist so what do I care". They have a point, the individual doesn't really bear direct consequences of losing privacy (unless he is a terrorist, criminal etc). The privacy issue is a social one, only when masses of individuals are spied upon, then nasty stuff may happen. So while your efforts are serious I'm wondering what is their point. I don't see any solution for this surveillance society we ended up with other than regulations through our government representatives.
I don't think of myself as a criminal or terrorist. But then my moral code is fundamentally from Aleister Crowley. So I'm well aware of the possibility that others might consider me a criminal or terrorist.
Even if there were laws and regulations that better protected privacy, you couldn't count on that. You can't trust government agencies, because they stretch the limits, and outright lie about what they do.
In my experience, Tor through VPN services isn't substantially slower than Tor alone. I only know that from experiments using VPS, however, because I've never used Tor (or I2P or Freenet, for that matter) directly.
VPNs through Tor also aren't substantially slower than Tor alone. And indeed, one can use MPTCP to aggregate multiple VPN-via-Tor connections. But only between suitably configured devices, of course.
regardless of "substantially slower" it is indeed slower, I guess it depends on your VPN link, but at the very least your MTU has to be considerably smaller meaning more round trips for "large" objects (anything over 1KiB essentially)
I worked for a Comcast subsidiary in 2010-2011 timeframe. The company owned the network end to end. They had about 250k subscribers at the time across 4 states and at the time was the first DOCIS 3.0 network in the US. They were collecting DNS log data back then. I've been told that hasn't stopped and has progressed. Don't trust your ISP to not be passively monitoring. This particular ISP had closets full of old Sandvines [0] hardware as well that I ran across one day. I asked what the hardware had been used for and the answer was simply: "network monitoring for law enforcement". At the time all of that old gear had been decomm'd. But as I've said in older posts the DC had a hands off, tamper taped mobile rack that was plugged into core routing installed by a 3 letter agency while I was employed. This was pre-Snowden and post 9/11, likely courtesy of all those fun programs we found out about that Clapper denied.
We'll know how much this will affect those TLAs when the government suddenly gets involved for some altruistic reason to block DNS over HTTPS. "Don't let google take over the internet!" "Time to break up big tech!"
Not attacking Google - their approach here is fine.
But Mozilla switching people is a worry for me. Sure people “have a choice” but in reality expecting the average Joe who doesn’t even know what DNS is to make an informed decision about it is unrealistic.
Meanwhile Mozilla has started sending a list of every domain you visit to a US company subject to US law enforcement. Not ideal.
I’m friends with solutions engineers at Hortonworks and Cloudera. It’s possible I’m wrong, and since this is anecdotal evidence I see “fact” isn’t a valid use here.
I recall wanting to do research in university and needing this data. It would tell me how frequent bit flips are in dns traffic.
And in anonymous, aggregated form (e.g. only include domains that were accessed by multiple customers, the frequency per day and domain name, maybe geographical data precise to a region corresponding to a million people), I would be perfectly fine with this, even if it gets sent to ad companies. I'd not like it, but I'd also not see the harm and there is a lot of money involved, so if we can't stop it then I'll be fine with it in a basic form (aggregated). At least until we decide that trying to optimize manipulating/influencing people is brainwashing (I'm undecided whether playing psychological tricks on people while they try to get groceries or look for information online or whatever is morally okay).
It used to be illegal for ISPs to use web browsing data for advertising purposes but the Republican House, Senate and President passed a law allowing them to make it an opt-out.
I worked at a couple of major telcos at my country, and at the last one - where we had literally millions of active ISP and mobile users - we were approached by a company willing to pay for DNS resolver data. It is definitely a thing (and possible income source) even if you don’t do that kind of analytics yourself.
But I’m fascinated by the legal implications. Right now in Portugal sites are DNS-blocked for copyright reasons (IIRC without the need for what you’d call full legal oversight, just a sort of loose arbitration with the local equivalent of the RIAA), and this is going to play merry havoc with that.
(Uber’s website was also DNS blocked for a while due to hassles with licensed cabs, which was interesting because the mobile app never stopped working — can’t remember if it was an actual court order, but this should give you an idea of how technically clueless some people are over here...)
While I definitely agree with the sentiment, I would much rather browsers used my own caching DNS server that I can configure to talk to root nameservers: this would be the best of both worlds (ISPs can't track me, and I wouldn't be handing data to another party either, except, well, root servers). I am sure it's going to be possible, but compared to setting it on my DHCP server, now every client's browser would need reconfiguration.
If your DNS server is in the cloud, your ISP can still see your unencrypted queries to that server. If it is at home, your ISP can still see the unencrypted queries of that server to the root servers.
Unless you encrypt the traffic, DNS is transparent to the ISP whichever way you set it up.
And unless you are also using a VPN, the ISP can learn most of what it can learn with DNS just by looking at the IPs you send packets too. Most commercial websites that matter aren’t sharing IPs.
>Moreover, the centralized control of encrypted DNS threatens to harm consumers by interfering with a wide range of services provided by ISPs (both enterprise and public-facing) and others. Over the last several decades, DNS has been used to build other critical internet features and functionality including: (a) the provision of parental controls and IoT management for end users; (b) connecting end users to the nearest content delivery networks, thus ensuring the delivery of content in the fastest, cheapest, and most reliable manner; and (c) assisting rights holders’ and law enforcement’s efforts in enforcing judicial orders in combatting online piracy, as well as law enforcement’s efforts in enforcing judicial orders in combatting the exploitation of minors. Google’s centralization of DNS would bypass these critical features, undermining important consumer services and protections, and likely resulting in confusion because consumers will not understand why these features are no longer working. This centralization also raises serious cybersecurity risks and creates a single point of failure for global Internet services that is fundamentally at odds with the decentralized architecture of the internet. By limiting the ability to spot network threat indicators, it would also undermine federal government and private sector efforts to use DNS information to mitigate cybersecurity risks.
We agree that ISPs should not need to view your browsing data without your consent. But there are many technical reasons for an ISP to want to run DNS outside the resolver privacy conversation:
For one some ISPs run content filtering services. Some users prefer to concede extreme privacy for what they view as a safer browsing experience. It might not be your jam, but it exists.
DNS is designed to be provider independent. It literally does not matter if a Google or Cloudflare or OpenDNS or DNSFilter or your ISP resolves requests. It was designed this way so that the system could be distributed and so that there is not a single point of failure for the internet’s arguably most important system.
Its distributed nature means there are technical performance advantages to doing the above: reduced request latency, localized traffic routing and reduced bandwidth, etc. You don’t need a giant any cast network to serve DNS. You just need to use the servers closest to you.
I don't think any of these things justify the ISP's response.
Regarding content filtering services, in that case the user is specifically opting in to that service, so they won't need or care to use an alternate resolver.
I agree that, ideally, you would use a resolver that's close to you in order to minimize latency and increase reliability, but:
1) This requires you to trust your ISP. Many people don't, and with good reason.
2) ISP DNS isn't exactly always the most reliable or fast thing anyway. I easily get better latency from Cloudflare or Quad9 (their old-school Do53 stuff, not the new-fangled DoH) than from Comcast's resolver.
And regardless, if your DoH provider of choice goes down, you can always fall back to a different one, or to your ISP's resolver.
This is a pretty silly debate. All you have to do is look at AT&T's DNS, see it hijack NXDOMAIN to send you to ad sites, and know that mainstream ISP DNS isn't trustworthy. We don't need to weigh up counterfactuals.
I think the missing piece here is the constant focus on the US.
In Europe ISPs are under much stricter rules about data privacy and generally cannot do things like the above. Having worked for several ISPs here I’ve never found them misusing DNS data (although sometimes it was logged for a time for management / troubleshooting.)
For a European; with reasonable trust in my ISP, I don’t want Mozilla sending all my queries to a US company which can be forced to reveal that to the US govt, or use it for some other nefarious purpose.
FWIW I’ve never used my ISP DNS though have always run my own recursor at home.
There is no reason for ISP customers to use ISP DNS, given the available alternatives, and this will become even clearer as more people boot up DoH resolvers as alternatives to Cloud Flare.
Again this is absolutely false. Your ISP, and nobody else, can deliver the lowest latency and quickest path DNS resolution short of other providers paying ISPs for last mile fog boxes (as some DNS providers do). Why can’t my ISP support DoT?
But that also highlights a huge misconception about DoT/DoH: it only provides privacy to the resolver. It does not make your requests private in the eyes of the server or spanning the recursive queries that may be required during resolution. I’m not particularly compelled to trust Cloudflare more than OpenDNS or whatever. It’s the same situation with VPN.
Anyway it’s well known that the actual solution for people concerned with utmost privacy is a round robin resolver selection strategy. It’s super easy to implement... why aren’t browsers providing this type of option?
My ISP’s DNS servers take longer both in round trip and total resolution time compared to both 1.1.1.1 and 8.8.8.8... and I have both Comcast and AT&T in an urban area. While this might have been true in the past, that is definitely no longer the case in a lot of areas.
They can, and I would be fine using it if it were a) fast, b) reliable, and c) (here's the big one) legally required that they not log or do anything with my queries.
As it stands, Comcast's provided resolver is somehow slower than some of the third-party providers for me, and I don't care to give them the ability to sell my DNS data.
> Its distributed nature means there are technical performance advantages to doing the above: reduced request latency, localized traffic routing and reduced bandwidth, etc. You don’t need a giant any cast network to serve DNS. You just need to use the servers closest to you.
My issue with this is that I've never been with an ISP that had a faster response time than Cloudflare/Google - and one would think they should, after all, my ISP should be able to reach me as quickly (or quicker) than any other corporation.
My current ISP has the fastest DNS benchmarks I've seen, and they're at 81ms for an uncached response, vs Cloudflare's 63ms and Google's 69ms. Cached response is similar (since I have a local cache).
In addition, my ISP does not provide DoH/DNSCrypt/DNSSec. None. Just 'vanilla' DNS. Furthermore, they also don't provide an unaltered DNS service: they block some websites from resolving, the list isn't made available, and is decided via extrajudicial means. You cannot opt-out, and all ISPs in the country adhere to this. They're not forced by law to do so. I'm also not in a normally thought of as a repressive country: it's a member state of the European Union, after all.
There are very good reasons for people to be outright hostile to ISPs and their shady underhanded practices, as you're seeing in this discussion. I feel that it is in any mostly online-based organisation's best interests to expose those practices.
I'm taking issue at the hyperbolic nature of the comment. I'm not an ISP apologist. But to say there are zero technical reasons for an ISP to want to provide DNS is unfair and incorrect.
Cloudflare and Google pay ISPs for the latency they get, FWIW. If I made my own resolver service today I would not be able to compete with your ISP without forking over $$$.
I don't really understand why you keep repeating this claim that we're arguing that there are zero technical reasons for an ISP to want to provide DNS. No one is saying that.
Perhaps you misunderstood my original topelevel comment. If that's the case, let me try to clarify: ISPs have zero technical reasons to complain that people are using alternative resolvers. I totally see why they want to provide DNS resolvers, and that makes perfect sense. Unfortunately, part of that "want" is so they can sell DNS query data to third parties, which is just another reason why I don't want to use them.
> Cloudflare and Google pay ISPs for the latency they get, FWIW. If I made my own resolver service today I would not be able to compete with your ISP without forking over $$$.
I think the main reason for this is even if your competitor grew like a weed, it would be a decade or two before you had the scale to justify rolling out a CDN/caching infrastructure like that of cloudflare. That's not a matter of simply paying ISPs money.
> In addition, my ISP does not provide DoH/DNSCrypt/DNSSec. None. Just 'vanilla' DNS. Furthermore, they also don't provide an unaltered DNS service: they block some websites from resolving, the list isn't made available, and is decided via extrajudicial means. You cannot opt-out, and all ISPs in the country adhere to this. They're not forced by law to do so. I'm also not in a normally thought of as a repressive country: it's a member state of the European Union, after all.
Many of us do consider EU nations repressive states, especially as regards protections for unpopular speech (and armed self-defense, but that's less relevant here).
But DoH is provider independent. It's just like I can swap out AT&T's regular DNS service for Cloudflare's in my home setup. Which I did.
Mozilla's move to reconfigure Firefox to use DoH is a bit sneakier, but it fits with their privacy stance and their low market share does give them cover.
That is understandable. But when the majority of US ISPs are monopolitical or oligopolitical organizations with zero oversight (Ajit Patel), it becomes harder to argue that sell.
I'd separate "valid" and "reasonable". UK ISPs have a "valid" reason to DPI DNS and block pornhub, but i wouldn't say its reasonable for them to mess with internet packets not destined for their network. Thankfully DoH pressures them to suck it up and accept that blocking needs to be done by parents via parental controls.
Actually everyone should prefer the other guy do it rather than host it themselves. Either way the bits have to be transported to the same colocated facilities it's a matter of who has to pay for and operate the servers.
At least Cloudflare has KPMG audit them on their privacy claims. Better than nothing.
At the end of the day, any grouping of individuals are a (partially biased) sample of the society in general. The role of media and education is fairly decisive in forming social norms. We may have one or two lost generations of engineers following orders, but as Joe said 'The future is unwritten".
That's a good question, they said it would happen annually so they should have had one by April 1st 2019. I put a question into support, we'll see if it goes anywhere.
The only question that remained was when to launch the new service? This is the first consumer product Cloudflare has ever launched, so we wanted to reach a wider audience. At the same time, we're geeks at heart. 1.1.1.1 has 4 1s. So it seemed clear that 4/1 (April 1st) was the date we needed to launch it.”
> Actually everyone should prefer the other guy do it rather than host it themselves.
This isn't true. If you're hosting it, you can control it and you can make sure that it's always operational. The last thing you want is a 100 phone call of "my internet isn't working" and then trying to explain it's not your fault, but rather it's "some other guy".
Not sure I understand. If you're using your ISP's DNS service, majority of your requests are going to hit their cache. You shouldn't notice any downtime as long as the cache doesn't expire.
I mean if all of Google/Cloudflares anycast resolvers go tits up I'm going to get endless calls regardless if the end user can resolve a cached name or not.
Or you can directly ask a domain's authoritative nameserver directly. Using an intermediate caching resolver isn't required. Recursively resolving the DNS query locally only requires asking a centralized nameserver for a domain's authoritative nameservers (the NS records) which can usually be cashed locally for a long time. Every other request is compartmentalized to different servers by domain delegation.
Or do both; configure your local resolver to try recursively resolving a request, and fall back to the ISP (other) cache if needed.
Could the collected DNS info be used for their own proprietary investment? I was reading a book about Koch industries and it made me think about the potential that most of the infrastructure companies could have outsized profit out of the derivative investment based on the information gathered from the business they are better known at.
They do use that information, it's not necessarilly sketchy. They run analytics just like everyone else. In fact, one could argue Google's huge push for https was primarily motivated to deprive service providers of valuable data that Google has anyway.
>They do use that information, it's not necessarilly sketchy. They run analytics just like everyone else.
First of all, I think the extent of the data collection that many companies engage in is sketchy.
That aside, if a website runs analytics that you don't like, you can stop using it. There are usually alternatives, if you're willing to give up some convenience. But if your local ISPs are monitoring you, not using the internet isn't really an option these days.
I really wish we didn't have to treat our ISPs as adversaries in that regard, but we've been at that point for a while.
Exactly; it's just the same old story with Google. We all know ISPs and Telcos are greedy af, but when Google is getting into providing DNS, they do it to close a loophole (from their point of view) where web visit sensor data is going to someone else; they really think they own the Internet. In this particular case, even if Google succeeds in establishing DoH via Chrome (and, sadly, also Firefox), ISPs will still get to see your IP data; they could try reverse-DNS lookup to get back domains, but this is much less targetted ever since HTTP/1.1 shared hosting. At the same time, Google is also engaged in AMP such that requests for many sites go to a single IP, with the actual requested site SSL-encrypted. What will happen next is that Google will, via piecemeal extension of HTTP/3, fuckup TCP/IP even more.
I hope somebody in regulation will finally stop Google and others to monopolize the web.
Could be caching too. Bunch of services like youtube and netflix, at least used, use DNS to direct users to local servers. This enabled a better experience for the users and lowered the amount of bandwidth
They also used this method to block region restricted content. Here in Aus Foxtel has a monopoly on all the good shows, they charge >$100 per month if you want access to everything on their crappy, ageing cable tv network. After Netflix blocked the vpn workaround, alot of people went back to torrenting
Google's design doesn't ask you to trust Google more than you already do if you use Chrome. It doesn't default you to Google's DNS servers, will honor your current nameservers, and will upgrade you to DoH at any of those servers who support it. I'm honestly not sure what more you could ask for from Google on this particular issue.
Yes, Google used the right approach here. They honor your DNS settings, and upgrade it if it's available. Firefox, on the other hand, plans to force all of their users to trust Cloudflare by default.. and most users won't even know they made that change.
Yes, as Google plan you implement it, which is fine.
Most of the hulaboo is about Mozilla who are moving customers DNS queries to Cloudflare en mass, regardless of what DNS server they have already configured.
Google has promoted its own DNS service over others in the past, including for non-chrome users, and presumably would do the same when DoH (in whatever form) is the norm.
I was simply saying we already know that ISPs misbehave, but presuming that Google wouldn’t is not necessarily a clear cut decision.
I still have something like 15 Spectrum Bogus NXDomains blacklisted on OpenWRT. When I set it up the page they were redirecting too was still the Charter page with a half done Find/Replace of Charter/Spectrum.
I have this adversarial opinion that I think is very unusual. Would love to hear your perspective.
Google pissed in the punch bowl by offering google fiber.
This forced the carriers to perceive google as an existential threat they are absolutely dependent upon for cheap ass android and ISP revenue from YouTube.
The only move they could make was to make google bleed. So they start offering content monetization and competing advertising platforms. Their goal isn’t to win, it’s to HURT GOOGLE. Advertising prices go down when there is meaningful competition. So shitty content monetizatuon from Comcast and VZ & ATT forces the price of google advertising down.
There is a big part of me that is pulling for the carriers on this front. I’m bummed more people don’t see it this way.
If the carriers were good actors that in general act in good faith most of the time, maybe (assuming your hunch is correct) I'd feel bad for them. But they don't, so I don't.
It isn't even all that sketchy, its just providing broad snapshots of what sites are getting traffic and which ones aren't, which is used by advertisers when they bid on their ad placements.
So yeah, its going to chop off some of their revenue and they don't like it.
I'm fine with encrypted DNS as long as it's from my router to the (encrypted) DNS provider of MY choice.
Interference from browsers with network level operations is my real worry. As far as I'm concerned, as long as the browser speaks HTTPS to my router, and my router speaks HTTPS to the servers, no problem. I'm worried about the "to protect the users we've hijacked their DNS directly via the browser" possibility though.
I know it used to be that using ISP DNS servers gave you access to some of their local caching and such. I don't hear that talked about much in these discussions. Is that no longer a thing, and thus we truly don't need ISP DNS?
If you're on a mainstream US ISP, interference from your browser with your ISP's "network level operations" is a privacy necessity. They're passively monitoring DNS to collect data on their customers and hijacking it to send users to advertising sites. ISP DNS is manifestly untrustworthy.
Well no, because my router is proxying DNS requests, and it's not to my ISP's DNS servers. (It's also serving a number of custom DNS records for internal/work stuff.)
I don't understand how trading one ISP for another (Cloudflare?) is an improvement long-run. The system itself needs to be resilient, not just depend on the kindness of the upstream gods.
> I don't understand how trading one ISP for another (Cloudflare?) is an improvement long-run. The system itself needs to be resilient, not just depend on the kindness of the upstream gods.
Mozilla and Cloudflare negotiated a special privacy policy for Firefox DoH requests [1] that limits what Cloudflare can do with the data – in particular, most information must be deleted after 24 hours. There is no technical measure holding them to that policy, but it’s a contract enforceable through the courts. Nothing similar applies to your average American consumer ISP.
DNS requests are transmitted in plaintext through the ISPs connections. Because DNS is not remotely secure there isn’t any reason they couldn’t simply redirect your selected DNS to their own, or replace “not found” responses with a link to their own advertisements.
So without DoH an ISP knows everything you request, even if you have a different DNS server set, and if they really wanted to they can simply hijack any connection you make.
It's a good point, but it is preventable by the network admin. For example, I bypass that by tunneling everything out over a VPN, and the local resolver attempts to use HTTPS to connect to upstream anyway. Obviously not every user is in a position to protect themselves in such a way, so I get why the browser is attempting to protect them.
Just seems very wrong to me to take the control away from the user/network-admin in any way. I mean, if you're gonna do it, go whole-hog. Delete HTTP from the browser entirely, right? I don't think that would go over well either, although it could certainly be justified by the same logic.
Maybe I'm misunderstanding something about the issue, there has been a fair bit of FUD, but I simply don't feel good about the browser taking authority outside it's "please render this code into a webpage" scope.
> take the control away from the user/network-admin
You are confusing the network admin and the user. Most users have little reason to trust their router, they often don't own it, update it or have any clue about it. Even experts change roles here when they use any other entities network.
I understand your use case, but I personally think the end devices should increasingly allow interception by network devices only with user consent, not implicitly.
In other words, opt-in on the device with DNS settings and certificates. If you don't own the device (e.g. have root/admin/etc), you don't get to control it - beyond blocking it.
If you're going to the trouble of VPN'ing your DNS, you're fine in the Chrome scenario and could I suppose reasonably just disable DoH everywhere. Your ISP absolutely does not want you to do this, but they don't want you DoH'ing either. DoH is, after all, just a VPN for DNS.
It’s not being deleted, but Chrome at least has been gradually phasing in a warning in the address bar whenever you visit an HTTP site. [1] (Firefox will apparently do the same starting soon.) I wouldn’t be surprised if the warning UIs get more aggressive a few years down the line, as HTTPS adoption continues to increase.
Even with DOH, as things stand right now the ISP can see with SNI what sites your visiting, or certificate name for sites still using TLS 1.2 or lower.
So moving the DNS to Cloudflare only means “now Cloudflare have my entire browsing history as well as my ISP.”
I do appreciate there is a draft on ESNI but it’s not there yet.
I encountered this in a local ISP in India in 2012: they were intercepting all DNS requests and forcibly using OpenDNS’s annoying NXDOMAIN advertising thing. When I returned in 2016 they’d stopped doing that. No idea if the technique is widespread.
This is easily solvable if you're using dnsmasq -- which isn't altogether unlikely as it's in basically every free router firmware (OpenWRT, DD-WRT, etc) as well as, until recently (replaced by systemd-resolved, but still an easy option to go back) used by default by NetworkManager on Linux desktops.
Basically, you just give it the bad IP addresses and it will replace every query result containing them with an NXDOMAIN.
So, assuming my local LAN DNS resolver, which serves my own custom DNS information to LAN clients, doesn't support DoH itself, but uses DoH to reach out to the authoritative servers, chrome will bypass this my local resolver?
Sounds like interfering with the way my intranet operates to me.
Why can't your local LAN DNS resolver support DoH itself if it can act as a DoH client to authoritative servers? That way the browser would know it can trust it to begin with.
Chrome doesn’t know that your local intranet is trusted or that the local resolver is trustworthy. You need to tell Chrome this by flipping a switch to either change your DoH provider or disable it all together.
This change is explicitly protecting users from malicious network operators. Since you control the endpoints it should be no big deal, you apply GPO, run Puppet, whatever and everybody is talking to your local DNS again but it is absolutely right to not trust local unencrypted DNS by default for every network you connect to.
In that context, I'd be perfectly happy if chrome had a "I'm on an untrusted network right now" switch, like incognito window. Not sure we should assume that the entire network between the browser and cloudflare is untrusted though.
Aren't there some "hijacks" that are actually valuable to users? For example, if I run a network inside an extremely limited internet environment, I can hijack the user's DNS and redirect them to a "Hey, we're sorry, but running Netflix here will ruin the network for everyone, we hope you understand" page. If their browser is ignoring my local DNS server my option would seem to be simply black-hole netflix packets in the firewall, which is a lot less friendly to the user. Would I be a malicious network operator in this case?
Yes. You would be malicious. Doesn't matter what your intentions are if someone with bad intensions could do something bad in that scenario.
For example redirecting the user to a fake webpage asking for their username and password.
A user will learn that there's blocking if they try and access Netflix and it doesn't work.
You can get something like a Juniper SRX firewall which can recognise applications via signature and do blocking that way. Rather than against IP ranges only.
Also as a network admin you're not saying why you won't be able to block DNS over HTTPS providers.
Unless you're thinking there's going to be some unknown DNS server used by the browser.
But if that's your fear you'll need to block all the online DNS lookup websites.
What if a user just types the IP address directly? Totally circumnavigates DNS.
There's presumably no way to allow that without also thereby allowing you to change the apparent content of the Netflix service—or of other sites! (Suppose that you could hijack the user's DNS to redirect ubuntu.com to a page that said "Thanks for your interest in Ubuntu! To download the latest version, click <a href='https://evil.com/ubuntu/ubuntu.iso'>here</a>." How can you allow one kind of hijacking without also allowing the other?)
There has been work on allowing networks to communicate out-of-band to browsers for administrative purposes. Even this is risky in general because of the phishing possibilities, among other things. Showing users arbitrary messages from network operators in the middle of the users' other browsing activities is likely to make it even easier to confuse the users into taking actions that they really didn't intend to do.
Exactly this. I build a DNS security product that works at the router level. Everything is secure on home networks running the product and it uses DoT for privacy so that ISPs can’t view your data—no browser intervention needed. Browsers interfering with user-configured defaults is incredibly presumptuous. I’m worried browsers are becoming less user-agent and more platform-agent...
Great. Now I've taken my laptop out of my house (where I'm using your router) to the coffee shop downstairs where they use an ISP provided gateway... And the ISP is spying on me again. Until DNS request is encrypted there are no solutions outside of a wholly self-managed network.
I’m unsure why this has to be set at the browser level instead of the OS level. What happens to all the DNS calls made by non-browser services on your laptop?
I believe it is due to technical problems of switching everything to DoH. Moreover if we think about it, I'll see that it is not a Google or Mozilla problem, it is a problem of OS developers. For example, it might be done by gethostbyname using DoH to resolve names. But it is up to libc developers, and it would lead to other problems, like system after update stopped working, due to custom configuration incompatible with DoH.
Mozilla and Google become unsatisfied with gethostbyname but they cannot change that part of OS. So they are solving their problems on their side.
FWIW, Chrome using an upgrade list only checks the system config (doesn't do any "do I eventually end up using 8.8.8.8" checks), so it shouldn't upgrade DoH even if your backend resolver is a third-party.
What I fear will happen in several years is that local ISPs will also begin offering DoH by default (if you can't beat the competition, join them) and continue snooping on your traffic, just like Google or Cloudflare could do now technically, if they wanted to. Ultimately this boils down to which entity you trust more, your ISP or some other provider. Today Google/Cloudflare et al are by far the more trustworthy options for DNS at least. But this may not remain forever this way. The price for privacy/security is eternal vigilance, something end users don't (or can't) want to do.
Why would you fear ISPs offering an encrypted service? It’s hardly a step backwards?
DoT would be preferable to DoH (no additional metadata / cookies,) but either way ISPs should adopt encrypted DNS.
You are correct it boils down to “who you trust.” In my country the ISP wins hands down over a foreign mega-corp so I end up making a different decision to you.
The key thing is that is a choice for users, not something software just does without knowledge of what’s going on.
Google's plans usually have carefully laid out technical justifications, and are mostly kinda boringly/obviously good, like QUIC/HTTP3. That you're usually skeptical of any plan coming from Google suggests that your skepticism is miscalibrated.
I think you're cherry picking. I'd say AMP and the consequent AMP for email are recent examples to the contrary. Nothing wrong with skepticism, especially directed at a company the size of Google.
Everything warrants skepticism until proven otherwise. Especially things that are being given out for free. Google might be operating on the up and up, but Google is just a large collection of people and some of them will be ethically lacking. And Google's employees have a large incentive to not see any issues with collecting all the personal information that exists.
Internally, Google employees have quite a large incentive to NOT collect unnecessary data. It's a fundamental tenant. Don't collect any data unless it's for a specific tangible feature that benefits the user.
> And Google's employees have a large incentive to not see any issues with collecting all the personal information that exists.
I can only speak from personal experience. But I would not agree.
Collection of data needs to be covered in a privacy document. You must argue why you're collecting it. There has to be a retention plan, such that data is purged when the user account is deleted, and/or the data expires over time.
You can of course get exemptions, IF there is a valid business reason. But all of this needs to be reviewed and approved by privacy people.
If you want to get things done. The paperwork is a strong incentive to avoid keeping data you don't need.
Note. privacy reviews cover more than I mentioned here. This was just a highlight.
Your comment is 'dead' (at my time of posting) when you simply stated that you disagree and politely brought up some factual supporting points. I didn't expect such hivemind-like behavior from HN...
It's easy to make proposals that incrementally increase user security while simultaneously increasing one's own ability to consolidate and exploit user data. Technical appeal needs to be evaluated with a simultaneous critical eye to social impact (QUIC is a perfect example -- it outcompetes TCP on an equivalent link, and falls apart over variable-latency or highly unreliable connections, like those that exist in developing nations -- but of course, Google doesn't care about those audiences).
Yes, they designed a protocol which assumes low-latency highly reliable connections, which developing nations do not have. I care about what people _do_, not what they say in their PR blogs.
I tend to call people out when they make claims that are not accurate.
> I care about what people _do_, not what they say in their PR blogs.
Did you read the blog? It's not just words, they are talking about products they have shipped. E.g. Files Go. You can believe what you want, but if you're going to big claims, you should back those up with credible data.
Further, we found that QUIC consumes significantly more than its fair share of bottleneck bandwidth when competing with TCP flows, which can be detrimental to a wide range of applications.
QUIC is at its essence an ARQ protocol, i.e. feedbacks are required to recover from packet losses. And this design choice then leads to inefficiencies when evaluating link conditions. And, in links where latency and losses are unstable, these limitations lead to a significant performance loss.
if you're going to big claims, you should back those up with credible data.
It does show QUIC falling apart with _out of order delivery_, however that is not something that latency or slow networks will produce. There is no reason to think that slow / third world countries have significantly more out of order delivery. The networks might be slower / have higher latencies, but packet order is likely to be the same.
That is different than dropped packets requiring retransmissions, but given QUIC and TCP both use the same congestion control algorithm (Cubic) there should be no difference on that score.
In terms of it being “unfair” when both types of streams are present that’s correct, but TCP with BBR also produces this kind of effect. It’s the algorithm used, not whether it’s QUIC or TCP, that causes this.
QUIC is not perfect, it’s still only at draft stage in the IETF. I’d be concerned that arguments like this are being made which, while seemingly well intentioned, have the effect of stifling innovation for all internet users.
You can bet that on a high latency link the fewer round-trips to set up a TLS connection with QUIC are gonna improve things.
The claim I was referencing was taking a weakness in protocol, and jumping to conclusions.
This would be the equivalent of one saying, "You don't care about the environment because you took a gas powered bus today". And then provide evidence about how busses are harmful to the environment, and provide details about busses emitting GHGs.
Likewise, you can't jump from a weakness in QUIC to big tech doesn't care about NBU.. when in reality, much of big tech pours so much engineering effort towards NBU (amongst other things). Files Go is a small example, and you can download the app here: https://play.google.com/store/apps/details?id=com.google.and.... It is not vaporware.
I would love to see the evidence for this as well.
Instead of providing any you just attacked the person who questioned you?
What specifically about the transport layer in QUIC makes it perform poorly on high latency links? It’s going through the IETF now I’d be surprised if they were complicit in such a backwards move.
Forget about developing nations, there are plenty of parts of the US where mobile Internet is unreliable or altogether unavailable (I live in Utah, ask me how I know).
Google doesn't even care if you're a paying customer -- they sell phones without expandable storage with the explanation that customers should just use the cloud (i.e., Google Drive) instead.
Then buy a phone with expandable storage, that does run Google's operating system. That's the beauty of Google -- don't like their hardware? Buy one of the hundred other models.
It was just an example in support of the point made in the parent: as far as Google is concerned, the only people that matter are ones with unlimited, fast and reliable Internet access at all times without exception.
If you thought I was facing some kind of dilemma regarding whether or not to buy a phone that is useless half the time I leave my house, then thank you, but that's not the case.
I don't think I'm being generous. Google's large scale plans are mostly about making the internet and technology ecosystem faster, safer, and more widely available. Of course, this is because their revenue scales as a factor of the number of people using the internet, the number of pages each person using the internet browses, and the willingness of people to spend money on the internet. But don't let the motive distract from the plans. Consider the plans on their own merits.
Why are those plans "obviously good"? They promote a view of the web that is all about piping a ton of content, sprinkled with ads, to passive consumers; just like TV.
Google's technical justifications are usually pathetically self-serving. My favorite example: Why have they not yet removed cookies from HTTP? There are obvious improvements to privacy if we switch to server-managed sessions chosen by user-provided identities, and get rid of cookies, but it would frustrate Google's tracking of us, so it can't happen.
I may not have the technical expertise to understand this fully but right now I'm doing adblocking by using adguard's DNS IPs in my router (1).
It kinda works everywhere but for some apps like Chromecast I have to null route two IP addresses (8.8.8.8 and 8.8.4.4) otherwise it doesn't work. Those are both Google's IPs afaik.
So my question is: will I be able to keep doing it after this? I am asking because I am extremely suspicious of Google these days and wondering if they have an ulterior motive to prevent users from doing such host based adblocking in future?
Yes, 8.8.8.8 and 8.8.4.4 are Google DNS resolvers. Sounds like your Chromecast has them hard-coded instead of respecting your locally configured DNS.
In comparison to your current position, where you're black-holing the hard-coded addresses and the app is falling back to your configured DNS: yes you will be able to continue doing that, assuming the Chromecast will maintain the same fallback behaviour. The exact addresses you need to block and the protocol/ports you need to block may change (eg. to port 443 tcp instead of port 53 udp).
The big thing that DoH will prevent is something that you aren't currently doing, which is: instead of null-routing 8.8.8.8, you could be intercepting DNS requests to 8.8.8.8 and responding to them yourself. You would need to do this if the chromecast didn't fall back to using your proper DNS server. DoH will prevent this kind of interception, so your only choices are to allow it through or block it. And if the Chromecast then refuses to fall back, then blocking it will make the device not work, with no viable workaround short of replacing the firmware.
The goal of DoH is ultimately to prevent your ISP doing the exact same thing to you, ie. intercepting (or just listening in on) your DNS requests even when you want them to go elsewhere. Unfortunately, there's no way to prevent the same protections from extending to a malicious local device trying to circumvent you on your local network.
If using Firefox you’ll need to manually change the DNS settings, as it will by default bypass your local DNS and send it to Cloudflare using DoH. You can easily disable that though.
With the statement "could interfere on a mass scale with critical Internet functions, as well as raise data-competition issues" they are actually lying and misrepresenting the issue. In reality there is not much "to interfere" - especially not so much, that you would need to contact the Congress...
Haha Big ISPs...there’s absolutely no reason why regular HTTP requests/responses should be TLS encrypted while DNS queries should not...they go hand in hand for maintaining end-user privacy and YOUR integrity.
"Going blind" is a term I've heard recently when talking with operators. Where as "going dark" referred to the DOJ/FBI's term for ubiquitous encipherment of the content, "going blind" refers to the metadata (DNS in this case).
My view is pretty basic: If I can see your DNS, I can pretty much guess on a very short list what kind of [browsing] behavior you are engaging in.
What you can infer is why and who. Which is the real danger. I would trust google to protect sensitive data like sexual preferences before I trust my ISP.
It all depends how much is abstracted behind a common host (eg name based virtual hosting). I can see you are going to Google. But I don't know what within Google you are really accessing or using in most cases.
If this prevents ISPs from making even a penny on data mined from DNS queries of their users, even in an aggregated and anonymized manner then so be it because ISPs are supposed to be dumb pipes. And there is nothing creepier than someone mining what I search for. Just fulfill the contract of giving me the internet for my 75USD a month.
It's pretty clear that the ISPs drafted their letter before Google made it clear that they would not be forcing the transition to their own DNS servers. The complaints are entirely about centralization.
Google has attempted to allay some of these concerns, but their initial blog post [1] makes it lear that only certain whitelisted DNS providers would be permitted to participate. That does imply a degree of centralization regardless of Google's assurances to the contrary.
At the request from some less technical friends I cooked up a solution for using encrypted DNS and Pi-hole together nicely wrapped in a docker-compose config that supports both x86_64 and ARM (RaspberryPi) deployments.
I guess this means no more DNS based ad blocking for devices like the Chromecast which ignore the DNS info provided by DHCP and are instead hard coded to use Google’s server?
I work for a large retailer ecommerce office and over the years found the business purchase huge lists of subscriber names plus domains from ISP customer browsing. Att and Verizon selling that I know about, maybe more that I dont know. With the amount of money involved that Im sure they aren't happy.
Is there a way to set up a big list of round-robin DNS servers in Linux, to at least minimize the amount of navigation history any one DNS provider knows about you?
Mozilla added a canary domain (use-application-dns.net) that if blocked will default to the local dns resolver. There are several threads in the pihole community about blocking it by default so I expect that will be done before mozilla turns int on for the masses.
Completely untrue. Those services just need to serve their own DoH endpoint and the user can add it in Firefox preferences. No harder than and arguably easier than the complicated procedure for changing system DNS, and it allows you to block things in your browser that you may not want blocked at the system level for all users.
If your PiHole servers a DoH endpoint, you're probably back to exposing plaintext DNS to your ISP. The whole point of DoH is to tunnel DNS out of your untrusted ISP network to anywhere else in the world where it can be trusted more.
What is the case, however, is that you could set up a DoH endpoint on some other network and route your DNS there.
Oh, it totally can, and there's nothing wrong with that. I would just hate for someone to terminate DoH on their home network and expose direct-to-the-roots DNS to their ISP, which is, if anything, marginally more attributable than normal ISP DNS. I'm definitely not talking down the idea of doing a PiHole setup.
I don't get why you'd think direct to the root DNS servers would be worse than using your ISPs servers. Using the root servers means you get DNSSEC which would prevent the greatest threats, hijacking and injection.
There is virtually no DNSSEC deployed on any major sites on the Internet and, because DNSSEC is a terrible protocol, it's unlikely there ever will be. I'm a broken record on this; you can just search "author:tptacek DNSSEC" in the bar below to get lots of different reasons why.
The most important thing for this thread though is that DNSSEC provides zero privacy and, in ordinary deployments (where you talk to a nameserver rather than directly running on on your computer) no protection against injection between you and your nameserver.
I don't think DNSSEC itself is likely to ever win. But it does have an additional dimension that makes it a better foundation for privacy than DoH. DoH is strictly transport layer security, meaning it still relies on a trusted third party (Mozilla or Google or whomever) to not vacuum your requests. Whereas if records are signed, they can be sent laterally between mutually untrusting peers, including bulk broadcasts, etc.
A better foundation for privacy? No. DNSSEC provides literally no privacy. It doesn't encrypt, it only signs. DNSSEC is passively observable by design.
For privacy, getting records signed is ultimately more long-term important than getting queries encrypted immediately. As DoH shows, bolting on transport layer security is trivial.
For example, you'd never want to set your DoH resolver to an arbitrary TOR hidden service. But there would be no problem querying DNSSEC through TOR (assuming the setup wrapped the server-server protocol in something that allowed such forwarding).
What a strange argument. If you want to argue that Tor is superior to DoH, argue that. DNSSEC has nothing to do with it. Which, of course, is obvious: DNSSEC is passively observable by design.
I'm not arguing TOR is "superior" - rather it just demonstrates a use of not needing to trust an upstream. It's also another datapoint for how easy it is to bolt on transport security.
The general principle I'm appealing to is that it's better for a protocol to be missing more-critical qualities that are easier to add later, than less-critical but harder-to-change qualities that will forever be a hindrance. Signed records make for a fundamental security property that cannot be made up for with transport security.
Another way of looking at it is that the records in DNS/DNSSEC form a higher layer protocol than the server-to-server communication. Every party in the system has to agree on the format/semantics of those data objects, whereas the server-to-server protocols can be upgraded pairwise.
What’s stopping your PiHole or DMS adblocker from functioning as a MITM proxy? You’d just terminate HTTPS at the PiHole and perform the filtering there, right?
Regardless, it’s a tiny thing to give up for more privacy.
Running a MITM HTTPS proxy means running a CA, means the proxy gets to decide what to do about certificate errors instead of the client, means maintaining a whitelist of sites that can't be MITM'd, means segregating all the devices that I can't put a CA signing certificate on, and is just in general an ugly thing that should be avoided wherever possible.
Mozilla's method of implementing this has also created a blueprint for malware to avoid network-level detection.
I don't like it. In my view, what's being given up is significant and the privacy gain minimal.
(Right now, Mozilla has a DNS-based killswitch, but how long until all the 'bad actors' Mozilla is targeting have implemented it? I know of one public DNS provider already doing that. They'll take away the killswitch, then all the 'bad countries' will force their populations to install MITM certificates [along with the UK] and the world is going to end up worse off thanks to Mozilla)
Thanks. I was also thinking... how does DoH prevent an ISP from spying on you? Even though the DNS requests and responses are encrypted, content requests are still routed via the ISP, right?
So the ISP still has a log of which IPs you’ve visited. They can resolve this back to site names and get the same information on you they had before.
I hate to respond to low-effort snark but will do so here to remind people that Google's plan doesn't default you to Google's servers, will honor your own nameservers, and will upgrade you to DoH if any of those servers support it. It's really hard to see what more you could ask for.
If I get the choice between finding a different way to do DNS based ad blocking and hiding my traffic from ISPs' advertising divisions, I will happily find a new PiHole alternative.
How exactly encrypted DNS will reduce spying? ISPs will still be able to observe IP addresses users connect to and even particular host names in SSL handshakes.
I am a bit stuck here. I know it is a bit insane, but I run a simple system at home because I think, so if I drop dead tomorrow how is my wife going to sort this. If I am dead, internet still needs to work so my kid can do her home work. So despite my geek love, I do not run my own DNS, etc. the other part is I use unblock-us so iPlayer (BBC) works here in the US. I would love to set everything up so everything is encrypted but ... yah. Sorry depressive.
That sounds backwards. You sure that will be their biggest concern if you drop dead? They can always throw out your weird techy stuff and buy some cheap commodity solution and get them installed.
Your reasoning sounds like, I'm not going to do breakfast for my family, because, ya know, if I drop dead, they will miss the breakfasts.
Something I’ve wondered: It isn’t quite clear from the various articles how they’re doing this monitoring. I can totally see how they could monitor their own caching resolvers. They might even passively monitor popular internet resolvers (1.1.1.1, 8.8.8.8). But if I run my own caching resolver at home, is that data being mined? I am aware it’s unencrypted and possible to do so, but is it actually happening? DoH sounds nice, but it brings me back to using a shared caching resolver which I’m not a huge fan of.
Your resolver still makes DNS requests that the ISPs snoop. Unless that connection is encrypted, they have the same info as if you used the ISP’s servers.
Your ISP, by virtue of supplying the pipe to the internet, can (and very likely does) still snoop on any old-fashioned plaintext DNS requests you make across it, even when you're not using their servers.
I might have misread the GP, but I kinda felt that it also brought up the issue that a pihole (or similar solutions) might cease to work in a "DoH / I automatically pick the best resolver if I deem yours not good enough" world.
DNS privacy is awesome. Filtering malicious and annoying (read: ads) content at the DNS level is mandatory for me..
I don't think how that would cease to work. At least in the case of Mozilla they try to detect if you have a custom DNS server. When found, they won't use DoH for fear of breaking many intranets in enterprises.
reply