Understanding /etc/resolv.conf: Purpose, History, and Common Uses

On most Unix-like systems, /etc/resolv.conf is the tiny text file that quietly decides how your box looks up hostnames. If DNS is “the phone book of the internet,” then resolv.conf is the resolver’s address book: where to ask, how to ask, and what shortcuts to use.

Wait, is it resolve.conf or resolv.conf?

First things first: the filename is /etc/resolv.conf — no “e” at the end of resolv. The name comes from the classic “resolver” library, not from the English verb “resolve.”

You’ll see “resolve.conf” in typos all over the internet (and in shell histories), but the real file is resolv.conf.

What /etc/resolv.conf actually does

On a typical Linux system, when a process calls getaddrinfo() to resolve a hostname like app.example.com, the C library’s resolver code decides how to perform the lookup. One of the key inputs for that decision is /etc/resolv.conf.

In broad strokes:

1. The application asks the C library to resolve a name.
2. The C library checks /etc/nsswitch.conf to see what mechanisms to use (DNS, /etc/hosts, LDAP, etc.).
3. If DNS is involved, the resolver reads /etc/resolv.conf to learn:
   • Which DNS servers to talk to.
   • Which search domains to append.
   • What resolver tunables (timeouts, retries, etc.) to use.

So /etc/resolv.conf doesn’t run a daemon; it’s just a config file that tells the resolver library how to talk to DNS.

Historical background: from BIND to glibc to systemd

Originally, the resolver logic lived in the BIND resolver library. Over time, that code was imported into the GNU C Library (glibc), which is what most Linux systems use today. The manual pages for resolv.conf still reflect that legacy: they describe the resolver routines and the file format for /etc/resolv.conf.

For many years, admins simply edited /etc/resolv.conf directly on each host to point at:

• ISP DNS servers
• Internal corporate resolvers
• Caching resolvers like dnsmasq or bind on 127.0.0.1

Modern systems changed the story:

• NetworkManager, resolvconf / openresolv, and similar tools started auto-generating resolv.conf based on interface configuration.
• systemd-resolved arrived and often owns /etc/resolv.conf via a symlink to a “stub” file in /run/systemd/resolve/.

That’s why on many modern distros the file contains big comments like “DO NOT EDIT THIS FILE BY HAND – YOUR CHANGES WILL BE OVERWRITTEN.”

Basic structure of /etc/resolv.conf

At its core, resolv.conf is a simple, line-oriented file with a handful of keywords. The most important are:

• nameserver
• search / domain
• options

Comments start with #. Whitespace is flexible (spaces or tabs).

A very minimal example:

Let’s break those down.

nameserver: where to send DNS queries

Each nameserver line gives an IP address of a DNS resolver:

Key points:

• Order matters: the resolver tries them in the order listed.
• Traditional glibc limits this to three nameservers; extra entries are ignored.
• These are recursive resolvers, not authoritative servers. Think “what my host asks,” not “who hosts example.com’s zone.”

On a system managed by systemd-resolved, you’ll often see:

That means the local systemd stub is doing the actual upstream querying and caching.

search and domain: building full hostnames

The search (and historical domain) directives define which suffixes get appended to bare hostnames:

If you run ping web01, the resolver will try:

1. web01.dev.example.com
2. web01.corp.example.com
3. web01 (as-is), depending on resolver behaviour.

Notes:

• Only one effective search list is used. With multiple search/domain lines, the last one wins.
• domain is essentially an older, single-domain variant of search and is considered obsolete for general use.
• Older glibc versions limit you to six domains and 256 characters total in the search list; newer ones lift that limit, but keeping it short is still good practice.

Search domains are very handy on internal networks, but they can:

• Generate lots of extra queries if misconfigured.
• Leak internal domain names out to public resolvers, which has privacy implications.

options: tuning resolver behaviour

The options line exposes various knobs supported by the resolver. Common ones include:

• timeout:n – Seconds to wait for a response from a nameserver before trying the next one.
• attempts:n – How many times to retry queries before giving up.
• rotate – Round-robin through nameservers instead of always starting with the first one.
• ndots:n – Controls when the resolver treats a name as “already fully qualified” vs “apply search domains.”

Example:

This can reduce perceived latency on flaky networks or help you load-balance among multiple resolvers.

How /etc/resolv.conf is managed today

1. Directly managed / static file

On minimal or older systems, /etc/resolv.conf is just a normal file:

• Edited directly by the admin.
• Persisted across reboots (assuming no network manager overwrites it).

This is still common on small servers, containers, or chroot environments.

2. Managed by resolvconf / openresolv or NetworkManager

On some distros, resolv.conf is clearly marked as managed:

In that setup:

• The network stack (NetworkManager, ifupdown scripts, DHCP client, etc.) feeds DNS data into resolvconf.
• resolvconf composes /etc/resolv.conf from those inputs.

If you need to change DNS, you edit the source — e.g., NetworkManager connection settings — not /etc/resolv.conf itself.

3. Managed by systemd-resolved

On many modern systems, /etc/resolv.conf is a symlink:

That stub file usually contains:

Here:

• Applications talk to the local stub on 127.0.0.53.
• systemd-resolved decides which upstream servers to contact, possibly per interface, with caching, split DNS, DNSSEC, and more.

Again, to change DNS, you adjust:

• Network configuration (.network files, NetworkManager, etc.), or
• resolved.conf and related systemd settings,

not the stub symlink target itself.

Common admin use cases

Even with all the automation, understanding resolv.conf is still very practical.

1. Pointing a host at specific DNS resolvers

You might want to:

• Use a corporate recursive resolver:
  
  nameserver 10.0.0.10 nameserver 10.0.0.11

  1 2 3

  nameserver 10.0.0.10 nameserver 10.0.0.11

• Use public resolvers:
  
  nameserver 1.1.1.1 nameserver 9.9.9.9

  1 2 3

  nameserver 1.1.1.1 nameserver 9.9.9.9

• Use a local caching resolver:
  
  nameserver 127.0.0.1

  1 2	nameserver 127.0.0.1

How you do this depends on who “owns” resolv.conf (static file, resolvconf, systemd-resolved, NetworkManager, etc.).

2. Configuring internal search domains

On an internal network, users may expect ssh web01 to “just work” without typing web01.dev.example.com.

That’s what the search directive is for:

With this in place, tools like ping, ssh, and curl will automatically try the fully qualified variants before giving up.

3. Troubleshooting DNS issues

When DNS is flaky, resolv.conf is one of the first files to inspect:

• Is /etc/resolv.conf a regular file or a symlink to somewhere unexpected?
• Are the nameserver IPs reachable from this host?
• Is a local stub (127.0.0.1 / 127.0.0.53) actually running?

You can pair that with tools like:

to see how the system is resolving names end-to-end.

Best practices and common pitfalls

A few practical guidelines for day-to-day operations:

Don’t fight your network manager

If resolv.conf announces that it’s generated and will be overwritten, believe it. Configure DNS via:

• NetworkManager profiles
• DHCP server options
• systemd network units / resolved.conf
• resolvconf/openresolv input files

rather than trying to “force” changes into resolv.conf.

Keep the nameserver list short and sane

• Stick to reliable resolvers that are reachable from the host’s network.
• Remember that traditional glibc only looks at the first three nameservers.
• Don’t sprinkle random public resolvers after internal ones if you rely on internal-only zones — that can lead to confusing partial failures.

Be cautious with search domains

• Use search domains primarily for internal, trusted namespaces.
• Keep the list modest to avoid latency and unnecessary query volume.
• Remember that every failed lookup might be tried with each search domain in turn (and leak those hostnames externally if you’re using public resolvers).

Know who really owns /etc/resolv.conf

On any given system, one of the most useful mental checklists is:

1. Is /etc/resolv.conf a regular file or symlink?
2. If symlink, what is the target (stub-resolv.conf, /run/systemd/resolve/resolv.conf, something else)?
3. Which service or tool is responsible for generating that target?

Once you know that, you know where to make persistent changes.

Summary

• The file is /etc/resolv.conf, not resolve.conf.
• It configures the C library resolver, telling it which DNS servers to query, which search domains to use, and how to tune timeouts and retries.
• Historically it was edited by hand; today it’s often auto-generated by tools like resolvconf, NetworkManager, or systemd-resolved.
• For day-to-day sysadmin work, understanding the keywords (nameserver, search, domain, options) and who owns the file on your distro is crucial for debugging DNS issues and designing clean network configs.