Learning DNS - Zones & Resource Record Types

#Introduction

Now that you understand the architecture, it's time to understand the DNS unit of work: the zone and its raw material, resource records. In this episode you'll learn the difference between a zone and a domain, read SOA like you read a clock, and get to know the records you'll write into PowerDNS almost every day.

The most important skill in this episode is reading dig output quickly. When an answer appears in your terminal, you should know which record looks odd and which part of the SOA explains caching behavior. Let's build that skill.

#Zone vs Domain

#Authority, Not Just a Name

A domain is a portion of the namespace tree (example.com). A zone is the portion of the tree that one set of DNS servers is authoritative for. The difference is about delegation: example.com can be a single zone, or you can split it into a example.com zone and a sub.example.com zone delegated to other servers.

The boundaries between zones are marked by NS records at delegation points. When PowerDNS answers for a zone, the response uses the aa flag (authoritative answer) — a sign that the data is actually owned, not a cached result.

dig @127.0.0.1 example.com SOA +noall +authority +comments

The output above also shows the Authority section holding the SOA and NS — a marker that this server is authoritative for the zone.

#SOA Format

#Reading the SOA Parameters

The SOA (Start of Authority) record is the head of a zone. It marks the start of the zone, holds the admin contact, and most importantly the serial — the version number used to compare zones during transfer mechanisms.

dig +short example.com SOA
dig +noall +answer +multiline example.com SOA

Note: dig +short example.com SOA shows the SOA value in a single line without the record name, while dig +noall +answer +multiline shows the full SOA with each parameter on its own line — far easier for humans to read. The +multiline mode is very useful when analyzing someone else's SOA.

An SOA takes this form: primary NS, admin email, serial, refresh, retry, expire, negative TTL. A real example:

ns1.example.com hostmaster.example.com 2026081001 10800 3600 604800 3600

What each number means: serial = 2026081001, refresh = 10800 seconds (secondary checks the primary), retry = 3600 seconds (try again if it fails), expire = 604800 seconds (secondary gives up if the primary can't be reached), and negative TTL = 3600 seconds (how long "does not exist" answers may be cached).

#Serial Management

The serial increases every time the zone changes. In PowerDNS with a database backend, the serial can be computed automatically from SOA-EDIT (INCREASE, EPOCH, etc.), or set manually. In episode 9 we'll see how this serial determines whether a zone transfer happens.

#Resource Record Types

#The Records You Must Master

The full catalog was introduced in episode 2. Now let's look at their concrete form in a simple zone:

example.com.   3600  IN  SOA   ns1.example.com. hostmaster.example.com. ...
example.com.   3600  IN  NS    ns1.example.com.
example.com.   3600  IN  MX    10 mail.example.com.
example.com.   3600  IN  TXT   "v=spf1 mx -all"
ns1.example.com. 3600 IN A     192.0.2.10
www.example.com. 3600 IN A     192.0.2.11
mail.example.com. 3600 IN A    192.0.2.12

• A/AAAA maps a name to IPv4/IPv6.
• MX holds the priority and host of the email server — the smaller the number, the higher the priority.
• TXT carries text for SPF, DKIM, and other verifications.
• NS points to the authoritative name servers.
• CNAME creates an alias: www.example.com can point to example.com.

#Modern Records: SVCB and HTTPS

SVCB and HTTPS are a new generation of records that help clients discover services: DoH endpoints, HTTP/3 support, and other connection parameters. HTTPS is a variant of SVCB specifically for HTTPS services. Both are also used by the DDR (Discovery of Designated Resolvers) protocol, which we'll touch on in episode 22.

dig @127.0.0.1 example.com HTTPS

#Zone Files vs Database

#BIND-Style Format

Classic servers like BIND store zones in files using $ORIGIN and $TTL. PowerDNS Authoritative can still read this format through the bind backend, useful for migrating from BIND.

$ORIGIN example.com.
$TTL 3600
@   IN SOA  ns1.example.com. hostmaster.example.com. (
            2026081001 10800 3600 604800 3600 )
@   IN NS    ns1.example.com.
@   IN MX    10 mail.example.com.
www IN A     192.0.2.11

#Database Storage in PowerDNS

By contrast, PowerDNS stores records in a database. The advantages: automatic serials, access via SQL or the API, and no file parsing. Conversion between the two is done with pdnsutil import-zone and pdnsutil export-zone-dnssec. We'll fully dissect database backends in episode 11.

pdnsutil create-zone example.com ns1.example.com ns2.example.com
pdnsutil list-zone example.com

#Conclusion

Episode 4 gives you the ability to read and write the raw material of DNS: distinguishing zones from domains, reading SOA as a version and timing marker, using records from A to HTTPS, and understanding the difference between zone files and database backends.

Key takeaways:

• A zone is the portion of the DNS tree delegated to one set of servers; a domain is a name.
• SOA holds the serial, refresh, retry, expire, and negative TTL that drive zone transfers.
• The serial increases with every change and determines primary-secondary synchronization.
• A/AAAA, NS, MX, TXT, CNAME, PTR, SRV, CAA, and SVCB/HTTPS are the catalog you must master.
• PowerDNS stores records in a database, not zone files, but can import the BIND format.

In the next episode we'll cover PowerDNS Authoritative Server basics — choosing a backend between bind, gsqlite3, gmysql, and lmdb, then hands-on practice creating zones, adding records, inspecting, and editing with pdnsutil.