DNS-over-https on macOS and iOS

DoH mobileconfig screenshot

Why bother with DNS-over-https?

I have run a DNS-over-https proxy for a while now, to experiment with it.

First, like the rest of my browsing acting, my DNS traffic is private. But DNS traffic is not, by default, encrypted. DNS-over-https — or “DoH” — fixes that.

Second, encrypting the traffic inhibits interference as well as protecting my privacy. Encryption isn’t just about privacy. Someone sitting in the path between my client and a DNS server could modify the response that I was getting, routing me to the wrong site.

Third, I want to use my DNS server, whatever network I am on. There are a few reasons for this:

Firefox has let you specify a DoH server in its Preferences pane for ages, but web browsing in Firefox accounts for only a small fraction of my DNS look-ups. I wanted to route all my DNS look-ups to my server, from my phone and my computers.

I needed a solution (or solutions) which would work for both macOS and iOS. And there is one…

(I don’t know whether tvOS – the operating system of the Apple TV — supports this. That could be interesting if I were travelling more. Update: I’ve successfully installed the .mobileconfig profile on my Apple TV too, but I haven’t tested it yet. It looks like it should work though, which would be interesting if I were travelling abroad and taking an Apple TV with me…)


This has worked in the handful of scenarios I have tested. What I cannot do is promise that it works in every scenario.

I do not know what Apple does behind the scenes, and whether it definitely means that all your DNS traffic is routed over https.

I also do not know whether a network operator can specify that DoH is not permitted on its network. Firefox has adopted a mechanism to facilitate this users who have had DoH enabled by default, and I do not know whether Apple has done the same. I would hope that there is no equivalent for when someone chooses to enable DoH themselves, but I do not know.

How to route your iOS or macOS DNS look-ups over https

As far as I know, you cannot — yet, at least — configure DoH using either the macOS or iOS GUI.

Instead, you need to use something easy, but still less user-friendly: a simple config file, which you load onto your device as a profile.

It sounds worse than it is.

1.) Create — or just download — a .mobileconfig profile

Pre-made templates for common DoH providers

Someone called Paul Miller has uploaded a lot of template .mobileconfig profiles to Github, and these cover many of the common DoH providers.

If you want to use Google, Cloudfare, or Quad9’s DoH servers, you should be able to download the relevant file and install it on your devices, without needing to do anything else.

Creating a .mobileconfig profile for your own DoH proxy

If you run your own DoH proxy and want to use that, download one of the .mobileconfig templates for DoH (e.g. this one, for Quad9), and make a couple of changes:

2.) Load the .mobileconfig profile onto your devices

If you’re using macOS, just double-click on the .mobileconfig file.

For iOS, you’ll need to get it onto the device. I tend to use AirDrop for this, as it will then prompt you to open it in Profiles, which is what you want.

Once you’ve gone through the profile installation process, you should be routing your DNS look-ups over https to your chosen DoH proxy.

In macOS, it shows up in the Network pane as a new connection.

On iOS, it appears in Settings, alongside VPN connections.

3.) Check it works

Even though it was showing that it was working, I was keen to verify this.

For me, this meant logging into my Pi-Hole instance (since my DoH proxy proxies traffic into Pi-Hole), and checking the access log.

Even though I was connected to a cellular network, and did not have a VPN connection up, I could see my DNS look-ups were going via Pi-Hole. Success!

If you are using a third party DoH service, I’m not sure how you could test it. If you knew there was a domain name you could not resolve over your Internet connection without DoH running, testing using that domain name should work, as long as your ISP is not also doing IP blacklisting / null routing.