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.
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.
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.
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"
Emacs has been a decent haven for me in my search for privacy, interopability, programmability: my user agent.
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...
Ideally then for all more involved software experiences native software would have to be shipped.
Stop with this stop political stuff in tech like root level zone server type of stuff.
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?
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?
Why not? Just make sure to use a VPN/etc to access services over the gateway.
I mean, this is the default case for everything going over the internet. Do you trust every router in the path?
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).
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.
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.
Exactly. That's what I said.
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)
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.
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.
Seems more plausible to just run DoH for my DNS and then not worry about my ISP snooping on my DNS requests.
Shame that I have 20 applications on several different users on two dozen different machines to configure
The same applies for your "home" environment. Since you usually don't want to run multiple DHCP servers, this would also work there.
option wpad-url code 252 = text;
option wpad-url "http://10.10.10.10/proxy.pac\n";
There is some work regarding this.
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.
I’m sure others do too I just can’t say for certain.
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.
Windows has support
https://techcommunity.microsoft.com/t5/networking-blog/windo...
You can put the proxy anywhere on the network and set up DHCP to point the clients to this proxy.
https://www.bleepingcomputer.com/news/security/microsoft-add...
i.e. Smart TVs will do this to get around pi-hole style ad blocking.
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.
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?
> 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.
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?
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.
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.
Like what?
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.
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.
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.
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.
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.
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.
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.
[1] - http://tinc-vpn.org/
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.
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.
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?
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.
I hadn't looked into this recently but it looks like you can configure a pihole to use DoH for outbound requests:
https://docs.pi-hole.net/guides/dns-over-https/
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.
Best of both worlds!
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.
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.
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.
There is no problem.
This is so obviously bad I don't understand.
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.
I think you're missing the point, here.
A lot of enterprises run their own delegating DNS server for a variety of reasons that have nothing to do with ad blocking.
DoH breaks that en masse.
Firefox has always struggled to gain adoption in corporate settings, and this looks like a nail in the coffin .
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.
https://firejaildns.wordpress.com/
and a survey of public DoH servers:
https://firejaildns.wordpress.com/2020/09/22/a-survey-of-pub...
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.
(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