Incident Overview
At the fictional logistics firm Solstice Freight, the internal engineering team runs two authoritative name servers for the zone internal.solsticefreight.corp: a primary, ns1-primary, and a secondary, ns2-secondary. On a Tuesday morning, the helpdesk begins receiving reports that a handful of internal applications are resolving an old load-balancer address for billing.internal.solsticefreight.corp that was retired three weeks earlier during a migration.The on-call administrator's first assumption is a stale client-side DNS cache.
However, the reports keep arriving from machines that were rebooted overnight, which should have cleared any local cache. A network engineer separately notes, almost in passing, that a routine firewall ACL tightening was rolled out to the DNS subnet two days earlier, restricting the allowed port range for that segment.
Nobody has yet connected the two observations.
Investigation Options
Review the available operational moves and select the best immediate action.
Restart the DNS service on the secondary server to force it to reload its existing data.
Capture and inspect bounded network traffic on port 53 between the primary and secondary name servers to confirm whether the TCP zone-transfer connection is being blocked before requesting any firewall change.
Manually copy the zone file from the primary server to the secondary server to synchronise records immediately.
Increase the DNS record TTL values so clients cache answers for longer, reducing the visible impact of the discrepancy.