Linux DNS Configuration and Verification

How a Linux System Resolves Domain Names

Before we change any settings, we need to understand where a Linux system looks for DNS information. The process is primarily controlled by three files in the /etc/ directory.

To explore these files, we'll use an article from CIQ, which provides a great overview of name resolution in Linux.

Let's break down what you just read:

1. /etc/nsswitch.conf (Name Service Switch): This is the master configuration file. It tells the system in what order to consult different sources for name resolution. A common configuration you saw is hosts: files dns. This means:

   • First, look in local files (specifically /etc/hosts).
   • If no answer is found, then query the DNS servers.
     This order is important. An entry in /etc/hosts can override what a DNS server would report, which is a powerful technique for local development and testing.

2. /etc/hosts: This is a simple text file that acts as a local, static address book. It maps IP addresses to hostnames. Any entries here are checked (by default) before any DNS query is sent to an external server. It's often used to define localhost or for creating local development domains without needing a real DNS server.

3. /etc/resolv.conf: If the system needs to perform a DNS query (as instructed by nsswitch.conf), this file tells it which DNS servers to ask.

Configuring DNS Settings Persistently

As the reading from CIQ mentioned, directly editing /etc/resolv.conf is often a temporary solution. On modern Linux systems, this file is frequently managed by a higher-level network management service and your changes can be overwritten on the next reboot or network restart.

For persistent changes, you should use the tool that manages your system's network configuration. Two common services are NetworkManager and systemd-resolved.

• NetworkManager: Used by default on many distributions like RHEL, CentOS, and Ubuntu Desktop. It provides a command-line tool called nmcli to modify connections.
  To set the DNS servers for a connection named eth0 to Google's (8.8.8.8) and Cloudflare's (1.1.1.1), you would use:

  # Set the DNS servers
  sudo nmcli con mod 'eth0' ipv4.dns "8.8.8.8 1.1.1.1"
  
  # Re-apply the connection settings
  sudo nmcli con up 'eth0' 
  

• systemd-resolved: A newer service that is becoming the standard for managing name resolution. It has its own configuration file (/etc/systemd/resolved.conf) and is controlled via systemctl. With systemd-resolved, /etc/resolv.conf is often a symbolic link to a file managed by the service, like /run/systemd/resolve/stub-resolv.conf.

Making changes with these tools ensures your DNS settings survive a reboot.

Verifying Name Resolution with dig and nslookup

Once you've configured your DNS settings, how do you test them? You need tools that can send DNS queries directly. The three most common are dig, nslookup, and host. While nslookup is widely available, dig (Domain Information Groper) is the preferred tool in modern DevOps because its output is more detailed and easier to script.

The following guide provides an excellent, command-driven tour of all three tools.

Let's practice with dig.

A simple query looks like this:

dig fossmint.com

Here are some of the most useful dig commands for a DevOps engineer:

• Get a simple answer: If you just want the IP address and nothing else, use +short.

  dig google.com +short
  # Output: 142.250.187.238 
  

• Query for a specific record type: You can ask for any record type, like MX for mail servers or TXT for text records.

  dig google.com MX +short
  # Output: 10 smtp.google.com.
  

• Query a specific DNS server: This is incredibly useful for troubleshooting. You can bypass your system's default resolver and ask another server directly. Use the @ symbol to specify the server.

  # Ask Cloudflare's resolver (1.1.1.1) for the IP of github.com
  dig @1.1.1.1 github.com A +short
  # Output: 20.205.243.166
  

• Trace the full resolution path: The +trace option makes dig act like a recursive resolver, showing you every step of the query from the root servers down to the authoritative nameserver. This is a powerful diagnostic tool.

  dig github.com +trace
  

While nslookup and host are simpler, they can be useful for quick checks:

# Basic lookup with nslookup
nslookup github.com

# Basic lookup with host
host github.com

dig github.com TXT

Conclusion

In this lesson, we bridged the gap between DNS theory and practice. You learned how to investigate and configure the files that control name resolution on a Linux client, and more importantly, how to use professional tools to query, verify, and troubleshoot DNS.

Key Takeaways:

• Name resolution on Linux is primarily controlled by /etc/nsswitch.conf, /etc/hosts, and /etc/resolv.conf.
• Directly editing /etc/resolv.conf is useful for temporary tests, but persistent changes should be made using tools like nmcli or by configuring systemd-resolved.
• dig is the most powerful and versatile command-line tool for DNS lookups. It allows you to query specific record types, target specific DNS servers, and trace the entire resolution path.
• nslookup and host are simpler alternatives for quick lookups.

In our next lesson, we will move up the network stack to look at the protocols that power the web: HTTP and HTTPS. You'll learn how these application-layer protocols work and understand the critical role that TLS/SSL certificates play in securing web traffic.