In Linux systems, the /etc/resolv.conf file plays a crucial role in domain name resolution. Two key directives often appear here:
nameserver 8.8.8.8 search example.com corp.example.com
Nameservers are specified using the nameserver directive, which defines the IP addresses of DNS servers to use for queries:
# Typical nameserver entries nameserver 1.1.1.1 # Cloudflare DNS nameserver 8.8.8.8 # Google DNS nameserver 192.168.1.1 # Local router
These servers are responsible for the actual DNS resolution process. The system queries them in order until it receives a response.
Search domains provide a list of domain suffixes to try when resolving unqualified hostnames:
search internal.example.com dev.example.com
When you try to access ping webserver, the system will attempt:
- webserver.internal.example.com
- webserver.dev.example.com
Here's how you might configure both in a corporate environment:
# /etc/resolv.conf for corporate network domain corp.example.com search corp.example.com asia.corp.example.com nameserver 10.0.0.1 nameserver 10.0.0.2 options timeout:2 attempts:2
When debugging DNS issues, consider these commands:
# Check current resolution configuration cat /etc/resolv.conf # Test DNS resolution host webserver host webserver.corp.example.com # Query specific nameserver dig @8.8.8.8 example.com
Modern systems often manage /etc/resolv.conf dynamically:
# For NetworkManager controlled systems nmcli dev show | grep DNS nmcli con modify "eth0" ipv4.dns "8.8.8.8 8.8.4.4" nmcli con modify "eth0" ipv4.dns-search "example.com"
When configuring DNS resolution in Linux systems (typically via /etc/resolv.conf), two distinct directives serve different purposes:
# Example resolv.conf
nameserver 8.8.8.8
search example.com corp.example.com
The nameserver entry specifies the IP address(es) of DNS servers that will perform actual hostname-to-IP resolution:
- Processes queries recursively from root DNS servers downward
- Multiple entries provide fallback redundancy (tried sequentially)
- Essential for all DNS lookups outside local network
# Functional test using nameserver
$ dig @8.8.8.8 google.com +short
142.250.190.46
The search entry defines domain suffixes to append for unqualified hostnames:
- Only affects lookups without dots (e.g., "web01" vs "web01.prod")
- Multiple domains are tried in order until resolution succeeds
- Primarily used in enterprise environments with internal domains
# With search domain example:
$ ping web01
# Actually tries:
# 1. web01.example.com
# 2. web01.corp.example.com
# 3. web01 (only if search fails)
Here's how to configure both elements programmatically in modern Linux distributions:
# Cloud-init example (Ubuntu)
network:
version: 2
ethernets:
eth0:
dhcp4: true
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
search: [example.com, corp.example.com]
# nmcli example (RHEL/CentOS)
nmcli con mod eth0 ipv4.dns "8.8.8.8 1.1.1.1"
nmcli con mod eth0 ipv4.dns-search "example.com,corp.example.com"
nmcli con up eth0
When troubleshooting DNS issues:
# Verify resolution order
$ getent hosts web01
# Check which DNS server responded
$ dig +trace +all web01.example.com
# Test search domain behavior
$ host -v web01
$ ping -c1 web01
Important caveats for containerized environments:
# Docker DNS configuration
docker run --dns 8.8.8.8 --dns-search example.com nginx
# Kubernetes DNS policy
apiVersion: v1
kind: Pod
metadata:
name: dns-example
spec:
dnsPolicy: "None"
dnsConfig:
nameservers:
- 1.2.3.4
searches:
- ns1.svc.cluster.local
- my.dns.search.suffix