Support Library
Lame Delegation
What a lame delegation is, how it happens, how to test every listed name server with dig, and how to fix it.
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
| Reply | Meaning |
|---|---|
| SOA with aa | Authoritative for this SOA query. Compare serials in a transfer topology and test the required records and paths. |
| REFUSED | The server refused this query; check ACLs and zone configuration |
| SERVFAIL | The server could not complete the query; an expired secondary is one possible cause. Check configuration and logs. |
| An answer without aa, or a referral | The server is answering from cache or pointing elsewhere; it is not authoritative |
| Timeout | No 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
- RFC 9499: DNS Terminology: defines lame delegation
- RFC 1912: Common DNS Operational and Configuration Errors
- RFC 1034: Domain Names, Concepts and Facilities: section 4.2.2 on delegation
- ISC: dig manual page