Network, VPN and firewallNew in this releasePublished 20 July 2026

DNS returns Server Failure or SERVFAIL: checking forwarders, firewall port 53 and cache

SERVFAIL means the resolver could not complete the query. Check authoritative data, forwarders, TCP/UDP 53, DNSSEC, timeouts and cache in sequence.

Control risk before changing productionValidate first in a test environment or on one representative system, and preserve configuration, logs and recoverable backups. Production cutovers, bulk policy changes, database repair and storage rebuild require a maintenance window and explicit rollback criteria.

1. Conclusion and scope

SERVFAIL does not mean that a name does not exist; it means the resolution process failed. A timeout, refusal or invalid response at the client resolver, caching server, upstream forwarder or authoritative server can produce the same result, so servers and record types must be compared.

This issue involves DNS, networks, VPN, firewall and controlled access. Validate query path, ports, return traffic and logging in layers.

2. Risk signals that deserve priority

The same name resolves intermittently and briefly works after cache clearing.
A records resolve but CNAME, AAAA or larger responses fail, or the two internal DNS servers disagree.

3. Pre-change assessment checklist

Use Resolve-DnsName or nslookup against each internal DNS server and the approved upstream resolver.
Check conditional-forwarder targets for empty values, wrong addresses, bad order or retired resolvers.
Verify outbound and return-path UDP 53 and TCP 53 from DNS servers to the upstream service.
Review DNS Server events, debug logs, recursion timeout, DNSSEC behaviour and negative cache.

Read-only checks and validation examples

Resolve-DnsName vendor.example -Type A -Server 192.0.2.53
Resolve-DnsName vendor.example -Type CNAME -Server 192.0.2.53
Test-NetConnection 203.0.113.53 -Port 53
Clear-DnsServerCache -Force

corp.example, 192.0.2.0/24 and 203.0.113.0/24 are documentation-only examples. Replace them only after the actual environment values have been verified.

4. Recommended implementation sequence

Correct the forwarder and firewall path first, then clear cache on both DNS servers.
Do not make clients bypass internal DNS as a permanent workaround.
Use a scoped conditional forwarder for a vendor namespace rather than changing all recursive traffic.
If the authoritative service is failing, preserve query evidence and escalate to the DNS provider.

Remote assessment or on-site work?Logs, configuration and a small number of systems can usually be assessed remotely. Physical servers, storage, data-centre power, bulk cutover and recovery exercises should use a controlled on-site window. On-site service is available for Zhejiang, Shanghai and Jiangsu; other locations can be supported remotely.

5. Validation, rollback and common mistakes

Repeated A, AAAA, CNAME and SOA queries return consistent results.
Both internal DNS servers work through failover and with warm and cold caches.
Logs no longer show persistent timeout, refusal or failed TCP fallback.

Common mistakes

Testing only ping or a web browser.
Clearing client cache while leaving bad server cache and forwarder settings.
Assuming UDP 53 is sufficient for every DNS response.

Frequently asked questions

Does SERVFAIL mean the domain does not exist?

No. A missing name normally returns NXDOMAIN; SERVFAIL means the resolver could not complete the process.

Must cache be cleared on both DNS servers?

Yes. Clients may use either server, so configuration and cache must be handled on each one.

Need an assessment based on the actual environment?

Provide versions, topology, complete errors, event-log timestamps, scope of impact, recent changes and actions already taken. We will first determine risk, service boundary and rollback, then confirm the implementation scope.