A safer and more private browsing experience with Secure DNS | Hacker News Reader

A safer and more private browsing experience with Secure DNS

blog.chromium.org

90 pointscaution108 comments

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.

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.

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.

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?

Windows 10 May 2020 update brings DoH support but chrome and Firefox are not using the Api for it to the best of my knowledge.

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?

Firefox assumes the OS does not use DoH and implements its own DoH lookup client with its own settings and its own list of servers. It's a huge mess.

Just like it does for the certificate store.... And not using proper UI toolkits...

Why has the world gone towards DNS over HTTPS as opposed to adding TLS itself to the DNS protocol?

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.

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.

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.

A more detailed comparison is here:

https://www.thesslstore.com/blog/dns-over-tls-vs-dns-over-ht...

You can run DoT on 443 as well.

Providers that want to block DoH or DoT are going to block providers based on destination IP or certificate fingerprints, not port numbers.

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.

> 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.

That kind of reasoning reinforces the existing problem instead of breaking things up by making support for arbitrary ports essential.

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.

The opposite is true: most DoT advocacy comes from operators (and suppliers to those operators) who specifically and overtly intend to filter DNS.

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.

If you want to put a couple bucks on this, I'd be happy to put my money where my mouth is. :)

>browsers, the most important application, are already bought in

That's an interesting way to phrase it. The RFC for DoH is co-authored by Mozilla. They didn't buy in, they created it.

Android - at least for now - supports DoT. But, who knows, they might switch to DoH in the future.

https://developers.google.com/speed/public-dns/docs/using#an...

PS: I have been using it for a while and it works fine.

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.

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.

Hm, why not add an encryption-upgrade path to the protocol using the same port? Why must we use another port?

Again, trivially easy to block that. But DoH is real HTTP(S), you cannot really distinguish it from a HTTPS request for wikipedia.org or outlook.com.

The SNI hole is slowly being addressed by ESNI - https://www.cloudflare.com/ssl/encrypted-sni/

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.

It means you need an active attacker instead of a passive one, so it still does improve security in practice.

Pretty marginal gains at the expense of eventually centralising most of the world's DNS lookups through a handful of FAANGs.

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.

This change represents a potential thin edge of an unsavory wedge.

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.

Won’t Chrome keep a single connection open for the lifetime of the browser?

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.

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.

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.

rocketspark.com -> 104.22.34.138

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.

So CDNs increase user security a little bit.

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.

Your local DNS filtering device can simply speak DoH; Pi-holes already do. That's a non-problem.

Am I the only one thinking it's weird that this rolls out on ChromeOS first but other Linux platforms (including Android) last?

I don't think it's weird. If there's a problem, it limits who is affected or allows them to fix it while the problem is small.

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.

What irritates me about DoH is it's lazy.

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.

[1] https://gigaom.com/2014/05/13/atts-gigapower-plans-turn-priv...

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.

The nonsavy user gets zero privacy. Who cares about encrypted DNS when your ISP sees every server you connect to?

The reason I don't trust my ISP is because of my government. I don't think appealing to them for help will be of much use.

Then DoH isn't going to help you very much. Move country or use a VPN.

DNSSEC provides no privacy (or, for that matter, endpoint DNS protection) at all.

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.

I don't see any mentions of it, so I'm assuming Google isn't using a canary domain to see if they should enable DoH or not. Can anyone else confirm?

DNS logs are important in an enterprise. But I'm sure many would want to also use DoH.

Does Chrome provide any audit logging for DNS while in DoH mode?

> 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".

Much of this comes from regulatory oversight of specific industries. DoH isn't going to fly in the banking sector for example.

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.

> As someone who works in academia

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.

Extremely helpful for detecting malware, or performing post-compromise IR.

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.)

Great project, thanks for the link.

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.

Bye bye DNS based ad blocking, hello malwares straight out of Google ads.

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.

You can run a pihole that delegates to a local cloudflared service.

Oh, get the heck out of here with "Secure DNS". Allowing Google to snoop on all DNS is the opposite of safer and more private.

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)

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.

Yes, Google is pushing DoH because, internally, in the AdWords division, they've broken elliptic curve DSA.

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.

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.

So what is actually going on there?

I'd like a honest technical description.

> 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.

[1] https://docs.google.com/document/d/15Ss0OaJeb-T3g2RMwgikHvsC...

[2] https://chromium.googlesource.com/chromium/src/+/b0436911ed6...

What about this enables Google to snoop on all DNS?

For someone who is using Google, it's safer to trust them with DNS rather then another company.

So both Firefox and now Chrome will ignore DNS-level malware blockers, such as Pi-Hole.

Malware/Adware will inevitably start using the same tricks, if they haven't already.

And of course DoH is impossible to block without also blocking all of HTTPS. That's the point of it.

A case study in unintended consequences.

You can turn it off?

For how long?

In these two examples, yes. In more malicious future software? Certainly not.

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)

http://github.com/yegle/your-dns

I'm not a Pi-Hole user but it looks like they already support this protocol?

https://docs.pi-hole.net/guides/dns-over-https/

That's for making upstream DNS over HTTPS requests, not how they serve clients on the local network.

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.

[0] https://support.mozilla.org/en-US/kb/canary-domain-use-appli...

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.

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.

This is literally what Firefox did and it was widely applauded.

Another thing that Firefox (Mozilla) does is absorbing millions of bucks from Google on yearly basis.

Oh well, that's not a cartel. Mind you.

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?

Not true. Publc DNS is opt-in. Pushing DNS with the browser is lock-in.

So who spreads the FUD then? Google and Mozilla combined effort (read Collusion) pushing this further warrants a thorough investigation.

Use of a specific browser is also opt-in (unless you are using an iPhone).

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?

Public DNS is opt-in. DoH in browser tied to specific list of servers is lock-in.

Some people argue that there will be an option for that. However the right solution is to make that decision at OS level.

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?

Reply on news.ycombinator.com