Table of Contents
Why DNS Matters
Domain Name System, or DNS, is the service that translates human readable names such as example.com into IP addresses such as 93.184.216.34. Every time you browse a website, send email, or connect to many network services, your system uses DNS behind the scenes. For a Linux server administrator, understanding DNS is essential, because misconfigured DNS often looks like “the network is down” even when IP connectivity is fine.
DNS is a distributed, hierarchical database. No single server holds all DNS information. Instead, many servers around the world cooperate, each being authoritative for a part of the namespace and caching data from others to make lookups fast and resilient.
DNS is not just a naming convenience. Correct DNS configuration is critical for web servers, email delivery, and many other internet services. Broken DNS often causes timeouts and security problems.
Names, Zones, and the DNS Hierarchy
DNS organizes names in a hierarchy that reads from right to left. The rightmost label is the top level domain, for example com, org, or a country code such as de. To the left of this, you have second level domains like example.com, and then further subdomains like www.example.com or mail.eu.example.com.
The entire DNS namespace is like a tree. At the top of this tree is the root. The root is represented as a trailing dot that is usually omitted. The full canonical form of www.example.com is www.example.com. with a dot at the end.
The tree structure affects how DNS is delegated. The owner of a domain can delegate a subdomain to a different set of authoritative servers. For example, example.com might be controlled by one team, but eu.example.com might be delegated to another, with its own set of DNS servers. This delegation is implemented through NS records, which you will see in detail when working with zones and records in later chapters.
A zone is the portion of the DNS namespace that a particular authoritative server manages as a single unit. A domain name such as example.com might correspond to one zone, or several zones if subdomains are delegated away. In practice, when you configure a DNS server like BIND, you define zones, not generic “domains”.
Resource Records and TTL
DNS stores information as resource records, often abbreviated as RRs. Each record has at least a name, a type, a class, a time to live, and some data. The most common class on the internet is IN for internet, so in many contexts it is omitted because it is implied.
The time to live, or TTL, is a number of seconds that tells caching resolvers how long they may hold on to a record before they must query again. A large TTL improves performance and reduces load on authoritative servers, but slows down propagation of changes. A small TTL causes more queries, but allows rapid changes, for example just before moving a service to a new IP address.
A line in a zone file looks conceptually like this:
name TTL CLASS TYPE RDATAFor example, in a typical zone you might see:
www 3600 IN A 203.0.113.10
which means the name www.example.com. has an IPv4 address of 203.0.113.10 and may be cached for up to 3600 seconds.
The TTL on a record directly controls how long other DNS servers and clients may cache it. If you intend to change an IP address or other critical record, lower the TTL well before making the change, then raise it again afterward.
Authoritative Servers, Caching, and Recursion
DNS involves several distinct roles. Understanding how they interact is critical for troubleshooting and server configuration.
An authoritative DNS server provides answers for specific zones that it is responsible for. It knows the “truth” for those zones because it loads them from zone files or a database. It does not guess and it does not need to look up the data elsewhere. When you host DNS for example.com, your DNS server is authoritative for that zone. When an authoritative server answers for its own zones, it sets the “authoritative answer” bit in responses.
A recursive resolver accepts queries from clients, looks up the answers by asking other DNS servers, follows referrals down the DNS hierarchy, and then returns the final result to the client. It also caches responses to speed up subsequent lookups. Your Linux server or workstation usually points to a recursive resolver, which might be provided by your ISP, your organization, or a public DNS service.
Caching is a core feature of DNS. When a recursive resolver receives a response, it stores the result in memory along with the TTL. Further client queries for the same name are answered directly from cache until the TTL expires. Proper caching reduces latency and load on authoritative servers, but can also delay the visibility of changes.
The process of following referrals is called recursion. A recursive resolver starts at the top of the hierarchy and asks the appropriate servers step by step until it reaches the authoritative server for the target name. In contrast, an authoritative only server does not perform recursion. It answers only for the zones it serves, and replies with a referral or an error for everything else.
Never expose an open recursive resolver to the public internet without strict access controls. Open resolvers are abused in DNS amplification attacks and can turn your server into a tool for denial of service.
How a Typical DNS Lookup Works
When a Linux client looks up a name such as www.example.com, it typically sends a query to its configured DNS resolver. The precise configuration uses /etc/resolv.conf or a system service that manages it, but from the DNS perspective the process is similar.
If the resolver already has a valid cached response for www.example.com, it returns the cached data immediately. The TTL is decremented as time passes. The client never contacts the authoritative server directly, it always talks to its resolver.
If the resolver does not have a cached answer, and recursion is enabled, the resolver performs a recursive lookup. It starts with a set of known root server addresses built into the software or configuration. The resolver sends a query for www.example.com. to one of the root servers. The root server does not know the answer, but it is authoritative for the root zone and knows which servers are responsible for .com. It replies with a referral that contains NS records for the .com top level domain and the addresses or names of their name servers.
The resolver then asks one of the .com servers. This server is authoritative for .com, not for example.com, but it knows which servers are authoritative for example.com. It replies with another referral that lists the NS records for example.com and possibly their IP addresses in additional data. The resolver now knows where to go next.
Next, the resolver sends a query for www.example.com. to one of the authoritative servers for example.com. This server has the actual zone data and knows the A record or CNAME for www. It returns an authoritative answer, which the resolver then caches and forwards to the original client.
From the client perspective, this is a single query and response. All the complexity of recursion and following referrals happens inside the resolver. When you run tools like dig on a client and query a resolver like 8.8.8.8, you will usually see only the final result, not the intermediate steps that occurred between resolvers and authoritative servers.
Forward and Reverse DNS
Most administrators first encounter forward DNS, where a hostname is translated to an IP address using records such as A and AAAA. However, reverse DNS is also important. Reverse DNS resolves an IP address back to a hostname. Many services particularly email servers use reverse DNS as part of their trust and spam filtering logic.
Forward lookups typically query names such as www.example.com. Reverse lookups query domains that represent IP ranges and are structured differently. For IPv4, the reverse namespace uses in-addr.arpa. For example, the reverse of 203.0.113.10 is represented as 10.113.0.203.in-addr.arpa. For IPv6, the reverse namespace uses ip6.arpa and writes out each hexadecimal nibble of the address in reverse order. Reverse lookups use PTR records, which map these reverse names to hostnames.
Unlike forward DNS, control of reverse zones is often tied to IP address allocation. Your hosting provider or network operator controls the reverse zones for their IP space and may delegate control of specific ranges to you. As a Linux server administrator, you need to be aware that having forward DNS without matching reverse DNS can cause problems, especially for mail servers and some security systems.
For services such as SMTP, mismatched or missing reverse DNS commonly causes delivery failures or spam classification. Always ensure that critical servers have consistent forward and reverse DNS.
Stub Resolvers and /etc/resolv.conf
On a typical Linux system, the application that wants to resolve a name does not speak DNS directly to the internet. Instead it calls the system resolver library, which is often provided by glibc or another libc implementation. This client side component is sometimes called a stub resolver. It is simple and does not perform recursion or caching by itself, it relies on upstream resolvers.
The stub resolver reads configuration from files such as /etc/resolv.conf and sometimes from nsswitch.conf and other system specific mechanisms. In /etc/resolv.conf, you usually see entries like:
nameserver 192.0.2.53
nameserver 2001:db8::53
search example.com
The nameserver lines tell the stub resolver which upstream recursive resolvers to query. The search line defines one or more domains that the resolver will append for unqualified names. For example, if the search domain is example.com and you resolve web1, the stub resolver will try web1.example.com.
Modern distributions often do not let you edit /etc/resolv.conf directly, because it is managed by components like NetworkManager, systemd-resolved, or DHCP clients. These services dynamically update the list of upstream resolvers based on network configuration. As a server administrator, you must know which component manages name resolution on your system, or your manual changes will be overwritten.
DNS over UDP and TCP
DNS traditionally uses UDP on port 53 for most queries and responses. UDP is connectionless and lightweight, which makes it suitable for the large number of small DNS packets that flow across the internet. However, DNS can also use TCP on port 53, and in some scenarios it must.
If a response is too large to fit in a single UDP packet, the server sets a truncation flag. The resolver then retries the query over TCP, which can carry larger messages. With the introduction of DNSSEC and more complex records, larger responses have become more common, so TCP usage has increased.
Zone transfers between authoritative servers, which are used to synchronize primary and secondary servers for a zone, always occur over TCP. Misconfigured firewalls that block DNS over TCP can cause subtle and intermittent DNS failures, because some queries will work and others will fail when they exceed UDP size limits.
The introduction of EDNS0 extended DNS capabilities and lets clients advertise a larger UDP buffer size, which reduces the need for TCP fallback. However, as an administrator you must still ensure that both UDP and TCP port 53 are correctly handled on firewalls for your DNS servers.
Caching, Negative Answers, and TTL Behavior
Caching in DNS does not apply only to positive answers. Negative responses are also cached. When a resolver is told that a name does not exist, it may cache this information for a certain period. This is controlled by a special value in the SOA record of a zone, often called the negative TTL or minimum TTL, depending on the DNS specification version.
The SOA record contains several timing values, including the default TTL for records that omit it, the refresh and retry intervals for secondary servers, and the negative caching TTL. When an authoritative server responds with NXDOMAIN for a name, resolvers can cache that non existence status up to the negative TTL. This is useful to avoid repeated queries for invalid or mistyped names, but it also means that recently added names might not be visible to some clients until the negative TTL expires.
You must understand how TTL values interact with resolver caches when planning DNS changes. There is no central authority to “flush the cache of the internet”. Each resolver maintains its own cache, and these caches expire entries independently based on TTL. During migrations and failovers, use lower TTLs well in advance to reduce the time during which clients might see outdated information.
DNS Security Basics and DNSSEC Concepts
DNS was originally designed without strong security mechanisms. Classic DNS queries and responses are unencrypted and unauthenticated. This makes them vulnerable to spoofing and man in the middle attacks. An attacker on the path can forge replies that redirect users to malicious servers. This is problematic for any security sensitive service that relies on DNS.
Several technologies try to address these weaknesses. DNSSEC adds cryptographic signatures to DNS data so that resolvers can verify that the information came from the correct authoritative source and was not modified. With DNSSEC, each zone has a public private key pair. The zone is signed with the private key, and resolvers validate signatures using the public key, which is anchored via a chain of trust starting from the root zone.
DNSSEC does not encrypt the data, but it provides integrity and authenticity. Deploying DNSSEC involves key management, signing zones, and publishing DS records at the parent zone, and it requires resolvers that perform validation. In later chapters on advanced DNS configuration, you will see how to manage these components in practice.
Other approaches, such as DNS over TLS and DNS over HTTPS, aim to provide confidentiality by encrypting DNS traffic between clients and resolvers. These are mainly client side and resolver side concerns. As a server administrator running authoritative DNS, your primary focus is usually on correctness, availability, and integrity through proper configuration and optional DNSSEC.
Putting DNS in Context for Linux Servers
On a Linux server, DNS touches many subsystems. Package managers, configuration management tools, and application frameworks often rely on hostnames and service names. Authentication infrastructure such as Kerberos and directory systems depend on correct DNS for realm discovery, service location, and reverse lookups. When you administer web and email servers, correct entries for A, AAAA, MX, and related records are mandatory.
From a troubleshooting perspective, always distinguish between basic IP connectivity and name resolution. Use tools to test raw connectivity such as ping and ss, and tools that specifically probe DNS behavior such as dig and host. Remember that problems may arise on the client, on an intermediate recursive resolver, or on the authoritative servers.
As you move into configuring BIND and working with concrete records and zones in the following chapters, keep this conceptual model of DNS in mind. The hierarchical nature, the role separation between authoritative and recursive components, and the impact of caching and TTLs will guide your decisions and help you diagnose issues effectively.