Mullvad announced that it is shutting down the public encrypted DNS servers it has maintained since 2022, and instead of its own infrastructure will financially support Quad9. The blog wording is brief: «we’re putting those resources toward financially supporting Quad9 instead». The date is also stated plainly in the company’s help section — the service will stop operating on November 2, 2026.
The news seems minor until you remember how many configurations in four years have acquired the line 194.242.2.4. Below are the questions that come up first, along with answers from Mullvad and Quad9’s official documentation.
Deadline — November 2, 2026. Mullvad writes about it like this: «If you have manually configured our DoH servers, switch before November 2nd 2026». It’s separately noted that DoH profiles for iOS and macOS will simply stop working: «Any existing iOS and macOS Mullvad DoH profile will stop working».
«I have a Mullvad subscription — will I even notice this?»
Most likely not. The public resolver and DNS inside the VPN are different things, and only the first is being shut down. While you’re connected to Mullvad VPN, requests are serviced by the tunnel’s internal resolver: «traffic is already encrypted and Mullvad VPN’s internal DNS handles all queries». It’s precisely because of this duplication that the company decided it no longer needs its public DNS.
Users of Mullvad Browser with default settings won’t notice anything either — they’ll be switched to Quad9 automatically. The scenario «I typed the address manually» breaks: in the router, in the system, in the client, in the phone profile.
Who exactly needs to move: you have dns.mullvad.net or an address in the 194.242.2.2–194.242.2.9 range in your config; you set up a DoH profile on iOS or macOS; you use the resolver Mullvad without their VPN — for example, as an upstream for AdGuard Home or Pi-hole.
What exactly are they turning off
There were six public variants, and they differed only in the blocklists. All six addresses are decommissioned at the same time.
| Variant | IPv4 | IPv6 | What it blocked |
|---|---|---|---|
dns |
194.242.2.2 | 2a07:e340::2 | nothing |
adblock |
194.242.2.3 | 2a07:e340::3 | advertising, trackers |
base |
194.242.2.4 | 2a07:e340::4 | + malware |
extended |
194.242.2.5 | 2a07:e340::5 | + social networks |
family |
194.242.2.6 | 2a07:e340::6 | + explicit content 18+, gambling |
all |
194.242.2.9 | 2a07:e340::9 | all categories at once |
Each had its own DoH endpoint of the form https://<variant>.dns.mullvad.net/dns-query and a DoT host <variant>.dns.mullvad.net on port 853.
Where this address could have settled on your side
The most honest way is to search, not rely on memory. On a server or a home machine:
grep -rIn -E '194\.242\.2\.[0-9]|dns\.mullvad\.net' /etc /opt /srv "$HOME" 2>/dev/null
Places that grep won’t cover and should be opened manually: the AdGuard Home web interface or Pi-hole (upstream field), router settings, Android’s “Private DNS” (it contains a DoT host), iOS and macOS configuration profiles, provider panel, if the resolver was set in the network VPS settings.
In client configs for sing-box and Xray the address sits in the dns section; the server descriptions changed between versions, so adjust according to your version’s documentation, not someone else’s online example.
What to switch to and what you lose along the way
Quad9 has three public variants, and none of them replicate adblock or extended.
| Variant | IPv4 | DoH | What it does |
|---|---|---|---|
| primary | 9.9.9.9, 149.112.112.112 | https://dns.quad9.net/dns-query |
blocks malware domains, DNSSEC validation |
| unfiltered | 9.9.9.10, 149.112.112.10 | https://dns10.quad9.net/dns-query |
blocks nothing, DNSSEC validation |
| with ECS | 9.9.9.11, 149.112.112.11 | https://dns11.quad9.net/dns-query |
like primary, plus reveals client subnet to authoritative servers |
Practical takeaway not stated in the announcement itself: Quad9 does not block ads and trackers at all. If you were using adblock, extended, or all for browser quiet, a simple address change won’t fix it — you’ll need to reintroduce filtering on your side with AdGuard Home, Pi-hole, or a browser blocker.
The ECS variant (dns11) should be chosen with awareness: it forwards part of your subnet to authoritative servers to deliver the nearest CDN node. Faster — yes, private — not really. For a home network behind a VPN, there’s usually little value.
Concrete lines for typical places:
# systemd-resolved, /etc/systemd/resolved.conf
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
DNSOverTLS=yes
# AdGuard Home, Upstream DNS servers field
https://dns.quad9.net/dns-query
# Unbound, forward-zone
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 9.9.9.9@853#dns.quad9.net
# Android, "Private DNS" — only the host name
dns.quad9.net
A ten-minute action plan: run the grep from the section above → replace what you find → restart the affected service → verify resolution with the commands below → remove old DoH profiles from iOS and macOS so the phone isn’t left without a resolver on November 2.
How to verify the migration succeeded
dig @9.9.9.9 example.com +short
kdig -d @dns.quad9.net +tls example.com
resolvectl status | grep -A3 'Current DNS'
The first command checks a normal UDP resolver, the second ensures a TLS session is actually established (kdig is in the knot-dnsutils package), the third shows which server the system is actually using after the config change.
Separately, make sure DNSSEC validation is in place:
dig @9.9.9.9 dnssec-failed.org
Domain dnssec-failed.org is signed incorrectly on purpose. The testing resolver should return status: SERVFAIL; if an address comes back, it means the query bypassed Quad9 — most likely the resolver of your provider.
“Maybe not Quad9”
Switching one public resolver for another does not change the main issue: Your entire DNS is still visible to one organization. If that bothered you with Mullvad, it bothers you exactly the same with Quad9 — the Swiss non-profit structure there is not an argument, but a fact.
An alternative discussed on the forum in a breakdown of the 1.1.1.1 cache is to run your own recursive resolver: Unbound in recursive mode talks to root and authoritative servers itself, without a single intermediary. The cost is a cold cache at start, your own DNSSEC tuning, and the fact that your IP is now visible directly to the authoritative servers. There is no ready-made “best” option here; there is a choice of whom you prefer to give this telemetry.
Sources
- Mullvad: Shutting down our public encrypted DNS servers and sponsoring Quad9 instead
- Mullvad: DNS over HTTPS and DNS over TLS help page
- Quad9: Service Addresses & Features
Where are you migrating to — Quad9, your own Unbound, or a local resolver in a Docker setup? And a separate question for those who were using adblock: how do you plan to close the ad gap now that it’s no longer blocked at the resolver level?