Your Alternate DNS Isn't a Backup: Why Windows 11 Ignores It When Your Primary Blocks a Site

You set Quad9 as your primary DNS to block malware. For safety, you added Google DNS as the alternate. It feels right—if one fails, the other steps in. But on Windows 11, that alternate server is not the safety net you think it is. When your primary DNS blocks a malicious site, Windows never asks the alternate for a second opinion. Instead, it accepts the block as the final answer, leaving you unaware that your backup would have happily served the dangerous page.

That’s not a bug. It’s how Microsoft designed the DNS client, and it has been hiding in plain sight. As first reported by MakeUseOf, the interaction between Windows’ DNS resolution logic and security-focused resolvers like Quad9 creates a silent, invisible snag that can undermine the very protections you configured.

The Silent Rule: A Block Is Still an Answer

In Windows 11, when you type a domain name into your browser, the operating system’s DNS client sends a query to the first server listed in your network settings—the “preferred” DNS. Only if that server does not respond at all—no reply within the timeout, or an outright failure like SERVFAIL—does Windows try the “alternate” DNS.

Crucially, a negative response counts as a valid reply. If your preferred DNS returns NXDOMAIN (“this domain does not exist”), Windows considers the job done. It will not re-query the alternate server to see if that one knows something different.

Quad9 and similar blocking resolvers exploit this behavior on purpose. When Quad9 detects a malicious domain, it intentionally replies with NXDOMAIN. To the Windows DNS client, that response is indistinguishable from a genuinely nonexistent domain. So the alternate server, even if it would resolve the domain perfectly, sits idle. That’s good news when Quad9 blocks a threat—the alternate can’t undo the block—but it also means your alternate resolver’s different filtering, logging, or privacy policies are applied only in the rare event that the primary resolver completely fails to answer.

Why Mixing DNS Providers Breaks Your Security Model

The problem escalates when the two DNS addresses belong to different services. Consider a common configuration: Quad9 (9.9.9.9) as preferred to block malware, and Google DNS (8.8.8.8) as alternate “just in case.” A user assumes they are doubly protected—filtering from Quad9, with Google as a reliable backup. But that setup silently breaks consistency:

• If Quad9 blocks a domain, Windows stops. The block holds. You are safe—for that query.
• If Quad9’s infrastructure experiences a brief outage, or if a specific query triggers a SERVFAIL (server failure) rather than a clean NXDOMAIN, Windows will fall back to 8.8.8.8. Google’s resolver does not filter malware, so the malicious domain resolves normally. The user has no idea they are suddenly unprotected.
• Even worse: some routers and forwarders do not respect the “primary first” logic at all, as we’ll see in a moment.

The lesson is stark: a mismatched pair of DNS servers gives you the security posture of whichever resolver happens to answer, and you cannot predict which one that will be.

Your Router Is Not on Your Side

When a Windows PC sits behind a typical home router, the device’s DNS settings often point to the router itself (e.g., 192.168.1.1), which then forwards queries to the servers you entered in the router’s admin panel. But the router’s DNS forwarder may treat those entries very differently from Windows.

MakeUseOf highlighted the most common forwarder, dnsmasq, which is embedded in countless consumer routers, mesh systems, and firewalls. By default, dnsmasq does not honor the “preferred” and “alternate” labels you see in the config page. Instead, it queries all configured upstream servers at once and uses whichever reply arrives first. It then latches onto that server for subsequent queries, only re-evaluating when the server returns a SERVFAIL or REFUSED, or after a time-out.

This means your “alternate” DNS might be answering lookups even when your “primary” is perfectly healthy. If those two servers have different filtering policies—one blocks trackers, the other does not—you get inconsistent behavior. A site might load one minute and vanish the next, because one lookup went to the unfiltered resolver. Troubleshooting such intermittent failures can drive you mad.

The Browser Layer Adds Another Twist

Windows 11 has built-in support for DNS over HTTPS (DoH). But browsers like Microsoft Edge can also enforce their own encrypted DNS settings, completely bypassing both the device’s and the router’s configuration. In a business environment, group policies or Microsoft Intune might force all endpoint DNS traffic to a secure resolver; at home, the user might have manually flipped a switch in Edge’s privacy settings.

Thus, even if you perfectly pair Quad9’s primary and secondary IPs on your router, a machine running Edge in automatic DoH mode might upgrade its DNS to a different provider—say, Cloudflare—when it detects compatibility. The result: your DNS filtering evaporates for that browser, with no warning.

How We Got Here: A Legacy Label in a Modern Stack

The two‑box “preferred / alternate” DNS model dates back decades, to an era when a network had exactly one clear hierarchy of resolvers. Windows’ resolver behavior—stop on any non‑failure response—is also old. Microsoft documented it clearly in the Windows DNS client documentation, but few users ever read it. The label “alternate” implies a standby that backs up the primary, but in truth it’s more of a “live spare” that only fires when the primary goes completely dark.

The rise of cloud‑based content filtering, ad blocking, and privacy‑focused resolvers changed user expectations. People now choose a DNS service for specific features, not just speed. The mismatch between strict blocking resolvers and permissive alternatives turned a once‑benign design choice into a hidden trap.

Consumer routers compounded the problem. To spread load and improve resilience, many shippers adopted dnsmasq’s default “ask all” behavior. Some routers allow you to force strict ordering (--strict-order), but average users never touch that advanced setting.

Finally, the proliferation of encrypted DNS protocols—DoH, DoT—and browsers that implement their own DNS overrides has layered multiple competing resolvers onto a single device, often without the user’s awareness.

What You Should Do Right Now

For everyone: pair primary and secondary from the same service.
Every major secure DNS provider publishes two IP addresses that point to the same filtering infrastructure. Using those as a matched pair ensures redundancy without changing the security policy:

This simple step eliminates policy inconsistency regardless of whether Windows or your router handles DNS.

For home users with a router: log into the admin interface and confirm that both DNS entries use the same provider’s pair. If your router supports strict-order for DNS, enable it only if you fully understand that it forces the first server to handle all queries until it fails—and you are certain you want that behavior. Otherwise, leave the default and trust the matching pair.

For power users and gamers: test your configuration. Use nslookup with a domain known to be blocked (e.g., nslookup testmalware.quad9.net) and verify which server responds. Repeat several times to see if answers come from both addresses. If you see inconsistencies, switch to a matched pair.

For IT administrators: audit your endpoint DNS-over-HTTPS settings via Group Policy or MDM. Ensure that all managed browsers and the OS itself are configured to use the same, authorized resolvers. Block unapproved encrypted DNS in firewalls if necessary. Monitor resolver logs to detect clients bypassing your intended security chain.

If you rely on DNS filtering for security: never mix a filtering resolver with an unfiltered one. The alternate is not a second opinion; it’s a silent fallback that can leak dangerous traffic when you least expect it.

Outlook: Rethinking the Alternate DNS Label

Microsoft could improve clarity in the Windows Settings app by adding a tooltip or informational text explaining that negative responses do not trigger a fallback. But given the long history of this behavior, a change is unlikely in the near term.

What is more probable is that the increasing adoption of zero-trust network models and cloud-delivered security will make local DNS settings less relevant. We are already seeing the shift with DNS-over-HTTPS being forced by browsers and operating systems. Eventually, the pair of IP addresses in a dusty control panel might be replaced by a single, policy-driven resolver configured through MDM or a cloud portal.

Until then, the simplest protection remains: keep your DNS servers in the same family. That way, your internet stays predictable and your defenses stay up—exactly as you intended.