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.
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.
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.
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?
Literally all this does is break things.
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.
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.
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.
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.
I'd prefer dnscrypt (https://en.wikipedia.org/wiki/DNSCrypt). I'm still not sure why we're going with DoH instead of dnscrypt.
TLS does that part. HTTPS solved/worked around a lot of web problems (same-origin policy) that don't apply to DNS.
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.
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.
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.
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.
For 95% of users, DoH just lets Google monetize the lookups, instead.
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.
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.
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.
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.
The downside is, of course, that Starbucks can't redirect you to their "please accept our TOS" portal.
The idea of these new transports is not to impact existing DNS.
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 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.
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.
unless you're saying we should replace SSH with HTTP.
And yes, DNS is easier to debug than HTTP if HTTP depends on HTTP.
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.
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.
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...
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.
You’re talking the protocol frame now, not the original protocol.
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.
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.
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?
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.
Given how that is, I wonder how people would react to the idea of using even stronger security like off-the-Record Messaging.
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.