What is a lame delegation and how do you fix it?

A lame delegation happens when a domain's parent zone (such as .com) lists a nameserver for the domain, but that nameserver doesn't actually serve the domain's zone. When a resolver asks it, the server refuses, gives a non-authoritative answer, or doesn't respond at all. To fix it, find which listed nameservers are lame by querying each one directly with dig +norecurse and checking for the aa flag, then either add the zone to those servers or remove them from the nameserver list at your registrar so that only servers that really host your zone remain.

Lame delegations are one of the quietest DNS faults. A domain with one lame nameserver out of four usually still works, just a little slower and less reliably, so the problem can go unnoticed for years. When every nameserver is lame, the domain stops resolving entirely. This guide explains how delegation works, what makes a nameserver lame, how to test for it, the common ways it happens, and how to fix and prevent it.

How Delegation Works

DNS is a hierarchy of zones. The .com zone doesn't hold your website's records. Instead, it holds NS records that delegate example.com to your nameservers. That delegation says "for anything under example.com, ask these servers".

You can see the delegation by asking a .com server directly:

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

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.		172800	IN	NS	ns1.example.net.
example.com.		172800	IN	NS	ns2.example.net.

The records appear in the AUTHORITY section with no aa flag, because the .com server isn't authoritative for example.com. It's only pointing the way. Those NS records are set by your registrar when you enter nameservers in its control panel.

Each of the servers named in the delegation is expected to be authoritative for the zone. When a resolver queries one of them, it should get an answer with the aa (authoritative answer) flag set.

What Makes a Delegation Lame

A delegation is lame when a nameserver named in it isn't actually authoritative for the zone. The DNS terminology standard (RFC 9499) defines it as a delegation where one or more of the designated nameservers answers non-authoritatively for the zone, and notes that the term is often used more loosely to include servers that don't respond at all.

In practice, a lame nameserver behaves in one of these ways:

Behaviour	What the resolver sees
Server doesn't have the zone and refuses	status: REFUSED
Server doesn't have the zone and answers from cache or recursion	An answer without the aa flag
Server returns a referral back up the tree	NOERROR with no answer and NS records pointing elsewhere
Server has the zone but it failed to load or has expired	SERVFAIL
Server address doesn't respond	Timeout
Nameserver hostname doesn't resolve	No address to query at all

The strict definition focuses on servers that answer non-authoritatively, but in everyday use the term covers all of these. They all mean the same thing for resolvers: a listed nameserver that can't be used.

Why Lame Delegations Matter

Partial Lameness

If some but not all of your nameservers are lame, the domain still resolves, but:

• Lookups are slower: Resolvers pick nameservers based on past response times, but they still waste time on the lame ones, especially when their caches are cold. Each timeout can add hundreds of milliseconds or more.
• Reliability drops: You have fewer working nameservers than you think. If one of the good ones fails, you may have no redundancy left.
• Intermittent failures appear: Some lookups that hit a lame server first may fail or be retried, producing problems that are hard to reproduce.

Full Lameness

If every listed nameserver is lame, resolvers can't get an answer at all. They return SERVFAIL, and the domain, including its website and email, stops working.

Security Risk

A lame delegation to a nameserver at a large DNS hosting provider can be dangerous. If your domain is delegated to a provider's nameservers but your zone no longer exists there, someone else may be able to create an account and add a zone for your domain on those same servers. They would then control answers for your domain from that nameserver. Many providers now guard against this, but removing lame delegations to third-party providers is still an important part of DNS hygiene.

How to Detect a Lame Delegation

Step 1: Get the Delegation from the Parent

Always check what the parent says, not just what your own zone says, because the parent's NS records are what resolvers follow. For .com and .net, ask a Verisign server. For other TLDs, find one first:

# Find a nameserver for the TLD, then ask it for your domain's delegation
tld_ns=$(dig org NS +short | head -n 1)
dig +norecurse @"$tld_ns" example.org NS

A simpler option that works for any domain is dig +trace, which follows the delegation from the root and shows the NS records each level returns:

dig +trace example.com NS

Step 2: Query Each Nameserver Directly

Ask every listed nameserver for the zone's SOA record, with recursion turned off, and look at the status and flags:

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

A healthy, authoritative response looks like this:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31570
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.		3600	IN	SOA	ns1.example.net. hostmaster.example.com. 2026101801 7200 3600 1209600 300

The important parts are status: NOERROR, the aa flag, and an SOA record in the answer section.

A lame server typically looks like this instead:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61832
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Step 3: Check All Nameservers with a Script

This script reads the delegation from the parent, tests every nameserver on every address it has, and reports which are lame:

#!/usr/bin/env bash
# Usage: ./lamecheck.sh example.com
zone="${1%.}"
tld="${zone##*.}"
parent_ns=$(dig +short "$tld" NS | head -n 1)

echo "Delegation for $zone from $parent_ns:"
nameservers=$(dig +norecurse @"$parent_ns" "$zone" NS +noall +authority +answer |
              awk '$4=="NS"{print $5}' | sort -u)

for ns in $nameservers; do
  addrs=$(dig +short "$ns" A; dig +short "$ns" AAAA)
  if [ -z "$addrs" ]; then
    printf "  %-28s %-26s %s\n" "$ns" "-" "LAME (name does not resolve)"
    continue
  fi
  for ip in $addrs; do
    out=$(dig @"$ip" "$zone" SOA +norecurse +time=3 +tries=1 2>&1)
    status=$(echo "$out" | awk -F'status: ' '/status:/{split($2,a,",");print a[1]}')
    if echo "$out" | grep -qE "flags:[^;]* aa[ ;]"; then aa="yes"; else aa="no"; fi
    serial=$(echo "$out" | awk '$4=="SOA"{print $7}')
    if [ "$status" = "NOERROR" ] && [ "$aa" = "yes" ] && [ -n "$serial" ]; then
      result="OK (serial $serial)"
    elif [ -z "$status" ]; then
      result="LAME (no response)"
    else
      result="LAME (status=$status, aa=$aa)"
    fi
    printf "  %-28s %-26s %s\n" "$ns" "$ip" "$result"
  done
done

Example output for a domain with one good and one lame nameserver:

Delegation for example.com from a.gtld-servers.net.:
  ns1.example.net.             198.51.100.53              OK (serial 2026101801)
  ns2.oldhost.example.         203.0.113.53               LAME (status=REFUSED, aa=no)

If the machine you run it on has no IPv6 connectivity, every IPv6 address will show as "no response", so run it from an IPv6-capable host or ignore those lines. The script handles the common case of a second-level domain directly under a TLD. For deeper delegations, such as a subdomain delegated to a different provider, use dig +trace to find the parent's nameservers and query them yourself.

Step 4: Compare Parent and Child NS Records

Your zone also contains its own NS records at the apex. Ideally they match the parent's delegation exactly. Mismatches are a common source of lameness, because a nameserver might be listed in one place and forgotten in the other:

# What the parent says
dig +norecurse @a.gtld-servers.net example.com NS +noall +authority

# What your zone says
dig @ns1.example.net example.com NS +norecurse +noall +answer

If the parent lists ns2.oldhost.example but your zone doesn't, the parent's list is out of date. If your zone lists a server the parent doesn't, that server doesn't get used for initial lookups and may hide a problem.

Online Tools

Several free tools test delegation thoroughly and flag lame servers, including DNSViz (dnsviz.net), which shows the delegation graphically, and Zonemaster (zonemaster.net), which runs a full suite of delegation and consistency tests. Zonemaster also has a command-line version if you want to run the same tests in automation.

Common Causes

Changing DNS Providers Without Updating All Nameservers

You move to a new DNS provider and enter its nameservers at your registrar, but leave one of the old provider's nameservers in the list. Once you cancel the old account, that server stops serving your zone and becomes lame.

Deleting the Zone Before Changing the Delegation

You delete your domain from a DNS provider's dashboard, or close the account, before changing the nameservers at the registrar. Every listed nameserver is now lame and the domain goes offline.

Typos in Nameserver Names

ns1.exmaple.net instead of ns1.example.net. The misspelled name may not resolve at all, or worse, may resolve to someone else's server.

Secondary Servers That Stopped Transferring

If you run your own primary and secondary nameservers, a secondary that can't reach the primary keeps serving its copy until the SOA expire time passes, then stops answering for the zone. Firewall changes, a changed primary IP address, or a broken TSIG key are the usual culprits.

Zone Not Added to a New Nameserver

When adding a new nameserver to the delegation, it's easy to update the registrar first and add the zone to the server later. During that gap, the new nameserver is lame.

Subdomain Delegations

If you delegate a subdomain, such as dev.example.com, to another team or provider, the NS records for it live in your zone. If that team retires their servers without telling you, your zone still delegates to them and the subdomain becomes lame. This is also a common route to subdomain takeover.

; In the example.com zone file
dev.example.com.    3600  IN  NS  ns1.dev-provider.example.
dev.example.com.    3600  IN  NS  ns2.dev-provider.example.

How to Fix a Lame Delegation

The fix is always one of two things: make the nameserver authoritative for the zone, or stop listing it.

Option 1: Add the Zone to the Lame Nameserver

If the server is supposed to serve your zone, add it. With a managed DNS provider, add the domain to your account and recreate the records. With your own BIND secondary, add the zone and check it transfers:

// named.conf.local on the secondary
zone "example.com" {
    type secondary;
    primaries { 198.51.100.53; };
    file "/var/cache/bind/db.example.com";
};

sudo named-checkconf
sudo rndc reconfig
sudo rndc retransfer example.com
dig @localhost example.com SOA +norecurse

On the primary, make sure transfers to the secondary are allowed and that it sends NOTIFY messages:

zone "example.com" {
    type primary;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 203.0.113.53; };
    also-notify { 203.0.113.53; };
};

Option 2: Remove the Lame Nameserver from the Delegation

If the server shouldn't be serving your zone any more, remove it:

1. At your registrar, edit the domain's nameservers and delete the lame entry. This updates the parent zone's NS records.
2. In your zone, remove the matching NS record at the apex so parent and child agree.
3. For subdomain delegations, delete the NS records for the subdomain from your zone, or replace them with the correct servers.

Keep at least two working nameservers, ideally on different networks.

Verify the Fix

The parent's NS records are often cached with long TTLs, commonly 48 hours at large TLDs, so resolvers may keep trying the lame server for a while. Confirm the parent has been updated by querying it directly:

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

Then run your lame delegation check again. Every nameserver should return NOERROR with the aa flag and the same SOA serial.

Preventing Lame Delegations

• Change the delegation before deleting a zone: When moving providers, set up the zone at the new provider, update the registrar, wait for the old NS TTL to pass, and only then remove the zone from the old provider.
• Keep parent and child NS records identical: Update both whenever you change nameservers.
• Monitor all nameservers: Have your monitoring query each nameserver directly for the SOA record and alert if any stops returning an authoritative answer or falls behind on the serial.
• Audit subdomain delegations regularly and remove ones that are no longer in use.
• Log lame servers if you run a resolver: BIND has a lame-servers logging category, so you can see which domains are delegating to servers that don't answer properly.

logging {
    channel lame_log {
        file "/var/log/named/lame.log" versions 3 size 10m;
        print-time yes;
    };
    category lame-servers { lame_log; };
};

---

FAQ: Lame Delegation

---

Conclusion

A lame delegation is a nameserver that the parent zone sends resolvers to, but that can't give an authoritative answer for your domain. One lame server out of several causes slowness and weakens redundancy, while a fully lame delegation takes the domain offline. It usually comes from incomplete provider migrations, deleted zones, typos, or secondaries that stopped receiving transfers.

Checking for it takes a few dig commands: read the delegation from the parent, then query every listed nameserver with recursion off and look for NOERROR and the aa flag. Fix any lame server by either adding the zone to it or removing it from the registrar and your zone, keep parent and child NS records in sync, and monitor each nameserver individually so you hear about the next one before your visitors do.