The short answer

A delegation is lame when a listed name server does not serve the delegated zone authoritatively. A non-authoritative response can demonstrate that problem, while a timeout only demonstrates a failure to receive a response on that path. REFUSED can result from access controls, so it does not alone prove the zone is absent. Resolvers may recover by trying other listed servers, producing slow or intermittent lookups.

$ dig +norecurse @ns2.example.net example.com SOA

A healthy server returns the zone's SOA with aa in the flags. A response without authority warrants checking whether that server hosts the zone. Diagnose refused, failed and missing responses separately before calling the delegation lame.

How it happens

  • The zone moved to a new provider, but the registrar still lists one of the old provider's servers, which has deleted the zone.
  • A server was decommissioned or renumbered and nobody updated the NS records or glue.
  • A secondary server stopped transferring the zone and its copy expired, so it now answers SERVFAIL or REFUSED.
  • The NS records in the parent and in the zone itself list different servers, and one set is out of date.

Checking every server

Start from the delegation the parent publishes, then ask each server in turn, over both IPv4 and IPv6 if it has both:

$ dig +norecurse +noall +authority @a.gtld-servers.net example.com NS

$ dig +norecurse @ns1.example.net example.com SOA

$ dig +norecurse -6 @ns1.example.net example.com SOA
ReplyMeaning
SOA with aaAuthoritative for this SOA query. Compare serials in a transfer topology and test the required records and paths.
REFUSEDThe server refused this query; check ACLs and zone configuration
SERVFAILThe server could not complete the query; an expired secondary is one possible cause. Check configuration and logs.
An answer without aa, or a referralThe server is answering from cache or pointing elsewhere; it is not authoritative
TimeoutNo response reached this client; check server health, filtering and the path for this address family

Also compare the parent's NS list with the NS records the zone publishes (dig +norecurse @ns1.example.net example.com NS). They should match.

Fixing it

Either make the server authoritative again, by restoring the zone or its transfers, or remove it from the delegation at your registrar and from the zone's own NS records. Keep at least two working servers, ideally on different networks. Resolvers that cached the old NS set keep using it until its TTL runs out, which for many TLDs is a day or two.

How DNS Panopticon helps

Domain Visualizer reports a lame name server when an NS host listed for the domain has no A or AAAA address, which is one cause of lameness. It does not send queries to each authoritative server, so it cannot see a server that has an address but refuses or fails for the zone. Use the per-server checks above for that.

Sources and further reading