Hacker News new | past | comments | ask | show | jobs | submit login
Google rolls out DNS-over-HTTPS support in Chrome 83 (theregister.co.uk)
143 points by samizdis 6 days ago | hide | past | web | favorite | 136 comments





For those of you worrying about what this will do to parental controls, I did a little bit of research.

In this blog the chromium team say:

https://blog.chromium.org/2019/10/addressing-some-misconcept...

> The first claim is that Google is going to redirect user DNS traffic to Google's own DNS or another DoH-compliant DNS provider. That is incorrect. Because we believe in user choice and user control, we have no plans to force users to change their DNS provider. Today, there are many independent DNS providers, although ISPs serve approximately 97% of user DNS needs. As long as these service providers keep catering to user needs and concerns, it will remain a diverse ecosystem. We’re simply enabling support in Chrome for secure DoH connections if a user’s DNS provider of choice offers it. Chrome will check if the user’s DNS provider is among a list of participating DoH-compatible providers and if so, it will enable DoH. If the DNS provider is not on the list, Chrome won’t enable DoH and will continue to operate as it does today. As DoH adoption increases, we expect to see the number of DoH-enabled DNS providers grow.

This is re-iterated in the next paragraph

> The second claim we’ve seen is that the secure DoH connection will limit the family-safe content controls offered by some ISPs. In fact, any existing content controls of your DNS provider, including any protections for children, should remain active. DoH secures the URL data only while it’s in transit between your browser and the DNS provider, so your provider’s malware protection and parental control features will continue to work as they have in the past.

So this isn't going to break parental controls by default...

...unlike Firefox's proposed scheme which requires action by the DNS providers.

https://support.mozilla.org/en-US/kb/configuring-networks-di...


>...unlike Firefox's proposed scheme which requires action by the DNS providers.

Maintaining a hardcoded whitelist of providers (which is what it sounds like is happening in Chrome) is a bit naff. Mozilla's solution scales, at least.

Also, their solution doesn't _require_ action from the DNS providers - corporate IT staff can customise this behaviour for managed machines via an pref or enterprise policy.

Defaulting to transport security for DNS queries out of the box is a Good Thing.


My home ISP which provides the filtered DNS I use for my children haven't managed to configure their DNS to do the right thing with use-application-dns.net (it should NXDOMAIN)

That is what I meant by the DNS providers need to take action.

Now I imagine these will all get fixed eventually, but I know if I was a teenage boy I wouldn't be complaining to anyone that my internet was suddenly unfiltered ;-)


If I was a teenage boy I'd simply change the DNS server to something more appropriate for my needs, or manually enable DoH if you're MitMing DNS

I'd like to see the OS, not browser, attempt to use the configured DNS entry via DOH, failing back to DoT and finally DNS. I'd like my browser to use the OS to provide DNS services, not implement their own. I'd like my OS to take hints from my network (DHCP etc), but for me, the sysadmin, be able to override them if I don't trust the network.


[flagged]


I'm guessing that is unlikely for the parent post.

FYI a fun little weekend project might be to set up network-wide ad/nsfw blocking with pihole and a Raspberry Pi. Mine cost about $40, maybe 2 hours to configure how I want it. My work laptop has a nsfw filter while my the rest of my devices have more intense ad blocking, and of course all block malware domains. You need a router that supports a custom dns setting though, and static internal IPs if you want per-device rules.

The main reason to do this it to block ads on smart TVs, etc. though, not for your use case.


Using DNS for parental controls is likely not very effective except for very young children. Most devices that you would give to children (anything from Apple, most Android devices, Chromebooks, Windows) offer parental controls that aren't as easy to circumvent and work on networks other than your home network. Of course, it might be good to use both as a sort of defense in depth.

Parental controls on chromebooks are awful. Family Link itself is a badly put together product, but its claim to support ChromeOS is woeful, half of the stuff doesn't work, and mysteriously disappears from the app when the device in question is a chromebook.

They haven't done a good job. FWIW I work for Google, mean no offense to the team that works on this, but it has all sorts of problems, including service reliability. My wife is taking UX design courses and one of her final course projects was a multi page paper breaking down a bunch of our issues with it :-)

We've been down this road for months. Issues at home with mental health damaging content being accessed repeatedly, and I ended up signing up for OpenDNS; problem solved [for now].


I've been extremely frustrated with the ux and functionality of family link.

It's been pretty effective up to age ~13. I'm not really sure after that, as I don't really bother to monitor.

I've blocked malware too by having DNS controls, presumably that won't be possible with DoH: Chrome (without addons) might check to see if I've set a local DNS provider but ad-/app- embedded malware won't.


That's reasonable. After a certain point, the goal is to encourage good judgement and trustworthiness, not lock down everything super aggressively.

So Pi-hole should continue to work without issue?

My worry here is that google has proven they see themselves as the only subversives allowed.

They are okay with themselves censoring and curating content but someone outside comes in and they are not happy to have other subversives. I used to trust them to do the right thing many years ago, but that’s not the case any longer.


With Chrome I don't think there will be a problem.

With Firefox it needs to report use-application-dns.net as not available (see NXDOMAIN below)

    $ dig use-application-dns.net.
    ; <<>> DiG 9.16.1-Ubuntu <<>> use-application-dns.net.
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22419
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

I'm not against the idea of DoH but I do want to exert control about how it is being used.

So if you want to use DoH within your network and have Pi-hole, I'd probably put a DoH endpoint on the same server as the Pi-hole and configure my browser to point to that instead.

It'd look something like

Laptop/desktop --(DoH)--> DoH server --> Pi-hole --> Upstream DNS --(DoH?)--> Public DNS

Not ideal but until someone creates a system that acts as DoH server, adblocker, upstream DoH resolver, this is probably the best that one can do for now.


DoH is such a weird concept to me. It feels like HTTP is a pretty poor protocol to be eating the world.

I can easily imagine that the resources being spent on DoH are many orders of magnitude more than was spent on actually fixing or updating the DNS protocol.

This is not in defence of the current DNS system, I'm just sad that the only way we can think to fix DNS is to make it not DNS, but some form of HTTP name resolution.


There's value in solving the security challenges of HTTPS once, and to then resist reinventing the wheel elsewhere. Using it for DNS doesn't strike me as a particularly bad case of shoehorning.

What specifically don't you like about the use of HTTPS? Would you prefer DNS-over-TLS? Apparently [0] that's an option too. I don't think it would be possible to be quite as lightweight as the plain old UDP-based DNS protocol while giving the desired security properties.

[0] https://en.wikipedia.org/wiki/DNS_over_TLS


I specifically mentioned "HTTP" and not "HTTPS" because, while there are some security extension headers in http; the majority of HTTPS's security is a solved-once situation already in the form of TLS.

The reason I don't like HTTP for all purposes is because, while it has proven to be expandable, I feel like we're going to have this "oh shit" moment in 10 years where we realise all the cruft we've added to it and how it's bogging down otherwise simple communication.

DNS was designed to be incredibly low latency, QUIC is a response to the high latency of TCP for HTTP in general; but then you're still sending a fair amount of content that is completely unneeded.

A few dozen bytes here and there don't matter much, but that mentality is why computers today have worse input lag than computers 30 years ago, despite being many hundreds of times faster.


DNS latency is much more provider specific then protocol. If you were using both in a vacuum, you'd be correct, but in the real world DoH does not have any significant impact on latency. Switching to Cloudflare's DoH service improved my DNS resolution significantly over my ISPs.

I can see where you're coming from. I share your disdain for avoidable bloat.

I suspect you know rather more about QUIC than I do. DNS-over-QUIC sounds like a secure, low-latency solution, at least on the face of it. Would it really be possible to shave off much overhead there?


I think it's over complicated too, but I bet that in real-world use, the latency might not be that noticeable.

For one thing, if your DNS server is nearby, as it traditionally is with an ISP, latency is usually low. If you want to establish a TCP connection quickly, one thing that helps an enormous amount is to move the server as close to the client as possible.

I don't know if they are planning to do this, but you could also do some connection caching. Keep that TCP connection open while you are browsing.

It is a shame to have to do things to mitigate latency that you could have just not added in the first place. But at least the mitigation probably works.


DoH does not fix the security issues with DNS. My ISP hijacks it and sends you to a page full of ads when you visit a missing domain just like older DNS. The browser vendors even provide explicit instructions for this.

Literally all this does is break things.


How does your ISP hijack an HTTPS connection? Are you using your ISP's DNS service?

They don’t hijack https they hijack DoH. The point behind this is to protect the average user but they’re just going to get the recursive resolver from dhcp. People who bother to use something are the same ones who will tunnel traffic or run their own resolver.

> They don’t hijack https they hijack DoH

DoH stands for DNS-over-HTTPS. You cannot hijack DoH without hijacking an HTTPS connection.

> they’re just going to get the recursive resolver from dhcp

In answer to my earlier question then, you're using your ISP's DoH DNS service, correct? If that's the case, there's no hijacking going on.

> People who bother to use something are the same ones who will tunnel traffic or run their own resolver.

This is the reason Firefox went with CloudFlare's DoH. Resisting ISPs' bullshit is much of the point.


> You cannot hijack DoH without hijacking an HTTPS connection.

Not true. An ISP can always reroute packets where ever they want. Want to reroute from a trusted resolver to your own, which is bootstrapped over regular DNS? No problem. Client checks it? No problem, it will fallback to regular DNS.


> Client checks it? No problem, it will fallback to regular DNS.

That's a good point, I'd missed that. I'd hope the browser would show a warning in this case though.

I don't imagine there'd be any point redirecting a DoH request rather than just blocking it outright though. No serious DoH implementation is going to fail to check the cert.


Unless you have trusted a CA from your ISP, they won't have a valid cert. They can divert the packETS, but their response will be invalid (fail when the client checks the cert).

I addressed this in my response. You're right that redirection does little more than just blocking the traffic, on account of the certificate check, but if the attacker can force a fallback to regular DNS, that's a problem.

Every browser DoH implementation checks certificates.

Nope. All you have to do is block the ones the two border vendors use as defaults and you’re back to square one.

Right, as withinboredom said. I don't know if ISPs are likely to be so brazen though.

> Would you prefer DNS-over-TLS?

I'd prefer dnscrypt (https://en.wikipedia.org/wiki/DNSCrypt). I'm still not sure why we're going with DoH instead of dnscrypt.


Has anyone even written an I-D for DNSCrypt?

> There's value in solving the security challenges of HTTPS once, and to then resist reinventing the wheel elsewhere.

TLS does that part. HTTPS solved/worked around a lot of web problems (same-origin policy) that don't apply to DNS.


> I can easily imagine that the resources being spent on DoH are many orders of magnitude more than was spent on actually fixing or updating the DNS protocol.

You're absolutely right. It's obvious that a better way forward is to fix and update DNS.

Is it possible that you are so right that everyone concerned agrees with you, and has for years? There have been efforts to improve, fix, and upgrade DNS for decades now. They've consistently run afoul of intractable political problems in getting improvements into actual use. Long story short, there's a vast number of parties involved, most of whom have no reason to want to upgrade.

You're right. This is sad. It's also the way forward that people have been able to find after literal decades of trying to improve DNS.


No. There have been literal decades of effort to deploy DNSSEC, which (1) is a server-to-server protocol that doesn't protect last-mile browser lookups at all, and (2) doesn't encrypt messages or provide any privacy. There have been desultory efforts to tack some kind of last-mile security onto the DNSSEC stack, like TSIG, but even that doesn't encrypt messages or provide privacy.

Despite getting DNSSEC deployed at most of the DNS roots almost a decade ago, and to a point where companies can actually turn it on if they want, DNSSEC adoption hasn't cracked 2% of .COM, and, if you measure popular domains outside the US government, its adoption gets even worse: virtually no major platforms or tech companies use it. Those companies have security teams with people who specialize in evaluating technology and getting it deployed, and they have all come to the conclusion that what the IETF worked on to "improve DNS" wasn't worth it.

Meanwhile, virtually every major ISP in America monetizes DNS lookups for their customers. Not only that, but most real DNS spoofing attacks are either last-mile interceptions or phishing attacks on registrars. Which is to say, while the IETF was futzing around with a 1990s-cryptography signature scheme nobody is going to use, the real problem was right there waiting to be solved. Thankfully, Mozilla solved it, and in just a couple years DoH has protected more people on the Internet than DNSSEC is likely ever to.


I mean, DNS is a protocol from the dinosaur days of the internet, where cryptography just wasn't a concern for anything. It's also foundational. Moving to a truly encrypted, private, not-transparently-backward-compatible protocol was never likely to see better adoption than DNSSEC.

IMO, telling all this to someone who has no historical context and innocently asks "Why not just fix DNS?" is lighting a candle with a flamethrower. Plus all the strong emotions that get conjured by DNSSEC and its history (at some point someone will chip in asking about DNSCurve...).

The important points for the casual observer are that people have considered updating DNS and that DNS is unfixable for political and economic reasons. Which is why the best answer we have today is to tunnel it over HTTPS.


DoH is essentially the IETF's version of DNSCurve. DNSCurve (and then DNSCrypt) were at base the idea that we should secure DNS bottom-up, starting from the resolvers, rather than what the IETF had been doing, which was the top-down start-at-the-roots concept of DNSSEC. Neither DNSCurve nor DNSCrypt had any real push in the IETF that I can find; Dempsky wrote an I-D for DNSCurve back in 2010 that has like 2 mailing list posts about it, and I can't find anything for DNSCrypt despite it actually having users.

Meanwhile, the idea that we can't do anything but tunnel DNS through HTTPS because of inertia or politics is obviously false, because there are competing proposals, one of them with serious IETF energy, that don't do that. They're just not popular among users.


I remember during 2009 IETF meeting talking about using end-to-end, and the response I got back was that DNS resolving must be a simple caching server at the ISP end because companies has shown that for every millisecond slower a website loaded there was a noticeable loss in sales, and thus anything that impact performance would not be acceptable.

Under that mentality you could not do much with the last-mile, and you can definitely not do any serious security that protect confidentiality between client and server. You could do something DNSSEC because it did not cause a 10ms lookup to go to 11ms, and thus no one was screaming bloody murder over it.


Which is "something must be done; this is something" logic, right? It's pretty plain to see that the operator community did not in fact want DNSSEC, despite its favorable latency characteristics.

The original intent behind dnssec is before my time working in the dns industry, and when it come the last couple decades the larger push seems to be focused on making people feel more secure in using dns for identification and authentication purposes. How well it does the job depend a lot on the threat model, and how large the actually risks are for that model.

How likely is it that an attacker can take over an domain on say cloudflare/microsoft using dns authentication, or someone managing to spoofing an email by changing the dmarc signature? On the average case I suspect the risk is very small, but then I don't think that specific attack surface has been well tested enough to demonstrate how good the idea is to put keys and proof of identity in dns without any additional system to validate the records.


I worked at Network Associates not long after they bought TIS, which had the original DARPA contract for DNSSEC, and had been working on DNS security for at least 2 years prior to that, and the push then was (unfortunately) the same as it is now: to authenticate the DNS, to create a resilient global PKI that can be used to increase the importance of the DNS in other applications. Privacy has literally never been in its remit; that's why they spun up a separate WG (DPRIVE) to work on it.

DNS would still be easier to replace than IPv4, but there's less of a technical motivation.

> virtually every major ISP in America monetizes DNS lookups for their customers

For 95% of users, DoH just lets Google monetize the lookups, instead.


There is no DNS-related reason to use HTTPS.

This is a tactical move to obfuscate and make port filtering more difficult because suddenly DNS uses the same protocol and same port as 99% as your traffic. This is versus DNS-over-TLS that offers the same privacy BUT still uses a DNS-specific port so is easier to detect and block. Of course you can still block by IP...

Other than that, it is exactly the same DNS messages. It's just that they are encoded in HTTP messages.


I think you're right on the money here.

DNS-over-TLS uses port 853, so is trivial to block on a firewall and force fallback to plain-text DNS.

DoH is resilient to such an attacker - be it sketchy guy in starbucks trying to steal your cookies, or yourself trying to run pi-hole adblock.


>or yourself trying to run pi-hole adblock.

If you are smart, at this point you'd have already switched to a DoH server using your own certificate (I use a local AdGuard Home instance for that). You can then point not just your browser (either using its configuration page or group policies) but also the operating system and secure the whole thing. After that your only threat is the same as it has always been, a device bypassing your local server, it is safe to assume those are compromised and should be put behind a firewall or disconnected from the network (it is also safe to assume that a firewall rule to capture and modify its DNS queries has never been a 100% reliable solution).

DoH already happened, there's no point in arguing against it like it's the end of the world as we know it. It's now time to adapt and update (or replace) the blocking mechanisms we are used to using. This may mean the end of pi-hole should they fail to add a DoH server to the default installation but we already have alternatives.


Not sure why you couldn't do TLS over port 53 though, we've had STARTTLS for decades, you can even inform software not to fallback.

The downside is, of course, that Starbucks can't redirect you to their "please accept our TOS" portal.


Either way, as a network admin, DoT is easy to block -- you simply redirect all port 53 traffic to your own DNS. DoT will either fail, or fallback to plain text.

Can't easily block all port 443 traffic (may as well not give any service), and as servers grow maintaining a blacklist of DoH would be problematic - especially when the DoH server is hidden behind normal sites on cloudflare etc.

Of course a sysadmin can always establish a VPN on any port to any IP with TCP, UDP, ICMP, or even running a VPN over unencrypted DNS, and bypass all that network work other than very specific IP whitelisting.

As a network admin and a sysadmin, I want to be able to control my systems from my network without losing control. I like the idea of DoH, I just don't want to have to reconfigure my DoH server everytime I want to connect to a split-brain network, or have an alternative PTR server, and I certainly don't want my browser using a different source for DNS to my other applications.


I'm also a network/server admin.

I don't see things as you do. Specialised protocols are better than generalised ones because they have understandable failure modes.

If DNS goes down, name resolution fails. But if DoH goes down, it could still be DNS, it could be TLS Suites, it could be incorrect headers, it could be mishandling of the proxy (or the proxy forwarding garbage), it could be anything.

that's why we consider DNS to be Layer 6 and not Layer 7, as things on Layer 7 may depend on it.


So DNS is easier to debug? So are many protocols. It doesn't mean we should still be using http, rlogin, or snmpv1.

There are significant benefits to the end user of DoH in bypassing malicious networks. It's out there, it's not going away. I'd like it to integrate well in a situation where I am the user, sysadmin and netadmin.


rlogin -> ssh.

unless you're saying we should replace SSH with HTTP.

And yes, DNS is easier to debug than HTTP if HTTP depends on HTTP.


The problem is that DoT has almost all the drawbacks of DNS from ability to block (and thus fall back to non-TLS dns which can be manipulated), and almost all the drawbacks of DoH (harder to debug). It's the worst of both worlds.

Well at this rate HTTP will simply eat all other things

Port 53 is already used for UDP and TCP DNS, so trying to use it for TLS (over TCP) on top of that would impact existing DNS infrastructure.

The idea of these new transports is not to impact existing DNS.


Is this true? I thought DoH used a JSON format of DNS messages, not the DNS wire format?

It uses the DNS wire format.

It encodes the wire format DNS messages in Base64 for requests and plain hex for responses (rfc8484). That's basically only an adaptation layer to fit into http messages.

Which is good because, really, there is no need to change DNS messages and this makes implementation easier. The aim clearly is to add a new transport for messages with as little impact as possible.


Ah, apparently now (RFC8484) it's standardized to use DNS wireformat, but originally Google DNS implemented "DNS-over-HTTPS" to be JSON[1] on 4/2/16 and added DNS wire format on 6/27/19[2].

Cloudflare also has the JSON format available[3]

[1]: https://groups.google.com/forum/?fromgroups#!topic/public-dn...

[2]: https://groups.google.com/forum/?fromgroups#!topic/public-dn...

[3]: https://developers.cloudflare.com/1.1.1.1/dns-over-https/jso...


It's still DNS - the protocol is the exact same except for some framing. It's just transported over HTTPS.

The only security DoH provides is transport security. if your TLS connection between you and the DoH server is OK, then you can be assured that the DNS response you got has not been tampered with.

It doesn't extend any trust beyond that.


That doesn’t make sense at all. It’s no longer the same protocol if it is framed by another protocol.

You’re talking the protocol frame now, not the original protocol.


That's like saying I'm no longer using HTTP in my browser because my VPN wraps up HTTP in another protocol.

DoH is the simple idea that instead of proxying your DNS request to whatever and whoever is configured by the local network operator, usually the ISP, we will proxy it to google under https if you use chrome or cloudflare if you use firefox. (Technically both browsers allow for this setting to be overwritten)

Once the proxied package arrive at google/cloudflare it is back to normal dns operations.

An other way to see it is that DoH is a https based VPN that the browser has chosen for you, but which only proxy dns traffic.

Fixing the dns protocol is what DoT is for, and especially aDoT which would allow in the future for end-to-end encryption between end user and DNS server. Sadly aDoT is only a draft right now, and there is a lot of resistance to the idea of moving away from the caching proxy model.


This is obviously incorrect, right? Google has ad nauseam repeated that they're not shifting Chrome users to Google DNS, but rather upgrading users to DoH iff their current provider supports it. How does that fact not refute your central claim here?

The central claim is that doh operate identical to the communication between the stub resolver and the recursive resolver, and it is simply the client proxying the resolving request to a third party. The specific transport layer, that of https, is basically irrelevant to the security design of the dns protocol itself which is unaware if it got proxied through https, by unencrypted udp packages, or tunneled through a vpn service.

The default behavor of chrome is to automatically use their DoH service if the users broadband ISP supports it. I don't dispute that or intended to comment on it. If my above comment implied something else I am sorry as that was not the intention nor the central message of the comment. The comment was not a critique of googles default choice in chrome, but rather an attempt to explain how DoH relate to the DNS protocol and how aDoT, which is based on DoT, might actually fix the security faults of the dns protocol by enabling end-to-end encryption between the user and the dns server.


The comment you wrote upthread said literally the opposite, both of what you just wrote here, and of the truth, which is, of course, that Google is not in fact redirecting or proxying DNS requests for Chrome users back to Google.

Good thing then that was not the intent.

Do you have anything to say the aspect of proxying dns to a third party, or the possibility of end-to-end encryption in dns?


I think that DoH and DoT do essentially the same thing, and that the only meaningful difference is that DoT was designed with a kill switch for network operators to overrule applications running on computers. As an owner of a computer, I would rather not give AT&T, let alone a random coffee shop or hotel, the ability to disable my secure lookups; obviously, I think DoH is the better plan. Fortunately, it appears to be roflstomping DoT in the marketplace.

DoH and DoT are both using the design of using a third party that is an caching proxy, and neither allow for end-to-end encryption between the client and the authoritative dns server.

With end-to-end encryption there is no kill switch, so that would make it a rather huge practical difference between aDoT and DoT. It also provide confidentiality which is a much better design for privacy than DoH.

As an owner of an computer, are you against end-to-end encryption for dns, or in favor of end-to-end encryption? You comment above does not answer that question.


It is interesting that people have such negative reaction to the idea of end-to-end encryption in dns. I can think of very few other technical areas where having secure communication between the client and server without the involvement of third parties is seen as something bad and who ever suggest it should be shunned.

Given how that is, I wonder how people would react to the idea of using even stronger security like off-the-Record Messaging.


I didn't downvote your comment, because I couldn't even understand it. You advocated for DoT (and extensions to it). I pointed out that DoT and DoH are the same thing. You came back with a non-sequitur about end-to-end encryption.

I am advocating for aDoT, which is not DoT. The "a" letter in the beginning is an important distinction and stands for (a)uthoritative and aDoT is an early rfc draft about communication between a resolver and an authoritative server.

To explain the terminology I use I can source the definitions from RFC 1034. We have "stub", "recursive", and "authoritative" resolvers. A stub resolver sits at clients because in 1987 not every computer had enough computer resources to run a recursive resolver themselves, and stub resolver talks exclusively to recursive resolvers. Recursive resolvers iterative talks to authoritative servers in order to resolve a domain name into a resource record (ip addresses, text, alias and so on), and the recursive resolver return the results to the stub resolver or the computer that host it.

As the RFC specify, there was original two reasons why a machine may want to have a stub resolver and use someone else recursive resolver. One is the above reason that stub resolvers can be used on machines that do not have the computer resources to run a resolver. The second is in order to "centralize the cache for a whole local network or organization.". The preferred way as specified by the RFC is to do the recursive resolving on all machines, but if you want a centralized cache or have machines that do not have enough in terms of 1987 computer resources then there is a option to use a stub resolver.

DoH and DoT is technology to encrypt the traffic between the stub resolver and the recursive resolver. Neither can be used if one follow the recommendation and operate the recursive resolver yourself. DNS between recursive resolving and the authoritative server is in plain text. aDoT fixes this, allowing for encrypted traffic between the recursive resolving and authoritative server. When a client who runs its own recursive resolver can create a encrypted channel between it and the authoritative server, what we have is end-to-end encryption.

If there is a technical concept here you don't under just let me know and I can try to explain it further.


I'm familiar. Obviously, over the long term, DoH is going to make its way to authority services, and subsume the legacy plaintext service. Maybe, because nobody has a strong interest in anti-censorship in recursor-to-authority communications, it'll even be DoT between cache and authority servers; I don't care (though it will be silly to have two different transports for the same fundamental transaction).

Isnt this something the OS should handle and Chrome just uses the OS interfaces for this?

Isn't TLS 1.3 something OS should provide?

Isn't QUIC something an OS should provide?

Isn't the OS responsible for preventing antivirus software installing insecure browser plugins?

Isn't the OS responsible for process sandboxing?

Isn't the OS responsible for secure font rendering?

Isn't the OS responsible for shipping with decent optimized image and movie decoding libraries?

The innovation must be pushed somewhere. These days it's being pushed by the browser vendors and not OS vendors.


Yep and not saying its entirely wrong, but check my reply to asdf-asdf-asdf.

in theory, yes.

the problem is, how can chrome+firefox persuade microsoft, apple, debian and redhat to add it? and how long will that take? maybe some of them don't want it at all.

with the current approach they can offer this improvement to their user right now.


I understand that, but what Im concerned about is Chrome or Firefox or etc skipping my OS settings and preferences. Like they already do in some cases.

Internet Explorer had tight coupling with OS.

It should teach that Evergreen Browser requires Evergreen OS. And there is long tail.

Windows XP (2001) support:

* Internet Explorer 8 (2009) * Chrome 49 (2016) * Firefox 52 (2017)

IE supported latest versions only, should have been most integrated and now it's dead.


This has echoes of MS SQL Server (and maybe others) where there's an argument to built a miniature operating system within RDBMS for technical reasons.

Given that whole UI and windowing toolkits are moving into the browser, that argument of replacing chunks of the OS, from top to bottom, starts to become more relevant (if not more comfortable).

And then the next step could be to have Google as a compulsory proxy for all web traffic, because of government blocks.


It's available in the newest Windows 10 Insiders build.

The subsequent SSL requests still include the host in clear text, so while a move in the right direction, does little to stop request sniffing.

Right now yes, but when Encrypted SNI is adopted then not anymore.

It seems that when DoH and ESNI become the defaults there won't be much sniffing going on? (Apart from looking at the IPs of course.)


Star or thumbs up these issues if you want ESNI to be prioritized more:

https://bugs.chromium.org/p/chromium/issues/detail?id=908132

https://github.com/openssl/openssl/issues/7482


Exposing the host if often not that much of a problem in my opinion. I doubt if there are any solutions to obfuscate the host, since packages just need to be routed somewhere. At least it wouldn't be a DNS problem, since for IP the same restrictions apply.

You still ultimately will be exposing server you're talking to by ip, right?

No, they only include the DNS server name in cleartext. (Unless I’m misunderstanding DoH)

The lookup is encrypted yes. Your actual subsequent request to the webserver you looked up the DNS entry for however exposes the host in clear text. This is how a lot of corporate firewalls sniff HTTPS requests for host without a root cert.

https://security.stackexchange.com/questions/86723/why-do-ht...


If you enable it in about:config, Firefox does support the Encrypted SNI proposal when used with DoH and providers that support it. It works for me on Firefox for Android.

https://blog.cloudflare.com/encrypted-sni/

Disclaimer: I work for Cloudflare, but not on this project.


ESNI is a great solution but unlike DoH it has yet to see wider adoption. I have it enabled and I have Firefox pointed to my local DoH server, the majority of the websites still reply with NXDOMAIN to the _esni query. Besides Cloudflare I've only found 1 other website that has it enabled.

I wonder in what new ways will ISPs start blocking illegal websites.

Isn't the most common way to block "illegal websites" just to block it on the DNS owned by the ISP? (which is the one you will automatically use unless you configure something else). And just making their domain point to some website saying the site is blocked. Afaik this will still work. And the normal workaround of just changing to a different DNS should work aswell.

Is sniffing of traffic common in other countries?


I don't know about other countries, but this never worked in Kazakhstan. They block whole IP ranges and your traffic silently gets dropped. I'm sure that having a single monopolistic ISP helps with implementing this.

I think that this change would mean that, by default, the DNS server used will be specified by Google/Chrome team. If the DNS server were still my router then there's no point to this really.

> the DNS server used will be specified by Google/Chrome team

I don't think that any oppressive regime is going to have any qualms about routing 8.8.8.8 to its own server, or just blocking it. So you use the national DNS or get nothing.


Can't wait for Google to be named "Internet Villians" like Mozilla because GCHQ got salty they can't slurp DNS traffic.

It wasn't GCHQ, it was UK ISPs:

* https://www.theregister.co.uk/2019/07/06/mozilla_ukisp_valla...

They have (had?) a requirement to block certain sites (e.g., CP), and their CEOs could be sent to jail if they didn't. So from their perspective, Mozilla was not doing a good thing as it was causing them grief in being able to follow the law:

> for their proposed approach to introduce DNS-over-HTTPS in such a way as to bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK

* https://www.ispa.org.uk/ispa-announces-finalists-for-2019-in...

So yeah, I can understand why they'd be salty. As someone who works in IT I'm also salty at DoH for similar netsec reasons. (DoT is another matter.)


> It wasn't GCHQ, it was UK ISPs

With UK laws it's close enough.


Blackhole routing. You setup a /dev/null router with BGP and advertise the IPs you want unreachable, and things get dropped at the network edge.

IMHO, DoH will simply have network operators go from having a light touch on the network with DNS filtering, to a much heavier hand with routing and inspection. Because the regimes and laws that are currently in place won't just magically go away. (Thanks Mozilla.)


The intent is that collateral damage from such actions is so enormous that they become unthinkable. "We'll just block all of Cloudflare's IPs" is like "We'll just ban all Chinese products". OK, so now your economy is in ruins, what next?

China's great firewall for example degrades access to some popular web sites, but it doesn't do a lot of IP blackholing because that hurts China more than they'd like.


They don't have to block all of Cloudflare's IPs. First they block 1.1.1.1 so that DoH doesn't work, then they look at" 'nown bad' domains and see to what they resolve to and start with those.

If there's collateral damage to some other sites, then depending on the 'importance' of that they want to block--oh well.


The idea that authoritarian regimes will just say "ohhh know it is cloudflare" and then back down is extreme naive

More likely they will just force Cloudflare to do their censorship for them, which cloudflare has already been proven to be malleable toward


I doubt they would do blackhole routing, they risk blocking IPs from cloud providers like AWS, Azure and GCP.

Perhaps it's a little naive of me to think that ISP and government would consider that they might block and IP that's only going to do something "illegal" for a short while and the be recycled for something else.


Couldn't they just block the IP? Sure, it's easier to get a new IP than a new URL, but still?

When a good chunk of websites are behind Cloudflare, hosted on AWS or on another cloud platform, the IP is increasingly useless.

In Turkey, It's DNS + IP blocking. There are rumours for slowing down certain connections, especially social media stuff when something sensational happens.

More actually. Many levels of blocking exist but not all actively used. Different websites are blocked using different methods at different levels.

Correct. However, I believe it's not because the government mandated it. The same website could be blocked differently on different ISPs. For example, when Wikipedia was blocked it was not possible to access it without a VPN from Kablonet but a simple DNS provider change was enough on TurkNET.

Turkcell implements the most powerful censorship and Turk Telecom has the most sophisticated censorship infrastructure in Turkey.

what's the difference between powerful and sophisticated censorship mechanisms?

The sophisticated one is distributed and also more resilient against workarounds, the powerful one is centralised yet has the ability to process most requests per unit time without visible degradation on connection speed and latency.

Does this ignore the os hostfile like Firefox's DoH does?

I use PiHole with a DoH upstream. I want all devices on my network to use my DNS server. Mozilla's implementation is easily managed using their canary domain "use-application-dns.net" but Google doesn't have this option. I do not want any queries sent to Google. It is not feasible to manage chrome flags on every device, especially mobiles. Does anyone know if Chrome will be using their two public IP's, 8.8.8.8 and 8.8.4.4 for this new DoH service? If that is the case this will be easy to block at the network level. Thanks.

Chrome Enterprise (which, contrary to what the name might suggest, is not a paid enterprise offering) offers management tooling for managing flags across many devices. Here's the flag for DoH: https://cloud.google.com/docs/chrome-enterprise/policies/?po...

but Chrome Enterprise means it has to connect and phone home to Google all the time anyway, no? That defeats any potential benefit of having more control over the browser.

Given this is a "free" offering, the data being mined finances this service.


If parent wants to manage Chrome configuration across N devices, Chrome Enterprise is a good tool for the job. They may or may not care if their data is on Google servers or not. They might consider these two items to be two entirely distinct and different benefits.

If parent wants to avoid having any of their data cross Google machines, you are completely correct that Chrome is the wrong tool for the job.


Have you considered just blocking outgoing on port 53 on your network? There are a few too many devices out there that have hardcoded DNS and don't respect the resolver communicated to it. (Chromecast is an easy example.)

Yes, 53 is allowed only to pihole and dropped everywhere else. I just blocked 853 on each pfsense interface. I will see how it acts when I get off work.

I think they say in the article

Is this a scheme from adcompanies like Google to circumvent Pi-hole?

Maybe not. Dns over http makes it easy to use for example http://nextdns.io which is nice alternative for Pi-hole (and more convenient IMHO).

I think this is mostly against ISPs who would like to mess with/redirect your traffic (for example show their own page for mistyped URLs).


Pi-hole can just support DoH as well, this doesn't really change anything in terms of adblocking.

FWIW, this seems to be the GPO that controls DoH

https://cloud.google.com/docs/chrome-enterprise/policies/?po...

I was looking for this as I want to explicitly control when I choose to enable DoH.


it still obeys HOSTS right? have to assume that's a must

eta: oh interesting, at some point I turned on "managed" to prevent it from password cloud saving or some other nuisance and now I get this:

      Use secure DNS
          This setting is disabled on managed browsers

So if I wanted to keep analytic data of where my users are going, should I set up my own office DoH server and forward requests to an external DoH? Would I be able to then use our in house DoH and get analytics from that?

Running version 83.0.4103.61 but I don't see the DoH-related entries in Chrome Settings. Is this still in a phased rollout?

Option is visible under chrome://flags/#dns-over-https flag. However on Ubuntu 18.04 I've the message: "Not available on your platform.".

Same here, same version. I also do not have the new Safety Check described here: https://www.blog.google/products/chrome/more-intuitive-priva...

How will that affect things like pi-hole?

See: https://github.com/notracking/hosts-blocklists#dns-over-http... how Mozilla deals with this.

For Chrome this feature seems not to be implemented, making it harder to control your DNS behavior in your own network. (see Q&A at the bottom of the page) https://sites.google.com/a/chromium.org/dev/developers/dns-o...


I have Pi-Hole configured to use DoT for it’s outgoing DNS requests in a home network with a DNS server you trust using DoT internally is arguably less important.

I’ll be looking to see if what configuration options are available and if I can set up a DoT server on the Pi-Hole.

Ideally I would want at least the ability to set DoT on/off by default based on the network I’m using so if it’s the home network I don’t care but all other networks I would like to have DoT as the default option.

It would also be interesting to see if there is a default fallback unto standard DNS or not.


Setting up recursive dns with unbound on the pi-hole

https://docs.pi-hole.net/guides/unbound/


i'd rather have https over dns, to deal with wifi portals.

So, then google get to decice what web sites that even exist in your universe. Nice played.

Chrome checks if the DNS server configured supports DoH, and if yes uses DoH to talk to it. How exactly does that mean that

> google get to decice what web sites that even exist in your universe.


I see you read the article... \s

Choose another DNS server.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: