Learning DNS - Core Concepts & Main Architecture

#Introduction

Before configuring PowerDNS, you must be able to read DNS "from the inside." Episode 2 dissects the four things that frame every DNS engineer's thinking: the hierarchical namespace, message anatomy, server roles, and resource records. All four are interrelated and will keep showing up in every episode that follows.

Think of this episode as a map. When we cover DNSSEC in episode 13, you'll meet the terms zone and delegation again. When we cover primary-secondary in episode 9, you'll use the SOA serial. Understand this map first, and everything else is just going deeper.

#The Hierarchical Namespace

#The Name Tree from Root to Subdomain

DNS is arranged like an upside-down tree. At the top is the root zone, written as a dot .. Below it are TLDs like .com, .net, and .id. Below the TLDs are second-level domains like example.com, and so on down to subdomains like www.example.com. Each separating dot marks one level of delegation.

.                  <- root zone
`-- com            <- TLD
    `-- example    <- second-level domain
        `-- www    <- subdomain

#Root Servers and the Resolution Flow

That delegation is carried out by a group of servers. Root servers (a-m.root-servers.net) tell you where the TLD servers are. TLD servers tell you where the authoritative servers for a second-level domain are. From there, clients finally get their answers.

There are two resolution styles that are important to distinguish:

• Iterative: the server answers "ask here" over and over until the final answer is found.
• Recursive: the server performs the entire search on behalf of the client, then returns the final answer.

dig +trace example.com

The command dig +trace example.com above shows the process step by step from root to the final answer — exactly like the recursive resolution a recursor performs.

#Anatomy of a DNS Message

#Header and the Four Message Sections

A DNS message consists of a header followed by four sections: Question, Answer, Authority, and Additional. The header holds an ID for matching queries and answers, plus flags such as QR (query or response), AA (authoritative answer), and RD/RA (recursion desired/available). The QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT fields state the number of records in each section.

dig +noall +comments example.com A

Notice the line containing status: NOERROR, flags: qr rd ra ad, and QUERY: 1, ANSWER: 1. When we use dig +dnssec in episode 14, the ad flag will be the marker of a successful validation. This shows how much information fits in a tiny 12-byte header.

#The EDNS OPT Record

The Additional section can carry a special record called OPT that implements the EDNS0 mechanism. This record lets clients and servers agree on UDP payload sizes larger than 512 bytes — an important requirement for DNSSEC and large answers.

#Server Roles in the Ecosystem

#Authoritative, Recursor, and dnsdist

There are three roles you'll keep encountering:

• Authoritative: holds the zone data and answers with the aa flag for names it is the authority for.
• Recursor: finds answers on behalf of clients, stores results in cache, and performs DNSSEC validation.
• dnsdist: sits in front, accepts queries, picks a backend, applies rate limiting, and provides DoT/DoH/DoQ.

In the PowerDNS stack, all three are separate daemons. This lets you run, measure, and upgrade each one independently.

clients -> dnsdist -> recursor -> internet
                     -> authoritative (local zones)

#Resource Records (RR)

#The Most Commonly Used RRs

A resource record is the unit of DNS data. Here are the most important ones:

• SOA: marks the start of a zone, holding the serial, refresh, retry, expire, and negative TTL.
• A/AAAA: the IPv4/IPv6 address of a name.
• NS: a zone's authoritative name server.
• MX: the email server along with its priority.
• TXT: free text, often used for SPF and DKIM.
• CNAME: aliases one name to another.
• PTR: maps an IP address back to a name, used in reverse zones.
• SRV: services and ports, for automatic discovery.
• CAA: restricts which CAs may issue certificates for a domain.
• SVCB/HTTPS: modern records that help clients discover DoH endpoints and HTTP/3.

Every record has a TTL (time to live) that determines how long an answer may be cached. TTL is a control knob you'll use constantly, especially when moving services.

dig +noall +answer example.com

#Conclusion

Episode 2 gives you the mental framework for the entire series: the hierarchical, delegated namespace, DNS messages with their header and four sections, the roles of authoritative, recursor, and dnsdist, and the catalog of resource records from SOA to SVCB.

Key takeaways:

• DNS is a name tree delegated from the root zone down to subdomains.
• Root servers and TLD servers direct resolution; they don't store application data.
• A DNS message contains a header plus Question, Answer, Authority, and Additional sections.
• EDNS0 via the OPT record expands the UDP payload for DNSSEC and large answers.
• Authoritative answers its own zones, Recursor finds answers, dnsdist balances and secures.
• Every record has a TTL that controls caching and that you'll use constantly throughout this series.

In the next episode we'll cover installation and initial setup — the structure of pdns.conf, recursor.yml, and dnsdist.yml, each daemon's systemd service, and connection verification with dig @127.0.0.1. This is the first point where you'll create PowerDNS configuration that actually runs in your lab.