5.4.3 DNS zones and records

Understanding DNS Zones and Records

In this chapter you will learn how DNS information is organized and described with zones and records. You will not yet configure a full DNS server, but you will see the concepts and syntax that are used when you later work with software such as BIND.

Domains, Authority, and Zones

A domain name describes a position in the DNS hierarchy, for example example.com, sub.example.com, or com. In practice a single organization is responsible for answering queries for some part of that namespace. That part is administered as a zone.

A DNS zone is an administrative unit of the DNS namespace that is served by at least one authoritative DNS server. A zone usually corresponds to a domain, such as a zone for example.com, but it can also be only a subdomain, for example a separate zone for internal.example.com with its own servers and policies.

The important property of a zone is authority. The servers that host a zone file are authoritative for the records inside that zone. When a resolver reaches them, their answers are final for that part of the namespace.

It is common to imagine three layers:

Top level domains such as com or org, each one typically a large zone.

Second level domains such as example.com, each usually its own zone managed by a domain owner.

Delegated subzones such as sub.example.com that can be hosted on different name servers from the parent.

A single domain can be split across multiple zones if necessary. For instance, example.com might be one zone, while eu.example.com and us.example.com are separate zones delegated to other servers. The parent zone contains delegation records that tell resolvers where to find the authoritative servers for the child zones.

Zone Files and Their Structure

Authoritative DNS software such as BIND stores zone data in a zone file. A zone file is a text file that contains resource records for a particular zone. The zone file describes all the known names under that zone and how they should be resolved.

Zone files use a specific syntax. The name on each line is relative to an origin, which is usually the zone name itself. There are directives to control the interpretation of the file. The most common directive is $ORIGIN, which sets the current domain suffix, and $TTL, which sets the default time to live for records that do not specify their own value.

A minimal zone file for example.com could look like this.

$TTL 3600
$ORIGIN example.com.
@   IN  SOA ns1.example.com. hostmaster.example.com. (
        2026010801 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        300 )      ; minimum
    IN  NS  ns1.example.com.
    IN  NS  ns2.example.com.
@   IN  A   203.0.113.10
www IN  A   203.0.113.11
mail IN  A  203.0.113.12

Names like @, www, and mail are labels. @ is a special symbol that refers to the origin, which is the zone apex. In this example the apex is example.com.. The trailing dot on example.com. indicates that it is a fully qualified domain name, which is important inside zone files because it stops the origin from being appended.

The IN field describes the class. Almost all records you will see in modern DNS zones use the Internet class, which is IN.

Time To Live and Caching

A key property of DNS records is that they can be cached by recursive resolvers for performance and resilience. The time to live, or TTL, defines how long a record is valid in caches.

The TTL is expressed in seconds. In a zone file you can set a default TTL with $TTL, and you can also set per record TTL values before the class. For example.

$TTL 3600
www 600 IN A 203.0.113.11

In this example the zone default is one hour, but www.example.com has a TTL of 600 seconds, which means ten minutes. During those ten minutes a resolver can answer queries from its cache without returning to the authoritative server.

When planning changes to important records, such as those for a website or mail server, it is common to lower the TTL some time in advance, then perform the change, and finally raise the TTL again after the new value is in use.

SOA Record: The Start of Authority

Every DNS zone must contain exactly one SOA record at the zone apex. The SOA record defines global parameters that control how secondary name servers synchronize with the primary and how caches should treat certain responses.

An SOA record has the following general structure.

example.com. IN SOA ns1.example.com. hostmaster.example.com. (
    2026010801 ; serial
    3600       ; refresh
    900        ; retry
    1209600    ; expire
    300 )      ; minimum

The fields after the contact address are numeric values that control zone transfers and negative caching.

The serial number is a monotonic value that identifies the current version of the zone. Secondary servers compare their copy with the primary. When the serial on the primary is higher, they transfer the zone. A commonly used pattern for the serial is YYYYMMDDnn, for example 2026010801 for the first change on that date. This is not required but makes it easy for humans to see when the zone was last updated.

The refresh interval is how often, in seconds, a secondary server will check with the primary to see if the serial has changed.

The retry interval is how long a secondary waits before trying again after a failed attempt to contact the primary.

The expire time defines how long a secondary will continue to serve data without contact from the primary. If this time passes without a successful refresh, the secondary stops serving the zone because its copy is considered too old.

The minimum field is used by caches to determine the TTL of negative answers, that is responses indicating that a name or record type does not exist. The details of this behavior depend on DNS specifications, but in practice this value controls how long resolvers will remember that a particular name was not found.

NS Records and Delegation

Name server records, NS records, tell the world which authoritative servers provide answers for a zone. At least two NS records are recommended for redundancy.

At the zone apex you will include NS records that point to your authoritative servers. For example.

example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.

These entries indicate that ns1.example.com and ns2.example.com are authoritative for the example.com zone. The domain names given as targets in NS records must themselves resolve to IP addresses with A or AAAA records, either in the same zone or in another zone.

Delegation uses NS records in the parent zone that point to the authoritative servers of a child zone. For example, if you delegate sub.example.com to other servers, the example.com zone might contain.

sub.example.com. IN NS ns1.subdns.net.
sub.example.com. IN NS ns2.subdns.net.

Once the parent provides these NS records, resolvers will query ns1.subdns.net and ns2.subdns.net when they need data for sub.example.com. The child zone itself must also contain its own SOA and NS records as required for any zone.

A and AAAA Records for Hostnames

The most commonly used DNS record types are A and AAAA records. An A record maps a hostname to an IPv4 address. An AAAA record maps a hostname to an IPv6 address.

An example of A and AAAA records in a zone file is the following.

@    IN A    203.0.113.10
www  IN A    203.0.113.11
www  IN AAAA 2001:db8::11

In this case example.com resolves to 203.0.113.10, and www.example.com resolves to both an IPv4 and an IPv6 address. A client that supports IPv6 can choose the appropriate address to use.

You can have multiple A or AAAA records for the same name. This is one way to implement simple load distribution across several servers.

www IN A 203.0.113.11
www IN A 203.0.113.12
www IN A 203.0.113.13

Resolvers typically return the list of addresses in a rotated order. Clients then pick one address, which spreads the queries among the available servers.

CNAME Records and Canonical Names

A CNAME record creates an alias from one name to another canonical name. The target of a CNAME must be another name, not an IP address. When a resolver encounters a CNAME, it will follow it to retrieve the actual resource records at the target name.

Consider this example.

www    IN CNAME web-frontend.example.com.
login  IN CNAME web-frontend.example.com.

Here both www.example.com and login.example.com are aliases for web-frontend.example.com. The A and AAAA records are attached to web-frontend.example.com. This allows an administrator to change the address on the canonical name without editing every alias.

There are important constraints on CNAME usage. A name that has a CNAME record must not have any other record types with the same name in the same zone. That includes A, AAAA, MX, and others.

Because of this restriction, many administrators avoid using CNAME at the zone apex, since the apex must have SOA and NS records and often needs other records such as MX and TXT. For web services at the apex, other mechanisms like ALIAS or ANAME records may be provided by specific DNS providers, but those are not standard DNS record types and are implemented internally by the provider.

MX Records for Mail Routing

Mail exchange, or MX, records specify which hosts accept email for a domain. An MX record consists of a priority number and a hostname. The hostname must have A or AAAA records. For example.

example.com.  IN MX 10 mail1.example.com.
example.com.  IN MX 20 mail2.example.com.

In this case mail servers delivering messages to user@example.com will first attempt to contact mail1.example.com. If that server is not available, they will try mail2.example.com. Lower numbers indicate higher priority, so 10 is tried before 20.

An MX record should always point to a hostname, never directly to an IP address. In practice the same host may serve as both a mail server and a web server, but the records for each service are separate. For instance you might have mail1.example.com with both A and AAAA records and an MX record at the zone apex that points to that host.

TXT Records and Generic Metadata

TXT records store arbitrary text data in DNS. They are widely used to carry metadata for many protocols and services, including domain ownership verification, email authentication parameters, and service specific indicators.

Here is an example of a simple TXT record.

example.com. IN TXT "This is an example domain"

In production zones, TXT records are most often used with standardized content. Email systems rely on TXT records for SPF, DKIM, and DMARC. For example an SPF record might look like this.

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

Although the content here has a specific syntax, DNS itself treats it as a string. Interpretation is handled at the application level.

A single TXT record can contain multiple quoted strings that will be concatenated. This is sometimes used to keep long values readable in a zone file.

PTR Records for Reverse DNS

Normal DNS lookups are forward lookups that map hostnames to IP addresses. PTR records are used for reverse lookups, which map IP addresses back to hostnames. Reverse lookups use special domains, not the original zone for the hostname.

For IPv4 the reverse domain is under in-addr.arpa. For an address such as 203.0.113.11, the corresponding reverse name is 11.113.0.203.in-addr.arpa. A PTR record in the appropriate reverse zone might look like this.

11.113.0.203.in-addr.arpa. IN PTR www.example.com.

For IPv6 the reverse domain is under ip6.arpa, and each nibble of the address is reversed and separated by dots. In both cases the PTR record points from the numeric address representation to a hostname that should also have A or AAAA records.

Reverse DNS is particularly important for services like email, where many servers check that the reverse lookup for an IP address returns a reasonable hostname and that the forward lookup for that hostname points back to the same IP.

SRV Records for Service Discovery

Service records, or SRV records, provide a way to specify the location of servers for specific protocols and services, including port numbers and priorities. SRV records use a special naming convention at the left side. The name of the record is built as _<service>._<protocol>.<domain>.

Here is an example for a service using TCP on port 5222 under example.com.

_xmpp-client._tcp.example.com. IN SRV 10 5 5222 chat1.example.com.
_xmpp-client._tcp.example.com. IN SRV 20 5 5222 chat2.example.com.

The fields after the class are priority, weight, port, and target. The priority works similarly to MX records, that is lower values are preferred. The weight allows proportional load sharing among servers with the same priority. The port specifies where the service listens on the target host.

Many modern services use SRV records for discovery, especially in environments where port numbers and hostnames may change over time.

Caching, Negative Answers, and Record Lifetimes

In addition to positive answers, resolvers also cache negative results. If no record exists for a name, or if a type for a name is missing, the resolver may store this information for a limited time. The duration is controlled by the SOA minimum field and sometimes by explicit negative TTL values in responses.

This behavior reduces unnecessary repeated queries that would produce the same negative result. However, it also means that if you add a new name or new record type to a zone, clients may not see it until their negative cache entries have expired.

To summarize the relationship between TTL and caching, you can think of it as a bound on the caching period.

$$
\text{cache lifetime} \le \text{TTL}
$$

Caches may evict entries sooner for their own reasons, but they should not retain data longer than the TTL value they received.

Logical Grouping and Naming Practices

Although not enforced by DNS itself, it is common to choose names that reflect roles and services. For example, names like www, mail, api, and db give humans a quick idea of what a host does. Internally you may choose more detailed names and use CNAME records to create simple public aliases.

You can also use subdomains within the same zone to separate roles or regions, such as eu.example.com or dev.example.com, and give each set of hosts its own records. If these subdomains become complex or are managed by different teams, you can split them into distinct zones and delegate them with NS records.

When adding records to a zone file, it is useful to keep related records grouped together and to comment important decisions or dependencies. For instance, you might place A and AAAA records for a host, then any associated MX or SRV records, and document how they relate.

By understanding the essential record types and how zones contain them, you are now prepared to move on to the practical configuration of DNS servers. In the next chapters you will look at how to create and serve these zones using specific DNS server software.