Understanding DNS

DNS in the Big Picture

DNS (Domain Name System) is a distributed, hierarchical database that maps human‑readable names (like www.example.com) to technical identifiers (like IP addresses).

At a server‑administration level, you care about DNS because:

• Every public‑facing service you run (web, mail, APIs) is usually reached via DNS names.
• Configuration errors in DNS can make services appear “down” even when the server is fine.
• DNS often interacts with other infrastructure you manage (load balancers, CDNs, mail systems, reverse proxies).

This chapter focuses on understanding how DNS works conceptually and operationally so that later chapters (e.g., “Setting up BIND”) make sense.

Fundamental DNS Concepts

DNS as a Distributed Database

DNS is not one big central database; it is:

• Distributed: Different organizations manage different pieces (zones).
• Hierarchical: Like a tree starting from the root ..
• Authoritative vs cached: Some servers own the data; others just cache it temporarily.

DNS stores resource records (RRs). Each record is identified by:

• Name (e.g., www.example.com.)
• Type (e.g., A, AAAA, MX)
• Class (almost always IN for Internet)
• TTL (Time To Live)
• Value/RDATA (the actual content, like an IP address)

Conceptually, a record looks like:

$$
\text{name} \quad \text{TTL} \quad \text{class} \quad \text{type} \quad \text{value}
$$

Example:

www.example.com. 3600 IN A 203.0.113.10

The DNS Hierarchy

The DNS namespace is a tree:

• Root (.)
  The top of the tree. Root servers know where the top‑level domains live.
• Top‑Level Domains (TLDs)
  Examples: com, org, net, country TLDs like de, uk, jp, and newer gTLDs like dev, app.
• Second‑level and lower domains
  example.com, example.org, co.uk, etc.

A fully qualified domain name (FQDN) always conceptually ends with a dot, e.g. www.example.com.
Clients often omit the trailing dot; resolvers handle that.

Domains vs Zones

These are often confused:

• Domain: Any subtree in the DNS hierarchy, such as example.com or eu.example.com. It’s a name space concept.
• Zone: A portion of the DNS namespace that is served and managed as a unit by an authoritative nameserver.

A zone:

• Contains records for some part of a domain (or multiple domains via delegations and aliases).
• Has at least one authoritative DNS server.
• Is typically stored in a zone file when using traditional DNS servers like BIND.

Examples:

• example.com domain may be served as one zone.
• eu.example.com could be a separate zone delegated to another DNS provider or internal DNS.

Zones allow delegation of responsibility: your registrar delegates the example.com zone to your nameservers; you can delegate us.example.com to another team/provider.

How a DNS Query Works

The Main Players

For a typical DNS lookup, these roles are involved:

• Stub resolver
  Built into the OS; sends queries to a configured resolver (e.g., in /etc/resolv.conf).
• Recursive resolver
  Often run by ISPs, enterprises, or public providers (e.g., 1.1.1.1, 8.8.8.8).
  It:
• Accepts queries from clients.
• Does the “walking” through the DNS hierarchy.
• Caches answers.
• Authoritative nameservers
  Provide the final answers for a zone. They do not perform recursion.
• Root and TLD nameservers
  Authoritative for the root (.) and top‑level domains.

Step‑by‑Step Resolution

When a client needs www.example.com:

1. Client → Recursive Resolver
   Client asks: “What is www.example.com?”
2. Cache Check
   Resolver checks if it already has a fresh answer in cache.
• If yes, it replies immediately.
• If no, it starts a recursive resolution.
3. Ask Root Servers
   Resolver asks a root server: “Who knows .com?”
   Root replies with a referral to the .com TLD nameservers.
4. Ask TLD Servers
   Resolver asks .com servers: “Who is authoritative for example.com?”
   TLD servers reply with NS records (nameservers for example.com) plus their IP addresses (glue records, discussed later).
5. Ask Authoritative Servers for example.com
   Resolver asks those authoritative servers: “What is the A record for www.example.com?”
   Nameserver responds with the IP (and TTL).
6. Resolver Caches and Returns Answer
   Resolver stores the answer in cache for the TTL, then replies to the client.

On subsequent queries within the TTL, steps 3–5 are skipped due to caching.

Recursive vs Iterative Queries

• Recursive query: Client asks resolver to obtain the final answer. Resolver performs all follow‑up queries. This is what your laptop/servers usually do towards a recursive resolver.
• Iterative query: Resolver asks servers higher in the hierarchy for referrals and then follows them itself. Queries between resolvers and authoritative servers are usually iterative.

Authoritative servers typically do not accept recursive queries (and should not, for security reasons).

Caching and TTL

Each DNS record has a TTL (seconds). During that time, a resolver can reuse the answer from cache without querying the authoritative server again.

Implications for administration:

• Short TTLs (e.g., 60–300 seconds)
• Faster propagation of changes.
• Higher query load on authoritative servers.
• Long TTLs (e.g., 86400 seconds = 24h)
• Lower load.
• Slower propagation: changes may take “up to TTL” to be seen everywhere.

You can use this operationally:

• Before a planned migration, reduce TTLs (e.g., a day or two in advance).
• Make the change.
• After things stabilize, raise TTLs again.

Core DNS Record Types for Servers

DNS uses many record types; as a server admin, these matter most:

A and AAAA Records

• A: Address record for IPv4.
• AAAA: Address record for IPv6.

Examples:

www.example.com. 3600 IN A 203.0.113.10
www.example.com. 3600 IN AAAA 2001:db8::10

When load balancing with DNS, you can have multiple A/AAAA records for the same name.

CNAME Records

Canonical Name: an alias pointing to another name (canonical target).

Example:

www.example.com. 3600 IN CNAME web-frontend-1.example.com.

Rules and caveats:

• A CNAME must not coexist with other records of the same name (no A, MX, etc. on that name).
• CNAMEs can chain, but long chains are discouraged (performance and complexity).
• Some record types (like NS and MX targets) should not point to CNAMEs, according to standards.

MX Records

Mail Exchanger: tells other mail servers where to send email for your domain.

Example:

example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.backup-mx.tld.

Key points:

• Lower preference number = higher priority.
• MX targets must have corresponding A/AAAA records; using CNAME targets is discouraged or disallowed by many implementations.
• Proper MX configuration is critical for reliable mail delivery.

NS Records

Name Server: specifies authoritative servers for a zone (or sub‑zone).

Example (in the parent zone):

example.com. 172800 IN NS ns1.dns-provider.net.
example.com. 172800 IN NS ns2.dns-provider.net.

• NS records appear:
• In the parent zone (delegation).
• In the child zone itself (zone apex).
• NS targets must resolve to IP addresses, often via A/AAAA records in the same parent zone (glue).

SOA Record

Start of Authority: metadata for a zone. There is exactly one SOA record per zone, at the zone apex:

Example:

`example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2025121201 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ) ; minimum/negative TTL
`

Fields:

• Primary NS: the “master” nameserver (from the zone’s view).
• Responsible email: written with . instead of @ (first dot only).
• Serial: version number of the zone; must be incremented on changes.
• Refresh, retry, expire, minimum: timing values used by secondary nameservers and for negative caching.

As an admin, correct serial handling is important: secondaries won’t pick up changes if serial doesn’t increase.

TXT Records

Originally arbitrary text; now heavily used for:

• SPF policies
• Domain verification (e.g., for TLS certificates, cloud providers)
• DKIM and DMARC configuration
• Application‑specific metadata

Example:

example.com. 3600 IN TXT "v=spf1 mx -all"

PTR Records (Reverse DNS)

While forward DNS maps name → IP, reverse DNS maps IP → name using PTR records in special reverse zones:

• IPv4: in-addr.arpa
• IPv6: ip6.arpa

Example (IPv4):

IP 203.0.113.10 → 10.113.0.203.in-addr.arpa.

Record:

10.113.0.203.in-addr.arpa. 86400 IN PTR web-01.example.com.

Operational relevance:

• Mail servers often rely on correct reverse DNS for spam checks.
• Reverse DNS is usually controlled by whoever owns the IP block (ISP, hosting provider, your network team).

Zones, Delegation, and Glue

Zone Apex and Subdomains

The zone apex is the root name of a zone, e.g.:

• Zone: example.com. → apex is example.com.
• Zone: 1.168.192.in-addr.arpa. → apex is 1.168.192.in-addr.arpa.

A zone may contain records for subdomains, like:

www.example.com.
api.example.com.
eu.example.com.

These names can be answered by the same zone, or you can delegate a subtree as a separate zone.

Delegation

Delegation is how the DNS hierarchy is split among different authorities.

Example:

• You own example.com.
• You want eu.example.com managed by another team/DNS provider.

Steps conceptually:

1. In the example.com zone, you add NS records for eu.example.com that point to the nameservers for that subzone.
2. The authoritative servers for eu.example.com serve their own zone file with their own SOA, etc.

Clients resolving host.eu.example.com will:

• Ask the example.com nameservers.
• Get a referral via NS records to the eu.example.com nameservers.
• Then ask those servers for the final answer.

Delegation is fundamental when splitting public/internal DNS, or delegating reverse DNS sub‑blocks to customers.

Glue Records

Glue is an A/AAAA record placed in the parent zone to break circular dependencies.

Example:

You register example.com and want to use:

• ns1.example.com
• ns2.example.com

as nameservers for the zone.

Problem:
To resolve ns1.example.com, you need to query example.com nameservers, but to find example.com nameservers, you need ns1.example.com’s IP. Circular.

Solution:
At the TLD level (.com), your registrar adds:

• NS records: example.com. NS ns1.example.com.
• Glue: ns1.example.com. A 203.0.113.53

Now resolvers can find ns1.example.com without first resolving example.com.

Operational note: Glue is managed via your domain registrar interface, not in your own zone file alone.

DNS Resolution Patterns for Services

Web Services

Typical setup:

• example.com and www.example.com → point to:
• A single IP,
• Multiple IPs (DNS round‑robin),
• A load balancer or CDN.

You might use:

• A/AAAA records directly.
• CNAME records to a provider name (e.g., foo.cdnprovider.net.).

Consider:

• TTL vs how quickly you may move services.
• Whether you need subdomain isolation (e.g., static.example.com, api.example.com).

Mail Services

Key DNS aspects for mail:

• MX records: specify mail exchangers for example.com.
• A/AAAA for MX hostnames.
• PTR (reverse DNS) for outbound IPs.
• TXT for SPF, DKIM, DMARC.

While configuration details belong in mail‑specific chapters, understanding the DNS foundation is essential for troubleshooting deliverability.

Internally Scoped DNS

In corporate or data center environments:

• You often have split‑horizon DNS (different answers internally vs externally).
• Private zones like corp.example.com only resolvable inside the network.
• Service discovery via DNS (e.g., SRV records, or internal naming conventions).

Understanding that different resolvers (internal vs external) see different DNS views is crucial for diagnosing “it works on the server but not from the internet” scenarios.

DNS Security and Reliability Concepts

Common DNS Threats (Conceptual)

• Cache poisoning: Attacker tries to inject false records into a resolver’s cache.
• Spoofing / MITM: Returning fake answers to clients.
• Amplification attacks: Using open resolvers to DDoS victims.
• Zone data exposure: Unwanted disclosure of internal structure (e.g., via zone transfers).

At this stage, you should be able to recognize these as risks and tie them to later mitigation techniques.

DNSSEC (High‑Level View)

DNSSEC (DNS Security Extensions) adds authenticity and integrity to DNS data using digital signatures:

• Zones are signed with private keys.
• Clients (or resolvers) validate signatures using a chain of trust from the root.
• Provides assurance that the records you get are what the zone owner published.

Key point: DNSSEC protects against tampering and spoofing, but not against all DNS‑related problems (e.g., misconfiguration, denial of service).

Redundancy and Anycast

To make DNS resilient:

• Use at least two NS servers for each zone, ideally in different networks/regions.
• Many providers use anycast:
• The same IP address is announced from multiple locations.
• Clients are routed to the nearest instance.
• Increases availability and performance.

As an admin, you typically don’t implement anycast yourself unless at ISP scale, but you should understand that a single IP in NS records may represent multiple physical servers.

Practical Troubleshooting Mindset

Before configuring servers (covered in later chapters), it helps to think about how to reason about DNS issues.

Key questions when something “doesn’t resolve”:

1. Which resolver am I using?
• Check /etc/resolv.conf or system resolver configuration.
• Different networks/clients may see different DNS views.
2. Is the problem forward or reverse DNS?
• Name → IP vs IP → name.
3. Where does resolution break?
• At the root, TLD, parent zone, or authoritative zone?
• Is delegation correct (NS and glue)?
4. Is it caching‑related?
• Are you waiting for a TTL to expire?
• Did you increase the serial in the SOA?
5. Do different resolvers see different answers?
• Hinting at split‑horizon DNS, propagation delay, or a particular resolver’s cache.

Later, when you learn dig, nslookup, and other tools, you’ll use this conceptual model to interpret their output.

Summary

By understanding:

• The hierarchical, distributed nature of DNS,
• The roles of zones, delegations, and glue,
• Essential record types (A, AAAA, CNAME, MX, NS, SOA, TXT, PTR),
• How recursive resolution and caching actually work,

you’ll be prepared to:

• Design sane DNS layouts for services,
• Interpret DNS behavior under load and during migrations,
• Troubleshoot name resolution problems effectively.

Subsequent chapters on DNS server configuration and troubleshooting will build on these concepts.