A lame delegation is when a nameserver listed for your domain does not actually answer authoritatively for it. The parent zone points resolvers at that server, the server shrugs, and your domain becomes slow and unpredictable instead of cleanly broken. That is what makes it dangerous: half your visitors are fine, the other half see timeouts, and nothing in your control panel looks wrong.
This guide explains what a lame delegation really is, the exact ways it happens, and how to test each nameserver so you can point to the specific server that is misbehaving and fix it.
What "lame" actually means
Every domain is delegated. The parent zone (for example the .com servers) holds NS records that say "ask these nameservers about example.com." Those nameservers are supposed to be authoritative, meaning they hold the zone and set the Authoritative Answer (AA) flag when they reply.
A nameserver is lame when it is listed in that delegation but does not meet the contract. In practice it fails in one of a few ways:
- It does not host the zone at all, so it returns REFUSED or a non-authoritative answer.
- It hosts the zone but does not set the AA flag, or returns SERVFAIL.
- It is unreachable: the IP is dead, routed nowhere, or the port is blocked.
- The nameserver's own hostname no longer resolves, so resolvers cannot even find it.
Because a resolver picks among your listed nameservers more or less at random, a single lame server does not take you fully offline. It makes resolution intermittent, adds retry delays, and produces the "works for me, broken for them" reports that are so hard to chase down.
Why it happens
Lame delegations are almost always the residue of a change that was half finished. The most common causes:
- You added a nameserver at your registrar but never created the zone on that provider.
- You migrated DNS providers and left the old provider's nameservers in the delegation at the registrar.
- The parent's NS set (what your registrar publishes) no longer matches the NS records inside your own zone.
- An in-bailiwick nameserver (a nameserver named inside the domain it serves, like ns1.example.com) lost its glue record at the registrar, so it cannot be found.
- The domain used for your nameservers expired, or the nameserver IP changed and was never updated.
The two places delegation can disagree
There are two NS lists, and they must agree. The parent side is the delegation your registrar publishes to the TLD. The child side is the NS record set inside your zone apex. When they drift apart, resolvers can cache the wrong set and behavior turns flaky.
| Where you look | How to query | What healthy looks like |
|---|---|---|
| Parent (TLD) delegation | dig NS example.com @a.gtld-servers.net |
Lists every nameserver you expect, and only those |
| Child (authoritative) NS set | dig NS example.com @ns1.example.com |
Same list as the parent, AA flag set |
| Each individual nameserver | dig SOA example.com @ns2.example.com +norecurse |
status: NOERROR, flags: qr aa, matching serial |
| Glue for in-bailiwick NS | dig +trace example.com |
A and AAAA glue present for ns names inside the domain |
If the parent list and the child list differ, or any single server fails the SOA test, you have found your lame delegation.
How to diagnose it step by step
- Get the parent's view. Ask a TLD server (or run a trace) for your NS records so you know exactly which servers resolvers will be told to use. Our nameserver delegation trace walks the chain from the root to your nameservers and flags a mismatch for you, which is faster than querying gTLD servers by hand.
- Query each nameserver directly. For every server in the list, run
dig SOA example.com @thatserver +norecurseand confirm you getstatus: NOERRORwith theaaflag set and a matching SOA serial. A server that returns REFUSED, SERVFAIL, or drops the AA flag is your lame one. - Compare serials across servers. If one nameserver answers authoritatively but with an older SOA serial, zone transfers between your primary and secondary are broken. That is a softer form of lameness and still causes stale answers.
- Check reachability. If a server never answers, confirm the IP is live and that UDP and TCP port 53 are open. A firewall that blocks TCP 53 breaks large responses and DNSSEC.
- Confirm the record layer looks sane. Once the delegation is clean, a DNS lookup against your records confirms the actual A, MX, and TXT answers are what you expect from every server.
How to fix a lame delegation
The fix is always to make the delegation and the reality match. Depending on what you found:
- If a nameserver does not host the zone, either create the zone on that provider or remove that nameserver from the delegation at your registrar. Never advertise a nameserver that is not serving the zone.
- If you migrated providers, delete the old provider's nameservers from the registrar and from your apex NS records, and let the old records age out per their TTL.
- If the parent and child NS sets disagree, decide on the correct set and update both the registrar delegation and the zone's apex NS records so they are identical.
- If an in-bailiwick nameserver has no glue, add the glue (host) record at your registrar so ns1.example.com resolves to an IP.
- After any change, wait for the parent delegation NS TTL to expire before you expect every resolver to agree, then re-run the per-server SOA test.
Because delegation records are cached, a lame delegation you just fixed can linger in resolvers for hours. Verify with a DNS propagation check across regions so you can see the corrected NS set replacing the old one worldwide rather than trusting a single local query.
How lame delegation differs from a normal delegation trace
A healthy delegation trace simply shows the path from root to your nameservers. Lame delegation is the failure mode of that path: the servers exist in the listing but do not deliver authoritative answers. If you want the clean-state explainer first, read how DNS delegation works from root to nameservers, and if the culprit turns out to be a missing host record for an in-domain nameserver, see glue records explained.
FAQ
How is a lame delegation different from NXDOMAIN? NXDOMAIN means a name does not exist. A lame delegation means the name's nameservers exist in the listing but fail to answer authoritatively, so you often get SERVFAIL or intermittent timeouts instead of a clean "does not exist."
Why does my site work sometimes and fail other times? Resolvers spread queries across all listed nameservers. If one of four is lame, roughly a quarter of fresh lookups hit it and stall or fail, which produces inconsistent results depending on which resolver and which server got picked.
Can a lame delegation hurt email or just the website? Both. Receiving mail servers look up your MX and then the A record of the mail host, and they enforce timeouts. A lame nameserver can cause those lookups to fail, so mail is deferred or bounced even though your web A record is fine.
Does DNSSEC make lame delegation worse? It can. If a lame or unreachable nameserver also breaks DNSSEC responses (for example by dropping TCP 53), validating resolvers may return SERVFAIL rather than falling back cleanly, turning a soft problem into a hard failure.
How long after fixing does it take to clear? It clears within the TTL of the delegation's NS records, which is often one to two days at the TLD level. Lower the NS TTL before a planned nameserver change so corrections propagate faster.
Once the delegation is clean, keep it that way: any time you add or remove a nameserver, update the registrar and your apex NS records together, then run the per-server SOA test again before you walk away.