Quad9 has been the quiet default of privacy-conscious IT teams since 2017, but 2026 brings a fully matured product: a Swiss-registered nonprofit resolver that survived a high-profile European court challenge, expanded to 200+ anycast nodes, and hardened its encrypted DNS endpoints. If you are deciding whether 9.9.9.9 deserves a permanent place in your DNS stack — home network, business LAN, or individual devices — this is the evidence-based breakdown from architecture through verification.

What Quad9 Is and Who Runs It

Quad9 is a free recursive DNS resolver operated by the Quad9 Foundation, a Swiss nonprofit headquartered in Zurich. It was co-founded in 2017 by PCH (Packet Clearing House), IBM, and the Global Cyber Alliance. Since 2021 it has operated fully independently, separated from IBM. The legal entity is Swiss — which matters significantly for privacy law and jurisdictional reach.

The primary IPv4 address is 9.9.9.9, secondary 149.112.112.112. IPv6 primary is 2620:fe::fe, secondary 2620:fe::9. These are anycast addresses — every DNS query is automatically routed to the nearest Quad9 node out of 200+ global points of presence, with no configuration required on your end.

Quad9's value proposition is narrow and focused: block connections to known-malicious domains, validate DNSSEC signatures, and record zero per-IP query logs. It does not sell advertising, does not profile users, and has no paid tier. The free service is the only service.

Privacy Model: What Actually Gets Logged

This is the first thing any technically serious evaluation should audit. Quad9's published policy, confirmed through independent review, states the following:

  • No IP address logging. Your source IP is not written to disk at any point of presence worldwide.
  • Aggregate-only statistics. Quad9 publishes regional domain query-count data, but no per-IP or per-session records exist.
  • Swiss jurisdiction. Switzerland's Federal Act on Data Protection (nDSG, updated September 2023) provides meaningful privacy protections. Switzerland is not a Five Eyes member and has no automatic intelligence-sharing obligations with US, UK, Australian, Canadian, or New Zealand agencies.
  • Court-tested legal structure. In 2022, Sony Music filed suit in German courts to force Quad9 to block copyright-infringing domains. Quad9 won the final appeal in February 2023. The Hamburg Regional Court of Appeals ruled that a DNS resolver is not a "disturber" (Störer) under German law and cannot be compelled to block domains on behalf of rightsholders. The Swiss nonprofit structure held under direct legal attack — a meaningful data point for enterprise risk assessments.

For comparison: Google Public DNS (8.8.8.8) logs queries tied to your IP for 24–48 hours before pseudonymization and is subject to US court orders. Cloudflare (1.1.1.1) retains logs for 25 hours, publishes annual KPMG audits, and is headquartered in San Francisco under US jurisdiction. Both are credible resolvers with genuine privacy efforts, but neither is structured as a non-logging Swiss nonprofit with zero commercial incentive to monetize query data.

💡 Before switching resolver settings on a live site, confirm current propagation state with our DNS Propagation Checker — useful when timing a resolver change alongside an A-record or TTL update.

Threat Blocking: How the Blocklist Works

Quad9 does not maintain a simple static blocklist. The foundation aggregates threat intelligence from over 25 partners including IBM X-Force, Palo Alto Unit 42, Spamhaus, CIRCL (Luxembourg CERT), and SWITCH (Switzerland's national CERT). When a DNS query matches a known-malicious domain, Quad9 returns SERVFAIL rather than resolving the address, cutting the connection before any packet reaches the malicious server.

What Quad9 blocks by default:

  • Malware command-and-control (C2) infrastructure and callback domains
  • Phishing domains mimicking banks, cloud logins, and SaaS platforms
  • Ransomware download staging domains and exploit kit infrastructure
  • Botnet enrollment and persistence domains

What Quad9 does not block:

  • Legal adult content (use a separate DNS-level parental filter for this)
  • Advertising and tracking domains (use Pi-hole, NextDNS, or browser-level blocking)
  • Legal peer-to-peer or streaming services

Blocklist updates are continuous, fed by real-time threat feeds rather than batched daily imports. If a legitimate domain is incorrectly blocked, Quad9 accepts false-positive submissions on their website for manual review. There is no per-user allowlist in the free tier — if blocking a legitimate domain affects a critical workflow, the 9.9.9.10 variant (no blocking) is the escape hatch while the false positive is investigated.

Quad9 runs three service variants for different use cases:

  • 9.9.9.9 / 149.112.112.112 — Threat blocking enabled, DNSSEC validation, no IP logging. Correct choice for most deployments.
  • 9.9.9.10 / 149.112.112.10 — No threat blocking, DNSSEC on, no logging. For security researchers and incident responders who need to intentionally resolve malicious domains.
  • 9.9.9.11 / 149.112.112.11 — Threat blocking plus ECS (EDNS Client Subnet). Sends a /24 prefix to authoritative servers, improving CDN geo-routing accuracy at a minor privacy cost.

Performance in 2026

With 200+ anycast nodes, Quad9's latency is competitive across most regions. Independent benchmark data places it as follows:

  • Western Europe and North America: Median RTT of 5–15ms, comparable to Cloudflare 1.1.1.1 in most cities.
  • Asia-Pacific (Tokyo, Singapore, Sydney): 10–30ms in major metros. Cloudflare maintains a slight edge here due to denser PoP placement.
  • Latin America, Africa, South Asia: 30–80ms where Quad9's node density thins. Google 8.8.8.8 performs similarly in these regions.

For the vast majority of deployments, the latency difference between Quad9, Cloudflare, and Google is imperceptible day-to-day. DNS lookups measure in single-digit milliseconds and the delta between resolvers is rarely more than 10–15ms. The performance argument against Quad9 is theoretically valid only in extreme high-frequency lookup environments, which describes almost no home or SMB deployment.

One real-world caveat: some ISPs perform transparent DNS proxy, intercepting all UDP and TCP traffic on port 53 regardless of which resolver you configure. This is common with ISPs in the UK, UAE, and parts of APAC. If your ISP does this, plain Quad9 queries never leave the ISP network. The fix is DNS over HTTPS on port 443, which bypasses port-53 interception entirely.

Setting Up Quad9 on Every Platform

Windows 10 and 11

Plain DNS: Settings → Network and Internet → Wi-Fi or Ethernet → [Your interface] → Edit DNS. Set IPv4 Preferred DNS to 9.9.9.9, Alternate to 149.112.112.112. For dual-stack networks add IPv6 preferred 2620:fe::fe and alternate 2620:fe::9.

DNS over HTTPS on Windows 11: Settings → Network and Internet → Wi-Fi → Hardware properties → DNS server assignment → Edit → Manual → enter 9.9.9.9 → set the "DNS over HTTPS" dropdown to On (automatic template). Windows 11 has Quad9's DoH template pre-configured once you enter 9.9.9.9. If it does not auto-populate, manually enter https://dns.quad9.net/dns-query.

# Verify in PowerShell: Resolve-DnsName -Name quad9.net -Server 9.9.9.9 # Check which resolver Windows is actually using: nslookup quad9.net # The "Server:" line must show 9.9.9.9 # Flush DNS cache after changing settings: ipconfig /flushdns

macOS (Ventura, Sonoma, Sequoia)

System Settings → Network → [Interface] → Details → DNS → click the + button → add 9.9.9.9, then 149.112.112.112. Apply. Changes take effect for new queries immediately without restarting.

For DNS over TLS, macOS has no native GUI toggle. Use a signed .mobileconfig profile with a DNSSettings payload — Quad9 publishes ready-made signed profiles on their configuration page. Install by double-clicking the file and approving it under System Settings → Privacy and Security → Profiles.

# Verify in Terminal: dig @9.9.9.9 quad9.net +short # Check the active system resolver: scutil --dns | head -20 # Look for the "nameserver[0]" line

Linux with systemd-resolved

Edit /etc/systemd/resolved.conf to add Quad9 with DNS over TLS and DNSSEC validation enabled:

[Resolve] DNS=9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9 FallbackDNS=1.1.1.1 DNSOverTLS=yes DNSSEC=yes

Apply and verify:

sudo systemctl restart systemd-resolved resolvectl status resolvectl query quad9.net

If you use NetworkManager, configure DNS per connection profile instead:

nmcli con mod "Your Connection" ipv4.dns "9.9.9.9 149.112.112.112" nmcli con up "Your Connection"

iOS 17 and 18

Plain DNS: Settings → Wi-Fi → tap your network → Configure DNS → Manual → delete existing servers → add 9.9.9.9 and 149.112.112.112. This applies to that Wi-Fi network only and does not cover mobile data.

For system-wide encrypted DNS including mobile data, install Quad9's signed .mobileconfig profile from their site. This deploys an Apple DNSSettings payload enforced at the OS level across all interfaces simultaneously, overriding per-network settings.

Android 13, 14, and 15

Settings → Network and Internet → Private DNS → select "Private DNS provider hostname" → enter dns.quad9.net → tap Save. Android activates DNS over TLS automatically and applies it globally across both Wi-Fi and mobile data. No per-network configuration is needed, and it persists across network changes.

💡 After configuring Quad9, run a test lookup with the DNS Lookup tool and check the responding server — if it shows your ISP's resolver instead of 9.9.9.9, port-53 interception is active and you need to switch to DoH.

Routers: One Change, Whole Network

Setting DNS at the router level propagates Quad9 to every DHCP client automatically, removing the need for per-device configuration.

ASUS (AsusWRT): Navigate to 192.168.1.1 → Advanced Settings → LAN → DHCP Server → DNS Server 1: 9.9.9.9, DNS Server 2: 149.112.112.112. Also update WAN → Internet Connection → DNS Server 1 and 2 to 9.9.9.9 and 149.112.112.112, and set "Connect to DNS Server automatically" to No. Both entries are required — the WAN setting governs the router's own lookups, the LAN/DHCP setting pushes DNS to clients.

TP-Link Archer (current firmware): Navigate to tplinkwifi.net or 192.168.0.1 → Advanced → Network → DHCP Server → Primary DNS: 9.9.9.9, Secondary DNS: 149.112.112.112.

Netgear Nighthawk and Orbi: Navigate to routerlogin.net or orbilogin.com → Advanced → Setup → Internet Setup → DNS Address section → Use These DNS Servers → Primary: 9.9.9.9, Secondary: 149.112.112.112.

Linksys (Velop, Smart Wi-Fi): Navigate to linksyssmartwifi.com → Connectivity → Local Network → DHCP Settings → Static DNS 1: 9.9.9.9, DNS 2: 149.112.112.112.

Xiaomi (MiWiFi): Navigate to miwifi.com → More Settings → LAN Settings → DNS 1: 9.9.9.9, DNS 2: 149.112.112.112.

OpenWrt: Edit /etc/config/dhcp — within the lan dnsmasq block, add option dns '9.9.9.9'. For the router's own resolution over DoT, configure unbound with a forward-zone pointing to 9.9.9.9@853 and forward-tls-upstream: yes.

DD-WRT: Setup → Basic Setup → Static DNS 1: 9.9.9.9, Static DNS 2: 149.112.112.112. Optionally disable "Use DNSMasq for DNS" to bypass the local caching layer and send queries directly to Quad9.

Encrypted DNS, DNSSEC, and IPv6 in 2026

Quad9 supports all modern DNS transport and security protocols. The security foundation is described in RFC 4033, the DNSSEC requirements specification — Quad9 validates cryptographic signatures on every signed zone before returning a response.

  • DNS over HTTPS (DoH): Endpoint https://dns.quad9.net/dns-query — RFC 8484, port 443. Bypasses ISP port-53 interception and works through most corporate firewalls. Recommended for desktop browsers and any environment where port 853 is blocked.
  • DNS over TLS (DoT): Hostname dns.quad9.net, port 853. Preferred for routers running pfSense, OPNsense, or OpenWrt, and for Android Private DNS. The TLS certificate is publicly trusted.
  • DNSSEC validation: A zone with a broken chain of trust returns SERVFAIL instead of a potentially spoofed answer, protecting against cache poisoning. The 9.9.9.10 no-blocking variant still validates DNSSEC by default.
  • IPv6: Full anycast IPv6 support. Primary 2620:fe::fe, secondary 2620:fe::9. Works on dual-stack and IPv6-only networks without any additional configuration.
# Test DNSSEC validation — must return SERVFAIL if working correctly: dig @9.9.9.9 dnssec-failed.org A # Confirm Quad9 sees your correct egress IP: dig @9.9.9.9 TXT o-o.myaddr.l.google.com +short # Test IPv6 path to Quad9: dig @2620:fe::fe quad9.net AAAA # Test DoT directly (requires kdig): kdig @dns.quad9.net+tls quad9.net A

Confirming Quad9 Is Actually Resolving Your Queries

It is common to configure Quad9 and have a VPN client, corporate firewall, or ISP transparent proxy silently override it. Use these platform-specific checks to confirm end-to-end delivery:

# Linux: resolvectl status | grep "DNS Servers" # Must show 9.9.9.9 # Windows: nslookup quad9.net # The "Server:" line must show 9.9.9.9, not your ISP's hostname # macOS: dig quad9.net | grep "SERVER:" # Any platform — confirm DNSSEC validation is active: dig @9.9.9.9 dnssec-failed.org +dnssec # Must return SERVFAIL — if it returns an IP, something between # you and 9.9.9.9 is stripping DNSSEC responses

Common Misdiagnoses When Quad9 Seems Broken

  • VPN silently overrides DNS on connect. Most VPN clients push their own resolver at connection time, replacing whatever was configured at the OS level. This is normal VPN behavior — configure Quad9 inside your VPN client's DNS settings so it applies within the tunnel too.
  • ISP port-53 interception. Run dig @9.9.9.9 quad9.net +short and compare to dig quad9.net +short. If the results or SOA origin differ, your ISP is transparently proxying port 53. Fix: switch to DoH on port 443, which is far harder to intercept without breaking HTTPS broadly.
  • SERVFAIL on a domain that is not malicious. Two distinct causes: (a) the domain is on Quad9's blocklist — verify at quad9.net/result; or (b) the domain's own DNSSEC configuration is broken, which is not Quad9's doing. Test the same query against 9.9.9.10 (no blocking) to determine which cause applies.
  • Router changed but connected devices still use old DNS. Devices hold active DHCP leases and may not pick up new DNS settings until the lease expires or is renewed. Force renewal on Windows with ipconfig /release && ipconfig /renew, or toggle Wi-Fi off and back on for mobile devices.
  • Docker containers ignoring host DNS settings. Docker defaults to 8.8.8.8 for container resolution, independent of the host. Fix: add "dns": ["9.9.9.9", "149.112.112.112"] to /etc/docker/daemon.json and restart the Docker daemon.
  • Split-horizon DNS failures on corporate networks. Quad9 cannot resolve internal hostnames (e.g., fileserver.corp) that only exist in your private DNS. Use conditional forwarding or stub zones: route internal domain suffixes to your internal resolver and forward everything else to Quad9.

Quad9 vs Cloudflare 1.1.1.1 vs Google 8.8.8.8

The three major public resolvers are not interchangeable for all use cases. Here is a direct factual comparison as of 2026:

  • IP logging: Quad9 — no IP logs by architecture. Cloudflare — 25-hour retention with annual KPMG audit. Google — 24–48-hour IP logs before pseudonymization.
  • Legal jurisdiction: Quad9 — Switzerland (nDSG 2023). Cloudflare — United States. Google — United States.
  • Malware blocking by default: Quad9 yes. Cloudflare 1.1.1.1 no (use 1.1.1.2 for filtering). Google no.
  • DNSSEC validation: All three validate by default on their primary addresses.
  • Encrypted transports: DoH and DoT available on all three.
  • Global raw speed: Cloudflare leads in latency globally, particularly in Asia-Pacific. Quad9 and Google are comparable in North America and Europe.
  • Organizational structure: Quad9 is a nonprofit with no revenue incentive tied to query data. Cloudflare and Google are commercial entities.

Practical recommendation for 2026: for personal devices and home or SMB networks where privacy and passive malware protection are the primary goals, Quad9 is the strongest default. For environments where raw DNS latency is a measured bottleneck and malware blocking is handled at a separate layer (NGFWs, EDR), Cloudflare 1.1.1.1 is the alternative. Google 8.8.8.8 remains pragmatic for enterprise environments with legacy internal zones and misconfigured DNSSEC, because Google's validation is more permissive toward broken zone signatures.

Preventing Configuration Drift

Once Quad9 is configured, several mechanisms can silently revert you to an ISP or software-default resolver:

  • DHCP lease renewal. If your router's DHCP server advertises its own or ISP-provided DNS, a lease renewal on Windows or Android will override per-device static settings. Fix: set DNS at both the device level (static) and the router's DHCP server configuration — both must agree.
  • Linux /etc/resolv.conf overwrites. DHCP clients and NetworkManager rewrite this file on network events. Use systemd-resolved with a persistent resolved.conf entry. As a last resort, protect the file with sudo chattr +i /etc/resolv.conf, though this breaks DHCP-aware tooling.
  • VPN client reconnections. Every tunnel establishment typically re-pushes DNS. Add 9.9.9.9 to the VPN client's own DNS configuration fields so it persists through reconnects rather than reverting to the VPN provider's resolver.
  • Docker installations defaulting to 8.8.8.8. Once you add the Quad9 entry to daemon.json it survives reboots, but fresh Docker installs on a new machine default back. Add daemon.json configuration to your provisioning scripts or Ansible playbooks to prevent this.