I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS was discussed:
(full disclosure: I'm affiliated to Cloudflare, but opinions here are my own of course)
Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that).
Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi-hole. Network at work is managed by yet-someone-else. I often use my mobile carrier (LTE tethering), and often use WiFi at coffee shops.
For all of these cases I would prefer to not expose my DNS traffic. Heck, I'm 100% sure that my dns traffic today is being re-sold! I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party.
Many DNS people are opposed DoH, but I think this train has passed. As a user of the internet I really do want encrypt everything these days.
https://tools.ietf.org/html/rfc8404
If my corporate boss, or my ISP can mine less data about the malware I'm running - so be it. For me this is an acceptable cost of measurably improved privacy.
> I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party.
Not true.
They may be connecting directly by IP (it's typically not possible to determine if they did just from access logs). The web (or other application) server may also leak the name when connected to.
If you use TLS, which is likely, your domain names would leak through the certificate transparency logs.
...and there are surely more leak vectors than the above, so it's far from certain that the crawlers you see found their target by sniffing your DNS requests.
> The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party.
There are a number of other, perhaps more likely, reasons your hostnames have leaked.
Have you got any certificates for any of those names? Then they are in the public CT database which numerous people constantly scan for interesting data.
Are any of your DNS zones enumerable for some reason? Same thing. Any reverse DNS set up? What protocols and public services do you run? Do any expose hostnames in the protocol handshake? Then you are in the public Internet scan datasets.
As soon as you run any kind of SSL on any of your protocols your hostname is in the SNI header.
Host names are visible in a number of ways. It is best to consider them public data. I have seen a number of ISPs from the inside, and none of them has had any interesting in wiretapping their customer's DNS data. I'm not saying it doesn't happen, but it can't be very common. They have much more interesting data available to them should they want to go down that road.
> Personally I'm not an "owner" of the networks I'm connecting to.
But I am the owner of my own network, and DoH reduces my ability to protect it. That is the main (but not only) reason why I strongly object to DoH.
> I think this train has passed.
I suspect the battle has just begun. For example, my response to DoH has been to implement a MITM packet inspection system on my network to regain control over this. This means that DoH will not work from my network. I expect that we're going to see this sort of thing more and more.
What exactly are the threats that you expect blocking DoH to protect you from?
If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it, rather than trying to prevent them from learning where it is?
> What exactly are the threats that you expect blocking DoH to protect you from?
I want to maintain the ability to block the resolution of certain domain names.
The threat model is malicious software or websites that want to phone home. This includes reaching out to command-and-control servers, ad tracking servers, data exfiltration points, etc.
> If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it
Because most of the malicious actors don't use raw IP addresses as they can change frequently and without notice. They resolve a domain name instead. Blocking the domain name lookup is therefor more effective and less likely to result in blocking the wrong things than working with raw IP addresses.
This is not a replacement for other security measures (including IP-based blocks), but is is, in my opinion, a critical measure in and of itself.
I work at a k12 school and I am involved with many IT admins from other schools.
Some schools already started to block Firefox from being installed because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS.
There is a fine line between your ISP and local network operators that NEED to apply some security policies to their traffic. Even Google offers "Safe Search" for schools and libraries that removes porn content.
Unfortunately, on our school network, we also allow BYOD, so we will have to have some strict rules to block DoH, the same way we block proxies and vpns.
Look I sympathize with all the k12 network operators that have to apply all these brain-dead content filtering policies -- I used to be one. But surely you recognize that someone external to my device that can inspect, modify, compromise the security of, or block my connection to any part of the public internet is the enemy right?
You're free to do whatever you like with devices that you own and you're also free to have an acceptable use policy on your network but breaking security and privacy to accomplish it is the exact wrong way to go about it.
In my ideal world school BYOD devices would either not be allowed at or be given a private single-device VLAN with a direct unfiltered connection upstream, and made clear in policy that the school doesn't own, support, or control any aspect of them. No different whatsoever than students using their cellular connection.
I'm mostly like you, except I've seen where DoH (or rather the equivalent DNS control) can go wrong on my local network. I have a NAS, and did not set up the manufacturer's optional global DNS routing (because why the heck should anything on the internet know anything about my NAS). Unfortunately that means my Chromecast doesn't stream files off it properly, because that hard codes to using Google's global DNS servers (8.8.8.8), which isn't going to know about my local hostnames (nas.lan). I've had to change things to use IP addresses instead.
If you don't trust your network why don't you install a DNS stub resolver that tunnels to some external resolver that you trust and then set the OS to use localhost?
Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.
> install a DNS stub resolver that tunnels to some external resolver that you trust.
Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.
You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them.
As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver.
OS resolver -> a single thing you need to secure
every app uses its own resolver -> complete mess which makes it harder to ensure privacy of your traffic
Browsers don't trust the OS to provide secure private name resolution. And they really shouldn't when every OS just blindly takes whatever is offered via DHCP.
I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all of our sensitive information I think have earned the exception.
I don't think this is the proper approach. Once it's in browsers it will also be in electron applications. And those may update less frequently. Now you have balkanized implementations of custom DNS stub resolvers using different remote endpoints. That makes security updates more difficult, network issues more difficult to debug and so on.
Doing it properly would involve securing the system, once. This could be easily done by installing a DoH stub resolver service and then pointing the system config to localhost.
Your ISP doesn't really need DNS traffic to know things about you, IP addresses alone leak a lot of information, add to that SNI, response sizes, active probing, clear text traffic, etc. and you should realize that the only thing DoH does is letting one extra party to know what you are doing in addition to your ISP. DoH is net negative for privacy. You need at least a VPN to get to net positive, so that your ISP can't get that much data.
If you can't trust your ISP, leaking all of your DNS traffic to another party still doesn't let you trust your ISP, but now you have to trust that other party too, hence net negative. To avoid trusting your ISP you need at least a VPN.
ISPs already don't have a good track record, so I would argue them NXDOMAIN advertising (like Spectrum does by redirecting you to a yahoo search page) won't make someone unsubscribe from their services. But if a service like 1^4, that specifically states they don't track you, lies about it, then that would be a huge issue for all of the customers that pay for the company's other products.
The person who wrote your application stood it up using that CDN though. There are two parties we're concerned about: you and the entity you're communicating with.
You trust your device and the entity, and the entity trusts the infrastructure and services they're using. Everything else is the enemy. So moving the barrier to a CDN which the entity trusts is actually an improvement over intermediate ISPs which neither of you trust.
They may simply not care and only "trust" the CDN in so far as it bypasses local resolvers. I.e. they might be using it for reasons not aligned with my interests and not vet the CDN at all.
Why not run a Pi-hole? You only stand to benefit. Whilst it doesn't address DoH, it does go a long way in preventing the tracking you mention. It also saves on bandwidth. And because it works at the DNS level, you benefit from the calls not even being made. The Pi-hole can be customized with an endless set of rules to block about any ads, beacons, trackers. Couple this with uBlock Origin, Privacy Badger, Decentraleys, Referer Block, and some creative browser settings (about:config) and you are largely safe from prying eyes. JS can be whitelisted, etc. You have nothing to lose.
My setup is similar. Pihole with dnssec and dnscrypt-proxy connected to cloudflare. Didn't see a reason to use the cloudflared package instead of dnscrypt-proxy.
Without a doubt, DNS-over-HTTPS introduces some major concerns from a network operator and security perspective. But I'm also very privacy focused, and am conflicted on the issue.
>[Mozilla] believe that they need to build technology that will accommodate a hostile network operator who is going to replace your DNS with things pointing to their advertising servers or is going to monitor what you do and send it off to some human rights violation team somewhere and so rather than tell you to use VPNs or tell you to use tor they decided to build DNS into the web
Requiring the average Joe to use a VPN service just so they can have some reasonable attempt at privacy isn't really an option, as we have seen. Privacy shouldn't be a luxury reserved only for those who can afford it. What I would really like to see is our lawmakers step up and make modern privacy laws with respect to technology and the data that results of it, but that clearly isn't happening. Unfortunately, DNS-over-HTTPS will very likely be used against the consumer in the long-run. Instead of using a pi-hole with port 53 blocked, I can see many devices will start using DNS-over-HTTPS to bypass those restrictions. Chromecast, rokus, and other devices already have hard-coded DNS addresses built-in, it won't be a very large step for them to switch to DNS-over-HTTPS to bypass my own network policies.
His main argument seems to be that the network operator should have control over DNS requests for safety reasons. Control and monitoring. This is the antithesis of privacy and encryption. I wouldn't be surprised if he was pro http over https either.
Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours.
DoH breaks that completely; and hence the network operator should have the final say.
As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine, I have to check which browser they use... that is the antithesis of the problem, because when DoH doesn't work but normal DNS does, then I'm flat out of options.
This is why I choose not to use Firefox or any of the DoH mainline providers (Cloudflare,) and I go out of my way to make sure users cant do it.
The GP isn't arguing against TLS; he is arguing against random apps ignoring network-wide settings. When such app breaks, he cannot diagnose the problem, he has to diagnose first that the problem is caused by an app that ignores a setting it shouldn't ignore.
It is always the case that an app can break due to something in the app itself. An app may for example link with a different TLS implementation that breaks. Or an app may use the local DNS resolvers but do DNSSEC local validation.
With QUIC (HTTP3) a large part of the network stack will be part of the application. So you lose that visibility as well.
A corp network should set up their own DoH resolver anyway. And/or simply install a cert on their workstations and MITM every TLS connection.
Even better corps should only allow TLS that they can successfully MITM.
It's basic security. If the endpoint/host can do whatever due to lack of firewall/enforcement, then it doesn't really matter what the network operator wants.
> A corp network should set up their own DoH resolver anyway
What good is that is the browser uses their own list?
Literally that's what the article is saying. Firefox will force users to use ones that break the top-down approach on how software works. If I set a DHCP option for DoH, and setup my own DoH resolver, Firefox wont care, they will jsut use their list.
This also opens up possibilities for selling positions on the trusted list, because we've seen that happen before (adblock, or the firefox Mr Robot extension.)
Firefox itself, with plays like this are trying to make a decision about the whole, when they are completely forgetting the corporate side.
Are you going to change the settings manually after each connection in different network? Most people won't. We already have an automation for that, called DHCP, setting up network specific config system-wide... which Mozilla decided to ignore.
On your router, you can configure whatever you want to use for the DNS. You were able to do that for years.
But I want all the devices and apps to use whatever the local network tells them. I don't want to reconfigure the browser every time I connect at home/work/customer place/etc.
P.S. My ISP's DNS doesn't lie. Maybe you should vote with your money and choose better.
> On your router, you can configure whatever you want to use for the DNS. You were able to do that for years.
Sure, if you have a router and know how to configure it. The second requirement excludes the vast majority of non-tech-savvy users, even though they are also harmed by lying or data-collecting DNS resolvers and likely would not consent to them if asked. (The first requirement additionally excludes phones and other devices directly connected to a mobile network; of course, you can generally configure the devices themselves to use a different DNS server, but it may be annoying if you have a lot of them. More convenient if devices already default to the option that protects your privacy, i.e. DoH.)
> P.S. My ISP's DNS doesn't lie. Maybe you should vote with your money and choose better.
Even if it doesn’t lie, does it log requests and sell that data? Are you sure?
Anyway, in many locations including most of the US, there’s no meaningful choice available among wireline ISPs.
The point is that your router is a client of your ISPs network and you're overriding the servers provided by DHCP to your router.
In a crazy world where internally Firefox ran a small IP network for each tab and routed traffic between them for IPC would it suddenly be okay for Firefox to override DNS? Why or why not?
The difference is not in what is being done, but in who is in charge.
If you modify your router settings, it's you. You decided that you are not going to honor ISP suggested defaults, and it is up to you to assess costs/benefits and pick the right choice.
If Firefox overrides your settings, it means someone else does the decision about your tools. If that someone else makes it difficult to automate changing the default (e.g. ignoring DHCP; if you want, you can ignore DHCP at the system level, but this is not a decision an app should take), it means, that this someone else doesn't have good intentions towards you. Someone else decided what's "best" for you.
But right now within epsilon every computer will just blindly take what is given to it by DHCP making the local network operator, who is for almost everyone an untrusted party, the person who decides what's best for you.
I agree that DNS should be a system level concern rather than an app-level concern but in the real world browsers want to protect their users' privacy and the OS they run on doesn't do that. If every app went out and started using app-level DNS then it might get annoying but browsers are particularly privacy and security sensitive.
With this change almost everyone (i.e. people who don't mess with their OS setting and don't know or care what DNS is) are markedly better off.
I am no sysadmin but working closely with some. I have never seen any case where HTTPS-MITM helps. Yes, theoretically it does allow us to scan for malicious content in a secured connection. Brilliant, but that are not the attack vectors they are concerned about.
So what is left is that breaking up TLS just infringes on privacy and allows for tighter control. The security aspect is laughable.
Users are angry that their internet got slower, an it creates an enormous administrative cost, because you need countless exceptions to the rules.
Some of your best friends, eh? The point of MITMing HTTPS in an enterprise setting is not inbound content scanning (though that's pretty useful to), it's to prevent outbound transfer of secrets/HIPAA or PII data/financial data, and it's a regulatory requirement for some industries.
Besides, the point of DoH is to move DNS into the browser, which Google also controls, to prevent pihole-like DNS-based ad blocking. Cloudflare supports it because it allows them to lock down one of the few remaining actual distributed systems powering the internet. These companies are not your friends, and you should think harder about their incentives.
> it's a regulatory requirement for some industries.
It won't be when it's functionally impossible, which seems to be the point.
You do see the light at the end of the tunnel, right? Browsers shipping their own unmodifiable CA stores and disrespecting 3rd-party CAs signatures for public DNS names.
It seems you don't understand that there's Firefox ESR and other browsers too. The law very likely won't change just because consumer-friendly browsers by default are not enterprise-friendly. Big corps provision and manage their machines themselves, they modify the packages' built in configuration (they either create a new install package, or do it after install with scripts, or - if the application supports some kind of "group policy" then they use that).
Cost of compliance is a real thing, and making the workstations secure and compliant with their own policy is their responsibility in those industries. It's not fun, but it's perfectly doable.
Sysadmins should concentrate on managing and securing the devices and not the network. This is advantageous with todays mobile workforce where users expect the same experience at the office, coffee shop or home.
The argument that because encryption can be used for nefarious purposes it should not be offered by DNS providers at all does not add up. ISPs can block, redirect and sell DNS traffic and many are already doing some or all of these.
I’m specifically arguing that dns lookups should not be encrypted. Dns can be descriptive: ntp.example.com sounds like an Ntp server. Oh- this pcap shows an ntp flow afterwards. Probably synchronizing time.
Oh- adnetwork.example.com. Probably serving up ads.
I need to look at every protocol flow and sort by IP?
Who in their right mind blindly trusts all computers like this? If you ever want to troubleshoot your network, your job becomes way more tedious if dns requests are encrypted.
The issue comes from network operators wanting to control DNS from being a middleman in the connection, but there is no way to ensure the people acting as middlemen in the connection are authorized to be in the middle or authorized to change those DNS requests.
If a network operator can change DNS, then the ISP, network hops, or a malicious twin AP can as well.
ISPs also provide "their" DNS rr's. That does not mean you have to use ISPs' DNS RR to access the DNS.
> The DNS belongs to the network.
This is the question - should the network really be able to tell the client what IP corresponds with a DNS name? if no, then there's no good solution to blocking websites where you can't install things on the client's device. Meanwhile, if you say yes, then you must also say yes to ISPs being able to tell the client what IP corresponds to a DNS name. The only solution in an enterprise context is to buy new hardware (or install a software update if Cisco is feeling benevolent) that runs a DoH server. In a school-bocking-porn context, you could ban the biggest offenders via IP (mindgeek sites have a dedicated IP space I think, and you could cron your own DNS lookups for other non-CDN sites) and use SNI whitelist until eSNI is added to iOS.
The main argument should be that the OS controls what DNS is used.
The user of the OS can then set their own DNS. If applications just ignore this and use their own it takes away power from the user. Sure Firefox lets you turn it off, but a lot of people won’t bother.
After seeing every implementation of DoH giving a flying fuck about your actual network settings, I’ve decided it’s a technology I want nothing to do with.
I’ve actually actively blocked DoH for the major providers on my router, by writing some custom iptables rules.
Hopefully there will be a simple to use OpenWrt-package which you can install to do this automatically in the future.
I'll have to correct myself. It seems I gave up on the iptables-approach due to having some correctness errors.
Instead I ended up with these lines in /etc/config/firewall:
config rule
option target 'ACCEPT'
option name 'Allow router to perform DNS'
option family 'ipv4'
option src_ip '192.168.1.1'
option dest_port '53'
option src '*'
option dest '*'
config rule
option src 'lan'
option name 'Disallow Google DNS from LAN'
option family 'ipv4'
option dest_ip '8.8.8.8'
option target 'REJECT'
option dest 'wan'
config rule
option src 'lan'
option name 'Disallow Google DNS from LAN (2)'
option dest 'wan'
option family 'ipv4'
option dest_ip '8.8.4.4'
option target 'REJECT'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN'
option dest_ip '1.1.1.1'
option dest_port '443'
option target 'REJECT'
option proto 'tcp'
option family 'ipv4'
option dest 'wan'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN (2)'
option proto 'tcp'
option dest 'wan'
option dest_ip '1.0.0.1'
option dest_port '443'
option family 'ipv4'
option target 'REJECT'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN (3)'
option dest_ip '104.16.249.249'
option family 'ipv4'
option dest 'wan'
option target 'REJECT'
Pretty much as basic as you'd think.
Router itself acts as a DNS-server via dnsmasq, and is allowed to do anything I decide I want.
On my network I have a pi-hole instance which then forwards queries to the router, so it also intercepts/looks up local LAN names correctly.
All clients on the network are provided the pi-hole as the canonical DNS-server to use via DHCP options.
https://youtu.be/OxFFTxJv1L4?t=2799
After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.