Often regarded as a critical piece of the internet fabric, DNS functions as a directory service for the internet. Its biggest vulnerability has always been that its traffic was always sent across the wire in clear text (meaning anyone could read the queries). The solution for this came in the form of Encrypted DNS, which by its name meant the queries would be encrypted while in transit (similar to what we see with HTTPS).
During the same period, there has been a subtle fight between OS and Browsers for who controls this communication. It’s unbeknownst to many end-users, but the debate does spill over into a user’s experience. This article will highlight how by focusing on the macOS.
MacOS and Encrypted DNS
The MacOS introduced native support for encrypted DNS in Big Sur (version 11). This came in the form of using configuration files known as mobile.config. This configurations could be pushed to devices to standardize how a device connects to a network. Via these configurations, you could set the rules on a device to use a DOH (or DOT) stamp on the device, which would then dictate what encrypted DNS channel the device would use.
This worked great in Big Sur!
Then in version 12, Monterey, this broke for all browsers except Safari. The mobile.configs no longer worked on MacOS, but continued to work in iOS. When we say it didn’t work, we mean that the DNS was no longer encrypted. The browsers were defaulting to the devices IPv4 settings, ignoring the mobile.config.
This past week, version 13 (Ventura) was released and it appears the mobile.config is working on most browsers, except Chrome. The problem here is that Chrome adoption is massive compared to all other browsers put together. This article dives into what we saw and how we narrowed down the issue, isolating the problem to Chrome not respecting the macOS native support for encrypted DNS.
Chrome on MacOS Ignores Mobile.Config
The latest version of MacOS (13) seems to have fixed the mobile.config problems with encrypted DNS for all browsers, except Chrome and MS Edge. Here are the browsers we tested:
| Option | Description |
|---|---|
| Chrome | Does Not Work |
| Firefox | Works |
| Safari | Works |
| Opera | Works |
| Brave | Works |
| Edge | Does Not Work |
We focus on Chrome in this article, and not Edge, because MS Edge is built on Chromium so it’s essentially speaking to the same stack. What is odd to us is that Brave does work, and that browser is also built on top of Chromium.
We have not been able to figure out what Chrome is doing, but from what we can see it’s defaulting to the local, or network, DNS IPv4 settings before making a request to the encrypted DNS DOH configuration. It is as if the Chromium DNS stack has not been updated to support the OS encrypted DNS implementation. That or something changed between OS updates that has not been communicated to the Chrome team.
Here is what happens when you enable the a DOH config via mobile.config on MacOS 13 and use Chrome.
2022-10-25 18:18:19 A query: dohconfig-family.badexample.com: clear-text-dns
2022-10-25 18:18:19 HTTPS query: dohconfig-family.badexample.com: clear-text-dns
2022-10-25 18:18:19 HTTPS query: dohconfig-family.badexample.com: clear-text-dns
2022-10-25 18:18:19 A query: dohconfig-family.badexample.com: clear-text-dns
2022-10-25 18:18:19 A query: dohconfig-family.badexample.com: encrypted-dns
2022-10-25 18:18:19 A query: dohconfig-family.badexample.com: encrypted-dns
2022-10-25 18:18:19 A query: dohconfig-family.badexample.com: clear-text-dns
2022-10-25 18:18:19 HTTPS query: dohconfig-family.badexample.com: clear-text-dnsOf all the requests Chrome sent, only two went to the encrypted option set via the mobile.config file. This explains the issue we’re seeing with Chrome not working with the MacOS encrypted DNS native support.
We tested by manually setting the device locally with a set resolver, and by setting the router. In both instances, the results were the same. Chrome always defaulted to the local IPv4 settings, ignoring the encrypted DNS option.
Coincidently, when you try other browsers it works as it should, where the mobile.config is at the top of the communication hierarchy and all local and network settings are over ridden.
The next logical test was to see if this was specific to encrypted DNS protocols or maybe something with the native handling of encrypted DNS by the MacOS. To test this we leveraged the secure DNS option in Chrome (which uses encrypted DNS but leverages the encrypted DNS option in the browser instead of the MacOS). Doing so yielded this output:
2022-10-25 18:39:33 A query: dohconfig-family.badexample.com: encrypted-dns
2022-10-25 18:39:33 A query: dohconfig-family.badexample.com: encrypted-dns
2022-10-25 18:39:33 HTTPS query: dohconfig-family.badexample.com: encrypted-dns
2022-10-25 18:39:33 A query: dohconfig-family.badexample.com: encrypted-dns
2022-10-25 18:39:33 HTTPS query: dohconfig-family.badexample.com: encrypted-dns The logs above show that the secure DNS configuration in the browser is working as it should. This tells us that the browser will support encrypted DNS, but for whatever reason is not respecing the macOS native options.
Solving the Encrypted DNS Issue with Chrome and MacOS 13 Ventura
Solving the Chrome support for encrypted DNS using the MacOS native option will require you to configure Secure DNS in the browser in addition to using the mobile.config file. Not ideal, but manageable.
If you’re an organization managing a fleet of devices you can use your MDM to push a profile to the MacOS. This mobile.config will apply to all browsers, and applications on the OS, with exception to Chrome and MS Edge. For Chrome and MS Edge, we recommend configuring the browser to be managed via the Google Workspace Admin and forcing Secure DNS with your respective stamp.