How to Set Up AdGuard Home on Raspberry Pi for OpenClaw Agent DNS Security

Only 21% of executives report complete visibility into agent permissions, tool usage, or data access patterns, according to a 2026 briefing from the AIUC-1 Consortium developed with Stanford's Trustworthy AI Research Lab. That number means four out of five organizations running AI agents cannot see what those agents are doing on the network.

An OpenClaw agent on a Raspberry Pi has access to the shell, the filesystem, and outbound HTTP. Every time it calls an API, downloads a dependency, or checks a remote endpoint, it starts with a DNS query. DNS is the first observable signal of what your agent is actually doing, and it costs almost nothing to capture.

Firewall rules require you to predict which IP addresses to block. DNS filtering works at the domain level. You see the human-readable name of every service your agent contacts, and you can block entire categories of domains without maintaining IP lists that change weekly.

AdGuard Home turns a Raspberry Pi into a network-wide DNS filtering server. It logs every query from every device, including AI agents, and lets you block unwanted domains before the connection even starts. This guide covers the full setup: installing AdGuard Home on a Pi, configuring encrypted upstream resolvers, and using the dashboard to monitor what your OpenClaw agent is actually reaching on the network.

Most Raspberry Pi DNS filtering guides point to Pi-hole. It has millions of users, an active community, and extensive filter list curation. For the specific job of monitoring AI agent DNS activity with encrypted upstream queries, AdGuard Home requires fewer components.

The biggest difference is encrypted DNS support. AdGuard Home handles DNS-over-HTTPS (DOH), DNS-over-TLS (DOT), and DNS-over-QUIC (DOQ) natively. You paste a DOH URL into the dashboard and it works. Pi-hole needs an external tool like Unbound or cloudflared to get the same result. For an agent making calls to external APIs, encrypting those DNS queries means your ISP sees the connection to Cloudflare or Quad9 but not the individual domains the agent resolves.

Per-client filtering is the second reason. AdGuard Home lets you apply different rules to different client IPs out of the box. If your OpenClaw agent runs at 192.168.1.50, you can set stricter filters for that address without affecting your phone or laptop. Pi-hole added client-group management in later versions, but the setup involves more steps.

On resource usage, AdGuard Home idles at 30 to 50 MB of RAM compared to Pi-hole's 60 to 100 MB. On a Raspberry Pi that also runs an OpenClaw agent, that 30 to 50 MB difference leaves more headroom for the agent's own workload.

The install is simpler too. AdGuard Home ships as a single binary with zero dependencies. Pi-hole pulls in PHP, lighttpd, and its FTL engine. Neither approach is wrong, but fewer moving parts means fewer things to debug when something breaks at 2am.

You need a Raspberry Pi 4 or 5 running Raspberry Pi OS Lite (or any Debian-based Linux), a wired Ethernet connection, and a static IP address assigned to the Pi. Wi-Fi works but adds latency to every DNS query on your network, which becomes noticeable when the Pi handles lookups for dozens of devices.

Set a static IP through your router's DHCP reservation settings. This keeps the address stable without editing config files on the Pi itself.

Download and install

SSH into your Pi and download the latest AdGuard Home release for ARM from the official GitHub repository at github.com/AdguardTeam/AdGuardHome. Pick the architecture that matches your OS: arm64 for 64-bit Raspberry Pi OS on Pi 4 or 5, armv7 for 32-bit, or armv6 for Pi Zero.

wget https://github.com/AdguardTeam/AdGuardHome/releases/latest/download/AdGuardHome_linux_arm64.tar.gz
tar -xzf AdGuardHome_linux_arm64.tar.gz
cd AdGuardHome
sudo ./AdGuardHome -s install

This registers AdGuard Home as a system service that starts automatically on boot.

Run the setup wizard

Open a browser and go to http://<your-pi-ip>:3000. The first-run wizard walks through four steps: choosing the network interfaces to listen on, creating an admin username and password, configuring initial DNS settings, and reviewing your selections.

After the wizard finishes, the dashboard moves to port 80 by default. You can change this later in the settings if port 80 conflicts with another service on the Pi.

Point your network at the Pi

The fastest way to cover every device is to change the DNS server setting in your router's DHCP configuration to the Pi's IP address. The next time each device renews its lease, it starts sending DNS queries through AdGuard Home.

If you want to test before going network-wide, change DNS on a single device first. On macOS, go to System Settings then Network then DNS. On Linux, edit /etc/resolv.conf or your NetworkManager connection profile. On Windows, change the adapter's IPv4 DNS properties.

Verify it works

Run a quick check from any terminal on your network:

nslookup example.com <your-pi-ip>

You should see a response from the Pi's IP address. Then check the AdGuard Home dashboard. The query log should show the lookup from your client IP.

Manage the service on the Pi with:

• sudo ./AdGuardHome -s status to check if it is running
• sudo ./AdGuardHome -s restart to reload after config changes
• sudo ./AdGuardHome -s stop to halt the service

By default, AdGuard Home forwards DNS queries to upstream resolvers over plain UDP on port 53. Your ISP can read every domain name your network resolves. For an AI agent that calls external APIs, model endpoints, and package registries, that creates a detailed record of the agent's activity sitting on your ISP's infrastructure.

Encrypted upstream DNS closes that gap. Open the AdGuard Home dashboard, go to Settings, then DNS settings. Under "Upstream DNS servers," replace the defaults with encrypted alternatives.

Reliable choices for upstream DOH and DOT servers:

• https://dns.cloudflare.com/dns-query for Cloudflare's DOH resolver
• tls://dns.google for Google's DOT resolver
• https://dns.quad9.net/dns-query for Quad9's DOH resolver, which includes built-in malware domain blocking

You can list multiple upstream servers. AdGuard Home queries them in parallel and uses the fastest response, or you can switch to a load-balancing mode in the same settings panel.

Under "Bootstrap DNS servers," keep at least one plain DNS entry like 1.1.1.1 or 9.9.9.9. AdGuard Home needs unencrypted DNS to resolve the hostname of your DOH provider on first startup. Without a bootstrap entry, it cannot reach dns.cloudflare.com to start answering queries for everything else.

Click "Test upstreams" to confirm the encrypted connections work, then save. From this point forward, every DNS query leaving the Pi is encrypted. Your ISP sees the connection to Cloudflare or Quad9 but not the individual domain lookups.

For additional protection, enable DNSSEC validation in the same settings panel. DNSSEC prevents spoofing attacks where a malicious actor returns false DNS records for domains your agent is trying to reach.

See what your AI agents are doing on the network

Store DNS audit logs alongside agent output in a free 50 GB workspace. No credit card required, MCP-ready endpoint, and searchable with Intelligence Mode.

Sign Up Free

Once AdGuard Home is filtering your network, open the Query Log tab in the dashboard. Every DNS request from every device appears here with the domain name, the response type, whether it was blocked or allowed, the client IP address, and the timestamp.

To focus on your OpenClaw agent's activity, filter the log by the agent's client IP. If the agent runs on the same Raspberry Pi as AdGuard Home, its queries show up from 127.0.0.1. If the agent runs on a separate device on the same network, filter by that device's local IP.

What to watch for Normal agent behavior produces a predictable set of DNS queries: the LLM provider's API endpoint, any tool or skill endpoints the agent uses, package registries if the agent installs dependencies, and the workspace URL if the agent stores files remotely. These queries form a baseline you can learn in the first few hours of operation.

Suspicious patterns look different:

• Domains you do not recognize, especially in regions unrelated to your agent's configured services
• High-frequency polling to analytics, telemetry, or advertising endpoints that the agent should not need
• Queries to domains associated with cryptocurrency mining pools or command-and-control infrastructure
• Sudden spikes in query volume that correlate with a specific agent task or skill execution

AdGuard Home's custom filtering rules let you respond to what you find. Create rules that block specific domains or domain patterns for just the agent's client IP. You might allow all traffic from your personal devices but block known telemetry domains specifically for the agent.

DNS filtering typically blocks 15% to 40% of queries from connected devices, depending on the blocklist and the device type. An AI agent's block rate depends on which external services it contacts and how aggressive your filter list is. Start with a balanced list like Hagezi Multi Pro (roughly 300,000 domains) and tighten from there based on what the query log reveals.

The query log is also where you spot behavioral changes after updates. If an OpenClaw agent starts resolving new domains after a skill installation or configuration change, the AdGuard Home log captures it immediately. This is the kind of visibility that most organizations running AI agents currently lack.

AdGuard Home stores query logs locally on the Pi's filesystem. For a solo homelab, that is fine. For a team running OpenClaw agents across multiple devices, the logs need to live somewhere more accessible and more durable than an SD card.

Export logs using AdGuard Home's built-in API. The /control/querylog endpoint returns log entries as JSON, filterable by time range and client IP. A scheduled script can pull the agent-specific queries on a regular interval and push them to external storage.

Where you store them depends on your setup. Options include S3 buckets, a NAS share, a Git repository, or a cloud workspace. If your OpenClaw agent already uses Fast.io for file storage and handoff, the same workspace can hold the DNS audit artifacts. Configs, agent output, and DNS logs all sit in one place, which means anyone reviewing agent behavior sees the full picture without switching tools. The free tier covers 50 GB of storage and 5,000 credits per month with no credit card, which handles months of compressed DNS logs from a typical homelab deployment.

For teams that want searchability, enabling Intelligence Mode on a Fast.io workspace makes uploaded logs queryable by meaning. Upload a week of DNS query logs and ask "which external domains did the agent resolve outside of its expected set?" to surface anomalies without writing grep patterns. The same workspace MCP endpoint the agent uses for file operations can push log exports directly, keeping the audit pipeline within the agent's existing workflow.

The broader point is that DNS logs are only useful if someone can actually find and read them. Storing them on the same Pi that might have its SD card fail is not a serious audit strategy. Moving them to a shared workspace, whatever workspace you choose, turns raw DNS data into an audit trail that survives hardware failures and stays accessible to anyone on the team.