Linux / Intermediate: system administration reasoning / Lesson 11
Diagnose network paths and name resolution
Separate interface, route, resolver, transport, and application evidence when investigating a connection.
On this page
Lesson goals
- Read addresses, prefixes, routes, and listening sockets.
- Distinguish DNS lookup from actual connection success.
- Build a layered read-only diagnosis.
Interfaces carry addresses and scope
A network interface can have several IPv4 and IPv6 addresses. A prefix length identifies the network portion used in routing; it is not a count of machines currently connected. Loopback addresses refer to the local network stack and do not prove remote reachability. Private IPv4 ranges may need translation or private routing to reach other networks. IPv6 has its own address scopes and routing behavior, so a working IPv4 connection does not prove IPv6 works. Inspect assigned addresses before concluding a service or resolver is at fault.
A route chooses the next step
The routing table selects an outgoing interface and next hop for a destination, typically preferring the most specific matching prefix before other policy details. A default route handles destinations without a more specific match. ip route get asks how the local system would route a destination; it does not send a test packet or prove the next hop answers. Policy routing, multiple interfaces, and separate network namespaces can alter the result. Investigate from the same namespace and identity context as the application, especially when containers are involved.
ip -brief address
ip route get 192.0.2.10192.0.2.10 is a documentation address. The second command performs route lookup only; any returned route describes local configuration, not a reachable real server.
Name lookup follows configured policy
Applications commonly use the system’s name-service interface, which can consult /etc/hosts, DNS, and other configured sources. getent ahosts follows that system lookup path more closely than a direct DNS query tool. A DNS record can resolve correctly while its target service is unavailable. Conversely, connecting by address can work while name resolution fails. Inspect /etc/resolv.conf carefully because a resolver manager may generate it or point it to a local stub. Do not overwrite a managed file as a first response to a temporary lookup failure.
Transport evidence differs from application evidence
ss displays sockets and their states. A listener bound to 127.0.0.1 accepts local IPv4 connections, while a wildcard bind may expose broader interfaces subject to firewall policy. An established TCP connection proves a transport relationship, not valid application authentication or a successful request. Connection refused often means no accepting listener or an explicit rejection; a timeout may reflect packet loss, filtering, or an unresponsive destination. Neither message identifies a single universal cause. Inspect the listening address, port, protocol family, and namespace together.
ss -lnt
getent ahosts localhostThese read-only commands show TCP listening sockets and the system’s localhost answers. Their exact rows depend on the lab. No scan of another machine is performed.
Build a sequence that narrows uncertainty
Start with the exact application error, destination, port, and timestamp. Inspect local link and address state, the selected route, name lookup, and the relevant listener or connection. Then test an authorized application endpoint if the lab provides one. ping can help observe ICMP responses but blocked ICMP does not prove the application is down. Preserve both successful and failing evidence and avoid changing several network settings at once. A firewall or DNS change can create a second problem that obscures the original cause.
Common errors and fixes
DNS success is treated as service success
- Why it happens
- Name resolution was confused with transport and application behavior.
- How to fix it
- Check the destination port and an authorized application request.
- Prevent it next time
- Record each layer’s evidence independently.
A localhost-only service is expected remotely
- Why it happens
- The listener is bound to loopback.
- How to fix it
- Review the intended bind policy on a lab image.
- Prevent it next time
- Include bind addresses in deployment review.
Failed ping is treated as conclusive
- Why it happens
- ICMP policy was assumed to match application policy.
- How to fix it
- Test the intended authorized protocol and inspect routes.
- Prevent it next time
- Use tests that match the reported failure.
Check your understanding
1. A name resolves and TCP connects, but the server returns an authentication error. Which layers already have evidence?
Show worked solution
There is evidence of name lookup, some network path, an accepting transport endpoint, and an application response. Focus next on application identity, credentials, and policy. Replacing resolver settings would not address the observed authentication failure and could introduce an unrelated outage.
2. Why inspect inside a container when the host can connect successfully?
Show worked solution
The container may have a different network namespace, routes, DNS configuration, and source address. Host success narrows the external problem but does not prove the application’s own path. Repeat only authorized read-only checks from the failing context.
Key takeaways
- Separate addressing, routing, resolution, transport, and application checks.
- Observe from the same network context as the failing workload.