Every aspect of a Linux system’s TCP/IP behavior — its IP address, hostname resolution, DNS servers, and more — is controlled by a set of well-known configuration files. This article catalogs, from first principles, the essential TCP/IP configuration files on Linux, explains their format and purpose, and shows how they interact with each other during normal network operation.
Overview: The TCP/IP Configuration Landscape
flowchart TD
A[/"/etc/hostname"/] --> B[System Identity]
C[/"/etc/hosts"/] --> D[Static Name Resolution]
E[/"/etc/resolv.conf"/] --> F[DNS Resolution]
G[/"/etc/nsswitch.conf"/] --> H[Resolution Order]
I[/"/etc/netplan, interfaces, or NetworkManager"/] --> J[IP Address Configuration]
K[/"/etc/services"/] --> L[Port Name Mappings]/etc/hostname — The System’s Own Name
This simple file contains just the system’s hostname:
webserver01
Change it persistently:
sudo hostnamectl set-hostname webserver01
This updates /etc/hostname and applies the change immediately, without requiring a reboot on modern systemd-based systems.
/etc/hosts — Static Hostname-to-IP Mapping
This file provides a manual, local override for DNS — useful for testing, small networks, or ensuring certain critical lookups work even if DNS is unavailable.
127.0.0.1 localhost
127.0.1.1 webserver01
192.168.1.10 dbserver.local dbserver
192.168.1.20 fileserver.local fileserver
Format: IP_address canonical_hostname [aliases...]
Any hostname listed here resolves without querying DNS at all — the lookup stops as soon as a match is found here (subject to /etc/nsswitch.conf ordering, discussed below).
/etc/resolv.conf — DNS Resolver Configuration
Specifies which DNS servers the system should query, and optionally, a default search domain:
nameserver 8.8.8.8
nameserver 1.1.1.1
search example.com
nameserverlines list DNS servers to query, in ordersearchdefines domain suffixes automatically appended to unqualified hostnames (e.g., typingping db1would trydb1.example.com)
Important Modern Caveat
On many modern systems (Ubuntu with systemd-resolved, or systems using NetworkManager), /etc/resolv.conf is automatically generated and often symlinked to a dynamically managed file:
ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jul 24 09:00 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Manually editing this file directly is often pointless — changes get overwritten. Instead, DNS settings should be configured through Netplan, NetworkManager, or systemd-resolved‘s own configuration, as covered in our networking boot-time configuration article.
To check the actual DNS servers systemd-resolved is using:
resolvectl status
/etc/nsswitch.conf — Name Service Switch Configuration
This file controls the order in which different sources are consulted for various types of lookups, including hostname resolution:
hosts: files dns
This particular line means: check /etc/hosts (files) first, and only query DNS if no match is found there. This is why entries in /etc/hosts can effectively override DNS.
Other common sources include myhostname, mdns4_minimal (for .local mDNS/Bonjour-style resolution), and resolve (when systemd-resolved is in use):
hosts: files mdns4_minimal [NOTFOUND=return] dns
/etc/services — Port Number to Service Name Mappings
This file maps well-known port numbers to human-readable service names, used by various tools to display friendly names instead of raw port numbers:
ssh 22/tcp
http 80/tcp
https 443/tcp
mysql 3306/tcp
Tools like netstat (legacy) can use this file to show ssh instead of 22 in their output. It’s rarely edited manually except when adding entries for custom internal services.
/etc/hosts.allow and /etc/hosts.deny — TCP Wrappers (Legacy)
Older access control mechanism, still supported by some services (like sshd on certain systems), for restricting which hosts can connect:
# /etc/hosts.allow
sshd: 192.168.1.0/24
# /etc/hosts.deny
sshd: ALL
This is largely superseded by modern firewalls (iptables/nftables, ufw, firewalld) on most current systems, but you may still encounter it on legacy infrastructure.
/etc/sysctl.conf — Kernel Network Parameter Tuning
While not strictly an “addressing” configuration file, /etc/sysctl.conf (and files under /etc/sysctl.d/) controls low-level TCP/IP kernel behavior:
net.ipv4.ip_forward = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
Apply changes without rebooting:
sudo sysctl -p
Common uses include enabling IP forwarding (turning a Linux box into a router) or hardening against certain network-based attacks (SYN flood protection via tcp_syncookies).
Comparison Table: TCP/IP Configuration Files at a Glance
| File | Purpose | Typically Auto-Managed? |
|---|---|---|
/etc/hostname | System’s own hostname | No — set explicitly |
/etc/hosts | Static hostname-to-IP overrides | No — manually maintained |
/etc/resolv.conf | DNS servers to query | Often yes, on modern systems |
/etc/nsswitch.conf | Lookup source order | No — manually maintained |
/etc/services | Port-to-service name mapping | No — rarely edited |
/etc/hosts.allow / .deny | Legacy TCP Wrappers access control | No — manually maintained |
/etc/sysctl.conf | Kernel-level network tuning | No — manually maintained |
| Netplan / NetworkManager / interfaces | IP address, gateway, DNS assignment | No — manually maintained, but generates resolv.conf |
A Practical Example: Adding a Local Override for Testing
Suppose you’re testing a new version of a website before updating public DNS. You can force your machine to resolve the domain to a specific test server without touching production DNS:
sudo nano /etc/hosts
Add:
203.0.113.50 www.example.com
Now, on this machine only, visiting www.example.com in a browser or via curl hits your test server directly — a widely used technique for pre-launch testing.
curl https://www.example.com
Remember to remove this entry once testing is complete, or it will continue to silently override DNS for that hostname indefinitely on this machine.
Real-World Example: Diagnosing a DNS Resolution Order Issue
A server has an entry in /etc/hosts that conflicts with what DNS says, and a colleague is confused why their DNS change “isn’t working” on this one particular server.
cat /etc/hosts | grep example.com
cat /etc/nsswitch.conf | grep hosts
If /etc/hosts contains a matching entry and nsswitch.conf lists files before dns, the local file always wins — explaining the discrepancy immediately, without needing to question the DNS infrastructure itself.
Best Practices
- Keep
/etc/hostsentries documented and minimal. Stale entries are a classic, hard-to-diagnose source of “why is this resolving to the wrong IP” confusion. - Don’t manually edit auto-generated
/etc/resolv.confon systems usingsystemd-resolvedor NetworkManager — edit the underlying source configuration instead. - Understand your
/etc/nsswitch.conforder before assuming a DNS change should have taken effect. - Use
/etc/hostsdeliberately for testing, and clean up entries afterward to avoid confusing future troubleshooting. - Apply
sysctlchanges through/etc/sysctl.d/drop-in files rather than the monolithic/etc/sysctl.conf, for cleaner, more maintainable configuration management. - Version-control
/etc(e.g., withetckeeper) so changes to these files are tracked and reversible.
Troubleshooting
Problem: Hostname resolves to the wrong IP address
Check /etc/hosts first — it likely contains a stale or incorrect override:
grep hostname /etc/hosts
Problem: Edits to /etc/resolv.conf keep disappearing
The file is auto-managed. Check what’s managing it and edit the correct underlying source:
ls -la /etc/resolv.conf
resolvectl status
Problem: DNS changes don’t seem to take effect anywhere on the system
Check the resolution order:
cat /etc/nsswitch.conf | grep hosts
If files comes before dns and there’s a conflicting /etc/hosts entry, that’s the cause.
Problem: sysctl setting doesn’t persist after reboot
Ensure it’s saved to a persistent file, not just applied at runtime with sysctl -w:
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-custom.conf
sudo sysctl -p /etc/sysctl.d/99-custom.conf
Conclusion
TCP/IP networking on Linux is governed by a small but powerful set of configuration files, each responsible for a specific piece of the puzzle: identity (/etc/hostname), static overrides (/etc/hosts), DNS behavior (/etc/resolv.conf, /etc/nsswitch.conf), and low-level kernel tuning (/etc/sysctl.conf). Understanding how these files interact — especially the resolution order defined in nsswitch.conf and the increasingly auto-managed nature of resolv.conf — is essential for quickly diagnosing name resolution and connectivity issues rather than guessing at DNS problems that might actually be local configuration overrides.
