That's what browser manufacturers want to do, but that only works in the consumer space or small office space. A company isn't going to happy about a browser that by default will self-configure the intranet to be inaccessible. Especially given the way that updates tend to reset settings when the developers think that their preferred configuration is the only right configuration. And sure, they can probably deploy fixed settings that cover their needs, but what happens when you suddenly need multiple profiles with different configurations to handle the different DNS needs at different sites? "It's always DNS," is even a common saying for sysadmins. Now it's going to get more complicated because web browsers will ignore DHCP? Wow, great.
Simply put, I still don't buy the idea that the browser needs a DNS client. The OS network stack can, and should, be the provider of that service.
This is just, "We know what's best for everybody. It's easier to ignore router vendors, DNS server vendors, ISPs, IEEE standards, and so on if we just do it ourselves in spite of the problems it's sure to cause. That other way is hard, anyways. Damn the consequences, we're going to do it anyways!"
Google or Mozilla picking DoH server for you is somehow good for privacy, instead of using one configured by you and outside of their control. Sounds ridiculous, doesn't it? If not a deliberate attempt to make it harder for users to get any privacy by tracking them across changing ISPs and VPNs.
To be honest, I find the privacy thing is a red herring here. Yes, your browsing habits can be tracked, but there are already dozens easier ways to do that.
What I see as more concerning is that this could hugely shift how the whole system of domains runs. In the worst case, if a single (or a small group of) DoH services turn out to be dominating, they will effectively have full control over all domains - even local ones.
If you want to make a domain inaccessible, no need to bother with the registrar, simply stop serving it.
Want to add a new top-level domain without handing the IANA billions of dollars? No problem, just start to serve it tomorrow - "technically", it won't be a valid domain, but who cares if all browsers resolve it?
Think another domain is rightfully yours? You can file a dispute with the registrar and "proactively" redirect it to your own servers while the dispute is processed.
Maybe this is posted somewhere else, but where does it say that the browser will run towards a specific recursive resolver rather than simply do the job of the recursive resolving itself?
I know that both Cloudflare and Google are attempting become the central recursive resolver for everyone, but it seems to me that if we are abandoning the current system of having the ISP as your automatic recursive resolver, then the step to just do it yourself has gotten very small. The only argument I have heard against it is that users will rebel from the extra milliseconds from not getting a cached response from a local cache, compared to the anycast response that most large site has for DNS (which given the practical nature of anycast, will be more or less the same local provider).
Anycast and servers all over the globe don't help with latency. You also need to keep refreshing DNS records in background and have massive cache. But the memory is limited and you can't refresh everything for everyone. So only a percentage of queries can get responses from cache. If your own resolver could refresh records in background, you would get more responses from cache than sharing it with everyone. You also won't be affected by things like server load and connectivity issues, so you'll get overall better latency with queries mostly served from own cache matching your personal profile.
If you use your ISP's recursive resolver it will likely be a virtual machine on their cloud infrastructure, the very same system that they provide as a content delivery system for the anycast service. The latency for a DNS query will therefore often be the exact same latency for the caching resolver as if you asked the anycast DNS server directly, because it's part of the exact same system, possibly running on the exact same machine.
There is no need to keep refreshing DNS records in background and have a massive cache. The content delivery system does that all day long. Because this is a service that ISPs want to sell, there is also a huge incentive for them to get large companies to pay for the CDN rather than expect them to run background jobs with large memory costs for free.
But even if there were added latencies for some subset of sites, we are talking about milliseconds. With DoH there has been a simultaneous claim that with HTTPS they can push multiple responses for a single request (something which the DNS protocol supports but has never been used in any implementation), which means that now we can reduce the latency to a single round trip. The difference between a single round trip to Cloudflare's CDN recursive resolver, and a single round trip to the official anycast DNS resolver with DoH, is marginal if any. If the site is located on Cloudflare the whole question is also moot.
And you think you'll have better privacy sending queries to whatever server DHCP hands out?
If you're configuring your own DNS server you're waaaay out of scope for the problems this is trying to address.
> And you think you'll have better privacy sending queries to whatever server DHCP hands out?
Yes, because you have to trust one less third party if you use whatever internet connection DHCP provides you. ISPs can see IP addresses you connect to anyway and can figure out what domains and services they belong to. If you don't trust that DHCP, you have to use at least a trustworthy VPN to have some privacy improvement, DoH to a third party will only make it worse.
At work, yes. DoH will leak corporate internal DNS and lead to the public resolvers getting null routed.
At home, I block all the public resolvers on my router and intercept DNS, tunnel it through a vpn mesh.
For most people at public open WiFi spots, DoH could certainly help.
Yes. Because that's my network, my DHCP and something I have 100% control over.
There's literally nothing in the universe which better protects my privacy.
I think the criticism there is guest WiFi, but you can always configure your system to use a specific DNS server if you wish.
> browser that by default will self-configure the intranet to be inaccessible.
Maybe I am not up to date, but Mozzilla has always been explicit that it would not be activated by default (and that one way of activating it would have the system DNS as fallback)
> The OS network stack can, and should, be the provider of that service.
I understand why it is important not to mess with the underlying network stack, but I would also like not to be redirected to random websites when on a public wifi (even if sometimes blocking data intensive domains like youtube is a good thing). I feel that the original mozzilla blog had a pretty good explanation of the advantages.
Eh.... I agree that this is just "Google doing Google", but also, browsers have such intense requirements on DNS that they may want to do things the OS resolver can't. And you can't just tell arbitrary applications "Don't use the host resolver, use this other resolver", they'd literally need different calls, or you would need to overload the calls with LD_PRELOAD to a different library, etc. It would be pretty messy. Until there's a more interoperable, transparent way to replace a DNS client, shipping your own for you own weird edge cases seems fine. And anyway, you can disable it.
Here's the old thread by a Chrome dev on why they wanted their own resolver: https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok
> browsers have such intense requirements on DNS that they may want to do things the OS resolver can't.
I don't really agree. If the host's DNS client is using a good caching algorithm, then it should have a cache hit rate in the 80s or 90s if your hostnames are remotely sensible. Most people go to the same sites over and over, and those sites typically feature content from the same networks. In that case, over 80% of the DNS traffic isn't actually network traffic. It's just querying the host's cache database. Furthermore, the browser knows every link the user has access to on a page or bookmark. They can be (and probably already are) pre-fetching DNS for those sites.
In that case, they need to work with OS vendors to optimize that. OS vendors should clearly wish to do this; nearly every user wants a faster Internet experience, and if Google's dev is right that a DNS query is a significant bottleneck, then they should be interested in improving that aspect of the system.
It sounds to me like what they want DNS to do is return not just the IP of the actual address, but all the domain names and IPs of all known resources at that domain name. Of course, if you've got a CDN or other system, that makes DNS suddenly very complicated compared to the current system.
No, the more I think about this the more it feels like a way to move the Internet away from open DNS towards some siloed proprietary system where the core databases that control who is on the Internet name system suddenly aren't under IANA control.
> I agree that this is just "Google doing Google", but also, browsers have such intense requirements on DNS that they may want to do things the OS resolver can't.
That sounds like a bullshit argument right there.
Name on example, and then help me understand why it should be fixed again and again in every browser instead of once in core DNS.
Firefox Nightly lets you set the DoH server in network settings: https://i.imgur.com/wBAtJ7Z.png.
Note that this is still an experimental feature, so when this ships it won’t necessarily default to Cloudflare nor be enabled by default.
Manually setting it in about:config is not good enough.
When you connect to a network that needs its own DNS to access its resources, you are not going to change that setting each time you connect to that network.
Even more interesting thing happens, when you physically roam between several of such networks (for example: your company and your customer). What was until now handled transparently handled by DHCP for you, now you have to manually configure each time you connect to that another network.
Now, we have moved from static network config decades ago, and for a good reasons.
But this isn't about:config. This is in settings.
That assumes that you can trust the networks you connect to. There is a lot of evidence available that there are a lot of networks out there that should not be trusted.
Indeed - which is why e.g. Windows asks you whether your LAN/Wifi is a "home network", "work network" or "public network". You could use the same strategy to find out whether or not you should trust the networks DNS settings.
Assuming DNS resolution still happens in the OS, this is actually a somewhat sensible suggestion! Use DoH on public WiFi (although basic network hygiene suggests you should really use a VPN there), and use the DHCP-provided DNS server on home and work networks.
At home, the cable company is just as bad (or the same as) the mobile operator. Neither of these scenarios do you want to trust your ISP, or add to their profile of you.
At work though, probable the opposite.
> That assumes that you can trust the networks you connect to.
Which an overwhelming part of the world does. Forced DoH is making problems for the clear majority when trying to solve a minor problem for a tiny majority.
Clearly that's not going about things the right way.
Anyhow: If you don't trust a network... Why are you connecting to it?
I don't trust most of the networks I connect to. Home network - nope, I don't want to use Verizon's DNS servers; subway wifi - no; Coffee Shop - lol, no. Etc.
Why should I have to trust the network I'm connecting to? That seems like a major violation if the end to end principle. It's also just impractical.
If the overwheming majority of the wild trusts the networks they are connecting to, that seems like pretty good evidence that DoH or something like it has value.
This is a good start, but I don't see why you couldn't make it autoconfigurable like normal DNS is.
I suspect, few users will have anything useful to put in that field, except the default.
Normal DNS is autoconfigured via DHCP.
The browser doesn't have access to the DHCP data because it usually happened during the OS startup way before the desktop even becomes visible.
That doesn't stop you from using a custom DHCP option.
Nope. Mozilla blog says:
> "Moving forward, we are working to build a larger ecosystem of trusted DoH providers, and we hope to be able to experiment with other providers soon."
More in <https://blog.mozilla.org/futurereleases/2018/11/27/next-step...
Will any of these "trusted DoH providers" have access to my LAN internal host-names? And why should I trust those more than I trust my local pihole?
I'd rather have less people to trust, thank you.
There are some regions in the world, where you're better off with a DoH server that Mozilla has leverage with (because of a business contract).
Most notable, this doesn't hold true for Europe, where you do have a good contract with your ISP and GDPR protects you from lots of shenanigans that are possible in the US.
> There is a general expectation that when a browser starts turning on DoH, it will give the user a choice of trusted DoH providers and enable end users to specify their own trusted configurations, similar to the list of search providers seen in browsers today.
Is this really the general expectation?
From what I've read so far, I'd expect that both Chrome and Firefox will simply hardwire this to dedicated resolver endpoints selected by them - and maybe provide group policy or about:config options as an override, with strong communication that ordinary users should not use them.
"everything else over DoH"
I have local DNS servers set to resolve both our intranet and all external queries. Some external queries are blocked for various reason. Either a browser uses the local network settings or it gets banned from the network. This is not a discussion because the real world intrudes on what browser vendors think is best.
Implicit proxying and inspection has always been a farce when it comes to "locking down clients". If you want to control traffic to clients you operate you should do it as an explicit proxy. If you want to control traffic to clients you don't operate it's not actually possible to both respect the client and inspect the traffic enough to meet security goals.
This tradeoff has always been true but everyone settled on the "good enough" that means security isn't actually strong, clients aren't actually treated as internal or external, and protocols are ossified because the FW expects wxyz to implement the above two failures.
We don't want Google or Mozilla to have a running list of our users DNS requests. We don't want Google or Mozilla to have a list of our internal servers. They are browsers and can use the same network stack as any other program. I have other types of filtering, but the whole idea of a browser ignoring internal services is going to get it banned.
This set of concerns has little to do with DoH, Chrome has been doing a hell of a lot more user tracking than which DNS lookups were made for longer than DoH has been around.
Just because they do other user tracking, doesn't mean I want DoH to add to the list.
It sounds like you will have to ban all browsers on whatever network you manage.
Why would I have to ban all browsers? Why would anyone accept Google or Mozilla knowing all the sites they visit?
Ok, so suppose I have a non-rooted Android phone or iPhone. Also suppose, they go all-in with DoH, without any override option.
The user doesn't control the client, because it's locked down.
The admin doesn't control the client, because DoH is tamper-resistant.
Who exactly does control it?
If it's your devices: You. Get an MDM, stop letting users install apps that ignore the device proxy settings (or install their own apps in general).
If it's not your device: Them. It's their device, you aren't (and shouldn't be able to) control their traffic.
Yeah, but the owners of those devices can't control the traffic either.
I'm not sure what exactly you mean here, why can't a user control their own traffic and what does it have to do with DoH or it's impact on existing security implementations in businesses?
Because, if they use a non-rooted phone or device, a part of traffic will come from system apps or the OS itself that the user has no control over. Before, this traffic could be blocked by intercepting DNS - now, there wouldn't be a way to do it at all.
Firstly you still can, add a root certificate and continue using VPN/explicit proxy.
Secondly, again none of this has anything to do with DoH. Users still set the system DoH/DoT DNS server the same as they always set the system DNS server and assumed system apps/installed apps weren't using custom sockets/transports/encoding to get around it. Users still control the browser feature enablement and can change destination server.
DoH changes none of this and is irrelevant to it, DoH is just a standard serialization of something anyone has been able to do for decades now. What DoH DOES do is prevent every random node inbetween a device and the DNS server from inspecting/modifying the traffic unless the end station is explicitly configured to allow it.
"Either a browser uses the local network settings or it gets banned from the network."
How would you detect that a browser isn't using the local network settings?
In this case, when we are testing the initial setup before we create our images, we would see a bunch of traffic we didn't expect or we read articles that tell us our preferred browser is doing something we find unacceptable. Its not like most enterprise / educational institutions don't test their staff setups.
You require all Internet access to traverse a proxy server, the hostname of which only resolves internally.
I think its going to come down to smart network management in the client OS.
If I'm on a trusted network, use the network resolvers (either via UDP 53 or DoH, or whatever) and if I'm not use preconfigured resolvers like 184.108.40.206 or something, part of not trusting the network should also be not trusting the resolver. Before DoH this was a moot point since UDP 53 can be trivially captured and redirected, now the client OS can actually do something about it.
I don't like the idea of individual applications overriding system resolver settings.
> AFAIK it's not possible to distribute internal DoH servers via DHCP
Back in the days we used to call this DHCP option 6, i.e. DNS.
I'm not sure why you want to replace a DHCP provided DNS server with a DHCP provided DoH server.
Because why on earth would the DHCP-server provide different DNS-servers for those two use-cases? The idea itself makes no sense.
Can we please just get back to regular DNS, please? It works. It scales.
It's possibly the single last thing on the internet which is still decentralized, and I'd hate to see this become another centralized, single point of failure, walled-garden bullshit.
I assume you agree on the need for securing DNS (DNS over TLS for example).
Just watched a UKNOF presentation on DNS changes. Sounds like google/mozilla were fed up with the sluggishness of standards bodies, network operators, and OSes in securing DNS, so have gone for their own version. Charitably I'd like to think that this is a wakeup call from Mozilla, "sort out your shit or this is the future, but with google owning it"
Isn’t this a resolver configuration issue on the client?
The browsers are not respecting DHCP in this case, but that doesn’t mean that other resolvers can’t be configured via DHCP to try DoH or DoT.
If you're the admin, you can disable DoH through a group policy, no?
No. Well, not for shops that have non windows. In the bay area, it is quite common to have a mix of Windows, Mac and some Linux. We are 60+% Mac.
Serve the internal IPs from public hostname DNS records?
Internal DNS I think is largely not a good thing and I'd be happy to see it go.
As a sysadmin I disagree strongly.
Being able to host my own authoritative servers for my domains inside my org is a fantastic feature of DNS.
It lets me do things like split-horizon, which lets me deal with clients coming from different origins that may reach certain servers with or without NAT.
I'm also not keen on putting all my records on public name servers, for everyone to discover.
You could run your own DNS server. As long as you can get the relevant TLS cert, it doesn't even need to be public. You just would need to accept DOH connections
First thing that comes to mind with this idea is that Active Directory is going to be around for a long while yet.
Second, my network filters DNS rebinding, expect from plex.com. I guess I could ad my domain to it, but that's an extra point of failure.
Could you develop ? You think you should answer with internal IPs with external DNS records and everything is addressed at the routing level ?
The DNS zone would be public and tied to a real domain. So both private and public clients would be able to query Eg:
ci.myorg-int.com -> 10.11.12.13
The downside is that now all the internal services are discoverable using DNS scanning techniques. It means that competitors can see what services the organisation is using. Or attackers can better prepare themselves for infiltration.
Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. For example and attacker can trick your browser in requesting a resource from xxx.somedomain.com that points to 10.11.12.13. If the CI is vulnerable to CSRF then the attacker can use the browser to exfiltrate information or do some actions on the CI.
> Another downside of DoH is that it's not possible to filter out DNS rebinding attacks.
Your web server should be configured to not serve content just by IP and require Host header to be a domain you control. (like using server_name in nginx) Otherwise they can just point to 10.11.12.13 directly anyway.
Sure, the web server SHOULD... but what if it is misconfigured? Or doesn't have an option to properly validate the Host header?
This is an internal client using an internal IP address to communicate with an internal service... just so happens that a malicious user made the internal client talk to it maliciously.
DNS rebinding attacks being stopped by the resolver are a great place to start and something we can do. Bypassing that protection in the name of resolving using DoH just means you've made things less secure.
I agree. I think DoH should be put on the edge of the network, using something like dnscrypt-proxy.
I don't think it should be put in the browser. It would actually made my setup less private, since I use DoH over tor.
Though configuring the http servers (like printers or whatever) and/or putting them behind a proxy on a sparate network, if they are sensitive/not configurable, should be done too.
> Your web server should be configured
I think you underestimate the number of things on your network that run unconfigurable web servers.
DNSMASQ lets you luckily whitelist certain domains from dns rebinding protection (like Plex, which relies on resolving to internal IPs). I'm still not comfortable exposing internal network details to the internet however.
It's still not clear to me how this will work in internal networks. AFAIK it's not possible to distribute internal DoH servers via DHCP, and it seems orthagonal to the goals of DoH since "cafe wifi" could give you dodgy servers. But how do I as a network administrator with internal DNS domains serve my users?
Maybe browsers and OSs could look at the local search domain, and send queries matching to DHCP servers, and everything else over DoH, kinda like split dns with a VPN?
Why would you refer to a DNS server by domain name and not by IP in the first place?
I can think of some possible motivations:
(1) Some kind of load-balancing thing and/or edge DoH servers. It gives you an opportunity to connect to a DoH server near you. Latency matters for DNS, and for traditional DNS, DHCP takes care of hooking you up with a nearby server. This could give comparable functionality for DoH. (This could probably also be done at the IP routing layer. But it's nice to have options.)
(2) Decoupling. You can change DoH server IP addresses without releasing a new browser build. And anyway, if you did try to do it by releasing new browser builds, you'd have users who don't bother to update.
Also, presumably these services will use pinned certificates so it won't be possible for someone MITM the query for the DNS provider and do anything more than just DOS your DoH.
Comically enough, browser manufacturers aren't going to hardcode the IP of the DoH server. They will look it up using the DNS you already control. Give them a non-routable address and log the attempt. Then go tell that user to stop.
If some crazy group does hardcode it then they have made your job even easier.
for me this feels like trading the devil you know, for the devil you dont. my ISP snoops my DNS queries if i use their DNS, however Mozilla has shown time and time again they dont care what customers think in terms of privacy or features. no one wanted video chat, DRM content, or pocket and yet here we are looking at another feature from Mozilla that privileges them to my DNS queries.