sfw/fix
DNS_FAILURE critical

Lighthouse error "DNS_FAILURE": servers could not resolve domain

Lighthouse's headless Chrome could not resolve the hostname to an IP, so the audit never loaded the page.

What you see

Lighthouse returned error: DNS_FAILURE.
DNS servers could not resolve the provided domain.

What’s actually happening

The audit dies immediately with no metrics, no screenshot, just the DNS_FAILURE banner. PageSpeed Insights shows the same thing while the site loads fine in your own browser. That split is the tell: resolution is failing from Google's infrastructure, not from your machine.

Common causes

  • No A or AAAA record exists for the exact hostname you submitted (often the apex vs www mismatch — example.com has a record, www.example.com doesn't)
  • Nameservers were changed at the registrar recently and the new delegation hasn't propagated to public resolvers yet
  • A typo in the submitted URL, or a trailing hostname that was never provisioned (staging.example.com)
  • DNSSEC misconfiguration — a broken signature chain makes validating resolvers (like Google's 8.8.8.8) return SERVFAIL while non-validating resolvers still answer
  • Authoritative nameservers are down or rate-limiting queries from Google's IP ranges

How to fix it

  1. Resolve the exact URL from outside your networkRun dig +short www.example.com A and dig +short www.example.com AAAA. If it comes back empty, the record doesn't exist. Test against Google's resolver specifically: dig @8.8.8.8 www.example.com. If 8.8.8.8 fails but your ISP resolver succeeds, that's the audit's exact view.
  2. Add the missing record for the submitted hostnameIf you audited www.example.com, make sure www has its own A/CNAME record — an apex record alone won't cover it. Add an A record pointing to your server IP, or a CNAME to the apex if your DNS provider supports CNAME flattening at non-apex.
  3. Check DNSSEC chain validityPaste the domain into dnsviz.net or Verisign's DNSSEC Debugger. A red break in the chain explains why validating resolvers reject it. Either fix the DS record at the registrar to match your published DNSKEY, or temporarily disable DNSSEC until the keys line up.
  4. Wait out propagation, then confirm with a TTL-aware checkIf you just moved nameservers, check whatsmydns.net for global coverage. Propagation tracks the old NS record's TTL — could be minutes, could be 48 hours. Don't re-audit until 8.8.8.8 answers consistently.
  5. Verify nameserver reachabilitydig NS example.com to list authoritative servers, then query each directly: dig @ns1.example.com example.com. A server that times out or refuses is either down or filtering Google's query traffic.

Stop it recurring

Before submitting any URL to PageSpeed Insights, confirm dig @8.8.8.8 <hostname> returns an IP — Google audits from its own resolvers, not yours.

Related errors