Operating systems can and should implement DoH, not every single individual application (which can then decide to use poorly chosen servers and will have to get updated in the future for whatever the next spec might be). That the people who make operating systems put so little effort into this stuff that application developers feel they need to take this into their own hands is a travesty :/. (This is particularly annoying given that it is already the case on every operating system that if you want to use DoH and choose your DNS server you can easily do that as long as the software in question lets you by using the system resolver; it makes absolutely no sense to embed and hardcode this functionality into every app.)
(For more detailed complaints and arguments on this topic, I wrote a long comment about it a year ago.)
I agree with you but I just... gave up. The web ate the net, the browser is the new OS. It's silly, it's lazy, it's inefficient, it's everything I dislike about software engineering but at this point it feels like preaching in the wind. I just try to ignore it, keep writing low level code and if someday I can't find a programming job outside of web technologies anymore I'll just become a shepherd in the mountains or something. I'll make cheese.
It'll probably bounce back. We've been here before, when computing was centralized and everybody logged into the mainframe. Then it turned out that to have independent computers gave users a huge advantage and helped control costs.
Now, we're back to centralized systems- and I couldn't believe it when I watched the shift: What first caught my attention that this could get serious was gmail. Then g-office (whatever they called it then). Meanwhile a whole host of other services started.
I was developing a desktop app because I still wasn't convinced that people wouldn't prefer having their software and data "in hand," as it were.
I expect a new advantage will emerge and we'll want our machines and data back.
It's the tradeoff between local computing power and bandwidth/latency. It flips back and forth every couple decades based on what's expensive and what the last big advance was.
Even within the current era, render on server, render on client, ajax (the mix), etc.
We're seeing it now in gaming. Vidcards are the cost of a whole system now, games have become huge, and fast storage is still expensive; but bandwidth is increasing along with A/V streaming being perfected, so someone figured out how to minimize apparent control latency and now games are streaming. Once vidcards get cheap and SSD storage capacities catch up to 150GB games it'll flip back until the balance tips again.
Not enough to make even moderately latency-sensitive gaming worthwhile, though. I don't see that getting better unless there's widespread building of data centers all over the place to keep the services right in your neighborhood.
I’ve been pretty happy with PS Now, Shadow and GeForce Now. I show maybe an extra 50ms of latency max, more like 30ms avg.
I wouldn’t play really competitive shooters that way but it’s low enough to not bother me even in mouse/keyboard FPS (for the PC services). For controllers it’s completely negligible, like playing with a Bluetooth device or on a 2015 TV.
That said, I’m in Santa Clara County near one of the major Shadow datacenters, probably the others too, and I have gigabit. I am in the ideal situation you describe.
So is a lot of the world though. US is super rural for its economic weight but that’s not the norm. Most developed countries have much higher density and better networks. I think we’ll probably just end up dragging behind the curve until we mesh the flyover states better.
"You have been locked out of the G-Suite because a username closely affiliated with your IP address was discovered on the downside of a controversial reddit thread."
You made me feel a lot better, actually (I'm serious). <3 Maybe one day I will open the sandwich shop I sometimes threaten to leave software for, and I can buy your cheese. (I know that is a horrible business, but there was a great article I read 15 or so years ago about a developer quitting software to open a hot dog stand, and he seemed so happy about it.)
> It's silly, it's lazy, it's inefficient, it's everything I dislike about software engineering but at this point it feels like preaching in the wind.
It may not be conceptually beautiful but it is one of the most practical and useful technologies we've ever created, like C compared to lisp. The Web is the new "Worse is Better"
Wonder when they will ship a new version of AOL CDs to access the global CDN formerly known as the Internet.
Actually HTTP could directly handle DNS. Then you can decide between a cloudflare, google, akamai or amazon browser. Who needs more freedom if we can have security...
What do you think of a new standard for delivering instant web apps that is 1% of the complexity of browsers? Something, maybe a chat-like interface with buttons and input fields, that allows you to interact with a web server in a dynamic and useful way but it's at the same time very simple and fast.
Ideally then for all more involved software experiences native software would have to be shipped.
I see a comment like this basically every time something about DoH comes up.
What I haven't seen: A plan how this should be implemented, a proposal to OS vendors and developers, ideally with patches.
This raises a few questions. How should the OS decide which server to use? It obviously can't be DHCP, because that's not a secure thing to begin with. How does this interact with things like captive portals if you have a disconnect between the DNS functionality and the gui application? Do you have good answers for these?
It obviously can't be DHCP, because that's not a secure thing to begin with
Why not? DHCP is supposed to be authoritative for the network you're connected to. If you don't trust that network, you should probably also not be using its advertised gateway. Where does that leave you?
Personally when my laptop is connected to a network on a high latency link to the internet, I'd rather it used the local caching server rather than one half a continent away. Clearly if I don't trust that network provided DNS server I'll tunnel everything out to a trusted network, or I could specify a DOH.
I have no practical issue with DOH if it were implemented at the OS level and had standards around how to distribute recommended settings (just like my dhcp server distributes a recommended gateway, recommended ntp server, recommended tftp boot server, etc).
DNSSEC doesn't do that at all. DNSSEC does no transaction encryption. It allows full recursive resolvers --- the kind virtually nobody runs on their own machines --- to validate signatures on the tiny minority of domains (virtually none of them among the most popular on the Internet) that have opted in to DNSSEC over the last 10 years. Note that even in the unusual corner case where you're looking up a name that's actually signed with a DNS recursor that actually verifies DNSSEC signatures, the network between you can still snoop on all your DNS requests, because DNSSEC is bad.
If you're worried that your network upstream is intercepting your DNS requests (and if you're in the US on a mainstream ISP, you should be), this is the problem DoH is designed to solve, and it does so quite effectively.
DoH does not solve the problem that the resolver can just feed you wrong data. So if you want integrity for your DNS records you need DNSSEC. DoH/DoT does not solve that.
DoH deliberately doesn't touch that problem. In 25 years of work, DNSSEC hasn't put a dent in it --- look at the stats on which zones are signed (and note that most of those signatures are security theater, done automatically by registrars).
The fact is that there's nothing you can do to authenticate DNS records, and turning some silly "DNSSEC" feature on in your own stack won't do anything but make you feel better, because DNSSEC simply doesn't have meaningful adoption. However, enabling DoH does in fact immediately protect you from attacks that really do happen, like ISPs monetizing your DNS.
The problem is that DoH is not the solution, as you just change trust from resolver A to resolver B. With no indication that B is better than A.
If you fear that your ISP is selling your data you need to change your ISP. The ISP always know what sites you are accessing, regardless of DNS. DNS might be easier than SNI or IP lookups but the danger is still the same. Right now it might actually help but once encrypted DNS gets enough traction those methods will also adapt. (Assuming that ISPs still do that practice)
It's funny that you've managed simultaneously to argue that DNS monetization (which is ubiquitous) is both a reason to immediately change ISPs, and also not a big deal because ISPs can snoop on you anyways.
While I have strong normative beliefs here, I'm mostly just posting descriptively. DNSSEC isn't happening. Enabling DNSSEC in your local configuration won't meaningfully protect you, because you depend on the security teams of large companies to also participate in the system, and DNSSEC has been more or less rejected by the market. Meanwhile: there are specific problems that DoH does protect against, it's easy to roll out, and doesn't depend on the Stripe security team changing their mind about DNSSEC --- so DoH is on a path to become universal, even as DNSSEC whithers.
(I invite the curious to test my reporting out with the `host -t ds foo.com` command, for arbitrary values of "foo").
I know I sound like a sore winner about this, and I guess I sort of am, but it is a little alarming that there are still currents of sysadmin wisdom telling people to go out of their way to opt into DNSSEC, in the belief that it will somehow protect them from any kind of real attack. In reality: corrupted DNS records overwhelmingly come from phished registrar accounts, not the elaborate, geographically-specific DNS cache corruption attacks DNSSEC was envisaged to deal with. I think it's worth being plain with people about this stuff.
>It's funny that you've managed simultaneously to argue that DNS monetization (which is ubiquitous) is both a reason to immediately change ISPs, and also not a big deal because ISPs can snoop on you anyways.
Of course. If you know that your ISP is doing that, you change to one that is not doing it. It's not ubiquitous. Besides that, what makes you think that your DoH provider (if not your ISP) is also not selling that data?
You think that DoH/DoT is somewhat a replacement for DNSSEC but it's not. Both are independent. Doesn't matter how much domains have it.
How do I know if my ISP is doing that? And which ISP do I change to? Where I live, there’s effectively a single available ISP unless I don’t mind dropping down to single digit mbps.
Seems more plausible to just run DoH for my DNS and then not worry about my ISP snooping on my DNS requests.
The answer is: DHCP. In an environment where a captive portal is active you can ensure that only one DHCP server is running in your segment with no rogue DHCP servers. So telling a client with DHCP that a captive portal is active, and with URL to show it, is sane. This would eliminate a lot of stupid probing done by clients.
Same goes for announcing DoT/DoH servers that way.
The same applies for your "home" environment. Since you usually don't want to run multiple DHCP servers, this would also work there.
And it isn't like anyone needs to modify DHCP standards to support this. Just use any of the "options" text to add DoH/DoT, the same way browsers are advised of PAC URL's today. Only the clients would need updates to know how to use this, and adding the capability to an OS should be fairly easy to implement.
I did something similar for a PoC at my university. It worked, no surprise there. All you need to do is have a another client script in Debian to configure your resolver.
I should add that DoH developers should reach out to ISC for comment on DHCP, to get an idea what the cleanest method would be to implement DoH/DoT in DHCP that would work for 90%+ of DHCP implementations.
Isn't this the trusted network dialog in windows/etc when you connect to a new network?
If you don't trust the network, then the OS should be tunneling to a trusted one. If you do trust it then it can go ahead and use the DHCP/etc provided name servers.
After all it can decide to enable/disable access to services (windows filesharing for example) based on this, there isn't any reason it can't decide to trust the local nameserver too.
Some do, some don't. For example the captive portal issue, browsers can try to connect without DoH to a captive portal test page and provide a special non-DoH login tab. You can't do that on the OS level. You could create some interaction between the browser and the OS, but that's nontrivial and needs a solution.
Windows: Network Connectivity Status Indicator (NCSI) will ping www.msftncsi.com on older versions (8.1 and lower) or www.msftconnecttest.com on newer versions (10), and then prompts to open the web browser. Since IE/Edge will be always there, it works.
macOS: same as iOS (a dedicated window pinging www.apple.com).
Firefox: Detects detectportal.firefox.com and asks the user if the want to access the captive portal.
Android: Detects connectivitycheck.android.com on Android 5 and connectivitycheck.gstatic.com on Android 6+. I don't know if it applies to all phones, but I'm sure (that except for phones on Android One or Nexus/Pixel) Samsung also does this for phones outside of China.
OSes do at least some captive portal detection and prompting already too, but true, that might need additional work, I'm not familiar enough with the details.
As did Windows (I saw this as I read over the last six months of changelogs a few days ago)... so why exactly is this a thing Firefox is doing again? :/
To summarise, there is nothing inherently wrong with DoH (serving DNS RRs via HTTPS), but there is something inherently wrong with enabling applications to ignore the user's OS DNS settings by default and perform their own DNS resolution, whether via DoH or otherwise.
Will these user-hostile appllications and devices allow you to set the gateway? As long as you can use an OS of your choice on the gateway you should be able to control routing, including DNS.
> Operating systems can and should implement DoH, not every single individual application
I agree that it would be better for DoH to be done in the operating system than in applications, but the reality is that today, operating systems don't do this, and it's better to do DoH in applications than to not do it at all.
DoT or DoH are supported in Android (9+), iOS (14+), Linux (systemd-resolved, stubby, other resolvers), macOS (11+) and coming to Windows in 2021. So what exactly having separate implementation in apps achieves? That is, except for the possibility of mismatched configuration between such applications and the OS, leading to hard to debug problems?
No DoT is not DoH. They both are blockable; DoH servers must use either well-known IPs, or to be bootstrapped by the plain DNS. First one you can block as well, the second you can filter.
> Of those platforms that do support DoH, how many of them have it on by default, rather than requiring the user to know it exists and turn it on?
Being off by default is a feature. Those road warriors that do not trust their coffee shops can turn it on if they want it, but elsewhere it causes nothing but trouble.
> DoH servers must use either well-known IPs, or to be bootstrapped by the plain DNS.
The easy solution is for the well-kmown IP to be in the same pool that a major CDN uses, so it can't be blocked without major collateral damage.
As for being off by default, that's absolutely not a feature. Basically nobody who's non-technical will ever turn this on, even though it will improve privacy for no downside for most people. What "trouble" does it cause anyway?
> The easy solution is for the well-kmown IP to be in the same pool that a major CDN uses, so it can't be blocked without major collateral damage.
I can imagine that there are players who are OK with that collateral damage. In the end it will end up exactly like when the cloud providers disabled TLS domain fronting.
> even though it will improve privacy for no downside for most people
It won't. The big DoH providers will have nice behavioral data, on computer level, i.e. NAT is no longer a problem, they can distinguish separate device due to TLS session.
Privacy-wise, it is net negative. Few big companies will be getting data they didn't have until now.
> What "trouble" does it cause anyway?
You don't know, so you will use scare quotes then?
It has problems with DNS zones that only some resolvers can resolve, and/or are under ACLs so only local clients can resolve them. Your local network knows about them, the global ones don't.
It has problems with split-horizon names. So now, instead of getting internal IP for a service, you will be getting external one, so your traffic will go to router and back.
It has privacy implications that you didn't even began to think about.
Most networks are not coffeeshop wifi, where such behavior would be OK.
> I can imagine that there are players who are OK with that collateral damage. In the end it will end up exactly like when the cloud providers disabled TLS domain fronting.
The problem with domain fronting was that it could be blocked by blocking the chosen "front" domain, which bad actors were often willing to do. In this new era of eSNI, they'd have to block all of CloudFlare, which would be a lot harder sell even for an entity like China.
> It won't. The big DoH providers will have nice behavioral data, on computer level, i.e. NAT is no longer a problem, they can distinguish separate device due to TLS session.
> Privacy-wise, it is net negative. Few big companies will be getting data they didn't have until now.
I trust CloudFlare more than my ISP with my privacy, and if you don't, then you can pick another DoH server that you do trust.
> It has problems with DNS zones that only some resolvers can resolve, and/or are under ACLs so only local clients can resolve them. Your local network knows about them, the global ones don't.
Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
> It has problems with split-horizon names. So now, instead of getting internal IP for a service, you will be getting external one, so your traffic will go to router and back.
With managed clients, you'd push out configuration to exempt the internal names from DoH. And what's the use case for split-horizon DNS with unmanaged clients? I've never seen that.
> It has privacy implications that you didn't even began to think about.
> The problem with domain fronting was that it could be blocked by blocking the chosen "front" domain, which bad actors were often willing to do. In this new era of eSNI, they'd have to block all of CloudFlare, which would be a lot harder sell even for an entity like China.
Entity like China are willing to block entire subnets if the subnet owner doesn't coooperate and doesn't separate the traffic. That would make the subnet owner's customer nervous, thus them pushing for cooperation in the first place.
> I trust CloudFlare more than my ISP with my privacy, and if you don't, then you can pick another DoH server that you do trust.
The thing is, I don't want to pick one single DoH server. I want to use the resolver that knows the local network, i.e. exactly how DHCP works today. I would be fine if there was a way to announce DoH/DoT via DHCP[1] and all the systems and apps would respect it.
> Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
Just wait until ignorant people will start screaming about "DNS leaks" -- just like they do today with VPNs.
> And what's the use case for split-horizon DNS with unmanaged clients? I've never seen that.
BYODs. There are organizations (both for and non-profit), that have external co-workers, working with their own devices, that are not managed by GPO or MDM.
>> It has privacy implications that you didn't even began to think about.
> Like what?
Centralized service, preconfigured by default, used by many people, capable of discerning browsing habits per device even behind NAT. What could possibly go wrong.
[1] Though it has really no sense in trusted networks; DHCP can announce classic 53/udp service, the resolver can use DoT/DoH for the upstream, and the client would be none the wiser. In fact, many networks do exactly this today.
> Entity like China are willing to block entire subnets if the subnet owner doesn't coooperate and doesn't separate the traffic. That would make the subnet owner's customer nervous, thus them pushing for cooperation in the first place.
Once eSNI is widely deployed, in addition to CloudFlare, DoH could also be ran from anywhere in Azure, AWS, or GCP. At that point, China will have to choose between breaking all TLS, blocking almost all traffic to the US, or accepting DoH leaking.
> The thing is, I don't want to pick one single DoH server. I want to use the resolver that knows the local network, i.e. exactly how DHCP works today. I would be fine if there was a way to announce DoH/DoT via DHCP[1] and all the systems and apps would respect it.
But the network is the main adversary. It would just advertise a DoH server that does censorship or surveillance, and then we're back where we started.
> > Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
> Just wait until ignorant people will start screaming about "DNS leaks" -- just like they do today with VPNs.
That feature is optional. It's easy to turn that off if you don't want it to happen. And even if that weren't the case, isn't most of your DNS requests being safe better than none of them being safe?
> BYODs. There are organizations (both for and non-profit), that have external co-workers, working with their own devices, that are not managed by GPO or MDM.
So just add one step to onboarding: after "here's the Wi-Fi password", it's "here's the subnet to add to the DoH exclusion list".
> Centralized service, preconfigured by default, used by many people, capable of discerning browsing habits per device even behind NAT. What could possibly go wrong.
A lot less that could go wrong with the current state of ISPs.
From your linked comment, I would disagree with "web browsers decided that they didn't like end users being able to have this control". They don't like the default that requires users to make an active change to the get "upgraded", without ever being prompted so, not that the user can control it, and believe that in that situation, giving it a push is justified. See e.g. Chrome's policy: it checks if the configured DNS server also has a known DoH option, and if yes uses that.
Right, it's not about taking away user control, because users have the same exact level of control that they had before. Firefox/Chrome still offer all of the same customization options, and you can even turn off DoH entirely.
What it is about is that the defaults for pretty much all OSes are bad. Maybe if we lived in a world where DoH was shipping by default enabled in Linux/Mac/Windows and set to something private like Cloudflare, it would make sense not to even provide browser options at all.
But as it stands, the current solution (while a little unintuitive and hacky) give you the best of both worlds. If you're a normal user, you get secure defaults. If you're a power user, you can go into Firefox and point at your own DoH provider, or turn off DoH entirely if that's what you want. And if you're an admin deploying Firefox on a network, you can deploy it with a custom profile that sets its internal DoH/DNS settings to whatever you want.
> See e.g. Chrome's policy: it checks if the configured DNS server also has a known DoH option
Do you know of any references that describe how it determines if the DNS service offers a DoH option or not? I can't find anything more than vague descriptions.
You're essentially arguing that more flexibility is bad without real justification. Per application DNS/routing (split routing) is something most Operating Systems don't support today (or setting it up is incredibly complex).
Giving this kind of flexibility might open up a future where a competitor to ICANN-DNS could exist, and users could dogfood it via single browser/window/tab instead of having an all-or-nothing situation as per today.
But let's throw out incredible new capabilities that allow user flexibility/choice because it is different to how it was historically done.
Because DoH is implemented in the browser and bypasses the OS resolver configuration, it will specifically break things like pihole.
The correct solution is a) do this at the OS so users can configure the behaviour, b) add support to pihole or similar for making DoH requests out to somewhere like CloudFlare, c) also add support for receiving DoH requests for those people using a pihole over untrusted networks.
That's what I've figured out too. A while ago I started blocking port 443 to known DoH servers to prevent any machine from internal network bypassing the pihole. I expect televisions, smart lights and many other IoT devices to start using DoH to be able to track the users with pihole installed...
Do you also block plain old third-party unencrypted DNS servers? Because those could also trivially be used to bypass content filtering on your local resolver, no DoH required. In fact some web appliances like the Chromecast already do exactly this without having to use any kind of technology like DoH.
The problem you are describing is nothing to do with DoH, it is simply a consequence of the fact that DNS is not meant to provide access control. It is not an endpoint security management solution.
I do. I have always intercepted 53 and 853 and route them to my Unbound DNS recursive server. Unbound caches requests, blocks known malicious domains, then forwards the requests over a vpn mesh to other unbound servers that talk to the root name servers. The weakest link of course is that the root servers do not talk TLS yet. DNSSEC can be useful for zones that are signed.
Now consider you are visiting a friend's house and you find out they have such a setup on their network... you wouldn't be bothered to learn that all the domain names you visit, even over TLS, are being processed by the homeowner and could be logged?
At a friends house, my laptop will join my private VPN mesh and my DNS lookups will still use my servers. This does assume they allow outbound connectivity to more than 80/443. I have found places that do not allow this. I could run tinc [1] on 443, but if UDP is blocked, the VPN will be slower.
That said, in fairness, not everyone sets up their own VPN mesh. Some people use commercial VPN providers. So in that case, it would assume my friend does not block access to that VPN provider.
So, don't you think it would be more hospitable to just allow privacy technologies to be used on your network without forcing your guests to buy a VPN?
Maybe so, but that is my choice. It is my home and my network. I can choose to protect my guests and they can choose to get a VPN. I would not subject them to my ISP's DNS, nor would I subject them to centralized DNS. Both are equally dangerous in my view. I would always disclose to my guests what they are using, how to use it and what choices they have. The people implementing DoH in the browser are taking that choice away, so now my only option is to play the never ending game of whack-a-mole with the centralized DoH servers.
I do not think that it is fair to say that changing a default is equivalent to taking a choice away. They are only moving the choice from the network operator's hands directly into the user's hands, which is where I think it belongs (and where it really was in the first place). In the hands of the user whose device is actually establishing the connection.
You could block your guest's VPN connections, but you don't do that.. why not? Aren't they subverting your protection by using VPNs?
> nor would I subject them to centralized DNS. Both are equally dangerous in my view.
I would argue that large providers like Cloudflare are the only ones who realistically have the resources to stand up to threats like government intervention (where it is possible). They have strong legal and financial incentives to maintain their privacy guarantees which smaller providers don't have.
Also you have the advantage of your data "hiding in plain sight" due to the high volume they deal with.
I certainly wish there were more providers available than just Cloudflare and Google though.
I do not think that it is fair to say that changing a default is equivalent to taking a choice away
For my technical friends, that would be true. They can adjust their settings and be on their way. I won't block their choices aside from intercepting requests to the ISP DNS.
Most of my friends are not technical, have no idea how to tweak the settings in their browser and would not know they even need to care. So I think it is fair to say that a choice is being taken away. It isn't like browsers are going to prompt people and explain what is occurring. The masses will experience centralized DNS without any idea this is happening. I think we will fundamentally disagree here.
You could block your guest's VPN connections, but you don't do that.. why not?
My guests can choose to use a VPN if they wish, I would not take that choice away. That is an intentional move to protect their traffic. DoH is not an intentional choice. They did not choose this. If a technical friend chooses a DoH server, their laptop won't work and I will explain, if I had not already, that DoH servers are blocked. Anyone that knows me, would expect this behavior. Anyone that is my friend would accept this. We probably just have very different circles of friends.
I actually would support the idea of a prompt. In lieu of that, I prefer default-on to default-off, but I think I could agree that a prompt would be the best option.
Although if the only concern is that Firefox defaults to a poor choice (in your opinion), why not just block Firefox's default specifically? Why other public DoH servers too? Or why not just block the Firefox DoH canary domain which prevents it from defaulting to DoH unless the user specifically turns it on?
I would just block the DoH used by Firefox, but at the moment, nobody has really proven out the DoH/DoT solutions in the OS and browsers. Until such a time that users are made aware and given choices from both their OS and browsers, I choose to treat all of them as hostile in my own home network. I see the users as frogs in luke-warm water. Both ISP's and centralized DNS providers can choose to boil them once critical mass is reached. Some ISP's have already boiled some frogs, but this is limited to specific ISP's and specific countries. The DoH providers are in a position to boil ALL the frogs globally once everyone has forgotten about DoH and/or critical mass is reached.
At work, we already control these settings in the browser and can easily control any future settings in the OS so it is not an issue there.
So personally I plan to a) enable that so my outbound requests are encrypted, and then b) install a DNS blocklist so the hosts on my network will fall back to regular DNS and use the pihole.
> Or, you know, turn off DoH if you use a pihole. There is no problem to solve here [...]
On every app that will be baking in their own DNS resolution. Here's to hoping they all allow it to be changed via configuration. I suspect a favorite feature of pi-hole, blocking DNS from opaque devices like phones and TVs, will also cease to work when they use DoH too.
How do I enforce that? How can I ensure that no javascript payload or "smart" device on my network or app on my phone is connecting to a DoH server, when they're on my home network?
You don't. When the device manufacturers start being really evil and using certificate pinning for their DoH servers you simply don't buy those devices.
When the only devices available in the market for a given function end up being "evil" you either implement the functionality yourself or you just live without.
It's that or legislation (which will just become an arms race of manufacturers trying to work around the legislation).
I do without. No "smart" devices for me or my family. It's working so far. I about the eventual future when no major appliances, vehicles, etc, will be available without "smart" features implemented in an owner-hostile manner.
How do you currently deal with pinned certificates on those devices? What makes you think that they're currently respecting your network? A Google Chromecast will already ignore all of your network-wide DNS settings.
This removes a couple of avenues of attack you might have used to rein in some of those devices (but probably weren't doing), but it's just a symptom of the fact that using DNS for device control was always a really hacky, kind of awful solution to the problem of having rogue devices on the network.
Did you suddenly forget how to care about privacy and security before you buy your devices? No. Vote with your dollars, don't buy things that don't do what you need them to. If some IoT device only uses DoH, you already know that before you buy it: don't buy it. If an app only works with DoH, you already discovered that because you're someone who reads and comments on HN, and so you're guaranteed to check some app reviews before you buy into to: don't use it. No one's forcing you into this beyond your control.
Plus, right now we're talking about a browser adding DoH, and not some shit Google or Apple browser that makes the decision for you and it's final, but a fully configurable, user controlled, poweruser enabling browser that lets you modify its core behaviour without even having to recompile it yourself. You just open a tab and flip a boolean.
Yes, had this problem when I was setting up my pihole and took me a bit to figure out why it wasn't working with firefox. Imagine the sysadmin nightmare if you had to configure 100 different applications on every one of your systems to use the correct server...
I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, which has always been trivially bypassable long before DoH was around.
So given that DoH has real and practical security and privacy benefits, and non-DNS based content blocking solutions are already available, are more common, and work more effectively, I don't see how it is such a nightmare to adopt those more secure defaults for everyone.
Furthermore I don't think anyone is suggesting "100 different applications" will each have their own resolvers embedded. It makes sense for browsers to be a special case since they are particularly in need of the additional privacy affordances that DoH can provide, and operating system vendors have been slow to implement it.
Of course that could be easily bypassed, but such a restriction could be easily bypassed by determined employees regardless of whether Firefox natively supports DoH or not.
Local intranet sites will still continue to work without any changes because by default it will fall back to the native resolver if DoH can't resolve the domain. So there should be no breakage by default besides for content blocking use cases.
Is there no space between "operating system" and "applications"? How about a group of established hackers with expertise get together and create an open source, system-level, DoH service which can be made easy to install on the different mainstream OS (Windows installers/store/chocolatey, MacOS app store, Linux repositories, Google Play)? Is this asking for too much coordination among parties with disparate interests?
(I am wondering if the parenthetical I added a minute after I left my original comment wasn't there when you left this reply, but I go into detail on this topic in the linked comment: it already is the case that on every operating system you can do this and in fact people already have... as an example, if you want to use Cloudflare DoH, install their app!)
Is it possible to add root CA's for DoH only, so that I can intercept requests at the gateway and terminate the TLS connection there?
Can anyone link to the part of the source tree containing their DoH implementation? I would like to test whether it is possible to distinguish Firefox DoH from unbound.
I don't have a specific position on the use of DoH, but from a personal point of view I don't like that an application makes this choice for me and sends DNS traffic to providers I might not trust.
However, as a system administrator, I don't see in Firefox the equivalent of dig and nslookup: if a user reports an issue with Firefox, how can I ask him to verify which IP address a domain name resolves to? If I ask for a nslookup or dig result, I can no longer be sure that the OS resolver is giving the same answers that Firefox is returning.
You can ask the user to go to about:networking#dns and it will show Firefox's internal DNS cache. This is actually much more user-friendly today than asking them to open a terminal.
Grizzled sysadmin / desktop admin perspective here: I can't easily remotely interrogate a user's Firefox process, as you describe, like I can w/ the OS by remotely running "dig", "nslookup", etc, on the user's computer.
With the Firefox model I have to interrupt the user and ask them to become an active part of the troubleshooting process. I'd prefer fixing the problem "behind the scenes" without engaging the user, except to let them know when the problem is fixed. I consider it vastly more "user friendly" to enable support personnel to solve problems w/o distracting the user. I don't think very many developers consider that use case.
Tools that enable "concierge" support for VIPs, executives, Customers who will pay more to be doted-upon, etc, is a valuable attribute in software to me. Moving toward user self-service is laudable, but not if it's at the expense of dedicate support personnel's capabilities. In my experience, at least, the satisfaction and praise users express from having issues resolved without bothering them has been significant.
If you are on BigSur and would like enable DoH for a variety of providers I would check out https://encrypted-dns.party there is pre-made profiles for many. All open source.
I almost look forward to the day when it all blows up in the face of those who thought that all of these, in reality economical driven half-baked solutions - disguised as privacy or security, end up causing such a break down, that nothing works any longer.
The amount of sheer stupidity that goes into the "modern web" is just mind bugling.
DoH does absolutely nothing that helps privacy since the destination IP address is always clear and DoH only obscures that which it never should have touched with in the first place.
I have just about had it with the IT industry and the modern web!
> DoH does absolutely nothing that helps privacy since the destination IP address is always clear
There are multiple situations where destination IPs are shared across multiple websites, and DNS blacklisting is a common censorship technique in multiple firewalls and ISP blacklists.
This take is just completely wrong. Of course DNS records should be handled via HTTPS, of course it's a bad idea to do DNS via plaintext. This shouldn't be complicated, why are we still fighting over whether or not encrypting personal data in transit is a good idea?
I have seen more people on Hackernews than anywhere else on the entire web bash HTTPS encryption, and I genuinely do not understand how this forum, of all places, can be home to such a bad security take. Stop designing and advocating for Internet protocols to be monster-in-the-middled!
> Yeah, let's start feeding our mail, ftp, ntp, and everything else over HTTPS as well now we're at it!
...yes?
Holy crud, this is practically the most basic principle in security. If you don't want somebody to read it, encrypt it. This is exactly why we don't use email, unencrypted ftp, or SMS for anything that needs security or privacy. Don't send important information over plaintext!!
I think you misunderstand. Of course everything needs to be encrypted. However, feeding everything through HTTPS is WRONG! This is basic computer and network engineering. If you want to encrypt DNS, fine encrypt DNS, but flipping leave the HTTPS protocol out of it!
Furthermore, the destination IP address is ALWAYS in clear text when you use HTTPS. Which demonstrates exactly why this is so wrong.
DoH - is fake privacy, it's nothing more than extra sugar on Cloudflares spying cake - and more funding for Mozilla.
If you don't encrypt the DNS lookup, it doesn't matter whether or not you're hiding the IP address. And it's just false in general that DoH doesn't improve privacy today, even with the current IP situation.
I mentioned this above, but there are plenty of shared hosting servers that don't have unique IP addresses for every domain. This is not an uncommon thing, and it's one of the reasons why DNS blocking is so common in firewalls, even at the ISP/nation-state level. DoH will also obscure the vast majority of subdomains for a given domain, which, again, are often sharing IPs with each other.
Aside from that, DNS leaking is also very common when inexperienced users set up VPNs, and DoH basically gets rid of plaintext DNS leaks entirely.
Look, would it be nice to get rid of IP addresses? Yes. Does anybody have a scalable solution for getting rid of IP addresses that can be deployed today? No. The closest we have is the Tor network, which is not fast enough or robust enough to handle everyone on the Internet. I have very little sympathy for the argument that because SNI encryption isn't completely rolled out yet and because everyone isn't on Tor that we should ignore solveable security/privacy problems in the meantime.
There are multiple privacy issues with the way we currently connect to websites, and DoH solves one of those issues with very little if any downside. It's worth doing.
> This is basic computer and network engineering. If you want to encrypt DNS, fine encrypt DNS, but flipping leave the HTTPS protocol out of it!
Why? Why not use a single protocol that's widely tested and trusted by security experts? I mean, we didn't come up with a brand new encryption strategy for FTP, we made FTPS.
Why on earth would we want to use 5 different encryption protocols in the browser? That's just pointlessly adding attack surface. What's wrong with HTTPS that means it's a bad fit for encrypting a DNS query? A DNS query is essentially at its core an HTTP request to a remote server, and HTTPS is already very good at encrypting HTTP requests. There's no need to reinvent the wheel here.
By and large, I have not seen any real criticism of using HTTPS for DNS from security experts based on the technology itself -- they all seem to think the technology is fine. Virtually all of the current criticism from industry is coming from corporate players and ISPs who are mad that they won't be able to monitor DNS queries any more. And the fact that they're mad about that is strong evidence that DoH does provide a security gain. Corporations and ISPs would not be complaining about a privacy feature with no benefit to consumer privacy.
> it's nothing more than extra sugar on Cloudflares spying cake - and more funding for Mozilla
This is just blatant conspiracy. It's no harder for anyone to set up a DoH server than it is for them to set up a DNS server. There is nothing in DoH that gives Cloudflare more control over the web other than that they currently sponsor one of (if not the) most private DoH servers on the web today.
You can go into Firefox today and use any DoH server you want with zero consequence or downside. Chrome, by far the dominant browser on the web, does not use Cloudflare's DoH servers by default. There are reasons to be skeptical of Cloudflare in general, but if DoH in particular is a power grab by Cloudflare, then it's a pretty ineffective one.
> Why? Why not use a single protocol that's widely tested and trusted by security experts? I mean, we didn't come up with a brand new encryption strategy for FTP, we made FTPS.
> Why on earth would we want to use 5 different encryption protocols in the browser? That's just pointlessly adding attack surface. What's wrong with HTTPS that means it's a bad fit for encrypting a DNS query? A DNS query is essentially at its core an HTTP request to a remote server, and HTTPS is already very good at encrypting HTTP requests. There's no need to reinvent the wheel here.
This is where you're wrong. A DNS request is far from the same as a HTTP request!
You don't seem to understand how the technology really works in the underlying protocol.
HTTPS is designed to encrypt HTTP traffic, it was never designed to be stuffed by other kinds of traffic. When you stuff DNS into HTTPS you not only get a destination IP in clear text, something you cannot get if you use DoT e.g.
Furthermore, DoH also completely ruins analysis and monitoring of DNS traffic for security purposes. Already DoH has been used in a worm to mask connections to its command-and-control server.
If you want to solve the obvious problems with DNS, you don't keep doing the same mistake over and over again by patching with the same half-baked solution.
DoH does not solve ANY of the issues it is set out to do! I have worked for a long time in the ISP industry, users gets tracked by source IP and destination IP mainly, and figuring out what particular website they have visited, even when the hosting provider has multiple websites running on the same IP, is so easy just by looking at a hash of the payload that it is ridiculous.
> HTTPS is designed to encrypt HTTP traffic, it was never designed to be stuffed by other kinds of traffic. When you stuff DNS into HTTPS you not only get a destination IP in clear text, something you cannot get if you use DoT e.g.
No, I don't see what you're getting at. DoH is an almost strict upgrade over DoT, specifically because DNS queries get mixed in with regular traffic so they can't be separated and analyzed on their own.
I stand by my point, the differences between DNS and HTTP are not large enough to justify the kind of separation you're advocating for. This is not such a fundamentally different technology that we need to use multiple separate systems to handle it, and people definitely shouldn't be advocating for DoT over DoH. The fact that DoT uses a dedicated port is a weakness, not a strength.
For you to argue that DoH is fake privacy, and then to advocate for DoT of all things as a superior alternative makes me skeptical of rest of your arguments. We don't want user DNS settings to be subject to the whims of network operators.
> Furthermore, DoH also completely ruins analysis and monitoring of DNS traffic for security purposes. Already DoH has been used in a worm to mask connections to its command-and-control server.
> DoH is "fake privacy". Period.
DoH can't be both fake privacy and masking worms/ruining traffic analysis at the same time. Either it works or it doesn't, pick a lane.
The fact that ISPs, governments, and network administrators are complaining about DoH is strong evidence that it is an improvement over the current system, because the whole point of DoH is to prevent 3rd-parties from doing traffic analysis and blocking on DNS queries without the user's permission for any reason at all.
ISPs would not be complaining about this if it didn't affect their tracking and blocking capabilities. Network admins would not be complaining about this if it didn't make their jobs harder. The fact that they are complaining about this means we're doing something right.
What's the issue with having TLS-based authoritative lookups? I know it seems out of scope for what Mozilla's asking, but it seems like the missing piece of the puzzle to me.
It's great if your recursive resolver is trusted (maybe you trust cloudflare or nextdns), but what if you don't trust anyone and want to run your own TRR? From what I can see from my own TRR the queries to authoritative DNS are sent in the clear...
Edit On further thought, I realize that querying myanimememes.com's authoritative DNS CAN reveal which site you're interested in, but I believe most sites delegate their authoritative DNS these days to third parties.
There are a bunch of awkward constraints and trade-offs that make it difficult to do DNS-over-TLS to authoritative servers. I have some work in progress trying to write a reasonably comprehensive analysis of how to go about it (I have been waiting years for someone else to and finally lost patience...)
> but what if you don't trust anyone and want to run your own TRR?
You can do that today. Run your own DNS server w/ DoH as an endpoint (dnscrypt-proxy provides an avenue, you can also use nginx to do this). Then have enterprise policies on your network to point DoH clients to use this resolver.
I don't know if this is a solvable problem that doesn't require boiling the ocean. Opportunistic TLS would work fine but if the authoritative server for some domain doesn't do TLS then you're kinda stuck.
This article focus a lot on the technical and operational aspects of DNS and DoH, and only a single sentence about Trusted Recursive Resolver and a link.
The trust model in this change for improved security do not sit in the technical and operational aspects of DNS and DoH (assuming we trust the math involved in encryption that we already use for things like https). What the model depend on is the Trusted Recursive Resolver, and if we find those third-party to be more trusted than other alternatives. Mozilla is however not doing much work to convince and explain why that program should be trusted. Who verify that the logs and commitments are followed through? What is the consequences if someone fails? How can the individual user who is giving away their private data exercise control and agency?
In the linked document the only answer that I can find is this: The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion.
I personally do not think that is enough for me in regard to my own data. Where I live (EU) I at least got GDPR to use if my ISP decide to go rouge with my data. I also got a contract with the ISP. In additional my country have a few different government agencies that in theory could jump in. Neither of those would be an option if the data is shipped over seas.
Mozilla publicly lists the policies which TRRs contractually agree to. In addition to the above, the contracts (some of which have become public) also contain third-party audit requirements.
> What is the consequences if someone fails?
They lose their TRR status, presumably.
> How can the individual user who is giving away their private data exercise control and agency?
DoH is surfaced in Firefox, you can choose not to enable it, or you can choose to configure it to explicitly use any DoH endpoint your choose. On my network I use a Pi-Hole which talks to DoH on the backend and everything on my network is forced through the PiHole and all other DNS/DoH is blocked. You can use similar mechanisms, and Firefox surfaces preferences for DoH.
Just like any other decision, a sensible default which serves users needs to be made, and advanced users can configure things. Firefox chooses the sensible default of using encrypted DNS to trusted resolvers for users, and if you want to do otherwise, you are free to do so. Nothing removes your agency as a user.
> I personally do not think that is enough for me in regard to my own data. Where I live (EU) I at least got GDPR to use if my ISP decide to go rouge with my data. I also got a contract with the ISP. In additional my country have a few different government agencies that in theory could jump in. Neither of those would be an option if the data is shipped over seas.
Nothing in the current implementation ships data outside your jurisdiction. DoH is only enabled in the US pointed at a US-based provider (CloudFlare). There are numerous providers in the EU that may sign up to the TRR program as Mozilla gets to the point of rolling out DoH in Europe. This comment period gives them an opportunity to get feedback prior to getting to that point.
I think perhaps you should send them your feedback directly.
A lot of this could be resolved by a simple legal document given on first use when connected to the Trusted Recursive Resolver. Cloudflare could give the user a contract that obligates itself to follow the rules under the TRR program, with fines similar to GDPR if it ever broke them.
That way the user could exercise control and agency under contract law, and the cost of breaking the obligations would be financially in addition to loosing TRR status. It would also not make the situation worse compared to keeping the default in EU to be the users own ISP.
At most the user would loose the protection given by national consumer agencies, which for me would be a loss but for the average in EU might be less so.
Would CloudFlare agree to do so, or would they just drop out of TRR if such requirement were made?
That's an interesting concept. I'm sure there's lots of pieces to that. Perhaps you should email them that as part of your feedback to their comment period.
What I'd like to see would be a roving/untrusted-network setting. Something easy to flip on/off when you move from home/trusted networks to remote/untrusted networks. With hooks for plugins to be written that let you write rules for flipping it on/off automatically.
Instead of making the decision for people, make it a nice feature for then to use as they see fit. As toggleable feature, it could provide options for not just DoH but for VPN usage, TOR, maybe other things.
So, with Chrome and Firefox having decided to bypass anything set on a given network, how exactly do people propose libraries and schools that are required to block site do so?
Cool but ISP and others can still spy on IPs you make requests to and simply ask for reverse DNS of that IP to still get a good idea of what you are doing? Not sure how we could really achieve 100% privacy from the ISPs.
Isn't this more to prevent ISPs from modifying the results of your DNS queries? Also, in the future when we get encrypted SNI, users of websites behind CDNs like CloudFlare or similar (where the website you are visiting will not be discernible from the IP you're connecting to) will benefit from DoH + eSNI.
Another goal is to deal with the problem of "no log" VPN providers being forced to tag all internet-bound traffic on port 53 with the customer IP it originated from.
This has evolved into the universal compromise, since the VPN provider still gets to claim that they themselves aren't doing any logging. But of course their upstream ISP is now easily able to do so.
This is why mullvad intercepts all DNS queries (even to 8.8.8.8 or 1.1.1.1). Try using OpenNIC from behind mullvad: you won't get the extra TLDs.
Logging DNS makes it easy to selectively deanonymize people. All you have to do is get them to browse to a website that resolves a weird domain name.
Then, start a VPN provider and wait for the NSL to arrive, like Mozilla did.
Not a coincidence that they suddenly started pushing DoH hard shortly after launching their own VPN. Before that it was just another protocol; after the VPN they suddenly were in a big huge hurry to put people on DoH by default whether the system resolver supported it or not.
If your ISP is running the DNS with DoH/DoT then those queries can still be modified. Encrypted DNS does not solve the problem of DNS record manipulation.
For the rest, encrypted SNI might help, but it's still a draft so not really in use. Also 95%+ of sites are identifiable by IP only.
You could be using a VPN. I always found DNS with VPN messy, how not to leak queries, how to resolve internal records, how to react to the VPN servers dhcp info.
Never send DNS queries into a VPN. They are all logged along with the originating client IP.
If your VPN provider claims they "don't log" it just means they're tagging the query with your IP as it leaves their network and letting their upstream ISP do the logging.
Indeed, however there are more use cases for VPNs.
You might run a "road warrior"-setup, connecting to the company network for services and accidentally leaking company DNS info to the airports WLAN provider.
Ziggo and XS4all also have to block their IP addresses. Not sure if Ziggo has a page about this, but the one for XS4ALL is rather comprehensive: https://www.xs4all.nl/geblokkeerd/
Well after Firefox 69 DoH is overriden by laptop's company policy so effectively if one wants DoH always on and free use of addons, 69 is the last usable version.
DNS-over-HTTPS has protected more people in just a couple years than 25+ years of DNSSEC standardization attempts. DNSSEC is moribund; meanwhile, it's not a bad bet that most DNS lookups in 5 years will originate over DoH.
- they want DNS over TLS [multiple reasons why].
- they want to work around "problems" in the architecture of DNS.
- they want to force new functionality [read: protocol changes] on users without other DNS infrastructure adopting it.
- they can.
Are there lots of problems with DoH? Yes. Are we ignoring them all so we can get the above? Yes.
If you love privacy more than freedom, DoH is great. If you want the internet (and local/private networks) not to resemble America Online, DoH should frighten you.
I concur. Not sure why OC got downvoted but I do have a whitelisted Piehole at my home gateway in which to ensure that DNSSEC is clean AND that DNS nameserver is a well-known vetted one.
And DoH is harder to block once they go port 53 or https “incorrectly”.
(For more detailed complaints and arguments on this topic, I wrote a long comment about it a year ago.)
https://news.ycombinator.com/item?id=21701808