DNS Over HTTPS and TLS: Encrypt Your DNS Before Your ISP Sells It

Your ISP Knows Every Website You Visit. All of Them.

You use HTTPS for everything now. Your banking, your email, your completely legitimate browsing habits — all encrypted. You’re safe, right?

There’s a lookup that happens before you make any HTTPS connection. When you type netflix.com into your browser, your device asks a DNS resolver “what’s the IP address for netflix.com?” This question goes out in plain, unencrypted text to whoever your DNS resolver is — which by default is usually your ISP.

Your ISP doesn’t need to decrypt your HTTPS traffic to know what you’re doing. They have the DNS logs. “This IP address made 847 queries to reddit.com between 9pm and midnight” is just as revealing as reading the actual pages. And they sell it, or give it to whoever asks.

This is the problem encrypted DNS solves.

The Three Flavors of Encrypted DNS

DNS over TLS (DoT)

DoT is the straightforward approach: take regular DNS queries and wrap them in TLS, the same encryption layer used for HTTPS.

• Port: 853 (TCP)
• Protocol: TLS-wrapped DNS
• Status: RFC 7858, widely supported
• Pros: Clean separation from web traffic, easier to monitor and control
• Cons: Port 853 is obviously DNS traffic; easy for ISPs or restrictive networks to block

DoT traffic looks different from web traffic, which means a network operator can see “this device is making encrypted DNS queries to 1.1.1.1:853” and block port 853 if they want to force their own resolver.

DNS over HTTPS (DoH)

DoH takes DNS queries and wraps them in regular HTTPS on port 443.

• Port: 443 (TCP)
• Protocol: DNS queries in HTTP/2 or HTTP/3 POST/GET requests
• Status: RFC 8484, widely supported
• Pros: Indistinguishable from web traffic, extremely hard to block without breaking HTTPS entirely
• Cons: DNS traffic mixed with web traffic, harder to monitor on enterprise networks

DoH is controversial in enterprise environments for good reason — network admins who rely on being able to see DNS queries for security monitoring lose that visibility when clients use DoH to an external resolver. Firefox enabling DoH by default made a lot of sysadmins unhappy.

From a privacy standpoint, DoH is more robust because blocking it means blocking all HTTPS.

DNS over QUIC (DoQ)

DoQ is the newest option, using QUIC (the protocol underneath HTTP/3) instead of TCP.

• Port: 853 (UDP) — same port as DoT but UDP
• Protocol: DNS over QUIC
• Status: RFC 9250, still gaining adoption
• Pros: Lower latency than TCP-based options (no TCP handshake), better connection migration
• Cons: Newer, less widely supported by resolvers and clients

DoQ is what you’d want if you were designing encrypted DNS from scratch today. Practical support is growing but not universal yet.

Why Encrypted DNS Alone Isn’t the Full Privacy Picture

Before going further: encrypted DNS is necessary but not sufficient for privacy.

What encrypted DNS hides: The specific domain names you query.

What encrypted DNS does NOT hide:

• The IP addresses your device connects to (your ISP sees every connection)
• SNI (Server Name Indication) in TLS handshakes — until ECH (Encrypted Client Hello) is widely deployed, the hostname is still visible in the TLS handshake
• The timing and volume of your connections

If you query secretwebsite.com via DoH, your ISP doesn’t see the domain name in the DNS query. But when you then connect to the IP address for secretwebsite.com, they see the connection. And if secretwebsite.com doesn’t share its IP with other sites, the destination is obvious.

Encrypted DNS meaningfully improves privacy. It’s not a complete solution. Combine with a VPN or Tor if you need more.

Comparison of Public Encrypted DNS Resolvers

Self-Hosting with AdGuard Home

AdGuard Home is a network-wide DNS server with ad blocking, DoH/DoT/DoQ support, and a solid web UI. It’s the more full-featured option compared to Pi-hole for encrypted DNS specifically.

Running AdGuard Home in Docker

# docker-compose.yml
version: "3.8"

services:
  adguard:
    image: adguard/adguardhome:latest
    container_name: adguardhome
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"      # Web UI (redirect)
      - "443:443/tcp"    # Web UI + DoH
      - "443:443/udp"    # DoQ
      - "3000:3000/tcp"  # Initial setup
      - "853:853/tcp"    # DoT
      - "853:853/udp"    # DoQ
    volumes:
      - ./adguard/work:/opt/adguardhome/work
      - ./adguard/conf:/opt/adguardhome/conf
    restart: unless-stopped

Visit http://YOUR_IP:3000 for initial setup. Walk through the wizard, then configure:

1. Upstream DNS servers — where AdGuard forwards queries it doesn’t block:

   • tls://1.1.1.1 (Cloudflare DoT)
   • tls://9.9.9.9 (Quad9 DoT)
   • Or https://dns.cloudflare.com/dns-query (DoH)

2. Bootstrap DNS — plain DNS used to resolve the upstream DoT/DoH server addresses:

   • 1.1.1.1
   • 8.8.8.8

3. Encryption — configure your TLS certificate for serving DoH/DoT to clients.

Configuring TLS for DoH/DoT in AdGuard

# In AdGuard config (/opt/adguardhome/conf/AdGuardHome.yaml)
tls:
  enabled: true
  server_name: dns.yourdomain.com
  force_https: false
  port_https: 443
  port_dns_over_tls: 853
  port_dns_over_quic: 853
  certificate_chain: /opt/adguardhome/conf/cert.pem
  private_key: /opt/adguardhome/conf/key.pem

Use Let’s Encrypt or your existing certificate infrastructure. AdGuard can also use ACME automatically.

Your DoH endpoint becomes: https://dns.yourdomain.com/dns-query Your DoT address: tls://dns.yourdomain.com

Encrypted DNS Upstream in Pi-hole

Pi-hole is better at blocking than serving encrypted DNS to clients, but it can use encrypted DNS for its upstream queries.

Using cloudflared as DoH Proxy

# Install cloudflared
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb

# Configure as DoH proxy
sudo nano /etc/default/cloudflared

# Content:
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

# /etc/systemd/system/cloudflared.service
[Unit]
Description=cloudflared DNS over HTTPS proxy
After=network.target

[Service]
Type=simple
User=cloudflared
EnvironmentFile=/etc/default/cloudflared
ExecStart=/usr/local/bin/cloudflared proxy-dns $CLOUDFLARED_OPTS
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now cloudflared

In Pi-hole settings → DNS → Custom upstream: 127.0.0.1#5053

Uncheck all other upstream servers. Pi-hole now sends all queries to cloudflared which forwards them over DoH.

Configuring Clients to Use Encrypted DNS

Linux (systemd-resolved)

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1
FallbackDNS=9.9.9.9
DNSOverTLS=yes

sudo systemctl restart systemd-resolved
resolvectl status  # Verify DoT is active

Firefox

Settings → Privacy & Security → DNS over HTTPS

Set to “Max Protection” and enter your AdGuard Home DoH URL: https://dns.yourdomain.com/dns-query

Chrome / Chromium

chrome://settings/security → Advanced → Use secure DNS

Enter custom provider: https://dns.yourdomain.com/dns-query

Android

Settings → Network & Internet → Private DNS

Set to: dns.yourdomain.com (Android uses DoT for Private DNS)

iOS (16+)

Settings → Wi-Fi → your network → Configure DNS → Custom → add your DoT server

Or create a DNS configuration profile. Apple Configurator can generate these.

macOS

System Settings → Network → your connection → DNS → DNS settings

macOS doesn’t have native DoH UI — you need a profile or third-party app like Cloudflare’s 1.1.1.1 app which can set DoH system-wide.

Performance Considerations

Encrypted DNS adds latency compared to plain UDP DNS — roughly 5-50ms depending on TLS connection state.

Mitigations:

• DoH/DoT connections are kept alive and reused, so TLS handshake overhead only hits the first query
• Self-hosted AdGuard on your LAN has sub-millisecond overhead for cached queries
• DoQ (QUIC) has lower overhead than DoT because no TCP handshake
• Modern resolvers cache aggressively

In practice, most people don’t notice. DNS is cached heavily by the OS, browser, and resolver. The typical experience with a local AdGuard instance is imperceptibly different from plain DNS.

The bigger win is for privacy, not performance. And if you’re running AdGuard Home on your local network for blocking anyway, you might as well have it use DoT/DoH upstreams rather than plain UDP.

The “My ISP Still Sees the IPs” Rebuttal

Every time encrypted DNS comes up, someone correctly points out that the ISP still sees destination IPs. This is true and worth understanding properly.

DNS encryption makes traffic correlation harder, not impossible. The value is:

1. Bulk surveillance becomes harder: ISP logs showing “this customer queried malware-domain.com 50 times” are no longer available. IP-based correlation requires active investigation.

2. Casual logging is eliminated: Most ISPs log DNS queries opportunistically because it’s easy. Encrypted DNS removes the easy win.

3. Third-party DNS operators can’t build profiles: Without encrypted DNS, your queries go to ISP resolvers. With it, they go to a resolver you chose with a published privacy policy.

4. Network-level blocking becomes harder: Content filtering based on DNS interception stops working, which is either good or bad depending on your situation.

It’s a meaningful privacy improvement with real limitations. Understand both.