Learning DNS - PowerDNS Recursor Basics

#Introduction

If the Authoritative is the "data owner", the Recursor is the "travel agent" that finds that data for you. PowerDNS Recursor receives queries from clients, resolves them via root hints or forwarders, then stores the results in cache so subsequent queries are nearly free.

Episode 6 covers recursor.yml configuration: where to listen, how to handle local zones and forward zones, and the caching layers that let the recursor serve thousands of queries per second with limited resources.

#Basic recursor.yml Configuration

#Listen Address and Access

The /etc/powerdns/recursor.yml file controls all behavior. The first two things you must define: the address to listen on and who is allowed to query.

listen-addresses:
  - 127.0.0.1
  - 192.0.2.53
allow-from:
  - 192.0.2.0/24
  - 127.0.0.0/8
threads: 4

allow-from is the list of subnets allowed to use this recursor. Don't expose the recursor to the internet without an ACL — it becomes a reflector for amplification attacks. This setting is the first line of defense.

#Basic Verification

After restart, test from the client side:

sudo systemctl restart pdns-recursor
dig @127.0.0.1 example.com A +short

The recursor ships with built-in root hints, so without forwarders it can already resolve names from the internet. To see its statistics:

rec_control get uptime
rec_control get qps

#Local Zones and Forward Zones

#Local Zones: Answers Without Querying the Internet

The recursor can answer local zones itself, useful for internal environments. Local zones are defined with a zone file or inline:

local-zones:
  - name: internal.example.com
    type: native
    file: /etc/powerdns/local/internal.example.com.zone
  - name: lan.example.com
    type: master
    file: /etc/powerdns/local/lan.example.com.zone

#Forward Zones: Forwarding to Another Server

If your organization has an internal resolver or Authoritative for certain domains, the recursor can forward queries for those domains without doing a full resolution:

forward-zones:
  - zone: example.org
    addresses:
      - 192.0.2.10
  - zone: corp.local
    addresses:
      - 10.0.0.53
      - 10.0.0.54

With forward-zones, all queries for example.org are forwarded directly to 192.0.2.10 instead of being looked up from the root. This pattern is common with Active Directory, internal resolvers, or split-horizon DNS.

#Caching Mechanisms

#Packet Cache and Record Cache

The recursor uses two main caches:

• Packet cache: stores complete answers matching questions, so identical queries can be answered without recomputation. Very fast.
• Record cache: stores individual records with their TTLs, used to assemble new answers from combinations of records.

rec_control get packetcache-size
rec_control get max-cache-entries

These parameters can be set in recursor.yml. We'll discuss tuning them for performance in episode 19.

#Negative Caching and TTL

When a name doesn't exist, the negative answer (NXDOMAIN) is also cached according to the SOA's negative TTL. This prevents clients and upstream from being flooded with queries for names that simply don't exist.

max-negative-ttl: 3600
cache-ttl: 20

max-negative-ttl limits how long "does not exist" answers are stored. cache-ttl is the maximum TTL used for records from zones without an explicit TTL. Understanding TTL is key: a long TTL speeds things up and relieves the server, but slows down the propagation of changes.

#Watching the Recursor Work

#Statistics and Cache Dump

To prove caching works, query twice, then compare response times and statistics:

dig @127.0.0.1 example.com A +noall +stats | grep 'Query time'
dig @127.0.0.1 example.com A +noall +stats | grep 'Query time'
rec_control get cache-hits

On the second query, the response time is usually much lower because the answer comes from the packet cache. The cache-hits value in rec_control get cache-hits shows how often the cache answers without touching the internet — an important health metric we'll revisit in episode 19.

rec_control dump-cache /tmp/rec-cache.txt

#Conclusion

Episode 6 turns your Recursor into a genuinely useful resolver: listening with a safe ACL, answering local zones, forwarding certain domains, and storing answers in a measurable set of caching layers.

Key takeaways:

• allow-from must be restricted; an open recursor without an ACL is a DDoS amplification weapon.
• Local zones answer internal names without touching the internet.
• Forward zones route certain domains to an internal resolver or Authoritative.
• The packet cache answers identical queries; the record cache assembles new answers from cached records.
• Negative caching prevents NXDOMAIN floods; TTL controls speed versus data freshness.
• rec_control get cache-hits is the health barometer of the recursor.

In episode 7, we'll cover dnsdist basics — the DNS load balancer concept with frontends and backend pools, initial newServer configuration, load balancing policies like leastOutstanding and roundrobin, plus ACLs and the web dashboard.