Name resolution and connectivity tests

Thursday, October 29, begins with a flood. Between 7:55 and 8:20, nine tickets arrive from three different clients, all saying websites will not load. Jordan's first instinct is to suspect a major internet outage, but Marisol asks him to test before guessing. Within five minutes he finds that every affected device can reach outside IP addresses perfectly well, but none can turn names into addresses. All three clients use the same filtering DNS service that Brightline set up for them, and that service is having a regional problem. Marisol switches the three sites to the backup resolvers in the firewall settings, the tickets stop, and she posts a status update to the affected clients before most of their staff have finished their first coffee.

Name resolution is the fourth step on the staircase, and it fails more often than people think. This lesson explains how DNS works from a client's point of view and teaches the small set of command-line tests that every support technician uses to prove where a connectivity problem lies.

What DNS does

The Domain Name System translates names such as www.example.com into IP addresses. When an application needs to reach a name, the operating system first checks its own cache of recent answers and a local hosts file. If neither has the answer, it asks the DNS servers in its network settings. Those servers, called recursive resolvers, either answer from their own cache or work through the DNS hierarchy on the client's behalf: they ask the root servers which servers handle the top-level domain, ask those which servers are authoritative for the domain, and then ask the authoritative servers for the record itself. The answer comes back with a time to live, which says how long it may be cached.

Several types of DNS record matter to support work. An A record maps a name to an IPv4 address, and an AAAA record maps it to an IPv6 address. A CNAME record makes one name an alias for another. MX records tell email systems where to deliver mail for a domain. TXT records hold text, often used to prove domain ownership and to publish email security policies. PTR records support reverse lookups from an address back to a name.

Internal names and split DNS

Many organizations also have internal names that exist only on their own network, such as a file server or a printer. In networks built around Microsoft Active Directory, the domain controllers run DNS for the internal domain, and clients must use them as their DNS servers to find internal resources. If a laptop uses a public DNS resolver instead, it can browse the internet but cannot find the file server by name, which produces a confusing symptom: "the internet works but the shared drive is gone". Riverside Family Law's network is set up this way, and lesson 12 includes a ticket caused by exactly this mistake.

Some organizations use split DNS, where the same name resolves to an internal address inside the office and a public address outside. A user whose laptop has cached the inside answer may not reach the service from home until the cache clears. Clearing the client's DNS cache is a common fix after DNS changes.

The core connectivity tests

A small set of tools answers most connectivity questions. The ping command sends small echo requests and reports whether replies come back and how long they take. The traceroute command, tracert on Windows, shows each router along the path to a destination. The nslookup command, and dig on macOS and Linux, asks DNS servers directly and shows their answers. The ipconfig command on Windows, and ifconfig or ip on other systems, shows the device's own settings. Used in the right order, these tools climb the staircase from lesson 1 one step at a time.

The ladder works like this. First, ipconfig confirms that the device has a sensible address, mask, gateway and DNS server, not a 169.254 address. Next, pinging 127.0.0.1, the loopback address, confirms that the device's network software is working; this almost always succeeds and failure points to a damaged network stack. Pinging the device's own address confirms the interface is up. Pinging the default gateway confirms the device can reach its router across the local network. Pinging a well-known outside IP address confirms the internet connection beyond the router. Finally, pinging or looking up an outside name confirms DNS. The first test that fails shows which step on the staircase is broken.

C:\Users\jordan> ping 192.168.20.1
Reply from 192.168.20.1: bytes=32 time=2ms TTL=64
Reply from 192.168.20.1: bytes=32 time=1ms TTL=64

C:\Users\jordan> ping 9.9.9.9
Reply from 9.9.9.9: bytes=32 time=14ms TTL=57
Reply from 9.9.9.9: bytes=32 time=13ms TTL=57

C:\Users\jordan> ping www.example.com
Ping request could not find host www.example.com. Please check the name and try again.

C:\Users\jordan> nslookup www.example.com
Server:  UnKnown
Address:  192.168.20.1

*** UnKnown can't find www.example.com: Server failed

Jordan's tests at the bakery show exactly that pattern. The gateway replies in a couple of milliseconds, an outside address replies in about fourteen, so the link, address, gateway and internet connection are fine. The name lookup fails, and nslookup shows the DNS server returning a failure. The fault is at step four, and switching DNS servers fixes it.

Reading ping and traceroute results

A successful ping shows a reply from the target with a round-trip time. A request timed out means no reply came back within the time limit, which can mean the target is down, the path is broken, or a firewall is blocking ping. That last point matters: many servers and some home routers deliberately ignore ping, so a failed ping is not proof that a service is down. A destination host unreachable message from the device's own address or from a router means there is no route to the destination. Round-trip times that jump around or occasional lost replies suggest a congested or unstable link, often Wi-Fi.

Traceroute shows each router on the path with the time to reach it. It is useful for showing whether traffic leaves the office at all and roughly where it stops. Lines of asterisks mean a router did not answer, which is often normal for routers configured not to respond, so a support technician looks at where the trace stops for good rather than at every gap. At entry level, traceroute mostly answers one question: is the problem inside our network, or out at the provider or beyond?

C:\Users\jordan> tracert -d 9.9.9.9

  1     1 ms     1 ms     1 ms  192.168.20.1
  2     9 ms     8 ms     9 ms  100.64.12.1
  3    11 ms    10 ms    12 ms  206.47.0.25
  4     *        *        *     Request timed out.
  5    14 ms    13 ms    14 ms  9.9.9.9

Testing a specific service

Ping and DNS prove that the network can reach a host, but not that the service on it is working. Support technicians test services directly where they can: opening a web page in a browser, mapping a share, or, on Windows, using the PowerShell command Test-NetConnection with a port number to check whether a particular port answers. A website that loads for one user but not another, when both pass the ladder, points at the browser, the user's account or a cached sign-in, not the network.

PS C:\Users\jordan> Test-NetConnection fileserver01 -Port 445

ComputerName     : fileserver01
RemoteAddress    : 10.10.1.20
RemotePort       : 445
TcpTestSucceeded : True

Clearing caches

Clients cache DNS answers, and browsers cache their own. After a DNS change, or after a DNS failure that has been fixed, a device may keep using a stale or failed answer until the cache entry expires. On Windows, ipconfig /flushdns clears the system cache; on macOS, a command clears the resolver cache, and restarting the browser clears its own. Clearing caches is a quick test as well as a fix: if a name works after flushing, the cache was the problem.

The hosts file and other surprises

Before asking DNS, operating systems check a local hosts file, a simple text list of names and addresses. It is rarely used today, but malware sometimes edits it to redirect banking or security websites, and old entries left by a long-gone software install can send a name to an address that no longer exists. When one device resolves a name differently from all its neighbors, the hosts file is worth a look. On Windows it lives in the system32\drivers\etc folder; on macOS and Linux it is the file named hosts in the etc folder.

Browsers add their own twist. Many can use DNS over HTTPS, sending name lookups encrypted to a resolver chosen by the browser rather than the one in the device's network settings. That protects privacy on untrusted networks, but it can bypass the organization's filtering DNS and its internal names. If a website is blocked in one browser and not another, or an internal site works in one browser only, the browser's secure DNS setting is a suspect. Organizations usually control it through browser policy.

Testing from more than one place

A single test from a single device can mislead. When a service seems down, test from a second device on the same network, and if possible from outside it, for example from a phone on cellular data. If the service works from outside but not from inside, the fault is in the local network, its firewall or its DNS. If it fails everywhere, the service itself or its provider is having trouble, and many providers publish status pages that confirm outages. Checking a status page before deep troubleshooting has saved Jordan more than one wasted hour.