109.4 Configure Client Side DNS

Introduction

This lesson is about how a Linux client turns names into IP addresses.

The main question is:

How do you inspect and understand client-side DNS configuration, and how do you tell DNS problems apart from general network problems?

What you should be able to do after this lesson:

• Understand the role of /etc/resolv.conf.
• Understand search domains and nameserver settings.
• Use host, dig, and getent.
• Understand the relationship between /etc/hosts, DNS, and /etc/nsswitch.conf.
• Recognize when DNS config is managed automatically.

Big Idea: Name Resolution Has an Order

Beginners sometimes think "DNS" means every name lookup. Linux usually has a wider lookup flow:

application asks for a name -> the resolver follows /etc/nsswitch.conf -> local files or DNS are queried -> an address is returned

That explains why:

• a name may work from /etc/hosts even if DNS is down
• dig and an application may show different behavior
• manual edits to /etc/resolv.conf may not always stick

/etc/resolv.conf

This file tells the resolver which DNS servers to use and which search domains to apply.

Typical content:

nameserver 1.1.1.1
nameserver 8.8.8.8
search example.com lab.example.com

Simple meanings:

• nameserver = DNS server IP address
• search = suffix added to short hostnames

If you type:

web1

The resolver may also try:

web1.example.com

depending on the search settings.

/etc/nsswitch.conf

This file decides how host lookups are performed.

Common example:

hosts: files dns

Meaning:

• check /etc/hosts first
• then ask DNS

This is why getent hosts name is such a practical command. It follows the real host lookup policy more closely than raw DNS tools do.

/etc/hosts

This file is local static name mapping.

Example:

127.0.0.1 localhost
192.168.1.50 fileserver

It is useful for:

• local lab environments
• quick overrides
• testing without DNS

But remember:

• it only affects the local machine
• it is not a replacement for real DNS infrastructure

host, dig, and getent

host

Simple DNS query tool:

host example.com

dig

More detailed DNS query tool:

dig example.com
dig @1.1.1.1 example.com

getent

Queries the system databases using the configured lookup rules:

getent hosts example.com

This is often the best first tool when an application cannot resolve a name.

Automatically Managed DNS

On many modern systems, DNS settings are managed by:

• NetworkManager
• systemd-resolved
• DHCP clients

So if you edit /etc/resolv.conf directly and the change disappears, that may be expected behavior.

The lesson is not:

• "never edit the file"

The lesson is:

• first identify what actually owns the DNS configuration on that system

A Simple DNS Troubleshooting Pattern

When name resolution fails:

1. verify basic network reachability with a public IP
2. inspect /etc/resolv.conf
3. inspect /etc/nsswitch.conf
4. test with getent hosts
5. compare with host or dig
6. check whether a network manager is overwriting the resolver config

This separates DNS errors from routing or service problems.

Practice Step by Step

1) Inspect the resolver config

1. Run: sed -n '1,80p' /etc/resolv.conf
2. Identify:
   • nameserver lines
   • search lines

2) Check the lookup order

1. Run: grep '^hosts:' /etc/nsswitch.conf
2. Explain whether the system checks files before DNS.

3) Compare `getent`, `host`, and `dig`

1. Run: getent hosts example.com
2. Then: host example.com
3. Then: dig example.com +short
4. Compare the outputs and note that they are related but not identical tools.

4) Test a local override

1. Read: sed -n '1,80p' /etc/hosts
2. Observe how local names can exist there even without external DNS queries.
3. If you are on a test VM, you can add a temporary entry and check it with: getent hosts <name>

Cheat Sheet

sed -n '1,80p' /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
sed -n '1,80p' /etc/hosts
getent hosts example.com
host example.com
dig example.com
dig @1.1.1.1 example.com
dig example.com +short