Configure DNS Settings on Linux

Learn how DNS works on Linux, configure resolvers with ifupdown and /etc/network/interfaces, apply changes safely, and troubleshoot hostname resolution.

DNS, or the Domain Name System, translates human-readable hostnames such as example.com into IP addresses. Linux applications normally ask the system resolver to perform this translation before connecting to a hostname.

This lesson focuses on traditional Debian- and Ubuntu-based systems that use ifupdown and /etc/network/interfaces. Many newer systems use another networking stack, so first identify which service owns networking on the target machine.

What DNS Does on a Linux System

A hostname is a convenient label. An IP address identifies a destination on a network. DNS connects the two:

Application:    https://example.com
DNS result:     example.com -> an IP address
Network layer:  connect to that IP address

A DNS resolver is a server that receives DNS queries and returns answers. A configured resolver address is often called a nameserver. A system generally needs at least one reachable resolver for normal hostname lookup, and several resolvers can provide fallback when one is unavailable.

DNS configuration is only one part of networking:

IP addressing gives the interface its local address and network prefix.
Routing determines where packets go, including packets sent to a DNS server.
DNS resolver configuration identifies the servers used to translate names.
Local hostname overrides are manually defined mappings, usually in /etc/hosts.

A DNS setting cannot repair a missing IP address, an incorrect default route, or a firewall that blocks access to the resolver.

Identify the Network Configuration Method

The traditional ifupdown method reads interface definitions from /etc/network/interfaces and related files. It is still found on some Ubuntu and Debian installations, especially older or deliberately minimal systems.

Do not assume the interface is called eth0. eth0 is a conventional historical name. Modern Linux systems commonly use predictable names such as enp0s3, ens33, or another device-specific name.

ip link show

Use the output to identify the interface connected to the relevant network. Then determine which service manages it. Possible owners include ifupdown, NetworkManager, netplan, systemd-networkd, a DHCP client, a container runtime, or cloud-init.

Linux DNS Configuration Ownership by Networking Stack

Networking stack | Typical persistent configuration location | How DNS is applied | Whether /etc/network/interfaces is appropriate

ifupdown | /etc/network/interfaces | Interface directives are applied by ifup and ifdown | Yes, when ifupdown owns the interface

NetworkManager | NetworkManager connection profiles or its supported command-line tools | The service configures connection and resolver state | Usually no

netplan | Files under /etc/netplan/ | Netplan generates configuration for another backend | Usually no; configure netplan instead

systemd-networkd | Files under /etc/systemd/network/ | systemd-networkd manages links and DNS integration | Usually no

DHCP tooling, cloud-init, or containers | Tool-specific generated configuration | Automatic or runtime settings may replace manual values | Only if that tool delegates to ifupdown

Configure DNS in /etc/network/interfaces

On an applicable ifupdown system, open /etc/network/interfaces with elevated privileges and locate the stanza for the active interface. A stanza begins with a line such as iface and describes how that interface obtains its address.

iface eth0 inet dhcp
    dns-nameservers 8.8.8.8

The dns-nameservers directive belongs inside the relevant interface stanza. It specifies one or more valid, reachable DNS resolver IP addresses. Replace eth0 with the actual interface name on your system.

For fallback resolvers, separate the addresses with spaces:

iface eth0 inet dhcp
    dns-nameservers 8.8.8.8 1.1.1.1 9.9.9.9

These addresses are illustrative public resolvers. An organization may require internal DNS servers, and a home or hosted network may supply preferred resolver addresses through DHCP. Choose servers that the machine can reach and that are permitted by the network policy.

Resolver Configuration Examples

Use case | dns-nameservers value | Expected behavior

One resolver | 8.8.8.8 | Queries use one configured DNS server.

Several fallback resolvers | 8.8.8.8 1.1.1.1 9.9.9.9 | The resolver has additional servers when a preferred server is unavailable.

Organization or private network | 192.0.2.53 192.0.2.54 | Use the DNS servers supplied by the network administrator; the addresses are examples only.

DHCP and Static Interface Configuration

An interface can receive its address, gateway, and DNS information through DHCP, the Dynamic Host Configuration Protocol. A DHCP lease may include resolver addresses, and DHCP tooling can replace manually selected DNS settings when the lease is renewed.

With static networking, the administrator supplies the required interface settings instead of receiving them automatically. That normally includes an IP address, network prefix, gateway or route, and DNS resolver addresses.

iface eth0 inet static
    address 192.0.2.20/24
    gateway 192.0.2.1
    dns-nameservers 192.0.2.53 192.0.2.54

The addresses in this static example are documentation addresses. Use values appropriate for the actual network. If DHCP is intended to control DNS, check whether the network configuration explicitly preserves or overrides the DHCP-provided resolvers.

Apply Network Changes Safely

After saving the file, ifupdown can deactivate and reactivate the interface so it rereads the stanza:

sudo ifdown eth0
sudo ifup eth0

Substitute the real interface name. Bringing an interface down interrupts traffic. If you are connected through SSH over that interface, the command can disconnect your session and may prevent immediate recovery.

Prefer local console or out-of-band access for remote network changes.
Use a maintenance window when interruption is acceptable.
Keep a rollback plan, including the previous configuration and a way to regain access.
Do not use ifdown and ifup unless ifupdown actually manages the interface.

Exam-relevant note: ifdown deactivates an interface according to ifupdown configuration; ifup activates or reconfigures it according to that configuration. They are not universal commands for every Linux networking stack.

Verify DNS Resolution

First inspect the resolver state visible to the system:

cat /etc/resolv.conf

On an ifupdown setup, this file may show the nameservers produced by the interface configuration or by an associated resolver-management service. Then test a known hostname:

ping example.com

ping is a simple combined test: it first needs to resolve the hostname, then it sends ICMP packets to the resulting address. A successful ping therefore suggests both name resolution and ICMP reachability, but failure does not prove that DNS is broken.

Use a resolver-oriented lookup independently when available:

getent hosts example.com

getent asks the system's Name Service Switch configuration to resolve the name. If a DNS-specific utility is installed, it can provide additional query details. Compare hostname access with direct IP connectivity:

If a hostname fails to resolve but a known IP address is reachable, investigate DNS configuration or resolver reachability.
If both the hostname and the IP address fail, investigate the interface, route, firewall, gateway, or destination.
If lookup succeeds but ping fails, the destination may block ICMP, or the problem may involve routing or a firewall rather than DNS.

Understand Local Hostname Resolution

/etc/hosts contains local, static hostname-to-IP mappings. It is useful for a fixed development name or a small set of local overrides:

192.0.2.40    app.test

This mapping affects only the local machine. It does not configure a DNS server and is not a replacement for resolver configuration.

Lookup order is controlled by NSS, the Name Service Switch. The commonly used configuration file is /etc/nsswitch.conf. A line such as the following commonly checks local files before DNS:

hosts: files dns

With that order, an entry in /etc/hosts can take precedence over a DNS answer. An unexpected local address may therefore be caused by a stale or incorrect hosts-file entry.

Modern Resolver Configuration Context

Many current Linux distributions use /etc/resolv.conf as generated output rather than as the primary persistent configuration location. It may be a symbolic link or may be rewritten by systemd-resolved, NetworkManager, netplan, DHCP tooling, or another service.

For that reason, editing /etc/resolv.conf directly may provide only a temporary change. Likewise, adding dns-nameservers to /etc/network/interfaces may be ignored if another service owns the interface. Configure DNS in the system that owns networking, then verify the resulting resolver state.

DNS Troubleshooting Decision Guide

DNS Troubleshooting Decision Guide

Symptom | Likely cause | Check | Corrective action

Configured interface is not named eth0 | Predictable or virtual interface naming | Run ip link show and inspect the active interface stanza | Use the actual name in the configuration and commands.

DNS settings disappear after reboot or reconnection | DHCP, NetworkManager, netplan, cloud-init, or systemd-resolved owns the settings | Identify the active networking service and inspect /etc/resolv.conf | Configure DNS through the owning system.

Hostname fails but a public IP works | DNS lookup fails or resolvers are unreachable | Check resolver state and run getent hosts example.com | Correct resolver addresses and verify the route to them.

Hostname ping fails but lookup succeeds | ICMP is blocked or there is a non-DNS network problem | Test direct IP connectivity and the intended application protocol | Do not treat ping failure alone as proof of DNS failure.

ifdown or ifup fails | The interface is not managed by ifupdown or the stanza is incorrect | Verify the networking service and interface name | Use the owning service's supported reload procedure.

SSH disconnects during the change | The active remote interface was restarted | Review how the session connects to the host | Use console or out-of-band access and prepare rollback.

/etc/hosts returns an unexpected address | NSS checks the hosts file before DNS | Inspect the hosts entry and /etc/nsswitch.conf | Correct the mapping or adjust lookup policy deliberately.

Practical Checklist

Identify the active interface with ip link show; do not assume it is eth0.
Confirm that ifupdown owns the interface before editing /etc/network/interfaces.
Place dns-nameservers inside the matching iface stanza.
Use one or more valid, reachable resolver IP addresses.
Consider whether DHCP or another service will overwrite the setting.
Apply the change with ifdown and ifup only when appropriate, taking remote-access precautions.
Inspect /etc/resolv.conf and test with getent hosts example.com.
Compare hostname tests with direct IP connectivity to separate DNS problems from general network problems.

Key Terms

DNS: Domain Name System, used to resolve names such as example.com into IP addresses.
DNS resolver: A server contacted by the operating system to perform DNS queries.
nameserver: An address of a DNS server configured for name resolution.
DHCP: A protocol that can automatically provide IP settings, a gateway, and DNS servers.
systemd-resolved: A service that can manage DNS resolution and generated resolver configuration.
NetworkManager: A network-management service that may own connection and DNS settings.