ERR_DNS_SERVER_FAILED

What’s actually happening

The lookup completes and comes back failed, rather than hanging — the resolver got an answer, and that answer was SERVFAIL (RCODE 2). That's a different beast from NXDOMAIN (name definitely doesn't exist) or a stalled probe. Often the domain works for some people and not others depending on which resolver they use, which is the giveaway that it's a server-side or DNSSEC issue, not the visitor's machine. dig will print 'status: SERVFAIL'.

Common causes

• DNSSEC validation failure — the zone is signed but the signatures are expired, the DS record at the parent is wrong, or there's a broken chain of trust. A validating resolver returns SERVFAIL rather than serve unverifiable data.
• The authoritative nameservers are misconfigured, unreachable, or lame (delegated but not actually answering for the zone).
• A broken upstream/forwarder in the resolver chain failing the query.
• Zone errors — bad records, a zone that failed to load on the authoritative server.
• The recursive resolver itself is having trouble (overloaded, rate-limited by the authoritative side).

How to fix it

1. Confirm it's really SERVFAIL and isolate whereRun `dig example.com` and check for 'status: SERVFAIL'. Then query a different resolver: `dig @8.8.8.8 example.com` and `dig @1.1.1.1 example.com`. If one resolver returns SERVFAIL and another returns an answer, it's almost always DNSSEC validation differing between them.
2. Check DNSSEC with an external validatorRun the domain through dnsviz.net or verisign's DNSSEC debugger. Expired RRSIG signatures or a DS record at the registrar that doesn't match the zone's DNSKEY both produce SERVFAIL on validating resolvers. Fix means re-signing the zone or correcting/removing the DS record at the registrar.
3. Verify the authoritative nameservers answerFind the delegated NS with `dig NS example.com`, then query each one directly: `dig @ns1.provider.com example.com`. A timeout or REFUSED from an authoritative server means it's lame or down — fix the delegation or the server config so every listed NS actually serves the zone.
4. Test from the visitor side with a public resolverAs an end user who just wants the site, switch your machine to 8.8.8.8 or 1.1.1.1 and flush DNS (`ipconfig /flushdns` or the macOS dscacheutil command). Some resolvers cache a SERVFAIL briefly; a different one may still answer if the issue is localized upstream.
5. If you own the zone, re-sign or roll back DNSSECRe-sign the zone and push fresh signatures, or if a key/DS mismatch is blocking everything, temporarily remove the DS record at the registrar to go insecure until the chain is repaired. Then validate on dnsviz before re-enabling. Bumping the zone serial and reloading clears stale signed data.