DNS Troubleshooting at Layer 3: When the daemon loads the zone but the internet does not respond

I recently ran into a classic DNS challenge on a Linux server running cPanel and BIND: zone records were updated, the named daemon validated the syntax and loaded the new SOA serial without errors, but public internet resolvers (such as Google DNS at 8.8.8.8) continued returning stale data.

Here is the step-by-step diagnostic workflow, strace analysis on rndc, and the root cause identified in the TLD authority delegation layer.

1. The symptom: local vs. public query divergence#

After editing the zone for example.com and incrementing the SOA serial, I verified zone file integrity:

named-checkzone example.com /var/named/example.com.db
# zone example.com/IN: loaded serial 2026040608
# OK

Querying the local daemon (127.0.0.1) returned updated records immediately:

dig @127.0.0.1 example.com SOA +short
# ns1.example.com. hostmaster.guardian.hostingprovider.net. 2026040608 3600 1800 1209600 86400

dig @127.0.0.1 example.com A +short
# 198.51.100.246

However, querying public resolvers like 8.8.8.8:

dig @8.8.8.8 example.com SOA +short
# ns1.example.com. root.vps.example.com. 2026031501 3600 1800 1209600 86400

dig @8.8.8.8 example.com A +short
# 203.0.113.143

A clear discrepancy:

• Local (127.0.0.1): Serial 2026040608, pointing to new IP 198.51.100.246.
• Public (8.8.8.8): Old serial 2026031501, pointing to legacy server 203.0.113.143.

2. BIND control plane error (rndc out of range)#

Attempting to reload the zone via the control utility:

rndc reload example.com
# rndc: recv failed: out of range

To see what was occurring under system calls, I executed rndc under strace:

strace -v -s 1024 rndc reload example.com

Trace analysis#

The dump showed authentication key reading (/etc/rndc.key), socket allocation, and abrupt exit during signal handling:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 16
close(16) = 0
write(11, "\1\0\0\0\0\0\0\0", 8) = 8
rt_sigtimedwait([HUP INT TERM], rndc: recv failed: out of range
 <unfinished ...>) = ?
+++ exited with 1 +++

In BIND 9.16+, this indicates a control channel TCP handshake or buffer inconsistency on port 953. Restarting the daemon via systemd cleared the stuck control socket:

systemctl restart named

3. Tracing the delegation tree with dig +trace#

Even with named active on the new server IP, internet resolvers continued delivering old records.

I traced the delegation path from the Root Servers:

dig +trace example.com

Output:

com.                    86400   IN      DS      19718 13 2 ...
;; Received 1178 bytes from 198.97.190.53#53(h.root-servers.net) in 0 ms

example.com.            172800  IN      NS      ns1.example.com.
example.com.            172800  IN      NS      ns2.example.com.
;; Received 472 bytes from 192.43.172.30#53(i.gtld-servers.net) in 205 ms

example.com.            14400   IN      A       203.0.113.143
;; Received 159 bytes from 203.0.113.38#53(ns2.example.com) in 123 ms

Diagnostic breakdown:#

1. The Root Server referred resolution to .com TLD servers (gtld-servers.net).
2. The TLD server designated ns1.example.com and ns2.example.com as authoritative.
3. The resolver connected to ns2.example.com at IP 203.0.113.38 (the legacy server).
4. The legacy server answered with the old A record: 203.0.113.143.

The new server was operating as an isolated island because public delegation routed traffic to the old infrastructure.

4. Root cause: outdated glue records in the TLD#

Querying the authoritative .com TLD server directly without recursion:

dig ns example.com @i.gtld-servers.net

The response in the ADDITIONAL SECTION revealed the issue:

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

;; ADDITIONAL SECTION:
ns1.example.com. 172800  IN      A       203.0.113.143
ns2.example.com. 172800  IN      A       203.0.113.38

Because the nameservers (ns1/ns2) reside in the same domain they resolve (example.com), DNS protocol rules require Glue Records at the parent TLD to break circular dependencies.

The .com registry was still advertising legacy IP addresses for ns1 and ns2.

5. Remediation#

The fix does not live in local named.conf files. It must be updated at the Domain Registrar:

1. Log into your domain registrar dashboard (e.g. GoDaddy, Namecheap, Registro.br).
2. Locate the Glue Records management interface (often named Child Nameservers, Hostnames, or Registered Hosts).
3. Update the IP addresses:

• ns1.example.com -> 198.51.100.246
• ns2.example.com -> 198.51.100.247

1. Allow TLD delegation TTLs to expire and monitor with dig ns example.com @i.gtld-servers.net until the new IPs appear in the Additional Section.

Conclusion: practical lessons on DNS delegation#

1. Local queries only validate disk files: A healthy zone in 127.0.0.1 does not guarantee external internet traffic reaches your server.
2. Use dig +trace to observe true resolution paths: Trace queries clearly reveal where traffic is being diverted.
3. Same-domain nameservers require Glue Record updates: When your NS hosts share the domain name of the zone, updating registry glue records is mandatory to guide internet traffic to the new host.

See also

Servers Complete Guide to DNS Zones in cPanel and WHM: Fixing 'DNS Entry Already Exists', killdns CLI, and Advanced Templates

Linux Fixing 'cannot refresh cache whilst offline' in Linux and cPanel

Infrastructure Case Study (RCA): Investigating a Global Email Routing Outage Post-Migration in cPanel

This post is licensed under CC BY-NC.