Understanding /etc/resolv.conf Contents and Stub Generation

A detailed analysis of DNS configuration management on Linux systems

Key Highlights

Systemd-resolved uses a local stub (typically 127.0.0.53) with dynamic symlink generation.
NetworkManager updates the file based on active network connections and may integrate with systemd-resolved.
Openresolv and resolvconf combine information from multiple network sources to update the DNS configuration file dynamically.

1. Overview of /etc/resolv.conf

The file /etc/resolv.conf is critical for DNS resolution in Unix-like operating systems. It informs the system and applications about which nameservers to send DNS queries to, alongside any search domains for resolving unqualified hostnames. The content and method of management for this file can vary significantly based on the controlling service. We will explore four common management methods: by systemd-resolved, NetworkManager, openresolv, and traditional resolvconf, highlighting both the typical content of the file and the underlying mechanisms for generating or updating it.

2. Managed by systemd-resolved

Typical Contents and Stub Generation

When the systemd-resolved service manages the /etc/resolv.conf file, it commonly acts as a stub resolver. This stub resolver listens on a predefined local IP address, usually 127.0.0.53. The file often becomes a symlink pointing to a dynamic file maintained by the service – typically /run/systemd/resolve/stub-resolv.conf.

Typical Content


# This file is managed by systemd-resolved.
nameserver 127.0.0.53
# There might be additional configuration such as search domains:
search example.com

The stub generation process is automatic. Systemd-resolved creates a dynamic file that holds the local DNS settings. Network configuration details (such as those received via DHCP) and static configurations from files like /etc/systemd/resolved.conf inform the content of this stub. When a request for a hostname is made, queries are routed to 127.0.0.53, which then proxies the DNS queries to the upstream servers. In this way, systemd-resolved introduces caching and other intermediary DNS functionalities while abstracting direct exposure of the actual nameserver IPs to local applications.

3. Managed by NetworkManager

DNS Updates and Stub Generation

NetworkManager is widely used in desktop environments and is responsible for managing network connections, including democratically updating /etc/resolv.conf based on active connections. In configurations where NetworkManager manages the file directly, it writes the nameserver addresses provided by DHCP or manual configurations into /etc/resolv.conf.

Typical Content


# Generated by NetworkManager
nameserver 192.168.1.1
nameserver 8.8.8.8
search example.com

On some systems, NetworkManager is configured to work in conjunction with systemd-resolved by handing over DNS information via D-Bus. In such cases, even though NetworkManager is the active network service, the file may still point to the local stub (127.0.0.53) if systemd-resolved is managing DNS resolution underneath. Alternatively, NetworkManager may create or update /run/NetworkManager/resolv.conf and then adjust /etc/resolv.conf accordingly. The process of generating the stub or file involves:

Collecting DNS server addresses during DHCP negotiation.
Writing these addresses along with relevant search domains into the configuration file.
Automatically updating the file when network connections change.

This dynamic approach ensures that the DNS settings for an active network connection remain current. It is also possible to configure NetworkManager so that it either directly populates the file or interacts with other DNS management systems such as systemd-resolved, depending on the administrator’s settings.

4. Managed by openresolv

Merging Multiple Sources and Updates

The openresolv tool provides a resilient mechanism for managing the /etc/resolv.conf file, especially in environments where multiple network interfaces or VPN connections might coexist. This tool operates by merging DNS information that comes from various sources – such as DHCP, static configuration files, or VPN packages – and generating a consolidated /etc/resolv.conf file.

Typical Content


# Dynamic resolv.conf file for local clients
search localdomain
nameserver 1.1.1.1
nameserver 1.0.0.1

openresolv works by calling helper scripts when there are changes in the network configuration. These scripts append or adjust DNS server and search domain entries in the file, ensuring that the most relevant DNS servers – based on current network connections – are listed for applications to use. This intelligent merging avoids conflicts and ensures that the file reflects the combined state of all active network interfaces.

Additionally, openresolv can manage conditional forwarding and other advanced DNS features. It works as an intermediary layer, making sure that every subscriber (e.g., VPN clients or secondary network interfaces) can update the DNS settings without overwriting others. The resultant /etc/resolv.conf is a composite file that may contain DNS entries from various sources, ordered by priority as defined by the network configuration and administrative scripts.

5. Managed by resolvconf

Dynamic Aggregation from Multiple Services

The resolvconf script is another widely adopted tool for dynamically managing the /etc/resolv.conf file. Its purpose is to aggregate DNS information provided by diverse system components, such as DHCP clients, VPN services, or static overrides, and then to update the /etc/resolv.conf file accordingly.

Typical Content


# Generated resolv.conf file
search example.com
nameserver 9.9.9.9
nameserver 149.112.112.112

The working of resolvconf is relatively straightforward:

It listens for changes in network configuration from various sources.
When a change is detected—say a new DHCP lease or a VPN connection—the script consolidates the provided nameserver addresses.
It then rewrites the /etc/resolv.conf file with updated entries and search domains.

This aggregated approach provides system administrators with flexibility as the DNS configuration automatically reflects the current network conditions. By aggregating multiple sources, resolvconf allows for smoother transitions when network conditions change and prevents errors that might affect DNS resolution.

6. Comparative Table of DNS Management Methods

Management Tool	Typical Stub/Content	Mechanism/Notes
systemd-resolved	`nameserver 127.0.0.53 search example.com`	Acts as a stub resolver; updates via dynamic symlink to /run/systemd/resolve/stub-resolv.conf. Uses caching and routing logic.
NetworkManager	`nameserver 192.168.1.1 nameserver 8.8.8.8 search example.com`	Updates reflect current active network connection, either directly writing to /etc/resolv.conf or via systemd-resolved backend using D-Bus.
openresolv	`search localdomain nameserver 1.1.1.1 nameserver 1.0.0.1`	Merges DNS information from multiple network interfaces and sources using helper scripts.
resolvconf	`search example.com nameserver 9.9.9.9 nameserver 149.112.112.112`	Aggregates DNS data from various services; automatically regenerates file on network changes.

7. Detailed Analysis of Stub Generation and Management Process

Systemd-resolved Deep Dive

Systemd-resolved is designed to streamline DNS resolution by acting as an intermediary between applications and upstream DNS servers. The typical workflow involves:

Configuration and Symlink

Administrators configure global or per-interface DNS settings in files such as /etc/systemd/resolved.conf or through DHCP. During boot or on network changes, systemd-resolved generates the stub file at /run/systemd/resolve/stub-resolv.conf and then establishes a symlink from /etc/resolv.conf to it. This ensures that any application requesting DNS lookup always interacts with the local stub resolver.

Caching and Query Resolution

The stub resolver not only receives DNS queries from applications but also caches responses and manages timeouts. This setup reduces overall latency and network load by avoiding repetitive queries to remote DNS servers. The management of caching and fallback between different network states is handled fully within systemd-resolved, minimizing manual intervention.

NetworkManager Integration and Functionality

NetworkManager plays a dual role in modern Linux desktops. It handles network transitions—including Wi-Fi, Ethernet, and cellular—and keeps the DNS resolution configuration up-to-date. Here’s how it functions:

Collecting Data from DHCP and Static Configurations

When a new network connection is activated, NetworkManager retrieves DNS settings via DHCP or from a system user’s static configuration. Depending on settings, it might directly write the resolv.conf file with multiple nameserver entries extracted from the network or alternatively direct DNS queries to systemd-resolved by setting the local nameserver IP.

Dynamic Symlink Management

Similar to systemd-resolved, NetworkManager may manage a symlink pointing to a dynamic file, especially when integrated with other services. This flexibility allows it to seamlessly adapt the file content when moving between different networks, ensuring that the correct DNS servers are always in effect.

Openresolv and Resolvconf Techniques

Both openresolv and resolvconf share a common philosophy: they aggregate DNS configuration from various sources to produce a unified /etc/resolv.conf file.

Multi-Source Data Aggregation

Whether you’re using openresolv or resolvconf, the process involves collecting data from several pathways like DHCP clients, manual configurations, VPN clients, and sometimes even system services. The key advantage is the prevention of conflicts when multiple services attempt to update DNS settings simultaneously.

Scripting and Automation

Both tools rely on helper scripts that listen for network changes. Once a change is detected, these scripts rerun to regenerate the /etc/resolv.conf file. The content generated typically includes the order of precedence for nameservers and might incorporate search domains. For those managing complex network environments, this dynamic scripting guarantees that the file remains current without manual reconfiguration.

Note that while openresolv and resolvconf have similar goals, the implementation details can differ slightly based on the distribution and the specific scripts employed by the system. Nevertheless, the overall philosophy is consistent: dynamic, reliable, and multi-source DNS configuration management.

Conclusion

In summary, the management of the /etc/resolv.conf file is pivotal for ensuring that DNS queries proceed seamlessly across various Linux networks. Each method—whether it is systemd-resolved, NetworkManager, openresolv, or resolvconf—has its unique approach:

Systemd-resolved relies on a stub resolver, typically using 127.0.0.53, and employs a symlink mechanism to ensure that DNS queries leverage its internal caching and proxy functionalities.
NetworkManager utilizes dynamic data collection from active connections, writing directly to /etc/resolv.conf or interfacing with systemd-resolved, depending on configuration settings to maintain accurate DNS entries.
Openresolv elegantly manages multiple network interfaces by merging DNS information from various sources into a composite file, ensuring that all active network connections contribute to the overall configuration.
Resolvconf similarly aggregates data but often caters to a broader set of network inputs, regularly updating the file based on the latest changes observed from DHCP or VPN usage.

Understanding these differences helps system administrators tailor the DNS management strategy to suit specific needs and network environments. Whether the focus is on reliability, dynamic updates, or handling multiple sources concurrently, each solution offers a robust set of features. Ultimately, the choice of tool and configuration style should be based on the balance of simplicity, control, and adaptability required by the operating environment.