DNS filtering fail open vs fail closed: what happens when the filter is down

DNS filtering fail open vs fail closed is the choice of what a network does when its filtering resolver stops answering. Fail open falls back to an unfiltered resolver, so browsing continues without protection. Fail closed sends queries nowhere else, in line with NIST SP 800-53 control SC-24 (fail in known state), so nothing resolves unfiltered.

What is DNS filtering fail open vs fail closed?

DNS filtering sits at the first step of every connection. A cell phone asks a resolver to turn a domain name into an IP address before it opens any session (RFC 1035). A protective DNS resolver checks that name against threat intelligence and your content policy. It then returns the real address, a block page address or a refusal.

This placement is the reason DNS filtering works. The check happens before a single packet reaches the destination. It can stop a phishing link or a malware callback that a firewall would see only as allowed traffic on port 443. CISA and the NSA run protective DNS services on the same principle.

The placement is also the weak point. If every lookup depends on the filtering resolver, you need a plan for when it cannot be reached. There are only two plans.

• Fail open. The network or device sends the query to another resolver that applies no policy. Browsing carries on, but protection, logging and content rules stop until the filter returns.
• Fail closed. No unfiltered path exists. New lookups wait for a filtering resolver to answer, and nothing resolves without a policy decision.

The choice is a trade between availability and assurance. Fail open favors the visitor who wants a page to load now. Fail closed favors your security team, safeguarding lead and auditor, who need to show the network was filtered every minute of the year.

NIST SP 800-53 Rev. 5 frames the same idea in two controls. SC-24 is "fail in known state" and SC-7(18) is "fail secure" (NIST SP 800-53 Rev. 5).

How does filter failure behavior work at the resolver?

Your configuration decides filter failure behavior, not the filter itself. Three places set it: DHCP, any local DNS forwarder, and the device.

The DHCP DNS fields

DHCP is the protocol that hands each device its IP address and network settings when it joins. Most guest and staff networks use it to give every device two or more DNS server addresses. If all of them point to filtering resolvers, the design fails closed. If the second points to an ISP or public resolver, the design fails open, whatever the filtering vendor promises.

The local forwarder

Many firewalls and gateways run a DNS forwarder. Devices query the gateway, and the gateway forwards to upstream resolvers. Here the fallback lives in the forwarder's upstream list. A forwarder that lists a public resolver below the filter fails open, even if DHCP looks clean.

The device's own behavior

Resolver selection varies by operating system. Some devices treat the second server as a strict standby. Others query it whenever the first is slow, or send queries to both. On a fail open design, unfiltered answers can therefore leak out while the filter is perfectly healthy.

What fail closed looks like

In a fail closed design, every DNS address a device or forwarder can use points to a filtering resolver with the same policy. If one stops answering, the device retries against the next. The lookup fails only when every filtering resolver is unreachable. The device then gets a timeout or SERVFAIL, the standard DNS "server failure" response, instead of an unfiltered answer.

Done properly, fail closed is not fragile. The resilience comes from redundant filtering resolvers, not from an unfiltered escape hatch.

Fail open, fail closed, fail secure: which terms get confused?

Four neighboring terms turn up in vendor documents, audit findings and change tickets. They describe different things, and mixing them leads to the wrong design.

Fail closed is not default deny

Default deny is a policy choice about uncategorized domains. It runs while the filter is healthy. Fail closed is about what happens when the filter is absent. You can run fail closed with a permissive policy, or fail open with a strict one.

Serve-stale sits between the two

RFC 8767 lets a resolver answer from expired cache when it cannot reach upstream servers. That keeps popular names working during short outages. It replays the last decision, so a domain that turned malicious since then is not caught.

Bypass is not failure

A device using DNS over HTTPS (DoH, RFC 8484) or DNS over TLS (DoT, RFC 7858) to a public resolver never touches your filter. Fail closed settings do nothing about it. You handle bypass with egress rules.

Where do you meet a DNS filtering outage in practice?

A DNS filtering outage matters only when the internet link is up but the filter is unreachable. If the whole uplink drops, both modes look the same. In practice, the gap opens through ordinary operational events:

• a firewall change that blocks outbound port 53 to the filter's addresses;
• a local forwarder that crashes or stops forwarding upstream;
• a routing change on a branch WAN that sends DNS the wrong way;
• a contractor editing a DHCP scope and adding a public resolver "for resilience";
• an incident at the filtering provider itself.

Each of these looks harmless on a fail closed network. Each one silently removes protection on a fail open network.

Hospitality guest networks

Hotels and restaurant groups apply content policy to keep guest WiFi suitable for families and safe from malware. A fail open guest network drops that policy without telling anyone. For large hospitality operators, a policy lapse on public WiFi carries brand risk as well as security risk.

Healthcare

Shield blocks around 241,000 threats a week at St George's Healthcare NHS Trust. By our arithmetic, that averages about 1,400 an hour. A one-hour fail open window would let those lookups resolve unchecked, across patient, visitor, and staff devices.

Transportation hubs

Airports carry thousands of passenger devices on public networks, many of them unmanaged. In a terminal, a fail open gap means an unfiltered public network at peak volume.

Staff and corporate networks

Staff networks raise the stakes on availability. Business apps must keep working, so fail closed needs genuine redundancy behind it. Internal names usually resolve on internal DNS servers, which then forward external queries to the filter. Make sure that forwarding tier has no unfiltered upstream either.

What are the limits and edge cases of fail closed DNS?

Fail closed is the right default for most guest and staff WiFi. It still has limits, and you should know them before you design around it.

Fail closed with one resolver is an outage plan

If the network lists a single filtering address, fail closed means every outage of that address takes DNS down. Redundancy across multiple filtering resolvers is what makes fail closed workable. Ask your provider how many resolver addresses you can configure and test each one.

Cache keeps some names alive

Every DNS answer carries a TTL (time to live), the number of seconds a device or resolver may cache it. During a short outage, cached names keep working and new names fail. Visitors notice this as "some sites work, others don't", which can mislead your helpdesk.

Captive portals need DNS before login

A captive portal is the splash page a guest sees before getting online. The device must resolve the portal and any walled garden domains before it authenticates. If the pre-login network uses an unfiltered resolver, the portal becomes the gap. If it fails closed with no redundancy, guests cannot log in at all.

A failure looks different from a block

A blocked domain should return a block page or a clear refusal. A failed lookup returns a timeout or SERVFAIL. RFC 8914 Extended DNS Errors adds codes that tell them apart, such as Blocked (15) and Filtered (17) versus No Reachable Authority (22). Brief your help desk on both, so they can tell a policy block from an outage.

DNS cannot see past the name

Fail closed guarantees a policy decision on every lookup, not total coverage. Connections to raw IP addresses skip DNS entirely. Connections already open before the outage carry on. DNS also sees only the domain, never the path, which is explained in why DNS filtering cannot see full URLs.

For where these limits fit in a wider stack, see is DNS filtering enough? and the DNS filtering limits overview.

How does fail closed DNS relate to Purple Shield?

Purple Shield is protective DNS and content filtering for every network. Shield fails closed, so an outage never leaves a network unfiltered. Every lookup gets a policy decision or no answer, never an unchecked one.

You can run Shield standalone on any WiFi network or alongside Purple Access. You set a policy per network and per VLAN (virtual LAN, a logically separate network on shared hardware). Guest, staff, and back-office networks at one venue can each carry different rules. Shield needs no new hardware and sits as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet.

DNSFilter and Cisco Umbrella also filter at DNS resolution, so the placement argument applies to all three. The question to ask each vendor is where the fallback lives. Ask how their roaming agents behave when resolvers are unreachable, and how many filtering addresses you can configure. Then check that your own DHCP and forwarder settings do not reintroduce an unfiltered path.

Shield runs across Purple's footprint of 80,000+ venues in 90 countries. Read how Shield works for deployment detail. The enterprise WiFi security guide shows where DNS filtering sits alongside identity and segmentation.

This concept bites in the change window, not the brochure. The firewall rule, the DHCP edit or the "resilient" public secondary decides whether your network stays filtered. Audit those three settings this quarter. Next, read DNS over TLS and filtering: what port 853 changes, because a fail closed resolver only protects devices that actually use it.