Encrypted DNS on macOS: DoH and DoT With Configuration Profiles

HTTPS hides what you send to a website, but before your Mac can even open that connection, it has to ask a question in plain text: "what server does this name point to?" That question — a DNS lookup — travels unencrypted by default on most networks, which means your internet provider, your office network administrator, or anyone sharing an unsecured Wi-Fi network can see every domain you resolve, even if the pages themselves are fully encrypted afterward.

Why plain DNS leaks

Traditional DNS, standardized decades before HTTPS became the web’s default, sends queries over plain UDP or TCP on port 53 with no encryption and, in most home and public network setups, no authentication of the resolver either. A network operator does not need to break HTTPS to build a list of every domain you visit — it only needs to watch your DNS traffic, which sits in the clear right next to it. This is also how many DNS-based content filters and some forms of network-level surveillance work: not by inspecting your encrypted traffic, but by simply logging or blocking the lookup that has to happen before that traffic exists.

DoH and DoT: two ways to encrypt the same lookup

Two IETF standards solve this by wrapping the DNS query itself in encryption. DNS-over-TLS, defined in RFC 7858, wraps DNS queries in a dedicated encrypted TLS connection on port 853, distinguishing it from ordinary traffic and making it easy for a network to identify — and, in principle, for a network to block it entirely if it wants to stop encrypted DNS specifically. DNS-over-HTTPS, defined in RFC 8484, instead maps a DNS query onto a standard HTTPS request on port 443, the same port used by nearly all ordinary web traffic — a design choice that makes DoH queries far harder to distinguish from and therefore block separately from general web browsing.

Apple’s native support since macOS 11

Apple built encrypted DNS directly into its networking stack rather than leaving it to third-party apps, announcing the feature at WWDC 2020 alongside macOS Big Sur (macOS 11) and the equivalent iOS 14 release. The session laid out two ways to turn it on: a NEDNSSettingsManager API for apps to configure it programmatically, and — the option most people will actually use — a configuration profile carrying the com.apple.dnsSettings.managed payload, documented in Apple’s device management reference, which lets you specify a DoH or DoT resolver’s address and have every app on the system use it by default, no third-party software required.

A sample configuration profile

A configuration profile is an XML property list (a .mobileconfig file) that macOS can install through System Settings once you double-click it or drag it into the Profiles pane. The example below points a Mac at Quad9’s public DNS-over-HTTPS resolver — a widely used, no-account-required service that also blocks connections to domains known for phishing and other malicious activity by default. Replace the placeholder identifier and UUID values before using it; every real profile needs its own unique PayloadUUID.

quad9-doh.mobileconfig

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key>
      <string>com.apple.dnsSettings.managed</string>
      <key>PayloadIdentifier</key>
      <string>com.example.dns.quad9-doh</string>
      <key>PayloadUUID</key>
      <string>REPLACE-WITH-A-UNIQUE-UUID-1</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>PayloadDisplayName</key>
      <string>Quad9 Encrypted DNS (DoH)</string>
      <key>DNSSettings</key>
      <dict>
        <key>DNSProtocol</key>
        <string>HTTPS</string>
        <key>ServerURL</key>
        <string>https://dns.quad9.net/dns-query</string>
        <key>ServerAddresses</key>
        <array>
          <string>9.9.9.9</string>
          <string>149.112.112.112</string>
          <string>2620:fe::fe</string>
          <string>2620:fe::9</string>
        </array>
      </dict>
    </dict>
  </array>
  <key>PayloadDisplayName</key>
  <string>Encrypted DNS - Quad9</string>
  <key>PayloadIdentifier</key>
  <string>com.example.dns.quad9-doh.root</string>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>REPLACE-WITH-A-UNIQUE-UUID-2</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

To use Cloudflare instead, set ServerURL to https://cloudflare-dns.com/dns-query and ServerAddresses to 1.1.1.1 and 1.0.0.1 (with 2606:4700:4700::1111 and 2606:4700:4700::1001 for IPv6) — or, for DNS-over-TLS instead of DoH, set DNSProtocol to TLS and ServerName to one.one.one.one, per Cloudflare’s published DoT documentation.

Installing it

Save the file with a .mobileconfig extension and double-click it, or open System Settings, go to Privacy & Security, then Profiles, and drag the file in.
macOS will show the payload contents — including the resolver you configured — before you approve it; review this every time, since a profile is exactly how a malicious actor could redirect your DNS if you install one from an untrusted source.
Click Install and authenticate. An unsigned profile like this sample will show as "Unsigned" verification status; that is expected for a hand-built profile and is not itself a sign of tampering, but for anything beyond personal testing you should sign the profile so its integrity can be verified.

Verifying it worked

Do not just trust the settings pane — check from the terminal.

Terminal

# Show the resolvers macOS is actually configured to use
$ scutil --dns
# Look for your interface's resolver entry — it should now show
# the DoH/DoT server address you configured, not your router or ISP's resolver

# Confirm a lookup succeeds and see which resolver answered
$ dig example.com

# Cloudflare's own diagnostic page also reports whether your
# connection is using encrypted DNS when you open it in a browser
$ open https://1.1.1.1/help

If scutil --dns still lists your router’s address or your ISP’s resolver as the active DNS server, the profile did not take effect — check that you installed it under Profiles rather than just downloading it, and that no other network configuration (see below) is overriding it.

Pitfalls that make this stop working silently

A VPN app very commonly overrides system DNS settings while it is connected, routing lookups through its own resolver instead — check your DNS configuration again after connecting to a VPN, not just before.
Captive portals on hotel, airport and coffee-shop Wi-Fi generally cannot complete their login flow over encrypted DNS, since they rely on intercepting a plain DNS request to redirect you to a login page; you may need to temporarily remove or disable the profile to get online, then reinstall it once connected.
Some browsers — Firefox and Chrome among them — ship their own, separate DoH setting that can override or duplicate the system-level configuration; check the browser’s own network settings if its behavior does not match what scutil --dns reports.
iCloud Private Relay and encrypted DNS solve different, overlapping problems — Private Relay hides your IP from the sites you visit in Safari, while encrypted DNS hides which domains you resolve from your network; using one does not make the other redundant.

How FireAI and HisnLabs fit in

FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves.

FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.

You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.