Learning DNS - PowerDNS Authoritative Server Basics

#Introduction

This is the first moment you truly become a DNS operator: running the PowerDNS Authoritative Server that answers zones you own. Episode 5 covers two core topics — choosing a backend and managing zones with pdnsutil — and closes with a dig verification to make sure answers come with the aa flag.

If the previous episodes were theory, this is where you start typing a lot. Prepare a terminal in your lab, because every command here is worth practicing.

#Choosing a Backend

#The Backend's Role as Data Storage

The backend determines where PowerDNS stores zone data. Its configuration is one line in pdns.conf: launch=gsqlite3, launch=gmysql, launch=bind, or launch=lmdb. This choice doesn't affect how queries are answered, only how data is stored and accessed.

launch=gsqlite3
gsqlite3-database=/var/lib/powerdns/pdns.sqlite3

#Quick Comparison

• bind backend: reads and writes BIND-style zone files. Easiest to understand, good for migrations, but less flexible for automation.
• gsqlite3/gmysql: stores in a relational database. The most popular: supports the API, autoprovisioning, and SQL operations.
• lmdb: a high-performance embedded database built into PowerDNS, supports RRset comments. Good for large scale and high load.
• geoip and remote: we'll cover these in episode 11 — for location-based answers and API integration respectively.

For this series we use gsqlite3 so everything can be practiced without a MySQL server. If you use gmysql, you'll also need to run the database schema provided by PowerDNS.

#Creating Zones with pdnsutil

#create-zone

pdnsutil is the main administration tool for Authoritative. Your first zone is created with pdnsutil create-zone, with the zone name and two authoritative name servers as arguments:

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

pdnsutil list-zone shows all records in the zone. At the start, it contains the SOA and two NS records — enough for a valid zone. Because we use default-soa-content from episode 3, the SOA is automatically created with an initial serial.

#add-record

Add A and AAAA records for your servers and applications:

pdnsutil add-record example.com ns1 A 192.0.2.10
pdnsutil add-record example.com ns2 A 192.0.2.20
pdnsutil add-record example.com www A 192.0.2.30
pdnsutil add-record example.com www AAAA 2001:db8::30

The general syntax is pdnsutil add-record ZONE NAME TYPE CONTENT. For priority records like MX, add the priority number before the content.

#list-zone and check-zone

Always inspect the results:

pdnsutil list-zone example.com
pdnsutil check-zone example.com

pdnsutil check-zone validates the zone structure — for example, making sure SOA and NS exist and no CNAME violates the rules. If the output says Checked 4 records of 'example.com', 0 errors, your zone is healthy.

#Editing and Deleting Records

#edit-zone

To change many records at once, use the interactive editor:

pdnsutil edit-zone example.com

The editor opens all records in the classic zone format. After saving, PowerDNS writes them back to the database. Be careful with the serial: in manual mode, you must bump the serial yourself so changes get transferred to the secondary.

#delete-rrset

Deleting an entire RRset for a name:

pdnsutil delete-rrset example.com www A

pdnsutil delete-rrset example.com www A deletes all A records for www.example.com. After the change, run pdns_control notify example.com if there's a secondary that needs immediate synchronization — a topic for episode 9.

#Verification from the Client Perspective

#dig Against Authoritative

Test from another machine, or directly in the lab by pointing the server explicitly:

dig @192.0.2.10 example.com A +noall +answer +comments
dig @192.0.2.10 www.example.com AAAA +short

Note the aa flag on the first answer — proof that PowerDNS Authoritative is answering as the authority, not from cache. If you don't see aa, the query was likely forwarded to another daemon like the Recursor.

dig @127.0.0.1 -p 53 example.com SOA +short

#Conclusion

Episode 5 takes you from being a "DNS observer" to an "Authoritative operator": choosing a backend, creating zones with pdnsutil create-zone, filling them with records, validating with check-zone, and proving the answers via the aa flag in dig.

Key takeaways:

• The backend determines where data is stored; choose gsqlite3 for learning and gmysql or lmdb for scale.
• pdnsutil create-zone followed by add-record is the most common zone-creation cycle.
• pdnsutil check-zone must be run before a zone is considered healthy.
• Authoritative answers are marked with the aa flag — if it doesn't appear, the query isn't reaching the right daemon.
• pdns_control notify is needed to inform the secondary after manual changes.

In episode 6, we'll cover PowerDNS Recursor basics — configuring recursor.yml for listen addresses, local zones, and forward zones, plus caching mechanisms from packet cache and record cache to negative caching and TTL settings.