A DNS zone is a file of records, each with a name, a type and data: A maps a name to an IPv4 address, AAAA to an IPv6 address, CNAME makes one name an alias of another, MX names the mail server for a domain, NS names the servers of the zone, PTR maps an address back to a name and TXT holds free text. The zone needs one SOA record whose serial number must increase on every edit, or secondary servers will not copy the change. For the network 10.1.0.0/24 the reverse zone is 0.1.10.in-addr.arpa, and the address 10.1.0.5 is looked up as 5.0.1.10.in-addr.arpa.

Part of Networking

The DNS record types a settlement uses, a complete forward and reverse zone file, and the rules that make zone files fail quietly when broken.

A Zone File Is A List Of Names With Types, And Small Mistakes Break It Silently

DNS explains why a settlement runs a name server, and DNS Hierarchy how zones delegate to one another. This article is the content of a zone. The carrier Internet Infrastructure gives the first example: A records of the form library IN A 10.1.0.5, mail IN A 10.1.0.6 and council IN A 10.1.0.7. Protocols adds the time to live on each record.

Type	Holds	Used for
A	an IPv4 address	name to machine
AAAA	an IPv6 address	name to machine, if IPv6 is used (Packet Structure gives 128-bit addresses)
CNAME	another name	an alias such as wiki for library
MX	a preference number and a mail server name	where mail for the domain goes (Mail Server)
NS	the name of a server for the zone	listing the zone’s servers and delegating sub-zones
PTR	a name	address to name, in the reverse zone
TXT	text	notes and policy strings
SOA	serial, timers, contact	one per zone; controls copying to secondary servers

What You Need

The address plan, which is the source of the data (IP Addressing)
A name server that can serve zone files, such as BIND (the carrier)
A text editor and a habit of checking the zone with the server’s own checker before reloading it

Method: Write And Maintain A Zone

Step 1: Write the forward zone The settlement zone, with the carrier’s three names and two name servers in the server range (.2 to .10):

$TTL 1h
@        IN SOA  ns1.settlement.internal. admin.settlement.internal. (
                 2026102301 ; serial
                 1h         ; refresh
                 15m        ; retry
                 1w         ; expire
                 1h )       ; negative-answer TTL
         IN NS   ns1.settlement.internal.
         IN NS   ns2.settlement.internal.
         IN MX   10 mail.settlement.internal.
ns1      IN A    10.1.0.2
ns2      IN A    10.1.0.3
library  IN A    10.1.0.5
mail     IN A    10.1.0.6
council  IN A    10.1.0.7
wiki     IN CNAME library

The timers and the date-style serial are example values chosen for the example, not recommendations. The contact in the SOA record is written with a dot where the at-sign would be.

Step 2: Write the reverse zone The network 10.1.0.0/24 becomes 0.1.10.in-addr.arpa:

$TTL 1h
@   IN SOA  ns1.settlement.internal. admin.settlement.internal. (
            2026102301 1h 15m 1w 1h )
    IN NS   ns1.settlement.internal.
5   IN PTR  library.settlement.internal.
6   IN PTR  mail.settlement.internal.
7   IN PTR  council.settlement.internal.

Step 3: Raise the serial on every edit The convention year-month-day-two-digit-count (2026102301, then 2026102302) makes it easy. A secondary server copies a zone only when it sees a larger serial. An edit with an unchanged serial is the most common reason one server answers differently from the other.

Step 4: Check and reload, then test from another machine Use the server’s own zone checker before reloading, and query for each type afterwards.

Worked Example: Reverse Names And Mail Routing

Reverse name. Reverse the octets of 10.1.0.5 to get 5.0.1.10 and add .in-addr.arpa: 5.0.1.10.in-addr.arpa. A /24 zone takes the first three octets reversed: 0.1.10.in-addr.arpa, so within the zone the host part is just the last octet, the 5 of the PTR line. The reverse name is needed because octets are written most-significant first in an address but names in DNS are read from the right.

Mail. Mail for anyone@settlement.internal is delivered to the host named in the MX record, mail.settlement.internal, found by asking for its A record, 10.1.0.6. With two MX records the lower preference number is tried first; give the backup server the higher number, for example 10 and 20 (general knowledge).

The Rules That Cause Silent Failures

These are general knowledge, not from the other articles, and each is worth confirming in the documentation of your server:

The trailing dot — a name ending in a dot is complete. Without it the server appends the zone name, so mail.settlement.internal without a dot becomes mail.settlement.internal.settlement.internal.
A CNAME cannot share its name with other records — so no CNAME at the zone’s top
An MX record must name a host that has an address record — not an address and not a CNAME
Every NS name needs an address record the resolver can find

Common Mistakes

Editing without raising the serial — the secondary keeps the old data
Forgetting the reverse zone — some programs log and check addresses by name and fail without it
Typing an address in an MX line — mail then goes nowhere
Using the same name for two different machines in different zones — documents and logs become ambiguous; the plan must list each name once

What’s Next

Learn next: Mail Server — the main user of the MX record
Combine with: DNS Hierarchy — NS records that delegate to other settlements

Explorer

DNS Records