NxValue Stack

Encrypted DNS Explained: DoH vs DoT and How to Set It Up on Every Device

Ordinary DNS is sent in plain text. Every time your phone or laptop looks up a domain, that question travels across your Wi-Fi, your ISP, and anything else along the path, and anyone in the middle can read it or even tamper with the answer. Encrypted DNS fixes that by wrapping the lookup in TLS, the same technology that protects websites.

This guide explains the main flavours of encrypted DNS, shows how to turn it on for each kind of device, walks through what it takes to run your own encrypted endpoint, and covers how to test it and what it still does not hide.

What encrypted DNS protects

Encrypted DNS protects the conversation between your device and the DNS server you chose. That gives you:

It does not make you anonymous. Your ISP can still see the IP addresses you connect to, and often the site name sent during the TLS handshake. Encrypted DNS closes one door, not all of them.

DoT, DoH and DoQ: what's the difference?

All three do the same job. They differ in how they travel across the network.

For everyday use, the practical rule is simple: use whichever one your device supports natively. Android's system setting uses DoT. Browsers use DoH. Apple's configuration profiles can use either.

What you need before you start

Every device setting below asks for the same thing: a hostname (for DoT) or a URL (for DoH) that points at a resolver you trust. Large public resolvers publish theirs, so those are easy. If you want a private resolver with your own filtering and no shared logs, you need an endpoint of your own, and that is the part that takes work. The section "Running your own endpoint" covers it in detail.

Android

Android has encrypted DNS built into the system, so it applies to every app, on Wi-Fi and mobile data.

  1. Open Settings → Network & internet → Private DNS (the path varies slightly by manufacturer; searching Settings for "Private DNS" is quickest).
  2. Choose Private DNS provider hostname.
  3. Enter your resolver's hostname and save.

Android uses DoT for this setting. When you enter a hostname, Android requires an encrypted connection to it. If that server becomes unreachable, or its certificate expires, lookups fail rather than falling back to plain DNS. That is good for privacy, and worth knowing if something suddenly stops loading.

iPhone, iPad and Mac

Apple devices don't have a simple "enter a hostname" box. Instead, you install a DNS configuration profile that tells the system which encrypted resolver to use. The profile can specify DoH or DoT, and once installed it applies across the whole device.

  1. Get a .mobileconfig profile from your resolver provider, or create your own.
  2. On iPhone or iPad, open the profile, then go to Settings → General → VPN & Device Management to install it.
  3. On a Mac, open the profile and approve it in System Settings → Privacy & Security → Profiles.

To remove it later, delete the profile from the same screen.

Windows 11

Windows 11 supports DoH in its network settings.

  1. Open Settings → Network & internet, pick your Wi-Fi or Ethernet connection, and open its hardware properties.
  2. Next to DNS server assignment, choose Edit and switch to Manual.
  3. Enter the resolver's IP address and set DNS over HTTPS to on, using the provider's DoH template URL if asked.

Windows has historically been fussy about custom DoH servers that aren't on its built-in list. If the interface won't accept yours, the netsh dns command can register a custom DoH template, and Microsoft's documentation covers the exact syntax for your build.

Linux

On systems that use systemd-resolved, DoT is a couple of lines in /etc/systemd/resolved.conf:

[Resolve]
DNS=203.0.113.10#dns.example.com
DNSOverTLS=yes

Replace the address and hostname with your resolver's, then restart the service:

sudo systemctl restart systemd-resolved

DNSOverTLS=yes is the strict mode, so lookups fail if the server can't be reached over TLS.

Browsers

Browsers can use DoH on their own, independently of the operating system. That is convenient for a single browser and confusing if you forget it is on.

One catch: a browser that uses its own DoH provider bypasses a network-level filter such as Pi-hole. If you run a filtering resolver, point the browser's DoH setting at it too, or turn browser DoH off and let the system handle DNS.

Running your own endpoint: what it actually involves

If you run a private resolver such as Pi-hole, it speaks plain DNS on port 53. To make it reachable over DoT or DoH, you put an encrypting front end in front of it. Here is the realistic shape of the job, so you can decide whether it suits you.

1. A hostname and a public address

Devices need a name to connect to and a certificate to match it, so you need a domain or subdomain you control, such as dns.yourdomain.com, pointing at your server.

2. A TLS certificate that renews itself

Browsers and phones will reject a self-signed certificate, so you need one from a public certificate authority. A free automated one works well, using a tool such as certbot or acme.sh.

sudo certbot certonly --standalone -d dns.yourdomain.com

Certificates are short-lived by design, so renewal has to be automatic, and the service using the certificate must reload when it renews. Check that the renewal timer is actually running:

systemctl list-timers | grep certbot

3. A front end that terminates TLS

For DoT, a minimal nginx setup (it needs the stream module) looks like this:

stream {
    server {
        listen 853 ssl;
        ssl_certificate     /etc/letsencrypt/live/dns.yourdomain.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/dns.yourdomain.com/privkey.pem;
        proxy_pass 127.0.0.1:53;
    }
}

For DoH, you need something that speaks HTTP/2 and understands DNS messages. dnsdist is a common choice, with a configuration along these lines:

addDOHLocal("0.0.0.0:443", "/etc/letsencrypt/live/dns.yourdomain.com/fullchain.pem",
            "/etc/letsencrypt/live/dns.yourdomain.com/privkey.pem", "/dns-query")
newServer({address="127.0.0.1:53"})

Treat both as sketches. Option names change between versions, so check the documentation for what you have installed. Also expect practical snags: the proxy's user needs permission to read the certificate files, port 443 can clash with Pi-hole's own web interface if they share a machine, and Pi-hole must be set to accept queries from the proxy.

4. Don't build an open resolver

This is the step people skip, and the one that matters most. A DoT or DoH endpoint open to the whole internet is an open resolver, which strangers can use and attackers can abuse for DDoS amplification. You need to restrict who can use it: an allow-list of client addresses (hard when phones roam between networks), a secret URL path for DoH, or authentication features in your proxy. Whichever you choose, test it from outside your network to confirm it behaves as you intend.

5. Monitoring, so a silent expiry doesn't take your DNS down

With Android's strict Private DNS, an expired certificate means every lookup on the phone fails, and the symptom is "the internet is broken", not "the certificate expired". You can check expiry from any machine:

echo | openssl s_client -connect dns.yourdomain.com:853 2>/dev/null | openssl x509 -noout -dates

Many people put this in a scheduled check that emails them a warning.

How long does it take?

For someone comfortable with Linux, expect a few hours the first time, mostly spent on certificates, firewall rules, and testing. After that, the ongoing cost is small but real: renewals, proxy updates, and the occasional "why did DNS stop on my phone?" investigation. If you enjoy this kind of work, it is a rewarding project. If you would rather just have the endpoint, a managed option exists: NxValue Stack provisions a private Pi-hole + Unbound node with the DoH and DoT endpoints already generated, so the hostname is something you copy and paste rather than build. It works anywhere your phone has a connection, not only on your home network. You can try the demo node to see how the endpoint and dashboard look.

How to check that it's working

Don't assume a setting is doing what you think. A few quick checks:

If a device still shows your ISP's resolver, something is overriding your setting, usually a browser, an app, or a router that redirects DNS.

Common problems

Frequently asked questions

Does encrypted DNS slow things down? Slightly, on the first connection, because a TLS session has to be set up. After that the session is reused, and the difference is rarely noticeable. A nearby resolver with a good cache often feels faster than a distant one.

Does it work alongside a VPN? Usually the VPN takes over DNS and sends it through the tunnel, which overrides your device setting. If you want your own resolver while on a VPN, set it in the VPN's own configuration.

Do I still need DNSSEC? They solve different problems. Encrypted DNS protects the path between you and your resolver, while DNSSEC lets the resolver verify that answers really came from the domain's owner. They work well together.

Is encrypted DNS the same as a VPN? No. A VPN hides your traffic from the local network and your ISP by sending all of it through a tunnel. Encrypted DNS only protects DNS lookups.

Summary

NxValue Stack is an independent service provider and is not affiliated with Pi-hole LLC. Pi-hole is a registered trademark of Pi-hole LLC. Android, Apple, Windows, Firefox and Chrome are trademarks of their respective owners.

Skip the setup

Get your own private Pi-hole node with DoH and DoT endpoints. Billed hourly, cancel anytime.

Try the demo