Linux · Lesson 11
Networking, Interfaces & DNS
Troubleshoot Linux connectivity by separating interface state, addresses, routes, DNS, service exposure, firewall policy, and client reachability instead of changing network settings blindly.
Network problems are layered. A machine can have a healthy interface and broken DNS, correct DNS and no route, or a healthy route while the required application is listening only on localhost. Diagnose the failing layer first.
Lesson Snapshot
Learning objectives
Diagnose the network layer that is actually failing
Explain how Linux interfaces, addresses, routes, DNS, and network services work together.
Inspect current interface state, addressing, routes, DNS configuration, and listening services before changing anything.
Distinguish host configuration from upstream network behavior so local fixes are not applied to problems outside the machine.
Recognize common Ubuntu and Linux Mint networking tools such as ip, NetworkManager, netplan, and systemd-resolved where present.
Troubleshoot connectivity in layers: link, address, route, DNS, service, firewall, and client path.
Apply only the narrow configuration change justified by the scenario and verify the full required network path afterward.
Core idea
Connectivity is a chain, not one setting
Required communication depends on interface state, addressing, routing, name resolution, service binding, firewall policy, and the remote endpoint. A failure at any layer can look like a general network problem.
Availability risk
Network changes can remove your own recovery path
Address, route, DNS, NetworkManager, and netplan changes can cut off SSH immediately. Inspect the active manager and keep a recovery option before applying disruptive changes.
Networking fundamentals
Six concepts behind Linux connectivity
Interface
A network interface represents a wired, wireless, virtual, loopback, bridge, tunnel, or other network endpoint on the system.
Address
An interface can have one or more IPv4 or IPv6 addresses. Addressing determines how the host identifies itself on a network.
Route
Routes tell the kernel where to send traffic. The default route is especially important for reaching networks outside the local subnet.
DNS
DNS resolves names such as hostnames and domains to IP addresses. A host can have working IP connectivity while DNS resolution is broken.
Resolver
The local resolver configuration may be managed by NetworkManager, systemd-resolved, netplan, or static files depending on the system.
Service exposure
A correctly configured interface does not guarantee an application is reachable. The service, bind address, route, and firewall must also align.
Important paths
Know which component owns the network configuration
/etc/netplan/Common location for netplan YAML configuration on modern Ubuntu systems.
Do not edit or apply netplan blindly. A mistake can remove network access.
/etc/NetworkManager/NetworkManager system configuration and connection-related settings.
Desktop-oriented Ubuntu and Linux Mint systems often rely heavily on NetworkManager.
/etc/resolv.confResolver configuration entry point used by applications.
It may be a symlink managed by systemd-resolved or another service. Inspect before editing.
/etc/systemd/resolved.confConfiguration file for systemd-resolved where that service is used.
Changing resolver behavior can affect the entire system. Verify the active resolver first.
/etc/hostsStatic hostname-to-address mappings that are consulted locally.
Unexpected entries can override DNS results and misdirect applications.
/etc/nsswitch.confControls lookup order for names and other identity sources.
Changes can alter how hostnames resolve even when DNS itself is healthy.
Inspection first
Capture current network state before editing it
ip linkShow interfaces, administrative state, and link-layer information.
ip addrShow IPv4 and IPv6 addresses assigned to interfaces.
ip routeShow IPv4 routes including the default gateway.
ip -6 routeShow IPv6 routes when IPv6 is in use.
nmcli device statusShow NetworkManager device state on systems using NetworkManager.
nmcli connection showShow known NetworkManager connection profiles.
resolvectl statusShow resolver status, DNS servers, search domains, and per-link DNS information when systemd-resolved is active.
readlink -f /etc/resolv.confReveal whether /etc/resolv.conf is a regular file or managed symlink.
cat /etc/resolv.confShow the resolver configuration visible to applications.
getent hosts example.comTest name resolution using the system's normal name service configuration.
ping -c 3 127.0.0.1Test the local TCP/IP stack without depending on network connectivity.
ping -c 3 GATEWAY_IPTest reachability to the local gateway when ICMP is permitted.
ss -tulpnShow listening sockets and bind addresses for local network services.
ip neighShow neighbor-cache information for directly connected hosts.
Troubleshooting layers
Work from the local interface outward
Interface
Is the correct interface present and administratively up?
ip link, nmcli device status
Address
Does the interface have the expected IPv4 and/or IPv6 address?
ip addr
Local subnet
Can the host reach a nearby system or gateway on the same network?
ip route, ping where allowed, ip neigh
Route
Is there a correct path to the destination or a valid default route?
ip route, ip -6 route
DNS
Can the system resolve required names using the configured resolver path?
resolvectl status, getent hosts, /etc/resolv.conf
Service
Is the required application actually listening on the expected address and port?
ss -tulpn, systemctl status
Firewall
Does UFW permit the required network path while blocking unnecessary exposure?
ufw status verbose
Client path
Can the authorized client actually reach and use the required service?
Controlled client-side test
Routing
Routes decide where packets go
Connected route
Created for networks directly attached to an interface. It tells the kernel that destinations in that subnet are reachable without a gateway.
Default route
Used when no more specific route matches. It usually points to the local network gateway.
Metric
A route metric influences preference when multiple routes could reach the same destination.
Source address
The chosen source address can matter on multi-homed systems or hosts with several addresses.
Policy routing
Advanced systems can use multiple routing tables and rules. Do not assume one simple default route explains every path.
IPv6 route
IPv6 routing is separate from IPv4. Ignoring IPv6 can leave unexpected connectivity or exposure.
DNS
Name resolution is its own troubleshooting layer
Name resolution can fail while IP works
If reaching an IP works but a hostname fails, investigate DNS before changing interfaces or routes.
/etc/resolv.conf may be managed
On many Ubuntu-family systems, editing the file directly is temporary or incorrect because another service owns it.
Per-link DNS exists
systemd-resolved and NetworkManager can assign different DNS servers to different interfaces or VPNs.
/etc/hosts can override DNS
A local hosts entry may return an address even when the DNS server would answer differently.
Search domains affect short names
A hostname such as server1 may resolve differently depending on configured search domains.
DNS service and DNS client are different
A system may consume DNS as a client without running a DNS server. Do not open port 53 unless the host is actually required to serve DNS.
Network managers
Do not fight the component that owns the configuration
NetworkManager
Desktop and laptop networking, including many Ubuntu Desktop and Linux Mint installations.
nmcli device status; nmcli connection showEditing lower-level files can be overwritten or conflict with NetworkManager-managed profiles.
netplan
Ubuntu network configuration abstraction that can render settings to NetworkManager or systemd-networkd.
ls -l /etc/netplan; cat /etc/netplan/*.yamlYAML indentation matters. Validate before applying changes.
systemd-networkd
Common on some server and minimal systems.
networkctl; systemctl status systemd-networkdDo not enable or disable it without confirming whether it is the active network backend.
systemd-resolved
Local DNS resolver service on many Ubuntu systems.
resolvectl status; systemctl status systemd-resolvedResolver behavior can be tied to symlinks and per-link DNS settings.
Evidence-based reasoning
Fix the failing layer, not the symptom
The machine cannot reach example.com by name
Weak response
Replace /etc/resolv.conf immediately.
Better reasoning
Test IP connectivity first, inspect resolver ownership, DNS servers, /etc/hosts, and getent results, then change only the failing layer.
An interface has two IPv4 addresses
Weak response
Delete the unfamiliar address.
Better reasoning
Determine whether the system is multi-homed, hosting a service, using a migration address, or misconfigured before removing it.
There are two default routes
Weak response
Delete one of them.
Better reasoning
Compare interfaces, metrics, connection profiles, and scenario purpose. Multiple defaults can be intentional.
A service listens on 0.0.0.0
Weak response
The network configuration is wrong.
Better reasoning
The service is bound to all IPv4 interfaces. Decide whether that exposure matches the scenario, then address service bind settings and firewall scope.
NetworkManager is installed
Weak response
Disable it and use static files instead.
Better reasoning
Identify whether the system actively depends on NetworkManager before replacing its role.
resolv.conf contains 127.0.0.53
Weak response
DNS is broken because the file does not list a public DNS server.
Better reasoning
Recognize this as a common systemd-resolved stub resolver pattern and inspect resolvectl status for the upstream DNS servers.
Network evidence
Preserve the baseline before changing it
Interface state
ip linkShows which interfaces exist and whether they are administratively up.
Addressing
ip addrShows assigned IPv4/IPv6 addresses and interface scope.
Routing
ip routeShows the current forwarding decision table for IPv4.
Resolver state
resolvectl statusShows per-link DNS servers, search domains, and resolver configuration when supported.
NetworkManager state
nmcli connection showShows configured connection profiles and which are active.
Listening services
ss -tulpnShows which local applications expose network sockets and where they bind.
Controlled changes
Prefer reversible, manager-aware configuration
Bring an interface up
sudo ip link set INTERFACE upUse only when the interface should be active and its higher-level manager will not immediately override the change.
Renew a NetworkManager connection
sudo nmcli connection up 'CONNECTION_NAME'May interrupt connectivity. Confirm the connection profile and required remote-access path first.
Validate netplan
sudo netplan generateGeneration checks syntax/rendering but does not prove the configuration will preserve connectivity.
Test netplan with rollback window
sudo netplan tryPrefer this over immediate apply when supported because it can revert if the new configuration is not confirmed.
Apply netplan
sudo netplan applyCan disrupt remote access. Use only after review and validation.
Restart resolver
sudo systemctl restart systemd-resolvedOnly appropriate when systemd-resolved is the active resolver and the configuration change requires restart.
High-risk shortcuts
Network changes that can create outages or hide the cause
Editing /etc/resolv.conf without checking ownership
The file may be managed by systemd-resolved or NetworkManager and your edit may be overwritten or break resolution.
netplan apply over SSH without a recovery plan
A bad address, route, or DNS configuration can immediately cut off remote administration.
Deleting extra routes or addresses because they look unusual
Multi-homed systems and required services can legitimately use multiple addresses and routes.
Restarting every network service at once
Makes it harder to identify the real cause and can create a larger outage.
Disabling IPv6 without scenario justification
Can break applications or hide unexpected exposure rather than correctly securing it.
Testing only localhost
Local success does not prove routing, DNS, firewall, or remote-client connectivity.
Verification
Prove the full network path after a change
Interface
Confirm the required interface remains present and up.
Address
Confirm expected IPv4 and/or IPv6 addresses are assigned.
Route
Confirm the required local and default routes still exist with appropriate metrics.
DNS
Use getent hosts or an application lookup to verify required names resolve correctly.
Service
Confirm required network services are listening on the intended addresses and ports.
Client path
Test the full authorized path from client to required service after network changes.
Defensive lab
Diagnose a fictional DNS failure without breaking the network
Read the fictional scenario: the host must reach an internal DNS server and default gateway, Morgan must SSH from the training subnet, and an internal HTTPS application must remain reachable.
Record ip link, ip addr, ip route, nmcli device status, resolvectl status, /etc/resolv.conf ownership, and listening sockets without changing anything.
Test connectivity by layer: loopback, gateway, known IP destination, hostname resolution, SSH, and HTTPS.
Identify a fictional stale DNS server in the active connection profile but do not edit resolv.conf directly if it is managed.
Correct only the active DNS configuration using the system's actual network manager, preserving current address and route settings.
Verify the resolver state, hostname resolution, SSH, HTTPS, firewall rules, and system logs after the change.
Document the final interface, address, gateway, DNS servers, and required service exposure.
Lesson checklist
Before moving on
I can explain interfaces, addresses, routes, DNS, and resolvers.
I use ip link, ip addr, and ip route before changing network configuration.
I determine whether NetworkManager, netplan, systemd-networkd, and systemd-resolved are actually in use before editing files.
I inspect /etc/resolv.conf ownership before changing DNS settings.
I separate IP-connectivity problems from DNS-resolution problems.
I do not remove extra addresses or routes until I understand their role.
I correlate listening services with bind addresses and firewall policy.
I consider both IPv4 and IPv6 when reviewing exposure.
I avoid disruptive network changes over SSH without a recovery path.
I verify the full client-to-service path after configuration changes.
Reflection
Check your reasoning
Question 1
Why can a host reach an IP address but fail to reach the same service by hostname?
Question 2
Why should /etc/resolv.conf be inspected before it is edited?
Question 3
What is the difference between an interface address and a route?
Question 4
Why can multiple default routes be legitimate?
Question 5
How does a service listening on 127.0.0.1 differ from one listening on 0.0.0.0?
Question 6
What should you verify after changing DNS or route configuration on a system that must remain remotely accessible?
Carry this forward
Diagnose networking from the interface outward. Identify the active manager, preserve the current state, change only the failing layer, and verify the real client-to-service path before declaring the system healthy.