Linux Network Fundamentals: Interfaces, Routing, DNS

1. Why network fundamentals are essential for admins

The message "no internet connection" on a Linux server is rarely a single problem. It is the symptom of one of four possible causes: the interface is not active, it has no IP address, a matching route is missing, or DNS resolution fails. Anyone who does not cleanly separate these four layers often searches in the wrong place and wastes time on guesswork instead of targeted diagnosis. A solid understanding of interfaces, routing and name resolution turns guessing into a clear, repeatable checking process.

NetworkManager, systemd-networkd and cloud-init take a lot of configuration work off admins' shoulders today and abstract away the details. That abstraction becomes a problem the moment something breaks: anyone who only knows the abstraction layer stands helpless in front of a failure that can only be understood through the underlying kernel mechanisms. Especially on minimal container images and freshly provisioned servers without graphical tools, the ip command from the iproute2 package remains the most reliable common ground for diagnosis and configuration.

2. Understanding network interfaces with ip link and ip addr

The command ip link show lists all network interfaces on the system with their current state: UP or DOWN, the MAC address, the MTU, and whether a physical carrier signal is detected. An interface in state DOWN or without the LOWER_UP flag is the most common, yet most easily overlooked, cause of missing connectivity, for example when a network cable is not properly seated or a switch port has been disabled. ip addr show extends this view with the IP addresses actually assigned per interface, including the subnet mask.

Modern interface naming follows the Predictable Network Interface Names scheme from systemd-udev, such as enp3s0 or eno1, instead of the older but not reliably stable names like eth0. The loopback interface lo with the address 127.0.0.1 serves as a useful baseline: if even lo does not respond, there is a fundamental kernel or network stack problem, one that sits far below anything related to physical cabling.

# List all interfaces with state, MAC address and carrier status
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    link/ether 52:54:00:3a:1f:9c brd ff:ff:ff:ff:ff:ff

# Show assigned IPv4/IPv6 addresses per interface
$ ip -4 addr show enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    inet 192.168.10.42/24 brd 192.168.10.255 scope global enp3s0
       valid_lft forever preferred_lft forever

# Quick summary of all interfaces in brief form
$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8
enp3s0           UP             192.168.10.42/24

3. Configuring interfaces: addresses, MTU and link state

Changes made with ip addr add and ip link set take effect immediately but are transient: after a system or network service restart they are gone again. That makes these commands ideal for quick tests and emergency diagnostics, but unsuitable for permanent configuration. Persistent settings are instead the job of the respective network manager: Netplan on Ubuntu Server, NetworkManager keyfiles on desktop-oriented distributions, or .network files for systemd-networkd on minimal systems.

Netplan translates a declarative YAML file internally into NetworkManager or systemd-networkd configuration and is the standard way to set static addresses, DNS servers and routes on Ubuntu servers. After every change, netplan try applies the configuration on a trial basis and automatically rolls it back if no confirmation arrives within a time window, which prevents a server lockout caused by a broken network configuration. For DHCP interfaces, ip addr show shows the lease assigned by the DHCP server including its validity period.

# /etc/netplan/01-static.yaml, persistent static IP config on Ubuntu Server
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      addresses:
        - 192.168.10.42/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses: [1.1.1.1, 9.9.9.9]
        search: [internal.mironsoft.de]

# Apply safely: reverts automatically if not confirmed within 120s
# netplan try
# netplan apply

4. The routing table: ip route and the default gateway

Every packet that leaves the local machine gets assigned to an interface based on the kernel routing table. ip route show lists all known routes, and when several entries match, the kernel always picks the most specific one, the so called longest prefix match principle. The entry default via 192.168.10.1 dev enp3s0 defines the default gateway: the destination for all traffic for which no more specific route exists, which in practice means essentially all traffic bound for the internet.

If the default route is missing or points to an unreachable gateway, every outbound connection fails even though the interface itself is correctly configured. The command ip route get <target> is especially valuable here because it shows exactly which route the kernel would actually use for a given destination address, including the source address and outgoing interface, without sending a single packet.

# Show the full kernel routing table
$ ip route show
default via 192.168.10.1 dev enp3s0 proto dhcp metric 100
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.42

# Add a temporary default route (lost after reboot)
$ sudo ip route add default via 192.168.10.1 dev enp3s0

# Ask the kernel which route it would actually pick for a target
$ ip route get 8.8.8.8
8.8.8.8 via 192.168.10.1 dev enp3s0 src 192.168.10.42 uid 1000

# Add a specific route to a remote subnet via a different gateway
$ sudo ip route add 10.20.0.0/16 via 192.168.10.254 dev enp3s0

5. Multiple routes, metrics and policy-based routing

Servers with multiple network interfaces, for example a production uplink plus a separate interface for the backup network, often need more than a single default route. The metric value of a route decides its priority: when two default routes exist over different interfaces, the kernel always picks the one with the lower metric value if the prefix length is equal. This makes it possible to prefer a primary interface and keep a second one purely as a fallback, without having to switch routes manually.

When simple metric-based priority is not enough, policy-based routing with ip rule comes into play: it allows defining custom routing tables and selecting between them based on source address, destination port, or a firewall mark, for example to consistently send reply packets back out through the same interface the request arrived on. That is exactly what prevents asymmetric routing, which, with rp_filter (reverse path filtering) enabled, would otherwise cause the kernel to silently drop legitimate reply packets because they arrive on the "wrong" interface.

6. DNS resolution on Linux: resolv.conf and nsswitch.conf

Once the interface, IP address and route are correct, name resolution comes into play. Glibc's standard resolver reads /etc/resolv.conf for this, which contains the nameserver addresses and optional search domains for unqualified hostnames. On modern systems running systemd-resolved, this file is often just a symlink to /run/systemd/resolve/stub-resolv.conf and lists a single nameserver, 127.0.0.53, the local stub resolver that caches queries internally and forwards them to the actually configured upstream servers.

Which sources get queried during name resolution at all, and in what order, is controlled by the hosts line in /etc/nsswitch.conf. The typical entry hosts: files dns means: /etc/hosts is checked first, only then DNS. That explains why an incorrect entry in /etc/hosts can completely override a correct DNS answer, a commonly overlooked trap when debugging what looks like a DNS problem.

# /etc/resolv.conf, typical systemd-resolved stub configuration
nameserver 127.0.0.53
options edns0 trust-ad
search internal.mironsoft.de

# /etc/nsswitch.conf, relevant line for hostname resolution order
# "files" checked before "dns": /etc/hosts entries win over DNS answers
hosts: files dns myhostname

# /etc/systemd/resolved.conf, actual upstream DNS servers behind the stub
[Resolve]
DNS=1.1.1.1 9.9.9.9
FallbackDNS=8.8.8.8
Domains=internal.mironsoft.de

7. DNS tools for daily use: dig, resolvectl, getent

dig is the best tool for targeted DNS testing because it can bypass the local resolver entirely and query a specific nameserver directly: dig @1.1.1.1 mironsoft.de reveals whether the problem sits with the upstream server or already occurs locally. dig +short produces a terse, script-friendly output containing just the resolved IP address, ideal for health checks and monitoring scripts.

On systems running systemd-resolved, resolvectl status gives a complete overview of the DNS servers and search domains configured per interface, along with the current DNSSEC status. resolvectl query uses the same resolution path a real application would. Even closer to what an application actually experiences is getent hosts mironsoft.de: this command walks exactly the chain configured in nsswitch.conf and therefore reliably shows what any program on the system would actually receive as an answer, including any /etc/hosts overrides.

8. The right troubleshooting order: link, IP, route, DNS

Network failures can almost always be narrowed down efficiently by consistently checking from the bottom up instead of testing at random. Step one: ip link show, is the interface UP and is a carrier detected. Step two: ip addr show, does the interface have an IP address at all in the expected subnet. Step three: ip route show followed by a ping to the gateway, does a route exist and is the gateway reachable. Only after that, step four, comes the DNS check with dig or resolvectl query.

This order saves a massive amount of time because every higher layer depends on the one below it: a DNS error message on an interface without a route is misleading, because the actual problem sits two layers deeper. Automated health-check scripts often model exactly these four steps as a structured status report that monitoring systems such as Icinga or Prometheus exporters can consume directly.

{
  "host": "web-01.internal.mironsoft.de",
  "checked_at": "2026-07-12T09:14:02Z",
  "checks": {
    "link": { "interface": "enp3s0", "state": "UP", "carrier": true },
    "address": { "ipv4": "192.168.10.42/24", "assigned": true },
    "route": { "default_gateway": "192.168.10.1", "reachable": true, "rtt_ms": 0.4 },
    "dns": { "resolver": "127.0.0.53", "query": "mironsoft.de", "resolved": true, "rtt_ms": 12.7 }
  },
  "status": "ok"
}

9. Network tools compared: classic versus iproute2

Many older tutorials and scripts still rely on commands from the net-tools package, which have officially been considered deprecated for over two decades and are often not even preinstalled on minimal distributions anymore. The table below shows the direct successors from iproute2 and the DNS tools that come with systemd-resolved.

Switching is worthwhile not just for currency: iproute2 commands produce more structured output, support namespaces and policy routing natively, and can be printed directly as JSON with the -j flag, which greatly simplifies integrating them into custom monitoring and automation scripts, with no fragile text parsing required.

10. Summary

The Linux network fundamentals break down into four clearly separated layers: is the interface active (ip link), does it have a matching IP address (ip addr), does a working route to the destination exist (ip route), and does DNS correctly resolve the name that is needed (resolv.conf, nsswitch.conf, dig). Anyone who consistently follows this order usually finds the actual root cause within a few minutes, instead of fighting symptoms on the wrong layer.

The iproute2 package with ip and ss has long since replaced the classic net-tools commands such as ifconfig, route and netstat, and delivers more structured, in part JSON-capable output. Anyone who additionally understands how systemd-resolved mediates as a stub resolver between glibc and the actual upstream DNS servers can solve seemingly mysterious DNS problems in a targeted way instead of by trial and error.

11. FAQ: Linux Network Fundamentals