The upside of the "same provider" approach in Chromium is that it defuses a bunch of the complaints you get with Mozilla's approach about how they're picking winners (with the inevitable side dish of conspiracy theories).
The downside is that it's opportunistic encryption which means it fails open. If you're actively targeted this won't protect you. You'll need to explicitly configure a DoH server to be protected.
Forget the encryption; alter the protocol to support overfetching. (Instead of fetching a specific site, you fetch blocks of sites). In a naive version, you'd ask for every site from goodreads.com through to google.com, and then the client would actually visit the site it wanted. In a hardened protocol, I'd imagine you'd use hashing, along with a random salt so that there are many different ways to query the same site.
Right now, your DNS provider has a list of every website you visit (just not how many times you visited it). The shorter the DNS cache, the more closely this list matches your browsing behavior.
This definitely complicates the protocol, whether you put the burden at the resolver layer (needs larger cached) or at the level of authoritative servers (where'd they be effectively cooperating with root servers), but it's the only way to truly safeguard browsing data.
"Instead of fetching a specific site, you fetch blocks of sites."
I have been doing this for many years, putting bulk DNS data in HOSTS and personal use zone files served from loopback addresses. It is easier than ever today with so many sources of bulk DNS data.
DOH now lets users retrieve DNS data from recursive DNS servers (caches) in bulk, using HTTP/1.1 pipelining. Here is a working example: https://news.ycombinator.com/item?id=23242389
Many years ago, I started doing non-recursive (no caches used) bulk DNS data retrieval for speed and also for resiliency in the event of outages. However the privacy gains are obvious. A rough analogy is downloading all of Wikipedia in bulk and browsing articles offline as opposed to making separate requests online for each article and generating all the requisite DNS and TCP/HTTP traffic. Openmoko's Wikireader experimented with the idea of offline Wikipedia.
Not only does the DOH provider get a record of all the user's DNS lookups, she can now associate each request with the particular user program/device that made it.
What's really needed is to add support for DoH or similar to internet gateways. Attacks are nearly always between the gateway and the internet and not between the client and the gateway on the same LAN, and then the gateway can safely require DoH by default because it isn't a significant administrative burden to change it in one place for the whole network if that isn't what you want. They could even default to something like trying DoH to the DNS server configured via upstream DHCP with fallback to DoH to Cloudflare or similar if that fails, but no default fallback to unencrypted DNS.
Meanwhile if the administrator of the endpoint device knows their DNS server supports DoH, they could still manually enable it as required even if that isn't suitable as a default there, and the default Chromium is using still protects against passive attacks when your DNS server supports DoH.
Encrypted DNS is great, so long as the end user retains control over which DNS servers provide the answers.
This does appear to be the case here, and so it is still possible to disable it (use a local stubby instance to do encrypted DNS) or to use a custom setting (your nextdns.io config for example).
I can see this leading to frustrating issues where your browser works fine but every other native app on your system can't resolve hostnames because your regular DNS isn't working. Would be nice to have all hostname resolution dealt with at the OS level rather than special-cased within the browser. Is that something that modern OS's are planning to support?
What do you mean "the API"? Shouldn't Windows just pass all requests to resolve domains through doh or dot? Have they really added an opt-in API instead of making it the default?
There’s DoT (DNS Over TLS), which operates on port 853, uses TCP and provides encryption. But it’s also something network operators can easily block since it runs on a specific, separate port. DNS over HTTPS (DoH), on the other hand, rides on HTTPS/port 443, which cannot be blocked in networks without causing major disruptions to the rest of the web traffic.
Providers are hesitant to block IP addresses for a multitude of reasons, one of the simplest ones being that different services can run on a single IP.
And running DoT on a non-standard port breaks all sorts of things because it will be ... non-standard.
If there was a coordinated embrace and move to DoT (at least for the "last mile" part between end users and resolvers), network operators wouldn't be able to get away with blocking it (see secure IMAP, secure POP etc. for similar shifts in the past).
The internet is decentralized and "coordinated embrace" is not realistic or practical. See also: IPv6.
Pretty much the whole of the internet has been jammed into tcp/443 now, and it can't much be helped. Internet engineering needs to cope with the world as it is, not how we wish it were.
>The internet is decentralized and "coordinated embrace" is not realistic or practical.
I disagree, see the success of: letsencrypt, the wide spread use of 8.8.8.8 and 1.1.1.1; dkim/spf/dmarc; imaps, pop3s, tls ldap.
Why should a switch over to DoT be any different? If anything it should be easier. The general need for better security and privacy are much more widely understood and accepted concerns these days.
As said DNS operator (founder and CTO of DNSFilter.com) - I concur. We’ve been offering DoT for years, but are about to improve the offering with 0-RTT support.
We’re also working on POCs of DoH support, but it’s mostly moot compared to our DoT offerings which cover the whole OS, not just the browser.
Operating systems are going to do DoH (Microsoft already is), and that's going to be the end of it --- browsers, the most important application, are already bought in. DoT is a footnote.
While I truly respect your credentials, I disagree 100% with your conclusion and think DoT will win out. Should be fun to visit this thread in a year, just to see.
> DNS over HTTPS (DoH), on the other hand, rides on HTTPS/port 443, which cannot be blocked in networks without causing major disruptions...
And your point is what, exactly? TLS allows for traffic redirection and for a time people were using this to circumvent firewalls but the big providers who looked the other way locked it down when their traffic started being blocked.
DNS over TLS (DoT) already exists, and it's apparently both faster and more efficient. The argument I've heard for preferring DoH is the fact that it disguises DNS traffic, making it indistinguishable from other HTTPS traffic.
There is DNS-over-TLS. The difference between DoH and DoT is that DoT runs over a distinct port, and can be trivially filtered by network operators. DoH was created specifically to run encrypted DNS over a transport that would require more intensive filtering to block. As an anti-censorship mechanism, it's imperfect, but it comes at little real cost (other than preventing operators from blocking encrypted DNS, which is the point).
DoT is, effectively, DoH with a kill switch.
It'e essentially a moot point at this point; DoH won.
I think the arguments are that there's a degree of security through obfuscation by forcing everything over a single common port (443), the transmission integrity benefits of TCP versus UDP protocols, and maybe just the overall simplicity of HTTPS as a protocol.
If everything is encrypted over the wire in an HTTPS wrapper, then crappy internet providers can’t discriminate against your traffic based on its nature.
An interesting detail: How does their upgrade work if you're using a customised DNS service where the customisation is detected differently in DoH compared to plain DNS?
For example NextDNS customers using DoH put a customisation parameter in the DNS URL paths (and so it's opaque to an adversary on the network) but obviously there's no URL path in conventional DNS, so does Chromium spot your NextDNS configuration and figure out the right URL path?
Had a discussion just today with some colleagues because of internal company network(VPN) hijacking every port 53 request and responding in 2s(!).
I sure do hope this becomes a visible and flexible feature and not a google-only-dnses or "Oh, you have to run it with this special flag --use-dns-over-tls) kind of feature.
I think DNS topic has been underrepresented in the privacy-aware community. Hope this changes both for OSes and also apps people use regularly.
> Furthermore, if there’s any hiccup with the DNS-over-HTTPS connection, Chrome will fall back to the regular DNS service of the user’s current provider by default, in order to avoid any disruption, while periodically retrying to secure the DNS communication
Doesn't that make this pretty trivial to defeat? Just drop the DoH packets and boom, you've got unencrypted DNS again.
I think you're confused about what this change represents? It doesn't move DNS lookups between providers, it only enables DoH for providers known to support it.
The immediate adversary DoH faces down is major US ISPs, most (all?) of whom monetize passive DNS. DoH breaks the tooling ISPs use to track their users. ISPs could escalate, but it would be expensive and legally questionable. In reality, DoH will probably permanently break ISP DNS adtech.
There are more exotic adversaries for a DNS lookup system, and against them you'd want something more rigorous than an immediate DNS fallback. But the short-term win is major.
Touché. Totally agree that DoH is a win, and "DoH that doesn't protect against some attacks" is more of a win than no DoH that protects against no attacks.
I think this is phase 1, where phase 2 or 3 is "enabled by default and don't fall back to plain DNS". So it's trivial to defeat until they change a setting.
But that's not even the big problem here. The big problem is how big an impact this will be on less-than-perfect networks.
The internet feels "snappy" because of DNS's speed and connectionless nature (and a buttload of DNS caching). Once it relies on a connection-oriented protocol, a lot of people's internet experience is going to start sucking badly, and they'll have to modify more of the common internet protocols to make it suck less again.
Conveniently DoH servers didn't exist years ago, so any that you're talking to will be new. But new servers have no reason not to implement TLS 1.3, as does Chrome.
In TLS 1.3 you can choose to avoid the handshake roundtrip but then you're subject to a replay attack in which any request side effects happen again because your legitimate request was replayed. The bad guys don't get to understand the request or the answer, they just get to perform it, maybe against a different node of a distributed system or in a different timeframe. Conveniently DNS lookups are side effect free so this doesn't matter.
So that really cuts down on the potential additional latency compared to even an HTTP GET.
So why is this better when people could still take the raw IP addresses and do reverse look ups?
If I recall looking into the spec before there is a reason it’s an improvement but I can’t recall what it was.
I know there are tons of servers behind proxies and so forth but still it seems like over time databases could be built up to give some decent success with this countermeasure.
104.22.34.138 is one of the cloudflare servers, it does not have reverse dns record and you can't associate it with any specific website. If you're monitoring traffic, you would have no idea what website user is visiting unless you can intercept his unencrypted DNS queries as well.
If you're monitoring traffic you can see the SNI header in plaintext. ESNI is not deployed yet (and is only as secure as DNS; that is maybe why browsers are implementing DoH themselves instead of waiting for the OS).
For narrow cases like Cloudflare load balancing traffic, it would be difficult to reverse lookup without other compromises.
It always depends on who your adversary is. Chrome is a controlled, auto-updating application. Your Cloudflare traffic is going to a central authority, Cloudflare. They could decide to sell traffic information. Or the government where Google or Cloudflare main line employees eat and sleep could ask or order those working stiffs to do something secretly in spite of company policy or promises.
This does protect against a very narrow adversary, which is your ISP or router manufacturer monetizing your aggregated traffic statistics. It remains to be seen if there was ever harm there to the user in the first place.
The government, as an adversary, generally wants to put you in jail. Google working stiffs generally don't want to go to jail, so they'll comply with requests; or Google will want the government's business and just do the thing they ask for. Google already gives you the thing for free. Your ISP and router manufacturer just want to offer you lower prices.
Corporate and closed source or remotely managed software promises are just that.
From what I have seen Firefox has already been taking a similar approach for the past year. In enterprise environments, there's the ability to disable DoH. And for general audiences, the ability to fall back to normal DNS if necessary.
The significant difference here is that Firefox has made it possible to maintain Split DNS without managing and reconfiguring every device via a network signal to continue to use split DNS (e.g. PiHole)
What is the impact for an organization utilizing a BYOD policy that performs DNS filtering? What about home users filtering via PiHole or pfSense or parents that use local DNS filtering? Will every device's browser need to be changed? Will Chrome revert in the presence of a network signal to use local DNS (as is the case with FF)?
DNA crapware filtering was the most effective way of not having ads in every possible place on the web and also stop mass surveillance conducted by facebook and google. Now they want to know every last bit of information about you, the domains you interact with. Private mode wont work anymore.
Sigh, the two words Google and Privacy are like oil and water, but I digress...
It will be interesting to see what reception this will get in some countries where all ISP's are legally bound to modify DNS-requests to prevent users connecting to sites with content such as child pornography.
I get the impression Google, Mozilla etc. are genuinely irritated with crappy networks and invasive ISPs meddling with DNS traffic. What I don't accept is their decision to abuse their market positions to impose a quick, unilateral solution that comes with a range of unfortunate long term implications and secondary effects vis a vis centralization.
Imho, it would have been much, much better if they had used their resources and clout to help fund & advocate for a general, independent transition over to DoT for last mile and increased adoption of DNSSEC and DNSCurve upstream.
The world manged to move to encrypted email and www. Surely it could move to encrypted DNS without browser vendors forcing us to split name resolution and send half of it over HTTP?
The problem isn't just ISPs meddling with DNS traffic, but ISPs passively collecting DNS traffic and using it to track users, something which is believed to have happened in the US on at least one occasion. [1] DoT to your ISP doesn't help if you don't trust your ISP. There is also the risk of collection by intelligence agencies.
If you don't trust your ISP, you are savvy enough to use a). a different resolver or b). a VPN. In both cases, the decision is opt-in (which is what it should be).
Edit: or option c). apply pressure to your government representatives to update their privacy laws so ISP snooping doesn't happen in the first place. It's a sad state of affairs when the ISP market has failed so badly that you can't find an ISP you can trust.
> If you don't trust your ISP, you are savvy enough to use a). a different resolver or b). a VPN. In both cases, the decision is opt-in (which is what it should be).
So you think that non-savvy users don't deserve privacy?
> Edit: or option c). apply pressure to your government representatives to update their privacy laws so ISP snooping doesn't happen in the first place.
That's definitely desirable. Heck, the snooping in question might already be illegal in California under the new CCPA. But I don't see federal legislation happening anytime soon, and the US is not the only jurisdiction lacking privacy protections. And while privacy laws can prevent snooping for advertising purposes, good luck convincing the government to outlaw snooping by intelligence agencies. Ultimately, legal and technical measures are not mutually exclusive, and we should use both.
DoH isn't meant to provide any privacy beyond the first resolver anyway. DNSSEC gives you trust to the root servers, DNSCurve gives you privacy between supporting upstream resolvers.
No, it doesn't. DNSSEC does nothing but sign requests, and nothing at all for endpoints; it collapses down to a single header bit between resolvers and DNS servers.
Audit logging for DNS is generally poorly done. When Vixie's hair was on fire about DoH last summer I wrote this: https://github.com/m3047/shodohflo/
Look in app/ for a screenshot. Needs access to a recursive resolver compiled with support for Dnstap. If you've never paid attention to DNS or used web console (in Firefox) tools, I suspect you're in for a surprise.
Haven't tried it with DoT, I imagine that Dnstap would lose visibility for deciding which client to attribute the traffic to.
(The DNS agent is performant enough for full visibility into a workgroup of 50-100 people.)
Serious enterprises already manage all their endpoints directly, and control their DNS configurations. For that matter, they also run edge TLS proxies and push internal certs to all their machines, so they control HTTPS egress as well.
There are a couple security products that rely on monitoring DNS to function (the "passive DNS" products), and if you're one of those vendors, an industrywide shift to DoH is a real problem. But for everyone else, it's not so much a problem. The same enterprise people raising the alarm over DoH are the ones who tried to break TLS 1.3 to keep the non-forward-secure RSA handshake in the protocol, so their TLS sniffers would keep working. They adapted.
> DNS logs are important in an enterprise. But I'm sure many would want to also use DoH.
Really? Why? As someone who works in academia, I don't see why anyone would need access to my or my colleagues' DNS logs, but I understand things might be different in industry.
"Important" in the sense that many IT organizations have predicated their data forensics and incident response capabilities on being able to intercept and analyze traffic at arbitrary points within their corporate networks.
That's not to say that those choices reflect good architectural design, to be sure quite the opposite. But like many things in enterprise IT risk management, it comes down to where you spent your money, and things like DoH/DoT force will force certain organizations to admit "a lot in the wrong place".
To be clear, I'm not asking for the ability to intercept DNS requests, or encrypted traffic, at all. I'm fine (and encourage) encryption on the wire. I'm just as happy to get the logs on the local system, and ship them off.
I wouldn't blame or ride on academia. If you have no data worth exfiltration, experiments worth sabotaging or industry affiliations you might be right.
Yeah. I'm sure that's the eventual goal for regular end users. We'll all be fast-ring beta testers with unblock-able ads.
On the enterprise side it's probably a play to shift the market away from on-premise DNS based filtering and logging devices to SaaS based DoH filtering services. Tacit collusion will ensure no one builds a perpetually licensed device that does DoH and filtering.
Chrome maintains a list of DNS providers known to support DNS-over-HTTPS. Chrome uses this list to match the user’s current DNS service provider with that provider’s DNS-over-HTTPS service, if the provider offers one. By keeping the user’s chosen provider, we can preserve any extra services offered by the DNS service provider, such as family-safe filtering, and therefore avoid breaking user expectations.
Secure DNS is a "same-provider DNS-over-HTTPS upgrade" approach, and it sounds like you're conflating it with a different design, where Chrome would talk to Google-run DNS servers?
(Disclosure: I work at Google, speaking only for myself)
I doubt that what you quote is full story, however and I would really like if somebody would be able to investigate what is actually happening.
Let's take a trivial example: everybody has their own router at home, typically with the address of the DNS server visible in the local network as the address of the router, and their computers are seeing only that address.
If Chrome would keep that, nobody's router would "provide DNS-over-HTTPS" and nothing would happen. That means that Chrome will try to avoid using the router as a DNS, and instead try to "guess" if the local router is "changing something" or "using a provider" (whatever they define as that). And then the Chrome will contact that guessed provider.
As far as I understand, exactly the only device we can fully control is being actively avoided, and instead some "guessed" provider is contacted using HTTPS.
> If Chrome would keep that, nobody's router would "provide DNS-over-HTTPS" and nothing would happen. That means that Chrome will try to avoid using the router as a DNS, and instead try to "guess" if the local router is "changing something" or "using a provider" (whatever they define as that). And then the Chrome will contact that guessed provider.
That's not my read of the design doc [1] or code [2]. Instead, it looks to me like if you have your DNS server set to one of a hardcoded list of IPs known to support DoH then you get upgraded. That list is currently 8.8.8.8 (Google), 1.1.1.1 (CloudFlare), 9.9.9.9 (Quad9), and their aliases. If your DNS server is set to 192.168.0.1 or something, then this change will have no effect for you.
As far as I have noticed, only time Google makes something 'more private for everyone' historically, has been when they themselves have found a superior way to get around it.
Whether this is because the entire Internet uses Google Analytics, Gmail, etc, or because they have a different more effective way of tracking DNS queries is irrelevant, since they always manage to find a way due to being omnipresent.
> As far as I have noticed, only time Google makes something 'more private for everyone' historically, has been when they themselves have found a superior way to get around it.
In theory, DNS-over-HTTPS in Chrome allows Google to bypass OS-level ad blockers. Just like Manifest v3 limits the capabilities of in-browser ad blocking.
Not quite the implication I intended, but when you own something like Google Analytics, you don't need to see everyone's DNS queries, because you have much, much more.
Run your own DoH/DoT server that forward to PiHole? It works well and with the added benefit of bring PiHole with you (on Android P and above, via DoT)
As of Pi-Hole release 4.4 it will automatically disable DoH for all Firefox browsers it serves by sinkholing the canary domain [0].
For Chrome it appears that they are just upgrading to DoH for the existing DNS servers if it is possible. Since a local Pi-Hole server wouldn't be in their possible upgrade list it would be left untouched.
The relation between DNS and internet is the same as between a boot protocol and computer.
By taking a control over DNS, Google usurps the power and makes the open web a walled corporate franchise of its own.
In other words, Google steals the open web from the world. It injects a proprietary Trojan horse in disguise of security and established a total dictating power, deciding on what can be published on the web and what cannot.
The choice of timing speaks by itself as well. A pandemic is a great mud water to pull the trick like that.
Didn't you get enough stories about unwarranted pullouts of apps from Google Store? Website pullouts are the subject of the nearest future if we allow that to happen.
The community should boycott centralized DNS-over-HTTPS (DoH) approach as it clearly stays in the way of Open Internet was originally designed. DoH leads to a totally centralized, usurped, greed-driven future controlled by a single corporate entity.
This should also bring the closest attention of anti-monopoly committees around the world.
I know that not all people can grasp the danger DoH brings today, but this is a very dangerous development that may lead to disastrous consequences for communities around the world. Internet as we know it may just die.
DoH is a huge upgrade over unencrypted DNS. Google offering DoH (amongst others) is no more a danger to web censorship than their deployment of the Google Public DNS (8.8.8.8/8.8.4.4). Where was the outrage then?
It's tiresome seeing the same FUD over and over again each time DoH comes up, whether Google, Cloudflare, or whoever. This is religion, not science.
Did the rlogin/telnet people suffer so when ssh was introduced?
Google isn't taking control of DNS. That will still be up to the user, and like Firefox, I expect it to be configurable too. Mozilla already implemented and is using DNS-over-HTTPS. That is why I find the Google hate to be semi-manufactured. Cases like this, it makes no sense to argue against something like this. Even if I was running my own DNS server, I would still want to use DNS-over-HTTPS in my own setup.
I'm all for decentralizing DNS and the web as a whole, but does that mean that I am going to advocate against better centralized security because of it? Absolutely not, especially when a majority of users don't have access to decentralized DNS today.
Google has run free, open access, uncensored DNS for over a decade. What makes you think DoH in specific is indication of some nefarious plot to start censoring DNS? Whats in it for Google?
OK, lets assume DoH is locked to not just a list of servers, but one server: Google's. Whats in it for them to start censoring DNS?
Or is the argument that they will lock it in to your ISP's DNS server (autodetected, somehow), and your ISP will be evil (this is hardly a stretch of the imagination)? In this case, again, whats in it for Google?
The downside is that it's opportunistic encryption which means it fails open. If you're actively targeted this won't protect you. You'll need to explicitly configure a DoH server to be protected.