What lame delegation means
A DNS delegation is lame when a nameserver is listed in the parent zone as authoritative for a child zone, but the nameserver itself does not actually hold the zone — or does not know it is supposed to be authoritative for it. There is a mismatch between what the parent zone says and what the nameserver believes.
To understand this precisely, consider how DNS resolution works. When a resolver looks up example.com, it queries the root zone for the .com TLD nameservers, then queries the TLD zone for the nameservers responsible for example.com. These nameservers are the delegation recorded at the registrar. The resolver then contacts those nameservers and expects them to respond with authority — with the AA (Authoritative Answer) bit set in the response.
Lame delegation occurs when the nameserver the resolver contacts responds without the AA bit, or returns REFUSED, or returns SERVFAIL. The nameserver is saying "I don't know about this zone" to a resolver that was told — by the parent zone — that this nameserver is authoritative. The resolver cannot get a definitive answer and either tries the next listed nameserver, returns SERVFAIL, or gives up, depending on implementation.
How it causes problems
The symptoms of lame delegation are intermittent and misleading. If a domain has three nameservers and one is lame, resolution may succeed most of the time — resolvers that happen to query one of the two working nameservers get correct answers, while resolvers that query the lame one get a failure. The failure rate depends on how resolvers select nameservers and whether they learn to prefer the working ones.
Modern resolvers use RTT-weighted server selection and do learn to deprioritize unresponsive servers, but this learning is per-resolver and not guaranteed. A resolver that has cached the failure may retry the lame nameserver at the next TTL expiry and fail again. From the outside, the domain appears to have intermittent DNS failures with no obvious cause.
The practical impacts are varied. SMTP delivery failures are common — SMTP servers do their own DNS lookups and may hit the lame nameserver for MX resolution, causing mail to bounce or queue. API clients with strict DNS failure handling fail hard. DNSSEC-validating resolvers may return SERVFAIL for the entire zone if the lame nameserver provides an inconsistent or empty response. Certificate issuance may fail if the ACME DNS-01 challenge is directed to the lame nameserver.
Common causes
The most frequent cause is a DNS provider migration where the registrar's NS records were not updated. The process should be: provision the zone at the new DNS provider, populate all records, verify they are correct, then update the registrar NS records to point to the new provider. Organizations often do this in the wrong order, or update the registrar but forget to remove the zone from the old provider's nameservers (or remove it too quickly before the new NS records have propagated).
Account or subscription expiry at the DNS provider is another cause. If a DNS provider account lapses and the zones are deleted, the nameservers remain reachable but are no longer authoritative for the zone. The registrar NS records still point to the old provider's nameservers, which now return REFUSED because they have no record of the zone.
Secondary nameserver misconfiguration is a subtler case. An organization runs primary and secondary nameservers. The secondary is configured to receive zone transfers from the primary (AXFR/IXFR), but the zone transfer is failing — blocked by a firewall rule, a misconfigured TSIG key, or a wrong primary IP in the secondary's configuration. The secondary nameserver is listed in the delegation but is serving stale data or returning REFUSED because its zone has expired.
Registrar default nameservers are another pitfall. When a domain is first registered, some registrars automatically populate NS records with their own nameservers. If the zone is never created on those nameservers — because the domain owner immediately configured a different DNS provider — the registrar's nameservers are lame for the zone. This is easily missed if the DNS provider was configured correctly and resolution appears to work from the provider's nameservers, while the registrar's default servers sit lame in the delegation.
How to detect it
The direct test is to query each nameserver listed in the delegation explicitly and check the response flags. Using dig:
# Query a specific nameserver directly, bypassing resolver cache
dig @ns1.example-dns-provider.com example.com SOA +norec
# Check for the AA flag in the response header
# A healthy response includes: flags: qr aa rd; ANSWER: 1
# A lame response includes: flags: qr rd; ANSWER: 0 (missing 'aa')
# Or returns REFUSED or SERVFAILThe key flag is aa in the response header. Its absence from a nameserver that should be authoritative is the definition of lame delegation. A REFUSED response (RCODE 5) is an even clearer signal — the nameserver is explicitly saying it declines to answer for this zone.
Also compare the parent zone's NS records against the authoritative zone's own NS records. Query the TLD nameservers for the delegation NS records, then query the authoritative nameservers for their own NS records:
# Get the delegation NS records from the parent (TLD)
dig example.com NS @a.gtld-servers.net +norec
# Get the authoritative NS records from the zone itself
dig example.com NSThese two sets of NS records should match exactly. Differences indicate a zone that has been migrated without updating the registrar, or a zone where NS records have been changed in the zone file but not at the registrar.
The NS delegation consistency check
NS consistency is a closely related but distinct check from lame delegation. Lame delegation means a named nameserver is not authoritative. NS inconsistency means the set of nameservers differs between the parent delegation and the child zone's own NS record set.
A typical inconsistency scenario: the zone is hosted at a provider with four nameservers (ns1–ns4). The registrar has two of them (ns1, ns2) from an older configuration. The zone's own NS records have all four. Resolvers following the delegation will only contact ns1 and ns2, missing ns3 and ns4. This reduces resilience and may cause confusion when debugging — direct queries to ns3 and ns4 work, but recursive resolution only ever reaches ns1 and ns2.
The authoritative zone's NS records are what end users' resolvers ultimately receive as the answer to NS queries. The parent delegation controls which nameservers resolvers use to reach the zone. Both should be consistent and authoritative for the zone. An NS record in the zone file that names a server not listed in the parent delegation is a server that resolvers will never independently discover, even if it is functioning correctly.
How to fix it
The fix depends on the cause. In the common migration scenario:
- Verify that the zone is correctly provisioned at the new DNS provider — all records present, nameservers responding with AA bit set, zone content correct.
- Log into the registrar and update the NS records to point to the new provider's nameservers. Remove all nameservers from the old provider.
- Wait for the parent zone TTL to expire. The TLD zone's TTL for NS records is typically set by the registrar and is often 24–48 hours for legacy registrars, though modern providers use shorter TTLs (1–4 hours).
- Verify with explicit queries to the TLD nameservers that the new delegation is in place.
For a lame secondary nameserver, fix the zone transfer configuration: verify the primary allows AXFR from the secondary's IP, verify TSIG keys match if used, verify the secondary's configuration points to the correct primary. Force a zone transfer and verify the secondary's zone data is current.
After any fix, query all nameservers listed in the delegation individually and verify each returns the AA bit and consistent zone data.
Prevention
The most effective prevention is procedural: always update the registrar NS records as the final step of a DNS migration, not before provisioning the new zone. Run a consistency check immediately after any DNS-related change — nameserver updates, zone migrations, provider changes.
For secondary nameserver setups, monitor zone serial numbers across all nameservers. If the serial numbers diverge, zone transfers are failing. Alert on serial number staleness rather than waiting for a user to report intermittent DNS failures.
When decommissioning a DNS provider or deleting a zone, always remove the delegation (update the registrar NS records) before deleting the zone data. A nameserver that returns REFUSED is less harmful than a nameserver that returns stale data — but both indicate a lame or inconsistent delegation that should be cleaned up before the next TTL cycle completes.