How to Run an Authoritative DNS Server on Raspberry Pi with an OpenClaw Agent

Search for "Raspberry Pi DNS server" and you will find dozens of Pi-hole guides. Pi-hole is a recursive resolver with an ad-blocking filter list. It forwards queries upstream to Cloudflare or Google and blocks domains on a deny list before returning answers. It does not hold any zone data of its own.

A recursive resolver chases referrals. When a client asks for app.example.com, a recursive resolver starts at the root servers, walks through the .com TLD, and eventually reaches the authoritative server that holds the actual answer. It caches results to speed up repeat lookups, but it never owns the records.

An authoritative DNS server is the source of truth for a domain. It holds the zone files, the SOA record, the A and AAAA records, the MX entries, TXT records for SPF and DKIM, and everything else that defines how your domain resolves. When a recursive resolver reaches your authoritative server, it gets a definitive answer, not a cached copy from somewhere else.

The practical difference matters for anyone running their own domain. Pi-hole filters what your household can reach. A recursive resolver speeds up lookups by caching. An authoritative server publishes your records to the world. They can coexist on the same network, but they solve different problems.

This guide focuses on the authoritative side: running BIND9 on a Raspberry Pi so your domain's DNS records live on hardware you control, then using an OpenClaw agent to manage those records without logging into SSH every time something changes.

The hardware bar is low. BIND9 serving authoritative records for a handful of zones uses almost no CPU. A Raspberry Pi 4 with 2GB of RAM handles it comfortably, and a Pi 5 with 4GB or 8GB gives you headroom for logging, monitoring, and the OpenClaw agent running alongside it.

A wired Ethernet connection is not optional for a DNS server. Wi-Fi adds latency jitter and drops that make your zone unreliable for external resolvers trying to reach it. Plug in the cable.

Use a USB SSD instead of an SD card if this Pi will run for months without attention. SD cards degrade under sustained write loads, and DNS query logging generates a steady stream of writes. A 120GB SATA SSD on a USB 3.0 adapter costs less than replacing corrupted SD cards twice a year.

On the software side:

• Operating system: Raspberry Pi OS 64-bit (Bookworm or later). The 32-bit version works but limits memory addressing and has fewer upstream packages tested.
• BIND9: Available in the standard Raspberry Pi OS repositories. sudo apt install bind9 bind9-utils bind9-doc pulls everything you need.
• OpenClaw: Requires Node.js 24 and a 64-bit OS. Follow the installer at docs.openclaw.ai/install/raspberry-pi. The Pi 5 with 8GB is the recommended baseline for running OpenClaw comfortably alongside other services.
• A public IP or port forward: If you want external resolvers to reach your authoritative server, port 53 (TCP and UDP) must be reachable from the internet. Most home ISPs allow this but some block port 53. Check before investing time in the setup.

One thing to confirm before proceeding: your domain registrar must support setting custom nameservers with glue records. Without glue records pointing your NS hostnames to your Pi's IP address, recursive resolvers cannot find your authoritative server. Every major registrar (Namecheap, Cloudflare Registrar, Porkbun, Gandi) supports this.

Give your DNS agent a workspace your whole team can reach

Store zone snapshots, validation logs, and anomaly reports where both the OpenClaw agent and your team can access them. generous storage, no credit card, MCP endpoint ready for agent writes.

Start 14-Day Trial

Once BIND9 is installed, the default configuration runs as a caching recursive resolver. Turning it into an authoritative-only server requires three changes: disabling recursion, declaring your zones, and writing the zone files.

Start with /etc/bind/named.conf.options. The critical setting is recursion no;. This tells BIND to refuse recursive queries and only answer for zones it is authoritative for. Without this, your Pi becomes an open resolver, which is both a security risk and an invitation for DNS amplification attacks.

Other settings worth adjusting in the options block: set allow-transfer to the IP addresses of any secondary nameservers, and set listen-on to your Pi's Ethernet interface address rather than any. Rate limiting with rate-limit { responses-per-second 10; }; helps absorb junk traffic without saturating the Pi's network stack.

Next, declare the zone in /etc/bind/named.conf.local:

zone "example.com" {
    type primary;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 198.51.100.2; };
};

Then create the zone file at /etc/bind/zones/db.example.com. The SOA record is the header of the zone, and getting the serial number format right matters for secondary servers picking up changes. Use the YYYYMMDDNN convention, where NN is a two-digit revision counter that increments with each edit on a given day.

A minimal zone file for a domain with a web server and mail server looks like this:

$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
            2026051801  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            86400       ; Negative Cache TTL
        )

@       IN  NS  ns1.example.com.
@       IN  NS  ns2.example.com.
@       IN  A   203.0.113.10
www     IN  A   203.0.113.10
@       IN  MX  10 mail.example.com.
mail    IN  A   203.0.113.20
@       IN  TXT "v=spf1 mx -all"

Before restarting BIND, validate the configuration and zone file. named-checkconf catches syntax errors in the config files. named-checkzone example.com /etc/bind/zones/db.example.com validates the zone file structure, including SOA serial format and record consistency. Only reload after both commands pass cleanly: sudo systemctl reload named.

Test from another machine with dig @your-pi-ip example.com A. You should see your A record in the ANSWER section with the aa (authoritative answer) flag set. If the flag is missing, recursion is still enabled or the zone is not loading correctly.

An authoritative DNS server is simple to set up and annoying to maintain. Zone files need serial numbers incremented on every edit. TTL values need adjusting when you are migrating services. New subdomains get added, old ones get removed, and every change requires a syntax check and a reload. Miss the serial increment and secondary servers never pick up the update. Forget to validate and a typo in a zone file takes down resolution for the entire domain.

This is where the OpenClaw agent earns its keep. OpenClaw runs on the same Pi as BIND9, using cloud-hosted language models via API. It does not need a powerful local GPU. The Pi acts as a gateway, the models run remotely, and the agent executes shell commands locally.

A practical DNS management agent handles a specific set of tasks:

• Zone file edits: When you tell the agent to add a new A record or update an MX entry, it reads the current zone file, makes the change, increments the SOA serial number, runs named-checkzone to validate, and reloads BIND only if validation passes. No manual SSH required.
• Record audits: The agent can parse the zone file periodically and compare it against expected records. If a record is missing or a TTL is set to an unexpected value, it flags the discrepancy rather than silently fixing it.
• Query log monitoring: BIND9 writes query logs to /var/log/named/queries.log when logging is enabled. The agent can tail this log and flag patterns worth investigating, like a sudden spike in NXDOMAIN responses (which could indicate a misconfigured client or a subdomain enumeration scan) or queries for record types you do not serve.
• Reload coordination: After any zone change, the agent runs named-checkconf and named-checkzone, then executes rndc reload only on success. It captures the output of each step for the audit trail.

The agent does not replace BIND. It does not sit in the query path or proxy DNS traffic. It manages the files BIND reads and watches the logs BIND writes. That separation is important: if the agent crashes, DNS resolution continues normally because BIND is still running with the last valid zone file.

Because OpenClaw's specific skill and tool invocations evolve as the project matures, confirm the exact command syntax against the current OpenClaw documentation rather than relying on hardcoded examples. The pattern stays the same: the agent reads files, runs shell commands, and writes results back.

Zone files are small text files, but they are surprisingly easy to lose track of. If your only copy lives on the Pi's filesystem and the SD card fails, you are restoring from memory or from whatever backup you remembered to take last month.

The straightforward answer is version control. Push zone files to a Git repository and you get history, diffs, and rollback. But Git repos do not solve the access problem. When a colleague needs to review a DNS change at 2am, they need a link they can open in a browser, not a clone command and SSH key.

Local backups to a USB drive or NFS share work for disaster recovery but create the same access gap. Cloud storage services like S3 or Google Drive add browser access but lack the structured audit trail that DNS operations need.

A Fastio workspace fits the gap between Git and cloud storage for this use case. The OpenClaw agent pushes zone file snapshots, validation logs, and query anomaly reports to a shared workspace using the Fastio MCP server. Both the agent and your team can reach the same files. The agent writes through the API or MCP endpoint. Humans open a browser and see the current zone file, the last validation result, and the full change history, all without needing SSH access to the Pi.

The free tier gives you 50GB of storage, 5,000 API credits per month, and five workspaces with no credit card and no expiration. For a DNS management workflow, a single workspace with folders for zone snapshots, validation logs, and anomaly reports is more than enough.

When the agent finishes a zone change, it can push the updated zone file, the named-checkzone output, and a timestamped changelog entry to the workspace in one operation. If something goes wrong at 2am, anyone with workspace access can pull the last known good zone file and restore it, even if they have never touched the Pi before.

Intelligence Mode auto-indexes uploaded files for semantic search. This means you can ask questions like "when did we last change the MX record for example.com?" and get an answer with citations pointing to the specific zone snapshot, without manually searching through file names and dates.

A DNS server that answers correctly today can drift silently. TTLs expire, upstream registrar changes propagate, and secondary nameservers fall out of sync. The value of running an agent alongside BIND is not just automated edits. It is continuous verification that the server is doing what you think it is doing.

The simplest health check is a periodic dig against your own server from the Pi itself. If dig @127.0.0.1 example.com A +short returns the expected IP, the zone is loading and BIND is responding. If it returns nothing or an error, BIND is either down or the zone file is broken. The agent can run this check every few minutes and write the result to the workspace log.

For deeper monitoring, enable BIND9's query logging and have the agent watch for patterns:

• NXDOMAIN spikes: A sudden increase in queries for nonexistent subdomains often means a misconfigured application or a reconnaissance scan probing for valid hosts. The agent flags the spike and writes the top queried names to the audit log.
• SERVFAIL responses: These indicate that BIND tried to process a query but failed. On an authoritative-only server, this usually means a broken zone file slipped past validation. The agent should check the zone file immediately when SERVFAIL rates climb.
• Transfer failures: If you run secondary nameservers, failed zone transfers (AXFR or IXFR timeouts) mean your secondaries are serving stale data. The agent checks transfer status and alerts when the secondary's SOA serial falls behind the primary's.
• Query volume anomalies: A Pi handling DNS for a small domain might see a few hundred queries per hour. A sudden jump to thousands per second, without a corresponding change in your services, likely means someone is using your server as a reflector or running a subdomain brute-force. Rate limiting in BIND catches most of this at the packet level, but the agent provides the visibility layer.

The agent writes anomaly reports to the shared workspace rather than just printing them to a local log file that nobody reads. When paired with Fastio webhooks, workspace uploads can trigger downstream notifications, like a Slack message or an email, so the right person sees the alert without polling a dashboard.

For external validation, run a dig from a machine outside your network to confirm that recursive resolvers can reach your authoritative server and get the correct answer. If internal checks pass but external queries fail, the problem is likely a firewall rule, a missing glue record at the registrar, or an ISP blocking port 53.