DNS

On asking strangers for directions

2017-10-13 — 2026-04-28

Wherein the privacy implications of DNS resolver selection are examined, and the installation of encrypted-transport profiles upon Apple devices is described as a remedy for ISP observation of browsing habits.

computers are awful

computers are awful together

confidentiality

DNS determines where my devices go asking for directions on their way about the internet. My DNS setup thus impacts my security, safety, and convenience. My default DNS from my ISP is subject to AFAICT the highly criticised policy, within which your local council gets to know where you are browsing.

I might like a DNS service that does not record where I browse, so that I am less easily tracked and profiled by corporate interest or nascent police states etc. One way to fix this is with a VPN, but if I don’t want that overhead, I can also specifically encrypt my DNS queries to a supported DNS server.
I might like a DNS server that does not spoof sites. For example, when I work in Indonesia if I try to visit videos from Vimeo, I cannot do so without DNS hacks because otherwise I am redirected to a site which tells me that Vimeo is pornographic (!). In China, I understand this tactic is one way they enforce the great firewall. One way around this is DNSSEC, which guarantees authenticity.
Contrariwise, I might like a DNS service that is deliberately broken and will simply not work for malevolent sites such as malware distributors and advertisers, because filtering this myself is becoming difficult with some browsers. Some people maintain their own blocklists, but I am sometimes happy to entrust a third-party DNS provider with this power if they seem trustworthy.

Update: see DNS Privacy, a site which has more information than one could possibly want about the privacy details, or the IEEE overview.

1 Alternate DNS servers

1.1 Fancy

There are fancy DNS servers operated by e.g. Cloudflare and Adguard which offer value-added features such as censoring advertisers (and optionally “family unfriendly” content) by simply not resolving them, and DNS-over-TLS.

Adguard is

94.140.14.14
94.140.15.15

2a10:50c0::ad1:ff
2a10:50c0::ad2:ff

with TLS auth name dns.adguard-dns.com (the older dns.adguard.com and 176.103.130.130/131 addresses are deprecated as of 2022).

Cloudflare is American and has enabled Nazi speech. Adguard operates in a Russian jurisdiction. What that says about the risk and benefit profiles of these organisations I’ll leave you to decide for yourself.

Cisco’s opendns will do ad blocking, but it’s not TLS-compatible.

1.2 Vanilla, Australian

Public DNS list.

Whirlpool’s list of DNS Servers to use in Australia. AFAICT only my ISP is required to log my DNS usage, so presumably I improve privacy somewhat by using any DNS server that isn’t my ISP’s.

1.3 Vanilla, global

CCC’s recommended DNS servers globally:

85.214.20.141 (FoeBud)
204.152.184.76 (f.6to4-servers.net, ISC, USA)
2001:4f8:0:2::14 (f.6to4-servers.net, IPv6, ISC)
194.150.168.168 (dns.as250.net; Berlin/Frankfurt)
213.73.91.35 (dnscache.berlin.ccc.de)

Google DNS:

The Google Public DNS IP addresses (IPv4) are as follows:

8.8.8.8
8.8.4.4

The Google Public DNS IPv6 addresses are as follows:

2001:4860:4860::8888
2001:4860:4860::8844

2 Blocking some DNS records

I could do this myself with dnsmasq plus much love and attention and OCD, but I’m not quite anal retentive enough to get around to it. More comfortable might be to run a single board computer or vm as a net filter via pi-hole, which gives a nice GUI and monitoring system.

3 Encrypting DNS for privacy

3.1 Encrypted queries — DoT and DoH

If we want privacy about which sites we are requesting, we need an encrypted transport from us to the resolver. Two standards are in widespread use:

DNS-over-TLS (DoT, RFC 7858) — DNS wrapped in TLS on dedicated port 853. Easy to identify on the wire, and therefore easy for hostile networks to block.
DNS-over-HTTPS (DoH, RFC 8484) — DNS wrapped in HTTPS on port 443. Indistinguishable from regular web traffic, harder to block, but mixes DNS with the rest of the web in ways some operators dislike.

DoH dominates on client devices (Firefox, Chrome, iOS, Android, and macOS all support it natively); DoT is more common between system resolvers and upstream servers.

The encrypted transport hides our queries from the ISP and any on-path observer between us and the resolver. The resolver itself, of course, sees everything — we are choosing whom to trust, not eliminating trust.

There is also DNSCrypt — a pre-RFC encrypted DNS protocol that predates both DoT and DoH. The reference implementation is DNSCrypt/dnscrypt-proxy, still actively maintained as of 2026 and useful when we want anonymized DNSCrypt or oblivious DoH (ODoH).

How do we make our OS issue these encrypted queries? On Apple platforms (macOS 11+, iOS 14+) and Android 9+, the OS supports DoH or DoT directly — no extra daemon, just a configuration profile or a settings toggle. On Linux, systemd-resolved has supported DoT since version 239 (DNSOverTLS=yes in resolved.conf). For everything else, or for finer control, we run a local proxy: stubby, dnscrypt-proxy, or knot-resolver, listening on 127.0.0.1 and forwarding upstream over DoT/DoH.

3.2 Authenticated responses with DNSSEC

DoT and DoH protect the channel; DNSSEC protects the content. The two are orthogonal — DoT/DoH stops snooping and tampering between us and the resolver, but if the resolver returns a forged record (or has been fed one upstream) we have no way to tell. DNSSEC adds cryptographic signatures all the way down from the root, so a recursive resolver that validates DNSSEC can detect (most) forgeries.

Validation happens at the resolver, not at the client. Cloudflare 1.1.1.1, Quad9, and Google all validate DNSSEC by default. If we use one of these and trust the encrypted channel to it, we are getting the benefit. Forcing DNSSEC validation on the client would mean running our own recursive resolver (e.g. unbound) — see Setting up your own DNSSEC-aware resolver using Unbound.

Apple platforms expose DNSSEC validation to apps via Network.framework but do not validate at the OS level by default; we are relying on the resolver.

There is substantial overlap between unbound, stubby, and dnscrypt-proxy in practice — geeks usually try to get All The Cryptography at once.

4 DNS reconfiguring

So I’m going to reconfigure my DNS to be more secure. To do this I will point my OS at an encrypted resolver (DoH or DoT) and flush out the old poisoned records.

tl;dr we should use encrypted DNS servers (DoH or DoT) end-to-end, but even just dropping in a less-creepy DNS resolver helps. On macOS the cleanest path is a .mobileconfig profile — see below. On other platforms it’s a settings file e.g. Adguard, 94.140.14.14 and 94.140.15.15, Cloudflare, 1.1.1.1 and 1.0.0.1, or Quad9, 9.9.9.9 and 149.112.112.112.

The OS can benefit from a DNS flush; but also the browser can keep stale records around. Clearing browser DNS caches is also advised.

4.1 Ubuntu

First, I must configure my DNS settings. (I need to do this if I want to use VPN on linux apparently.)

If I want to encrypt, see Linuxbabe on DNS-over-TLS for Ubuntu using some app called stubby. I presume it is doing something to improve my confidentiality.

In practice installing it is easy. On e.g. Ubuntu, this is as simple as

sudo apt install stubby

Settings go in a text file /etc/stubby/stubby.yml; there is no settings GUI. The default settings work, but are slow. Then I am running my own DNS thingy on 127.0.0.1 (IPv4) or ::1 (IPv6) on port 53, which will in turn forward queries to the DNS-over-TLS servers I configured.

Now! We have an easy-to-remember secure DNS server to put into the ‘dns server’ box of the wifi settings window.

Shortcoming: the GUI config for network settings in Ubuntu seems to want me to configure it anew for every different WiFi network, for both IPv4 and IPv6. Needs a universal workaround. I think this is achievable via manually editing resolve.conf.

Having done that, I also needed to flush out the bad old records

4.2 macOS

I open System Settings → Network → (interface) → Details → DNS and I can put a list of resolvers in there. That gets me whatever resolver I want, but over plaintext UDP — my ISP no longer sees what I look up, but anyone else on the path between me and that resolver does. Not enough.

For an encrypted system DNS without a VPN and without running an extra daemon, the path on macOS 11 (Big Sur, late 2020) and later is a configuration profile. The OS supports DoH and DoT natively; Apple just declined to expose a UI for picking a server. So we install a .mobileconfig from the resolver of choice.

4.2.1 Recipe — encrypted system DNS on macOS

Pick a resolver we trust. A few of the usual suspects, all offering free DoH/DoT profiles:
- Cloudflare 1.1.1.1 — fast, validates DNSSEC, stated 24-hour log retention, based in the US.
- Quad9 — Swiss non-profit, validates DNSSEC, blocks known-malicious domains, does not log client IPs.
- NextDNS — generates a per-account profile so we can configure blocklists, see logs, choose retention.
- Mullvad — no logs, run by the Mullvad VPN people, no account required.
- AdGuard — ad-blocking on by default, generates a profile from a config wizard.
The paulmillr/encrypted-dns repo is a community-maintained collection of profiles for many of the above and others.

Any given profile may or may not work. I’ve been working systematically through them all
Download the .mobileconfig. Make sure the file extension is .mobileconfig and not .mobileconfig.txt — Safari sometimes appends the latter, in which case we rename.
Install the profile. Double-click the file. macOS opens System Settings → Privacy & Security → Profiles, asks for the admin password, and installs.
Flush the OS cache so stale plaintext-resolved records are not still floating about:
```
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
```
This flushes more than just DNS — dscacheutil controls Directory Services as a whole — but the side-effects are AFAIK harmless.
Verify. Visit https://1.1.1.1/help (works for any resolver, not only Cloudflare’s) and check that ”Connected to 1.1.1.1” and ”Using DNS over HTTPS (DoH)” (or DoT) are both green. https://on.quad9.net/ is the Quad9 equivalent. https://dnscheck.tools/ shows a more detailed picture, including which resolver actually answered.

4.2.2 Gotchas

Browsers may bypass the system resolver. Firefox in particular ships its own DoH (default upstream: Cloudflare via NextDNS, depending on locale). If Firefox is set to its own DoH, the system profile will not change Firefox’s behaviour. Same for Chrome’s “Secure DNS” setting. Either disable the browser’s setting or set it to ”With your current service provider” / ”Use system resolver”.
macOS 26.1 (Tahoe) broke older profiles. Apple changed the spec in late 2025 / early 2026 — see Quad9’s January 2026 advisory. Profiles built for older macOS will silently fail to apply. If a profile is more than a year old, regenerate it.
This is not a VPN. It hides the names we look up from my ISP and any on-path observer. It does not hide which IPs I subsequently connect to. The TLS SNI on those connections still leaks the hostname unless I’m also using ECH, which is patchy. If we want our ISP to see nothing, we want a VPN as well, not instead.
Captive portals. Some hotel/airport networks redirect DNS to their own resolver to drive their portal. An encrypted-DNS profile will refuse, and the captive portal will not work. macOS has a “captive portal assistant” exemption that handles most of this, but occasionally we have to disable the profile, log in, then re-enable it.
Per-network DNS still applies. A .mobileconfig profile applies system-wide, but specific Wi-Fi networks can override. System Settings → Network → (Wi-Fi) → Details → DNS is the override; leave it empty unless we explicitly want different DNS on that network.

For finer control — multiple upstreams, anonymised DNSCrypt, splitting domains across resolvers — that’s what dnscrypt-proxy is for. brew install dnscrypt-proxy, edit /usr/local/etc/dnscrypt-proxy/dnscrypt-proxy.toml, run as a launchd service, point macOS at 127.0.0.1. The older Pfiffer walkthrough using knot-resolver was a workaround for Apple’s pre-Big-Sur lack of native DoT and is no longer needed.

4.3 Windows

unihost:

ipconfig /flushdns

4.4 Android

Since Android 9 (Pie, 2018), there is a system setting Settings → Network & Internet → Private DNS that takes a DoT hostname directly. So dns.adguard-dns.com, 1dot1dot1dot1.cloudflare-dns.com, dns.quad9.net, and friends all work without any third-party app. This is DoT only — no DoH at the system level — but for our purposes that is fine.

4.5 iOS

iOS 14+ (2020) has the same encrypted-DNS support as macOS, via the same .mobileconfig profiles — install one and the whole device routes DNS over DoH or DoT. The Quad9, Cloudflare, NextDNS, and Mullvad pages linked above all serve iOS-compatible profiles.

The dnscloak app is no longer maintained and no longer in the App Store; ignore older recommendations.

4.6 Fancy stubby config

If we use stubby and want faster DNS, don’t rotate through the long default list of slow servers — settle on a short list of fast servers and rotate through them, disabling the others. e.g. Adguard and Cloudflare:

upstream_recursive_servers:
# Adguard servers
  - address_data: 94.140.14.14
    tls_auth_name: "dns.adguard-dns.com"
  - address_data: 94.140.15.15
    tls_auth_name: "dns.adguard-dns.com"
# Cloudflare servers
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
# IPv6 too, to avoid little accidents:
  - address_data: 2a10:50c0::ad1:ff
    tls_auth_name: "dns.adguard-dns.com"
  - address_data: 2a10:50c0::ad2:ff
    tls_auth_name: "dns.adguard-dns.com"
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"

We can choose whether to rotate through them constantly with the following parameter:

round_robin_upstreams: 0

stubby also supports SPKI pinning via tls_pubkey_pinset — pinning the public key fingerprint of the upstream so that we’ll notice if the certificate ever changes. I used to ship pinned configs here. Two things to flag:

The TLS auth name (e.g. cloudflare-dns.com) is already verified against the public CA chain, so a generic on-path attacker would need a valid certificate from a public CA to MitM us. SPKI pinning adds defence against an attacker who can mint such certificates (or compromise a CA), but at the cost of breaking when the resolver rotates keys, which they do.
The previously-published pin values for Cloudflare and AdGuard are now stale — Cloudflare in particular rotates keys regularly. As far as I can tell, the stubby community has moved away from publishing pins for this reason.

If we still want the fingerprint for our own resolver, we extract it like this:

echo | openssl s_client -connect '1.1.1.1:853' 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der |\
  openssl dgst -sha256 -binary | \
  openssl enc -base64

…and check it again on a different network from a different machine before trusting it, since this step itself is vulnerable to spoofing if we’re already on a hostile network.

5 Flushing

How to Flush DNS Cache (Windows, Mac, Chrome)

5.1 Ubuntu

stackoverflow

sudo systemd-resolve --flush-cache
sudo systemd-resolve --statistics

6 Registering domains

For bog-standard purposes, a cheap registrar is fine. I use GANDI (and that is my affiliate link, use it to give me 5 euros please).

For privacy-enhanced tinfoil-hat business, one might wish to anonymously own a domain. I’m not sure about all the mechanics of this, but here are some recommendations I was given when I was curious about it:

Njalla

We’re not actually a domain name registration service, we’re a customer to these. We sit in between the domain name registration service and you, acting as a privacy shield.

When you purchase a domain name through Njalla, we own it for you. However, the agreement between us grants you full usage rights to the domain. Whenever you want to, you can transfer the ownership to yourself or some other party.

PRQ is a 1337-lookin’ Swedish domain registrar that hosts weird hacker stuff.

Vindo offers anonymous domain registration as part of its hosting.