Hacker News new | past | comments | ask | show | jobs | submit login
Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims (technitium.com)
50 points by shreyasonline 16 days ago | hide | past | web | favorite | 66 comments



Part of Paul Vixie’s argument is that DNS is part of the control plane, and that DoH will bypass security policy. Let’s at least address this with some skepticism.

1. Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass.

2. While this can be true, it’s not actually anything to do with the way DoH works. You could just as easily choose to only upgrade to DoH when the DNS provider of your choosing happens to support it.

3. Home internet is not new or uncommon. 76% of the US has internet access according to a cursory Google search. A vast, vast majority of these users are casual users. The control plane is not under their control necessarily. The control plane is not something that can just absolutely be trusted.

With much respect, I simply must disagree. The notion that DoH is dangerous feels like it comes from a dated view of internet security, and it only reflects the mode of rollout where application software indiscriminately uses a DoH server in place of the user’s default DNS server.

Further, this article has a lot of interesting claims. It claims that many websites are still not running over TLS even though it’s free. Of course, this is undoubtedly true and reflected in statistics. However, is it true in a realistic sense? How many non-HTTPS pages do you browse?

Thanks to Cloudflare and other actors, I suspect ESNI will have no trouble gaining meaningful marketshare. Not full proliferation. We don’t need full proliferation for it to be useful, though.


In reality what's happening is a conflict between the security goals of network operators and those of end-users. Vixie, who runs a company that provides security services based on passively observing DNS, believes DoH sacrifices the security of networks in favor of end-users, and he's right. But:

1. In most situations, the end-users are the ones that matter; the cart shouldn't drag the horse.

2. In situations where that doesn't hold, serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways; why should anybody give anything up to make things easier for enterprises who are just a bit concerned about security, but not enough to take responsibility for endpoint security?


>DoH sacrifices the security of networks in favor of end-users

I agree, if you are considering the approach of just using an arbitrary DoH server. But I think it would be nice if people would at least acknowledge that this is not a fault of DoH. One could envision a future where local DNS servers could support DoH. I don't know how far away from reality this is, though.

If this is somehow a fault of DoH, I apologize for my misunderstanding. I admittedly haven't read the full standard.

>serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways

Thank you, this is precisely what I was thinking.


It's not at all a fault of DoH, since preventing "control plane operators" from coercing end-users into giving up their privacy is DoH's primary goal.


End users are not coerced by operators, they are the operators on their own devices and can do whatever the hell they want. The primary goal of DoH as proposed and implemented is to take away that ability from end users, hide that control from them. It's nothing more but malicious anti-user behavior.


This is obviously false.


> Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass.

That's assuming the clients and the network are adversarial to each other. Consider that the local DNS resolver may be blocking domains associated with malware or ads, which the client wants for it to do, and then changing the default DNS from the one configured via DHCP results in clients getting malware and ads they didn't want.

> While this can be true, it’s not actually anything to do with the way DoH works. You could just as easily choose to only upgrade to DoH when the DNS provider of your choosing happens to support it.

The major criticism of DoH is Firefox enabling it by default and overriding the existing system DNS configuration, requiring manual reconfiguration of arbitrarily many client devices to change it back to the way it was. There can obviously be no legitimate objection to it if it is disabled by default and only used when explicitly enabled by the user.

> Home internet is not new or uncommon. 76% of the US has internet access according to a cursory Google search. A vast, vast majority of these users are casual users. The control plane is not under their control necessarily. The control plane is not something that can just absolutely be trusted.

This is a great argument for making DoH/DoT/DNSCurve/etc. the default configuration for the builtin resolver in home internet routers. Which thereby solves the problem without introducing a new one where if you want to change the default it requires reconfiguring arbitrarily many separate applications on every individual client device, because in that case you can still configure the DNS for the local network in one location.


"The major criticism of DoH is Firefox enabling it by default and overriding the existing system DNS configuration, requiring manual reconfiguration of arbitrarily many client devices to change it back to the way it was. There can obviously be no legitimate objection to it if it is disabled by default and only used when explicitly enabled by the user."

+1 Firefox should also consider that such network settings are only accessible to root or administrators such that organizations can maintain network policies for the devices they own in their network.


Adversarial networks are the common case.

In the other cases, where DNS is being used as a legitimate policy vector, the entity enforcing that policy should also have endpoint control, which they can use either to re-establish network policy (by disabling DoH) or to enforce policy more reliably at the endpoint layer.


Adversarial networks are not the common case. On the majority of networks you can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will actually interfere with it in practice.

Adversarial networks exist, which is why something like DoH or DNSCurve should be used in favor of unauthenticated DNS over the internet, but the real issue here is independent of which DNS protocol is used -- it's how the recursive resolver is chosen.

The canonical answer to that is to use DHCP or similar to distribute the resolver that should be used for the local network, and allow the user to manually configure a different one in any case where that one is untrustworthy. DHCP is the ordinary method of endpoint control for configuring the endpoint's DNS server.

The endpoint shouldn't have to be exposed to manual configuration or give up even more control over other unrelated settings by adding their device to something like a third party Active Directory domain just to be able to plug into a local network and have local name resolution work.


Your threat model isn't the set of actors currently attacking you, but rather those actors who can and might attack you in the future. Your ISP is certainly adversarial in any sane threat model.


Aren't you the one usually telling everyone that DNSSEC is useless even though it solves the same problem, e.g. because the server can be verified with TLS instead? If the DNS attack is nothing more than a denial of service then it seems completely reasonable to wait until the attack is actually observed before applying a mitigation (third party DNS) that can have problematic side effects. Especially when the mitigation can be made as simple as a single checkbox in the browser.

And what makes Cloudflare any more trustworthy than the average ISP? Isn't that just switching the user's resolver from the network they explicitly chose to connect to, to a centralized third party that they didn't?


DNSSEC doesn't solve any practical problem, but does have the effect of escrowing TLS keys to world governments. DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem.

You don't have to use Cloud Flare for DoH, and I wouldn't.


> DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem.

That's assuming the DoH provider isn't monitoring queries either. Doesn't Cloudflare have a deal with APNIC to do exactly that?

> You don't have to use Cloud Flare for DoH, and I wouldn't.

That's the point -- the problem isn't that DoH exists, it's when an application changes your DNS provider to Cloudflare by default instead of using the one you have in your system configuration.


You can trivially boot up your own DoH provider if you don't trust any of the existing ones. It's hard to imagine a protocol that would improve this situation: "supported by major vendors, and free to use for everyone".

I won't use Firefox to begin with (I'll reconsider when it's mostly Rust!), and so don't care so much about how Mozilla is handling this. Personally, I wouldn't touch Cloud Flare with a 10 foot pole. But that's not what I'm commenting about; I'm talking about DoH itself, which is an unalloyed good thing, which you can tell in part by the fact that the knives are out for it.


"Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass."

Same argument can be done for firewall that filters traffic using IP addresses. In the same words, it can be said that, if your firewall security policy can be defeated by using VPN, its evidently not very hard to bypass.

Just like firewall is useful for security, so is DNS based policies.

Cloudflare is doing good job but, the concern is centralization. Its not going to be good to have most internet resources being resolved via Cloudflare DoH, then accessed via Cloudflare CDN.

ESNI will take a lot of time to gain meaningful market share. There are people still arguing that their website does not need to use HTTPS since they are just a static website or do not have login/user data. Such people completely fail to understand that HTTPS is not to protect them but to their end users from MiTM script injection attacks.


> The control plane is not under their control necessarily.

It is. They can even install a VPN everywhere they want, that's how much control they have. DoH wants to take it away.

> I suspect ESNI will have no trouble gaining meaningful marketshare.

You have not been paying attention. Those same organizations removed the exact ability esni proposes once governments applied a bit of pressure on them (I'm talking about collateral freedom domain fronting thing).


> It is. They can even install a VPN everywhere they want, that's how much control they have. DoH wants to take it away.

The network control plane is not on the end user’s computer. For a home network, this is probably their ISPs modem, followed their ISPs actual edge. You could opt to set up your own DNS server or use an alternate DNS server, which is bypassing the control plane, assuming your ISP doesn’t force you to use their restrictive equipment.

The difference between DoH and regular DNS here is that even if you choose another resolver, unencrypted DNS can still be intercepted, logged, and modified by the control plane; many providers have been doing this to monetize NX DOMAIN responses even when the user is using another DNS resolver. I first realized this when attempting to get rid of annoying NX DOMAIN search SPAM pages on my phone years ago... That is precisely why this issue is coming up now and not earlier when cleartext alternate DNS resolvers gained some popularity.

> DoH wants to take it away.

What does DoH take away? You can still configure your resolver today.

> You have not been paying attention. Those same organizations removed the exact ability esni proposes once governments applied a bit of pressure on them (I'm talking about collateral freedom domain fronting thing).

What have providers removed from ESNI?


> which is bypassing the control plane

This is not bypassing the control plane, this is the control plane. Each device is essentially its own network that connects to other networks. This is how operating systems work today.

> You can still configure your resolver today.

Yes, because of people who pushed back Mozilla.


Do you have an argument that would be persuasive to people not in the alternate universe where resolvers weren't configurable?


Even if Mozilla did make Cloudflare DoH mandatory, which to be honest is ridiculous and not a real thing that was ever happening, it’s not as if you have to use Firefox.


The claim that DoH will interfere with internal DNS of enterprises can be solved with a local deployment of a recursive DoH server right? That also addresses the concern of centralisation. Imagine every ISP offering a DoH sever... so now Cloudflare will not be in a position to scoop up the entire DNS data of the Internet.

I'm still waiting to see a genuinely technical disadvantage of DoH. All that I've read so far are social and implementation related issues that can be ironed out over time.


The thing that is still being ignored is the configuration mechanism for the DoH resolver.

Currently, the only way to configure it is manual and application-specific; there's no way to configure it for all apps and automatically, like DHCP for the normal, 53/udp DNS. Nobody is going to manually reconfigure their DNS every time they switch network (e.g. home -> office -> customer).


Currently, the only way to configure DoH for everything is one-time setting local dnscrypt-proxy as the only resolver. Easy on Android 9+ and Linux with systemd, on Windows you have to override DNS settings for all NICs because it has a weird process of resolving. Don't know about macOS, iOS is definitely out.

edit P.S: I'd never trust ISP's DNS servers, because it's the easiest way to track what customers does.


For iOS, you can check out DNSCloak, Adguard, NextDNS, Cloudflare 1.1.1.1, etc. which are all system wide resolver.


I may trust Comcast as far as I can throw them. I still prefer that they get my data, rather than even more of my browsing data go straight to Google.


The point of DoH is that you don't have to send your DNS queries to either of those entities.


Is DHCP useful to enforce network policy? What about users who manually set their DNS servers?

Wouldn't be a proxy checking the SNI of connections you open better?


Enforcement is step 2. Proxy with a blacklist of hostnames would do, but unfortunately, with encrypted SNIs on the horizon, full blown https proxy with custom CA enrolled on all machines would be necessary.

Step 1 is a mechanism for those, who do not want to fight the network policy, just want the autoconfiguration.


Why DoH and not DoT? DoT be much more suitable and provides same set of guarantees since both are essentially using TLS. DoH provides only one extra thing that is to make it difficult to block. If you run DoT over port 443 then it essentially becomes same as DoH in terms of difficult to block.


> to see a genuinely technical disadvantage of DoH

Lack of privacy issue aside, there are a bunch of technical disadvantages compared to alternatives. Like using encryption to a local resolver or to a resolver over trusted or encrypted network is unnecessary overhead and complexity, including operational complexity that you really want to avoid. And if there is a case to use encrypted communications with a recursive resolver (i.e. non local), it could be done by simply tunneling DNS protocol over any of existing crypto protocols, no need for yet another complex protocol tunneled over https that still has to be converted to a native DNS protocol down the line.


I’d prefer not to “trust” any network, even my local home network, and encrypt all the traffic traveling over it I can. especially in an age where a security camera or even your fridge can be compromised by non-targeted automated scripts and then all plaintext traffic on your network is exposed.

As for not using TLS/http to wrap the dns queries for secure transport across the net, what “existing crypto protocol” do you suggest they should have implemented instead?


I do sometimes use firefox and I found the canary hostname, linked in the article, to be a good tip:

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

My home network has a DNS server that already talks to the outside DNS servers with TLS, so having browsers reach out to cloudflare would prevent cross-device caching and only protect against snooping on my LAN or wifi, which I don't find to be very necessary. So I just made this domain return NXDOMAIN.


> DNS is one important control planes in a network. It essentially allows network administrators to block content based on domain names making it quite useful tool in the arsenal. It is being widely used to provide content filtering services, parental controls, and to block known malware command and control. Its so popular that a lot of people install a locally running DNS server on their home networks to block Internet Ads using block lists.

This is a totally wrong usage of DNS and I wish we would focus more effort into making IP-based blocking easy and accessible rather than wasting time trying to make DNS fit this niche. DNS is not the right tool for this job and maintaining this functionality is not a valid reason to block progress on more private technologies like DoH. And it's totally possible to run a PiHole-style system using DoH anyway.


I'm not convinced IP-based blocking can be more effective than DNS blocking. Very often many different sites are hosted on one IP address (e.g. a CDN in the 'worst' case), and IP blocking would mean lots of things become inaccessible.

Users access services by DNS name, so if you want to control access it has to be at that level. Whether DNS can be effectively blocked while maintaining privacy is another issue, but I can't see IP-based blocking helping here.


In my opinion, both DNS- and IP-based blocking are a hack because they fundamentally have to work based on limited information. After all, ad services could pretty easily start doing any of the following:

- proxying ad requests through the server of the website you're visiting;

- accessing ads by IP address directly; or

- using randomly generated domain names.

With a browser-based ad blocker, those measures would still be an obstacle, but at least you'd have a chance - you could switch to more heuristic ways of detecting ads based on, say, the scripts involved, or the content of the media being downloaded, or its size and placement on the page. None of that information is available to network-based blockers, at least not when HTTPS is in use.

Admittedly, those things probably won't happen anytime soon, at least not for regular website ads. (Though as one example, Twitch has already started using fairly sophisticated measures to bypass ad blockers for their video ads...) But I'm an idealist, and I like to fight on favorable territory. When it comes to cat and mouse games, I don't want to be the mouse.


I agree, CF allows porn and blocking every Cloudflare site isn't a viable course of action for most people. Governments like UK that mandate restricting access shouldn't be doing it for you by DPI'ing DNS.

Instead, any blocking needs to be done on the device, whether it be MDM for any business-related blocking or via Parental Controls/Restrictions for blocking porn.


IP blocking (or whitelisting) is useless when your target lives in the cloud. Many CDNs have a massive pool of IPs which change rapidly. Autoscaling systems have TTLs as low as 60 seconds. Not only will you fail to block (or allow) requests, but you will also block (or allow) requests to completely different organizations on the same multi-tenant cloud environment.


Same can be said about IP-based blocking that firewalls employ. IP-based blocking can also be bypassed by using various tunneling techniques but that does not make it useless. Having DNS based control in addition to IP-based control is much useful for most scenarios.


I like Chrome's approach to DoH. If the local DNS server is capable of DoH, then, and only then, Chrome switches to DoH. It is the safest choice to make, since if you are querying that name server, they have your data anyway, so you might as well encrypt it in transit.


Chrome has a short list of known DoH servers that it will use, and they are all public cloud DNS providers so it will not use your local DoH server. https://www.chromium.org/developers/dns-over-https


i am very avidly opposes to DoH because it doesn’t solve the problem people think it does. and it further entrenches cloudflare, who imho are vile but that aside the concentration isn’t a good thing.

however, your statement is wrong.

i won’t go further into detail because my comments on this subject universally attract all the downvotes so there’s no point. but in general the problem is you need to qualify “safest”. safest for what and for whom, and in what scenarios? you’ve left too much unsaid, so what you say is not generally true.


This comment says very little; you don't explain what problem people think DoH solves, won't go into detail on why the statement is wrong, nor why not qualifying "safest" makes it not generally true.

At least a comment that attracts downvotes may be useful to someone.


How would chrome know whether getaddrinfo() uses DoH to resolve a host?


Anyone can link to their own getaddrinfo(), including an internal function, they don't have to use one from whichever libc happens to be laying around on the system.

In theirs, they read the DNS servers from the OS (like the original), and then if it's part of a list of known DoH providers, they try to connect over DoH before falling back to regular DNS queries.


First, I know nothing about DoH, so take this with a grain of salt.

They should look up a canary domain that doesn't resolve from the roots, but local sites can configure to provide the address of a DoH resolver. Then you don't need to have a list of known DoH providers-- any site can install a DoH resolver and then add the canary domain to allow clients to upgrade.

It'd still be vulnerable to MITM attacks on initial connect, but at least the window for them is closed after the first resolution with this approach (better than normal DNS).


For reference, the code that does the protocol upgrade: https://github.com/chromium/chromium/blob/711b1ba2735f8af4bd...


That would mean bypassing OS configuration, including other naming sources then DNS.


Yes, and if you search for "Chrome DNS client", people have reported problems related to that.


My fear is that platforms start using DoH, bypassing local dns privacy resolver such as pihole, for tracking purpose. I have a nVidia Shield and I can see how many requests to tracking domains it does and if nVidia or Google uses DoH, I will not be able to block those requests.


Can anyone explain why DoH was invented? To me it seems like another one of the "let's solve this using web technologies!" Whereas DoT has a great ietf process behind it.


Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS).

Virtually all the opposition to DoH is rooted in two complaints:

1. It centralizes DNS at Cloudflare (obviously, you can point DoH elsewhere).

2. It's hard for network operators to block it (which is the point).


The biggest complaint I have regarding DoH is that it's extremely painful to configure because every application does it individually.

If I could configure DoH at the system level, as I do normal DNS, I'd be perfectly happy. As it stands, DoH could trivially be co-opted by browser vendors to ignore system DNS settings, and even if it isn't, it still makes DNS configuration a worse experience.


This seems a lot more like a complaint about your libc than about DoH. But the response to that complaint would likely be "give it time".


You can do this on Android Pie and newer, but the overall rollout on other systems might be held up due to the potential issues with enterprises not being happy that their DNS systems are no longer working (and that this is probably far from having priority P0).


> you can point DoH elsewhere

That only fixes the "Cloudflare" problem. It still centralize all DNS traffic onto a single service. I cannot configure Firefox to send packets only to the (hypothetically DoH capable) delegated nameserver(s) for each domain.

When you run your own recursive resolver (which is easy), only the lookup of the NS delegations needs to use a centralized service. This is relatively infrequent (NS records rarely use a very short TTL), so regular (TTL-respecting) caching prevents the centralized service from learning your pattern-of-life.

The DNS traffic for the A/AAAA records[1] is very different. Short TTLs are commonly used to force a DNS check every few minutes. In practice, this means a user's aggregate DNS traffic contains a very good pattern-of-life about the services they use and when they use them. When you run your own recursive resolver, nobody can learn the entire pattern-of-life; the traffic is distributed to different servers for each domain delegation.


Running your own recursive resolver on your own machine doesn't address DNS privacy; in fact, it does the opposite, making your DNS lookups even more attributable. Of course, you can run your own resolver on a network somewhere else, and then DoH to it, but then you're just making my point for me.


> making your DNS lookups even more attributable

That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recursive resolution locally.

It seems like you're only considering privacy at the protocol level. While that's important, it can eventually be fixed with improved protocols. I'm far more concerned about de facto standardizing on requiring a centralized service that necessarily has access to the plaintext DNS traffic. The only way to prevent logging of the user's entire internet pattern-of-life is to not give the entire pattern to a single entity.

To be clear: we should be updating all plaintext protocols with encryption/etc. Both DoT and DoH can help achieve that goal. Some sort of encrypted protocol is needed even when running a recursive resolver (such as DoT). It would also be great if popular OS had built-in support for running a local recursive resolver, OS-level support for DoH/DoT, and other advanced features.


DoH is the improved protocol. There's nothing "centralized" about it; you can run a DoH cache server anywhere you want.

The only reason anyone advocates DoT is because network operators can block it, forcing people to use plaintext DNS. Somehow, the meme has been created that DoT is somehow better or more privacy-respecting than DoH, but that's obviously false.


> DoH is the improved protocol.

That doesn't appear to be true, according to RFC 8484. DoH cannot be used for encrypting communication to domain-delegated nameservers. Running your own DoH server just moves the problem to a different host. If I run a DoH server locally as a recursive resolver, the encryption between the browser and the DoH server is useless. The DoH server still sends the requests to domain-delegated nameservers in plaintext.

The protocol is explicitly[1] focused:

    on communication between DNS clients (such as operating
    system stub resolvers) and recursive resolvers.
The RFC doesn't provide any method to discover the "URI Template" of a domain's authoritative DoH server. The existing NS records only[2] include a domain name. This omitted feature appears to be intentional; RFC 8484 only says[3] that configuration of the "URI Template":

    might be manual (such as a user typing URI Templates in
    a user interface for "options") or automatic (such as
    URI Templates being supplied in responses from DHCP or
    similar protocols).
Even worse, the protocol seems to require[3] aggregating all requests through a single DoH server:

    A DoH client MUST NOT use a different URI simply because
    it was discovered outside of the client's configuration
That seems to forbid the fundamental idea of discovering delegated nameservers. Why would a core feature of DNS be forbidden? Apparently from a concern[3] that allowing unrecognized URIs:

    may create additional operational, tracking, and security
    hazards that require limitations for safe usage. 
This is a strange concern. If the user wants to perform a DNS request, that's their business. How would this become a "tracking [or] security hazard"? This concern seems to be a consequence of a design goal for DoH:

    Two primary use cases were considered during this protocol's
    development.  These use cases are [...] allowing web applications
    to access DNS information via existing browser APIs in a safe way
    consistent with Cross Origin Resource Sharing (CORS)
DoH is designed to enable performing DNS requests in a web app (which will probably be yet another API I will need to disable). If I'm mistaken and it is possible to use DoH in a recursive resolver, how would that work?

> There's nothing "centralized" about it

Requiring that a client "MUST NOT use a different URI" is the very definition of a "centralized" protocol. Moving to DoH from my existing local recursive resolver would be a huge loss of privacy. If there a way DoH can compartmentalize DNS requests to the domain specific nameservers, I would like to know how.

[1] https://tools.ietf.org/html/rfc8484#section-1

[2] https://tools.ietf.org/html/rfc1035#section-3.3.11

[3] https://tools.ietf.org/html/rfc8484#section-3


Blocking the vast majority of DoH services should be pretty easy, just like with regular DNS. I block a lot of DNS servers that aren't my own. Not all of course, but enough to not have any outgoing requests on port 53.


It's difficult to block in the general case, though, without reterminating TLS.


My guess is that networks can block the DoT ports to force fallback to plaintext DNS. Whereas DoH looks indistinguishable to HTTPS traffic so it’s harder to block.


For people concerned with Firefox's use of cloudflare, it's very easy to configure an alternative DoH if you have one you prefer. You can do so via network prefs or about:config (the key is "network.trr.resolvers")


I haven't though much about this problem, but I'm curious why none of the solutions employ DTLS. Is UDP just pointless in this context?


DOH has the possibility to leverage the wrong parties against encryption. There needs to be a barrier of control.




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

Search: