VMware ESXi and vSphere Cluster Management

Configure DNS Settings on Linux

Learn how to configure DNS resolvers for a manually managed Ubuntu interface, apply the changes, and verify hostname resolution with Linux diagnostic tools.

DNS, or the Domain Name System, maps hostnames such as example.com to IP addresses. A Linux computer needs access to one or more DNS resolvers to translate internet and local hostnames before applications can connect to them.

DNS configuration is only one part of networking. IP addressing identifies the host, routing determines where packets go, and general connectivity determines whether packets can reach their destination. A working IP address and route do not guarantee that hostname resolution works.

Understand the Network Configuration Method First

This lesson focuses on the traditional Ubuntu and Debian-style ifupdown method. With this method, manually managed interface settings are stored in /etc/network/interfaces.

Older examples often use eth0 as the Ethernet interface name. Current Linux systems commonly use predictable names such as enp0s3 or ens33. Always use the actual interface name on the system.

ip link

The interfaces file method applies only when ifupdown manages the interface. NetworkManager, netplan, systemd-networkd, DHCP clients, and cloud-init may manage networking instead. If another service owns the interface, adding dns-nameservers to /etc/network/interfaces may have no effect.

DNS Configuration Components

Edit a Manual Interface Configuration

Open the interfaces file with elevated privileges and find the stanza for the Ethernet interface. An interface stanza is the group of directives belonging to one interface.

sudoedit /etc/network/interfaces

Add dns-nameservers inside the appropriate stanza. The following example assigns one public resolver to a statically configured interface:

auto eth0
iface eth0 inet static
    address 192.0.2.20
    netmask 255.255.255.0
    gateway 192.0.2.1
    dns-nameservers 8.8.8.8

Replace eth0 with the actual interface name. The DNS server values are IPv4 addresses. To configure several resolvers, put them on the same line in priority order, separated by spaces:

iface eth0 inet static
    address 192.0.2.20
    netmask 255.255.255.0
    gateway 192.0.2.1
    dns-nameservers 8.8.8.8 1.1.1.1 9.9.9.9

Multiple resolvers improve availability if one server is unavailable. Resolver order can affect which server is queried first, although resolver libraries and services may apply their own retry and selection behavior. Save the file after editing.

Choose Appropriate DNS Resolvers

8.8.8.8 is an example of a public DNS resolver. Other valid choices may include:

• A router-provided resolver on a home or small office network.
• An ISP-provided resolver.
• An organization’s internal resolver for private hostnames and corporate zones.
• A public resolver selected according to the organization’s security, privacy, and availability requirements.

Use internal resolvers when local names must resolve or when organizational DNS policies apply. Public resolvers may not know private internal names.

Apply the Interface Changes

For an interface managed by ifupdown, bring the interface down and back up so its configuration is reloaded:

sudo ifdown eth0
sudo ifup eth0

Substitute the actual interface name. The appropriate reload or restart procedure depends on the active network-management service. Do not use ifdown and ifup merely because they are available if NetworkManager, netplan, systemd-networkd, DHCP, or cloud-init manages the interface.

Understand resolv.conf and Resolver Services

Applications commonly obtain resolver information through /etc/resolv.conf. A traditional file might contain entries such as:

nameserver 8.8.8.8
nameserver 1.1.1.1

Interface-level DNS settings and /etc/resolv.conf are related but are not always the same configuration layer. An ifupdown helper may use the interface’s dns-nameservers values to update resolver settings. On modern systems, /etc/resolv.conf may instead be generated or linked to a resolver service.

systemd-resolved is a common modern resolver-management layer. NetworkManager, netplan, DHCP clients, and cloud-init can also generate or replace resolver settings. Do not assume that directly editing /etc/resolv.conf is permanent; an automatic service may overwrite the file.

resolvectl status

Use the system’s active network-management method to make persistent changes. If dns-nameservers appears to do nothing, first determine which service owns the interface and how that service supplies DNS information.

Verify Hostname Resolution

Test a hostname, not only an IP address. A basic end-to-end test is:

ping example.com

If the command displays an IP address for example.com, name lookup succeeded. However, a failed ping does not necessarily prove that DNS failed. The destination may block ICMP echo requests, or the host may have another connectivity problem.

Use DNS-focused or resolver-aware tools to separate name resolution from ICMP behavior:

getent hosts example.com
dig example.com
nslookup example.com
resolvectl query example.com

Not every system has every tool installed. getent hosts tests the system’s configured name-service path, while dig and nslookup provide DNS query diagnostics when available. resolvectl query is useful on systems using systemd-resolved.

DNS Test Results and Interpretation

Troubleshoot Common Problems

A hostname does not resolve after editing

• Confirm that dns-nameservers is inside the correct interface stanza.
• Confirm that the interface name is correct, such as enp0s3 rather than an assumed eth0.
• Check that the configured resolver addresses are reachable.
• Inspect /etc/resolv.conf and resolver status to see whether another service overwrote the settings.
• Run getent hosts hostname or dig hostname to isolate DNS from ping behavior.

The dns-nameservers directive has no effect

Determine whether NetworkManager, netplan, systemd-networkd, DHCP, or cloud-init manages the interface. Also check whether /etc/resolv.conf is generated or linked to systemd-resolved. Configure DNS through the active network stack rather than mixing management methods.

ifdown reports that the interface is not configured

• Verify that the interface has an ifupdown stanza in /etc/network/interfaces.
• Check whether a different network-management service owns the device.
• Verify the actual device name with ip link.

Ping fails even though DNS lookup succeeds

Successful lookup proves that a name was translated into an address, not that the destination accepts ICMP. The target may filter echo requests. Use getent, dig, or nslookup to confirm DNS independently, then test an allowed application protocol or another reachable host if end-to-end access must be verified.

The SSH connection is lost while applying settings

Bringing down a remote interface interrupts the connection by design. Recover through console or out-of-band access, or schedule the change for a maintenance window with a rollback plan.

Practical Verification Sequence

1. Identify the real interface name with ip link.
2. Confirm that ifupdown, rather than another network manager, owns the interface.
3. Add dns-nameservers to the correct interface stanza in /etc/network/interfaces.
4. List one or more reachable resolver IP addresses, separated by spaces.
5. Save the file.
6. Apply the change with sudo ifdown INTERFACE followed by sudo ifup INTERFACE, only when appropriate for the active manager.
7. Inspect the resulting resolver state and /etc/resolv.conf.
8. Run getent hosts example.com or dig example.com.
9. Use ping example.com only as an additional connectivity test, remembering that ICMP filtering can cause false conclusions.