Case study 05

The Network Wasn't Down

A system was being reported as a network problem. The symptoms pointed in that direction. The actual cause was a stale DNS A record.

The situation

A domain-joined machine could not reliably reach internal resources by name. Direct IP access worked. Name-based access failed intermittently.

The initial assumption was a network problem. Connectivity appeared to be dropping. Services were becoming unavailable. Users were unable to perform routine tasks.

I investigated the problem. The network was not the issue.

The investigation

I started with the symptoms. The user reported that they could not access a specific internal resource and received an error indicating that the resource was unavailable.

I tested direct IP connectivity to the affected resource. The connection succeeded, which indicated that the network was functional.

I tested name-based connectivity to the same resource. The connection failed intermittently, which suggested a name resolution problem rather than a network problem.

I ran nslookup against the DNS server from an affected client. The query returned an incorrect IP address for the internal resource. The DNS server was returning a stale A record that pointed to an IP address that had been reassigned to a different machine during a previous configuration change.

The finding

The DNS server was functioning correctly. It was returning the records stored in its database, and the database contained a record that was no longer accurate.

Two machines had inadvertently shared the same DNS name. Queries resolved to whichever record was returned first, which produced intermittent connectivity.

I opened Wireshark and captured DNS traffic during a failed connection attempt. The capture confirmed that the client received a valid DNS response pointing to the wrong destination.

The fix

I removed the stale A record from the DNS server and confirmed that the correct record was the only entry for the hostname. I flushed the DNS cache on affected clients using the appropriate command. I verified the fix with additional nslookup queries and connectivity tests.

What I learned

This case reinforced a lesson that I apply whenever I troubleshoot connectivity problems: not every connectivity problem is a network problem.

DNS is a common source of intermittent connectivity issues. A working network with stale DNS records can appear unreliable.

Technical takeaway

The investigation involved:

  • Direct IP and name-based connectivity testing
  • nslookup queries against the DNS server
  • Wireshark packet capture of DNS traffic
  • Removal of the stale record and cache flushing
  • Verification of the fix

The lesson applies broadly: separate the symptom from the cause before changing anything. When name resolution is involved, check the records before assuming the network failed.