---
title: "Authoritative BIND DNS in the Real World: Why Secondary Nameservers Serve Stale TTLs (And How to Catch Zone Drift in 60 Seconds) | GreenTree Field Notes"
url: https://www.greentreehosting.com/field-notes/bind-dns-soa-serial-drift-and-60-second-ttl-troubleshooting/
description: "By Gene Salvatore: How unincremented SOA serials, blocked TCP/UDP 53 IXFR/NOTIFY rules, and parent registrar glue mismatches cause secondary BIND nameservers to serve stale 3600s TTLs—plus our 60-second verification script."
format: text/markdown
generated_from: prerendered HTML (build time)
---

[ALL SYSADMIN FIELD NOTES & RUNBOOKS](https://www.greentreehosting.com/field-notes)

FN-2026-04 // DNS & LINUX OPSDNS & Linux Infrastructure · 7 min read

# Authoritative BIND DNS in the Real World: Why Secondary Nameservers Serve Stale TTLs (And How to Catch Zone Drift in 60 Seconds)

You edit a BIND zone file to set a 60-second TTL, reload named, query one nameserver, see 60, and assume you are done—only to discover later that two other nameservers are still serving a 3,600-second TTL or an old registrar delegation set. Here is why DNS drift happens and how we caught and fixed it in production.

Published: 2026-10-25•Last tested: 2026-10-25•Tested on ISC BIND 9.18 LTS (Ubuntu 24.04 LTS & AlmaLinux 9) across NS4, NS10, NS20, NS21, NS30 & NS40

01 // THE SYMPTOM

One authoritative nameserver returns your new 60-second TTL (or updated A record), while two other nameservers for the same domain keep returning 3,600 seconds or stale records.

02 // THE ROOT CAUSE

Either (1) the zone file was edited without incrementing the SOA serial number (so secondary BIND servers ignored the NOTIFY/IXFR), (2) individual records have hardcoded 3600 TTLs overriding $TTL 60, or (3) the domain registrar parent delegation lists different NS hostnames than the zone file.

03 // THE PERMANENT FIX

Always increment the YYYYMMDDnn SOA serial before rndc reload, strip stale per-record TTL overrides, align registrar glue/NS records with the zone, and query every delegated nameserver directly.

HIGH-AVAILABILITY TTL

60 Seconds

Short cache time on HA zones so planned maintenance and failover shift traffic in ~1 minute

ZONE SYNC TRIGGER

SOA Serial +1

Secondary BIND nodes only pull zone updates when the primary SOA serial strictly increases

DELEGATION CHECK

Parent vs. Zone

Registrar parent NS delegation must match the authoritative NS records inside the zone file

AUTOMATED WATCH

DNSBot.app

Continuous multi-node SOA serial, TTL, and registrar NS drift checks across our fleet

**Sysadmin Safety Notice:**Always validate zone syntax with named-checkzone <domain> <zonefile> before running rndc reload, and verify parent registrar glue records on a test domain before changing NS delegations.

INTERACTIVE SYSADMIN RUNBOOK · SAVED IN YOUR BROWSER

## Interactive Authoritative DNS & TTL Audit Checklist

Run through these 5 checks whenever you modify a BIND zone or prepare a domain for 60-second failover:

PROGRESS: 0 OF 5 STEPS VERIFIED (0%)CLICK ANY STEP TO CHECK OFF

Check the parent registrar NS delegation first (not just your local zone file)

Run dig +trace or whois/RDAP to see the exact list of nameservers assigned at the registrar. If a domain is delegated to 3 nameservers at the registrar, updating a 4th server that isn’t delegated won’t help.

Verify both the top-level $TTL directive AND per-record explicit TTL columns

In BIND zone files, an explicit number in the second column (e.g., @ 3600 IN A ...) overrides the global $TTL 60 directive at the top of the file!

Increment the SOA serial (YYYYMMDDnn) every single time you touch a zone file

If you edit a TTL or IP and run rndc reload without incrementing the SOA serial, the primary server reloads locally, but secondary nameservers see the same serial number and skip the zone transfer.

Query every authoritative nameserver directly by hostname (@ns...)

Never rely on a single default nslookup against 8.8.8.8 or 1.1.1.1. Query each authoritative nameserver individually to confirm identical SOA serials and TTLs.

Confirm notify/allow-transfer ACLs and automated scripts don’t overwrite manual TTL edits

If a control panel (such as Virtualmin/Webmin) or nightly sync script regenerates zone templates with a default 3600s TTL, update the template/config so it doesn’t revert your 60s TTL overnight.

FIELD NOTE 01 // THREE WAYS A 60-SECOND TTL GOES SIDEWAYS

## 1. Why Testing Only One Nameserver Lies to You (And What We Caught on Our Own Fleet)

When you query a domain through a public recursive resolver like Google (`8.8.8.8`) or Cloudflare (`1.1.1.1`), that resolver picks *one* of your domain’s authoritative nameservers and returns the answer. During a live audit of `cfelectricalservice.com`, `ns4` returned our 60-second HA TTL, while `ns20` and `ns30` had reverted to `3600`—even though all three had returned `60` the day before! Once we traced the zone serial and template sync across all three delegated nameservers (`ns4`, `ns20`, and `ns30`), all three immediately returned `60` in lockstep.

In 28 years of running authoritative BIND clusters, almost every case of nameserver inconsistency comes down to one of three culprits:

• **1. Forgetting to Increment the SOA Serial:** BIND secondary servers decide whether to pull a fresh zone transfer (`AXFR`/`IXFR`) by comparing one number: the 10-digit `SOA` serial (`YYYYMMDDnn`). If a script or administrator edits a TTL in the zone file and reloads `named` without bumping the serial, the primary server serves the new TTL while the secondaries keep serving the old zone. • **2. Control Panel or Template Overwrites:** If a server management panel or DNS template has a default record TTL of `3600`, an automated zone rebuild or Let’s Encrypt DNS-01 cleanup hook can silently rewrite the zone back to `3600` the next day. • **3. Registrar Delegation vs. Zone File Mismatch:** A domain only uses the nameservers registered in the parent TLD zone at the registrar. Always check the actual delegated nameservers at the registrar (`whois` / `dig NS`) so your zone’s `NS` records and your monitoring match reality.

| Failure Mode | What You See in Production | How We Prevent It |
| --- | --- | --- |
| Unincremented SOA Serial | Primary NS returns 60s TTL; secondary NS nodes return 3600s TTL | Enforce automated YYYYMMDDnn serial bump + named-checkzone + rndc reload |
| Explicit Per-Record TTL Override | $TTL 60 is set at top of file, but A record still answers with 3600 | Strip explicit 3600 column values on A/AAAA records in the zone file |
| Control Panel Template Regression | TTL is 60s today, then reverts to 3600s tomorrow after a panel task | Update server zone templates & monitor TTL across all NS nodes every 60s |
| Parent Registrar NS Mismatch | Zone lists 4 nameservers, but registrar only delegates 3 (or different ones) | Audit parent TLD glue records via HijackRadar.com & DNSBot.app |

FIELD NOTE 02 // THE 10-SECOND MULTI-NS AUDIT

## 2. The Exact Commands to Verify Every Nameserver Side by Side

Whenever we update a zone or prepare a high-availability domain for 60-second failover, we never stop after checking a single resolver. We query every delegated authoritative nameserver directly and inspect both the **TTL column** and the **SOA serial number**.

Below are the exact `dig` (Linux/macOS) and `Resolve-DnsName` (Windows PowerShell) commands you can run from any workstation to verify that every authoritative server for your domain is in lockstep:

Checking SOA Serials and Live A-Record TTLs Across All Delegated Nameservers

```
# 0. Always validate syntax on the primary BIND node before reloading
named-checkzone yourdomain.com /var/named/yourdomain.com.hosts && rndc reload yourdomain.com

# 1. Linux / macOS (dig): Check delegated NS list, then query each NS directly
dig +short NS yourdomain.com
for ns in $(dig +short NS yourdomain.com); do
  echo "=== Checking $ns ==="
  dig +noall +answer +norecurse @$ns yourdomain.com A
  dig +short +norecurse @$ns yourdomain.com SOA
done

# 2. Windows PowerShell: Query each authoritative nameserver for TTL & SOA Serial
$domain = "cfelectricalservice.com"
(Resolve-DnsName -Name $domain -Type NS).NameHost | ForEach-Object {
  $a = Resolve-DnsName -Name $domain -Type A -Server $_ -NoRecursion
  $soa = Resolve-DnsName -Name $domain -Type SOA -Server $_ -NoRecursion
  [PSCustomObject]@{ Nameserver = $_; IP = $a.IPAddress; TTL = $a.TTL; Serial = $soa.SerialNumber }
} | Format-Table -AutoSize
```

⚠ Test on a non-production system first and verify backups before running administrative commands.

SYSADMIN Q&A

## Common Questions on BIND DNS Serial Drift & 60s TTL Audits

### Does a 60-second DNS TTL slow down my website for regular visitors?

Not noticeably. Authoritative BIND responses take only a few milliseconds, and modern browsers and OS resolvers cache the lookup during a visitor’s browsing session. For high-availability business sites, the ability to shift traffic to a warm-standby server in ~60 seconds far outweighs a once-per-minute background DNS refresh.

### Why did my TTL revert from 60 seconds back to 3600 seconds overnight?

That almost always happens when an automated control panel task (such as a nightly backup/sync job, a Virtualmin zone rewrite, or an ACME SSL renewal hook) re-saves the zone using the panel’s default 3600-second template—or when the change was made on one server without bumping the SOA serial.

### How do I check which nameservers are actually assigned at my domain registrar?

Run dig +trace yourdomain.com or check the domain’s RDAP/WHOIS record at the registry level. That shows the parent delegation set held by the TLD registry, which is what recursive resolvers on the internet actually follow.

COMPANION CORNERSTONE REFERENCE GUIDE (/LIBRARY)

### Sovereign Multi-Cloud Linux & Geo-Redundant BIND DNS Architecture

Read the full architectural guide on how we operate geographically separated BIND nameservers across US East and US West cloud backbones with 60-second health telemetry.

[Read Full Engineering Guide](https://www.greentreehosting.com/library/sovereign-multi-cloud-linux-and-authoritative-bind-dns)

MULTI-NODE AUTHORITATIVE BIND DNS

### Want Your Domains on Monitored, Multi-Backbone Authoritative DNS?

Our multi-node authoritative BIND DNS network spans US East and US West cloud backbones and is continuously audited by DNSBot.app and HijackRadar.com for serial synchronization, TTL consistency, and registrar delegation locks.

[Explore Managed BIND DNS & Security](https://www.greentreehosting.com/infrastructure)[Inspect DNSBot.app & HijackRadar.com](https://www.greentreehosting.com/software)

RELATED FIELD NOTES & RUNBOOKS

## Related Notes From the Sysadmin Desk

[View All 8 Field Notes](https://www.greentreehosting.com/field-notes)

[DNS & Linux Infrastructure8 min readWritable Standby PostgreSQL Failback Merges: Why ON CONFLICT (id) DO NOTHING Silently Drops Rows on Sequential IDs (And How to Fix It With UUIDs or Split Sequence Ranges)Audit every table in the failback merge list: use UUID primary keys (DEFAULT gen_random_uuid()) on append-only lead/submission tables, or configure non-overlapping odd/even sequence steps (INCREMENT BY 2) dynamically above MAX(id)—and check secondary unique constraints and payload hashes before skipping.Open Field Note & Checklist](https://www.greentreehosting.com/field-notes/postgres-standby-failback-merge-id-collision-and-uuid-vs-sequence-ranges)[Server Transfers & Cutovers9 min readThe Zero-Downtime Server Transfer Runbook: How We Move Live Websites, Databases, and Mailboxes Without Losing a Single Order or EmailExecute a 5-stage cutover: lower DNS TTLs to 60 seconds 48 hours early, stage and test via local hosts-file override, pre-issue TLS certificates, run a final sub-second rsync + database delta sync, and enforce a 5-source 301 redirect map.Open Field Note & Checklist](https://www.greentreehosting.com/field-notes/zero-downtime-server-migration-and-cutover-runbook)[Web App Security & Linux Ops7 min readLocking the Front Door on Modern Web Apps: Why Your Production Container Should Never Serve From the Project Root (Plus Our 8-Point Pre-Launch Gate)Enforce strict path.resolve(DIST_DIR) confinement with explicit 403/404 dotfile blocking, disable production .map files, keep secrets strictly server-side, and run an 8-point negative-testing gate before launch.Open Field Note & Checklist](https://www.greentreehosting.com/field-notes/docker-static-asset-isolation-and-8-point-pre-launch-security-gate)