Fix DNS "Lame Server" Resolving Warnings in BIND (2026)

A "lame delegation" warning in BIND means a child zone is pointing to a name server that doesn’t actually host that zone.

The most common reason for this is a typo in the parent zone’s NS records. For example, if your domain is example.com and you delegate sub.example.com to ns1.example.com and ns2.example.com, a typo like ns1.example.co in the parent zone’s NS records for sub.example.com would cause a lame delegation. The parent zone (e.g., .com) thinks ns1.example.co is authoritative for sub.example.com, but when queried, ns1.example.co either doesn’t respond or responds that it doesn’t host the zone.

Here are the common causes and how to fix them:

Typo in the Parent Zone’s NS Records: This is the most frequent culprit. An administrator of the parent zone (e.g., a domain registrar or a higher-level DNS administrator) made a mistake when entering the name servers for your child zone.
- Diagnosis: Use dig from an external network to query the parent zone for your child zone’s NS records. For example, to check sub.example.com:
```
dig NS sub.example.com +short @8.8.8.8
```
  Then, for each NS record returned, query its IP address. If dig returns SERVFAIL or no records for the child zone, it’s likely a typo in the parent.
```
dig SOA sub.example.com @ns1.example.co +short
```
- Fix: You must contact the administrator of the parent zone and have them correct the NS records. For example, if the parent zone has ns1.example.co but it should be ns1.example.com, they need to edit their records.
- Why it works: The parent zone acts as a pointer. If the pointer is wrong, all child queries will go to the wrong place. Correcting the parent record fixes the initial delegation.
Incorrect IP Address for the Child Zone’s Name Server: The parent zone’s NS records correctly list the name server hostnames, but the A/AAAA records for those hostnames are either missing or point to the wrong IP addresses. This is often seen when the child zone’s name servers are newly set up or their IPs have changed.
- Diagnosis: After confirming the NS records in the parent zone are correct, check the A/AAAA records for the delegated name servers.
```
dig A ns1.sub.example.com +short @8.8.8.8
dig AAAA ns1.sub.example.com +short @8.8.8.8
```
  Compare these IPs to the actual IPs of ns1.sub.example.com. If they don’t match, the parent zone might be using outdated glue records.
- Fix: Ensure the A/AAAA records for your child zone’s name servers are correctly registered in the parent zone (often called "glue records"). This is typically done through your domain registrar’s control panel. If ns1.sub.example.com has IP 192.0.2.1, the parent zone (e.g., the .com registry) needs to have an A record for ns1.sub.example.com that resolves to 192.0.2.1.
- Why it works: The parent zone needs not only the name of the child’s authoritative server but also its address to be able to route queries directly to it. These are the glue records.
Child Zone’s Name Server Not Responding or Not Hosting the Zone: The parent zone correctly delegates to ns1.sub.example.com, and its IP is correct, but ns1.sub.example.com itself is misconfigured or down.
- Diagnosis: Directly query the child’s name server, assuming you know its IP.
```
dig SOA sub.example.com @<IP_of_ns1.sub.example.com>
```
  If this query times out, returns an unexpected error, or states that it doesn’t host the zone, then the problem is with the child’s authoritative server.
- Fix: Ensure the BIND server designated as ns1.sub.example.com is running, accessible on the network, and has a zone file for sub.example.com loaded and configured correctly. Check BIND logs for errors.
- Why it works: The delegation chain stops at the authoritative server. If that server is broken, no queries for the zone will be answered.
Firewall Blocking Queries: A firewall between the parent zone’s name servers and your child zone’s name servers, or between external clients and your child’s name servers, is blocking UDP/TCP port 53.
- Diagnosis: Use traceroute or mtr from a server that should be able to reach your name server to see where connectivity breaks. Then, attempt a direct telnet or nc to port 53.
```
nc -vz <IP_of_ns1.sub.example.com> 53
```
- Fix: Open UDP and TCP port 53 on any firewalls between your name servers and the internet, and between external resolvers and your name servers.
- Why it works: DNS queries are sent over port 53. If this port is blocked, the name server cannot receive queries or respond.
Incorrect allow-query or acl Configuration in BIND: The BIND server for ns1.sub.example.com is configured to only allow queries from specific IP addresses, and the parent zone’s authoritative servers are not on that list.
- Diagnosis: Examine the named.conf file for your BIND server. Look for acl definitions and allow-query directives within the zone configuration or globally.
- Fix: Modify the allow-query directive in your BIND configuration to include the IP addresses of the parent zone’s name servers, or a broader network that encompasses them. For example, if your zone sub.example.com is on ns1.sub.example.com:
```
zone "sub.example.com" {
    type master;
    file "/var/named/zones/db.sub.example.com";
    allow-query { localhost; 192.0.2.0/24; }; // Example: allow queries from localhost and a specific network
};
```
  Then, reload BIND: rndc reload.
- Why it works: BIND can be configured to be selective about who it answers queries for. If the parent’s resolvers aren’t permitted, they won’t get responses, leading to the appearance of a lame delegation.
DNSSEC Issues (Less Common for Lame Delegation, but Related): While not directly causing a "lame server" warning, misconfigurations with DNSSEC can sometimes manifest as resolution failures that might be confused with delegation issues. If DNSSEC is enabled, invalid signatures or missing keys can prevent validation.
- Diagnosis: Use dig +dnssec to query. Look for SERVFAIL responses and check the RRSIG and DNSKEY records.
- Fix: Carefully review your DNSSEC signing process, key rollovers, and ensure all zones involved are correctly signed and validated. This is a complex topic on its own.
- Why it works: DNSSEC adds cryptographic integrity checks. If these checks fail due to a configuration error, the resolver will typically drop the query, leading to a failure that can be mistaken for a delegation problem.

After fixing a lame delegation, you might encounter "SERVFAIL" errors if the name servers for the child zone are not properly configured or reachable.