What Is DNS? Domain Name Resolution Explained

Learn what DNS is, how hostnames become IP addresses, how DNS differs from DHCP, and how to verify name resolution on Linux.

The Domain Name System (DNS) is the naming and lookup system that associates readable domain and host names with network information, especially IP addresses. It is commonly described both as a distributed naming service and as a protocol used to exchange DNS queries and responses.

IP networks route traffic using numeric IP addresses. DNS makes that process practical for people and applications by allowing them to use names such as www.example.com instead of memorizing numeric IPv4 or IPv6 addresses.

DNS is one part of network communication, not the connection itself. A client first uses DNS to discover an address. It then uses that address for the actual HTTP, HTTPS, SSH, or other application connection.

For a related overview, see What Is DNS?

Hostnames, Domain Names, and IP Addresses

A hostname is a readable label identifying a host or service. For example, home-server might identify a computer on a private network, while www might identify a web service.

A domain name is a hierarchical name used in DNS, such as example.com. A fully qualified domain name (FQDN) is the complete DNS name of a host, such as www.example.com.

An IP address is a numeric network address used to route traffic to a host or network interface. IPv4 addresses look like 192.0.2.25; IPv6 addresses look like 2001:db8::25.

Names are easier to remember and manage than addresses. An organization can keep the name www.example.com while changing the server behind it. One name can also have multiple addresses, allowing several servers, IPv4 and IPv6 connectivity, or traffic distribution.

How DNS Resolution Works

Name resolution is the process of finding DNS data for a name. The application usually asks the operating system's DNS client or resolver rather than constructing DNS packets itself.

1. A user enters a hostname, such as www.example.com, into an application.
2. The client resolver checks local sources and available cache. A local /etc/hosts entry or cached answer may satisfy the request without contacting a DNS server.
3. If it needs an external answer, the resolver sends a DNS query to a configured DNS server, often a recursive resolver.
4. The recursive resolver returns a DNS response. The response may contain an IPv4 address, an IPv6 address, another DNS record, or an error.
5. The application receives the address and establishes its actual connection to that destination.

The DNS query and response are lookup traffic. They are separate from the later application traffic. For example, a browser may perform DNS resolution first and then create an HTTPS connection to the returned address.

DNS Resolution Flow

Conceptual Example: Resolving an Internal Host

Suppose a workstation needs to contact an internal system named home-server, but it does not know the system's IP address.

1. The workstation's DNS client sends a lookup request for home-server to its configured DNS server.
2. The DNS server finds the matching internal record, either from its own data, its cache, or another DNS server.
3. The DNS server returns an address such as 192.168.1.20.
4. The workstation then connects to 192.168.1.20 using the required application protocol.

DNS does not carry the application's files, web pages, shell session, or other service data. It supplies information that helps the client find the destination.

How a Client Knows Which DNS Server to Ask

A client must have one or more DNS resolver addresses configured. Common sources include:

• Manual operating-system or network-manager configuration
• DHCP supplied by a home router, office network, or other DHCP server
• A local router that forwards DNS queries
• VPN software that supplies internal DNS resolvers
• Network-management services such as NetworkManager or systemd-resolved

A recursive resolver can answer from its cache or obtain the answer from other DNS infrastructure. A cache stores previously obtained DNS data temporarily. The record's TTL, or time to live, indicates how long the data may generally be cached.

Not every DNS server stores one complete global table. DNS data is distributed among many administrative zones and servers. Recursive resolvers ask other parts of that infrastructure when they do not already have a usable cached answer.

Static and Dynamic Name Mappings

A fixed DNS record is managed by an administrator and may remain unchanged until deliberately edited. A local /etc/hosts entry is another form of static name-to-address mapping.

Other mappings change as infrastructure changes. For example, an administrator may update a record when a service moves to another server, or an automated system may update a record when an address changes. Caches can continue returning an older answer until its TTL expires.

DNS therefore provides a stable naming layer even when the underlying address or server changes. The name does not guarantee that only one address exists or that its mapping is permanent.

Common DNS Record Types

A name may have an A record, an AAAA record, both, or neither. The application and operating system decide how to use the returned results.

DNS and DHCP Are Different

DHCP is the Dynamic Host Configuration Protocol. It can automatically provide a device with an IP address, a default gateway, and DNS server addresses when the device joins a network.

DNS performs name resolution. DHCP supplies network configuration that can include the information needed to reach a DNS resolver. A device can therefore receive a valid address and gateway through DHCP while still being unable to resolve names if its DNS settings are missing or incorrect.

DNS Limitations and Dependence

DNS is not required when the destination IP address is already known. A client can attempt to connect directly to that address without first looking up a name.

Names are still the normal choice because addresses are difficult to remember, can change, and may represent multiple servers. Some services also behave differently when accessed by IP address. Web hosting may select content based on the domain name, and TLS certificates are normally issued for names rather than arbitrary numeric addresses.

If DNS fails, a named destination may not open even when basic IP connectivity still works. The network may be able to route packets, while the client lacks the address needed to start the application connection.

Verify DNS on Linux

Inspect interfaces and addresses

Use ip address to display network interfaces and assigned addresses:

ip address

Older documentation may use ifconfig:

ifconfig

ip address is preferred on current Linux systems. The legacy command may be available through the net-tools package.

Inspect resolver settings

A common resolver configuration interface is /etc/resolv.conf:

cat /etc/resolv.conf

Look for nameserver entries. The file may be generated or managed by NetworkManager, systemd-resolved, DHCP, or another tool, so manually editing it is not universally persistent.

On systems using systemd-resolved, inspect active DNS configuration with:

resolvectl status

Perform lookups

getent hosts uses the system's configured name-service mechanism:

getent hosts www.example.com

dig queries DNS and shows returned records in more detail:

dig www.example.com A
dig @1.1.1.1 www.example.com A

The second command asks a specifically selected resolver. The dig command is commonly supplied by a DNS utilities package.

To compare name lookup with direct IP reachability, first resolve a name and then test a known address:

getent hosts www.example.com
ping -c 3 1.1.1.1

ICMP echo requests may be blocked, so a failed ping does not prove that all IP connectivity is unavailable. It is still useful as one diagnostic signal.

Check local static mappings

The /etc/hosts file can provide local mappings before or alongside DNS, depending on the system's name-service configuration:

cat /etc/hosts
127.0.0.1 localhost

An unexpected entry there can override a DNS answer or cause a local name to resolve to an old address.

DNS Troubleshooting Examples

A website works by IP address but not by hostname

• No reachable DNS server may be configured.
• The configured resolver may be unavailable.
• The requested name may have no valid record.
• A VPN, firewall, or network policy may block DNS traffic.

1. Confirm that the host has an IP address and a default route.
2. Inspect the configured resolver addresses with resolvectl status or /etc/resolv.conf.
3. Compare getent hosts with a direct dig query.
4. Test a known public name and, where appropriate, query a known resolver explicitly.

DNS queries time out after joining a network

• DHCP may not have provided usable DNS server addresses.
• The configured DNS server may be unreachable from the current network.
• A captive portal or VPN may have changed network access.

Inspect current network settings, review resolvectl status or /etc/resolv.conf, and check reachability to the configured resolver.

A hostname returns an old address after a service move

• Cached data may remain valid until its TTL expires.
• Different resolvers may not yet have obtained the updated record.
• A local /etc/hosts entry may override DNS.

Compare the system resolver with an explicitly selected resolver, inspect local host mappings, and review the record TTL before assuming that the update failed.

An internal hostname fails while public sites work

• The device may be using public DNS instead of the organization's internal resolver.
• The required VPN connection may be absent.
• The internal DNS zone or record may be missing.

Verify the active DNS server list, connect to the required internal network or VPN, and query the expected internal resolver directly.