AdGuard Home
DNS Shield
A practical guide for building a network-wide DNS filtering layer with AdGuard Home.
The goal is not to replace a firewall, but to block unwanted DNS destinations before clients connect to them.
|
Router / Firewall
|
AdGuard Home DNS server
|
LAN clients: PC · notebook · phone · TV · NAS · IoT
The clean design is simple: the router advertises AdGuard Home as DNS through DHCP,
AdGuard Home filters DNS requests, and the router firewall prevents clients from bypassing it.
AdGuard Home is a DNS filtering server, not a firewall replacement
What it does well
- Blocks ads and trackers at DNS level
- Blocks known malware and phishing domains
- Filters telemetry and unwanted domains
- Shows query logs per client
- Supports custom blocklists and allowlists
- Can provide local DNS rewrites
- Can protect all devices that use it as DNS
What it cannot replace
- It does not replace router firewall rules
- It does not inspect encrypted HTTPS content
- It does not block direct IP connections
- It does not replace antivirus or EDR software
- It cannot reliably remove all in-app or video ads
- It cannot stop clients that bypass DNS unless the router enforces DNS
Best practical protection stack
+
AdGuard Home DNS filtering
+
OS and browser updates
+
safe browser habits
+
strong passwords / MFA
+
regular backup strategy
and good endpoint security. Treat it as a DNS shield, not as a packet firewall.
AdGuard Home vs AdGuard DNS vs AdGuard client apps
AdGuard Home
Self-hosted DNS filtering server for your LAN. It runs on a NAS, Linux server, Raspberry Pi,
mini PC, Docker host, Proxmox VM/LXC, or TrueNAS Apps.
AdGuard DNS
Public or private DNS service operated by AdGuard. Useful when you do not want to self-host,
or when you need protection for roaming devices outside your home network.
AdGuard Apps / Extensions
Endpoint-level filtering for Windows, macOS, Android, iOS, and browsers. These can filter more than DNS,
but they protect only the device where they are installed.
Safe installation order
Always-on device with static IP: NAS, mini PC, VM, LXC, Raspberry Pi, or server.
Linux service, Docker container, TrueNAS App, or another supported platform.
Router advertises AdGuard Home IP as the DNS server for LAN clients.
Block or redirect direct external DNS so clients cannot bypass filtering.
Pre-flight checklist
- Assign a static IP to the AdGuard Home host.
- Make sure no other service already uses port 53.
- Decide whether the router or AdGuard Home will provide DHCP.
- Do not use a public DNS server as a secondary DNS if strict filtering is required.
- Plan IPv6 DNS as well, otherwise clients may bypass filtering over IPv6.
- Do not expose port 53 or the admin interface to the public internet.
Check whether port 53 is already used
sudo ss -lnup | grep ‘:53’
If another DNS service is already bound to port 53, AdGuard Home will not be able to start its DNS listener.
Common examples are systemd-resolved, dnsmasq, unbound, named, or an existing router/NAS DNS service.
Native Linux installation
Official service method
Download the official release archive for your CPU architecture, unpack it, enter the
AdGuardHome directory, and install the binary as a service.
cd AdGuardHome
sudo ./AdGuardHome -s install
sudo ./AdGuardHome -s status
Open the initial setup wizard:
# Example:
http://192.168.1.10:3000
Service control
sudo ./AdGuardHome -s stop
sudo ./AdGuardHome -s restart
sudo ./AdGuardHome -s status
sudo ./AdGuardHome -s uninstall
Firewall ports for basic LAN use
53/tcp Plain DNS fallback / large DNS replies
3000/tcp Initial setup wizard
After setup, the web interface may use another port depending on your configuration.
Keep admin access limited to the trusted management LAN.
Docker: bridge mode vs host mode
Minimal bridge-mode container
This is a clean start for plain DNS filtering. It maps only the ports needed for DNS and the first setup wizard.
sudo mkdir -p /opt/adguardhome/conf
docker run –name adguardhome \
–restart unless-stopped \
-v /opt/adguardhome/work:/opt/adguardhome/work \
-v /opt/adguardhome/conf:/opt/adguardhome/conf \
-p 53:53/tcp \
-p 53:53/udp \
-p 3000:3000/tcp \
-d adguard/adguardhome
Host networking mode
Use host networking when you need AdGuard Home to see original client IP addresses more reliably
or when you want to run AdGuard Home DHCP inside Docker.
–network host \
–restart unless-stopped \
-v /opt/adguardhome/work:/opt/adguardhome/work \
-v /opt/adguardhome/conf:/opt/adguardhome/conf \
-d adguard/adguardhome
With --network host, Docker port mapping with -p is not used.
This mode is Linux-host oriented and is not the same as Docker Desktop networking on Windows/macOS.
Optional Docker Compose file
adguardhome:
image: adguard/adguardhome:latest
container_name: adguardhome
restart: unless-stopped
volumes:
– /opt/adguardhome/work:/opt/adguardhome/work
– /opt/adguardhome/conf:/opt/adguardhome/conf
ports:
– “53:53/tcp”
– “53:53/udp”
– “3000:3000/tcp”
Extended ports only when needed
443/tcp HTTPS / DoH
443/udp HTTP/3 / QUIC-related HTTPS use
853/tcp DNS-over-TLS
853/udp DNS-over-QUIC
5443/tcp DNSCrypt
5443/udp DNSCrypt
67/udp DHCP server
68/udp DHCP client/server traffic
Do not expose this blindly
Do not publish DNS or the admin panel to the public internet without access restrictions,
rate limiting, encryption, and a clear reason. An open recursive DNS resolver is a security problem.
When Linux already listens on port 53
On many Linux systems, systemd-resolved listens on 127.0.0.53:53.
If Docker or AdGuard Home cannot bind to port 53, either disable the stub listener or move AdGuard Home to a different design.
sudo tee /etc/systemd/resolved.conf.d/adguardhome.conf >/dev/null <<‘EOF’
[Resolve]
DNS=127.0.0.1
DNSStubListener=no
EOF
sudo mv /etc/resolv.conf /etc/resolv.conf.backup
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl reload-or-restart systemd-resolved
make sure name resolution still works after the change.
TrueNAS SCALE / Community Edition notes
Recommended modern path
Available Applications
Search: AdGuard Home
Install
Set persistent storage
Set networking / ports
Start the application
NAS-specific cautions
- Use a static IP for the NAS or for the app endpoint.
- Make sure port 53 is not already used by the NAS.
- Keep configuration and work data on persistent storage.
- Restrict the admin interface to the LAN or management VLAN.
- After setup, point router DHCP DNS to AdGuard Home.
Older plugin-style installations are not a good target for a new deployment. Prefer current TrueNAS Apps,
a dedicated VM, Docker/container host, or a small always-on Linux system.
Make clients actually use AdGuard Home
Recommended DHCP DNS design
AdGuard Home IP: 192.168.1.10
DHCP DNS option: 192.168.1.10
In the router DHCP server, advertise only the AdGuard Home IP as DNS.
Do not add 1.1.1.1, 8.8.8.8, or another public resolver as secondary DNS
if strict filtering is required.
Redundancy done correctly
If you want DNS redundancy, use two AdGuard Home instances:
Secondary DNS: 192.168.1.11
A public secondary DNS resolver is not a fallback for filtering. It is a bypass path.
DNS 1 / DNS 2 vs Bootstrap DNS
Keep these layers separate. Router DNS 1 and DNS 2 are the DNS servers
advertised to LAN clients. For filtering, they should point to AdGuard Home.
Bootstrap DNS is different: AdGuard Home uses it only to resolve the hostname of an encrypted
upstream resolver such as dns.quad9.net.
DNS 1: 192.168.1.10
DNS 2: empty or 192.168.1.11
AdGuard Home upstream DNS examples:
ISP DNS: use your provider resolver if you trust it
Quad9 plain DNS: 9.9.9.9 / 149.112.112.112
Quad9 DNS-over-HTTPS: https://dns.quad9.net/dns-query
Quad9 DNS-over-TLS: tls://dns.quad9.net
AdGuard Home Bootstrap DNS for Quad9 hostname resolution:
9.9.9.9
149.112.112.112
In other words: clients should ask AdGuard Home. AdGuard Home can then ask your ISP DNS, Quad9,
or another trusted upstream resolver. If you use a hostname-based encrypted upstream, Bootstrap DNS gives
AdGuard Home a plain resolver to resolve that upstream hostname before the encrypted connection is established.
IPv6 note
If IPv6 is enabled, configure IPv6 DNS advertisement as well. Many clients prefer IPv6 DNS if it is available.
If your router advertises an ISP IPv6 DNS server, clients may bypass AdGuard Home even when IPv4 DHCP is correct.
Block or redirect bypass attempts
Mode A · Block external plain DNS
Cleaner and more transparent. Clients must use the DNS server provided by DHCP.
Devices that try external port 53 directly will fail.
Block LAN -> WAN on TCP/UDP 53
Keep AdGuard Home -> upstream DNS allowed
Mode B · Redirect plain DNS
More forceful. Plain DNS requests to external servers are transparently redirected to AdGuard Home.
Useful for IoT devices and hardcoded DNS clients, but it can make troubleshooting less obvious.
Router rewrites destination to 192.168.1.10:53
AdGuard Home receives the DNS query
MikroTik example · block external plain DNS
Replace the LAN subnet, interface list and AdGuard Home IP with your real values.
Rule order matters: put these after established/related accepts and before broad internet allow rules.
add chain=forward action=accept src-address=192.168.1.0/24 dst-address=192.168.1.10 protocol=udp dst-port=53 comment=”Allow LAN DNS to AdGuard UDP”
add chain=forward action=accept src-address=192.168.1.0/24 dst-address=192.168.1.10 protocol=tcp dst-port=53 comment=”Allow LAN DNS to AdGuard TCP”
add chain=forward action=drop src-address=192.168.1.0/24 out-interface-list=WAN protocol=udp dst-port=53 comment=”Block external DNS UDP”
add chain=forward action=drop src-address=192.168.1.0/24 out-interface-list=WAN protocol=tcp dst-port=53 comment=”Block external DNS TCP”
MikroTik example · redirect plain DNS to AdGuard Home
This redirects plain TCP/UDP 53 DNS from LAN clients to AdGuard Home. Do not redirect the AdGuard Home server itself.
add chain=dstnat action=dst-nat src-address=192.168.1.0/24 dst-address=!192.168.1.10 protocol=udp dst-port=53 to-addresses=192.168.1.10 to-ports=53 comment=”Redirect LAN DNS UDP to AdGuard”
add chain=dstnat action=dst-nat src-address=192.168.1.0/24 dst-address=!192.168.1.10 protocol=tcp dst-port=53 to-addresses=192.168.1.10 to-ports=53 comment=”Redirect LAN DNS TCP to AdGuard”
They must be managed through endpoint policy, browser policy, firewall deny lists, or network controls.
Blocklists, allowlists and local DNS
Blocklist strategy
- Start with the default AdGuard DNS filter.
- Add only one or two trusted privacy/security lists.
- Observe Query Log for several days.
- Use allowlist rules for broken services.
- Avoid random huge blocklists unless you are ready to maintain exceptions.
Common custom filtering rules
||example-tracker.com^
@@||trusted-example.com^
badhost.example.com
Custom rules are useful for DNS filtering. For local hostnames, prefer DNS rewrites instead of mixing
local infrastructure into random filter lists.
DNS rewrites for local names
nas.home.arpa -> 192.168.1.2
server.home.arpa -> 192.168.1.10
printer.home.arpa -> 192.168.1.50
Use a real local domain such as home.arpa. Avoid relying on .local
for normal DNS because it is commonly used by mDNS/Bonjour.
Query log and privacy
Query logs are excellent for debugging, but they also reveal browsing metadata.
Set log retention intentionally and restrict access to the admin panel.
Choose upstream resolvers deliberately
Plain upstream examples
Quad9: 9.9.9.9 / 149.112.112.112
Cloudflare: 1.1.1.1 / 1.0.0.1
Google: 8.8.8.8 / 8.8.4.4
ISP DNS can be perfectly valid if you trust your provider and get good latency.
Quad9 is a strong option when you want a privacy-focused upstream with threat blocking.
Quad9 encrypted upstream examples
https://dns.quad9.net/dns-query
DNS-over-TLS:
tls://dns.quad9.net
Bootstrap DNS:
9.9.9.9
149.112.112.112
Bootstrap DNS is only used to resolve the hostname of the encrypted upstream resolver.
The actual DNS queries then go through the configured upstream transport.
Trust model
Choose an upstream resolver based on latency, reliability, DNSSEC behavior, filtering policy,
privacy policy and your location. The resolver still sees the DNS queries sent by AdGuard Home,
unless you run your own recursive resolver such as Unbound.
Recommended wording for DNS 1 / DNS 2 settings
When configuring a router, DNS 1 and DNS 2 should describe the DNS server that clients will use.
When configuring AdGuard Home, upstream DNS and Bootstrap DNS describe what AdGuard Home itself will use.
Do not mix these two layers.
DNS 1: 192.168.1.10
DNS 2: empty or second AdGuard Home instance
AdGuard Home upstream DNS:
Option A: ISP DNS resolver
Option B: Quad9 plain DNS 9.9.9.9 / 149.112.112.112
Option C: Quad9 DoH https://dns.quad9.net/dns-query
Option D: Quad9 DoT tls://dns.quad9.net
AdGuard Home Bootstrap DNS for Quad9 DoH/DoT:
9.9.9.9
149.112.112.112
Confirm that clients are really using AdGuard Home
From any client
dig @192.168.1.10 example.org
Then open AdGuard Home → Query Log and confirm that the request appears under the correct client.
Check client DNS configuration
ipconfig /all
# Linux with systemd-resolved
resolvectl status
# Router-side check
Watch AdGuard Home Query Log while a client opens websites.
Temporary block test
Add this custom filtering rule temporarily, query the domain, confirm that it is blocked, then remove the rule:
This proves that the client uses AdGuard Home and that DNS filtering is enabled.
When AdGuard Home should provide DHCP
Use router DHCP when possible
For most networks, the router should remain the DHCP server. It already understands VLANs,
gateway options, static leases, firewall zones and routing.
Use AdGuard DHCP only when needed
AdGuard Home can provide DHCP, but only use it if your router cannot advertise a custom DNS server
or if you explicitly want AdGuard Home to manage leases.
If AdGuard Home becomes DHCP server, disable DHCP on the router for that LAN/VLAN.
Typical problems and quick checks
Clients do not appear in Query Log
- Client is not using AdGuard Home as DNS.
- Router DHCP still advertises router or public DNS.
- IPv6 DNS bypass is active.
- Docker bridge mode hides original source IPs.
- AdGuard Home listens on the wrong interface.
Websites or apps break
- Open Query Log and find blocked domains at the exact timestamp.
- Temporarily disable one blocklist at a time.
- Add a narrow allowlist rule instead of disabling protection globally.
- Avoid stacking too many aggressive lists.
Port 53 bind error
sudo systemctl status systemd-resolved
sudo systemctl status dnsmasq
sudo systemctl status unbound
Smart TV / IoT bypass
Many IoT devices try hardcoded DNS or encrypted DNS. Use router-side DNS enforcement,
IoT VLANs, and explicit firewall policy. Do not rely only on DHCP settings.
Minimal working setup
Linux service
cd AdGuardHome
sudo ./AdGuardHome -s install
sudo ./AdGuardHome -s status
# Open:
http://SERVER_IP:3000
Docker minimal
docker run –name adguardhome \
–restart unless-stopped \
-v /opt/adguardhome/work:/opt/adguardhome/work \
-v /opt/adguardhome/conf:/opt/adguardhome/conf \
-p 53:53/tcp \
-p 53:53/udp \
-p 3000:3000/tcp \
-d adguard/adguardhome
Router DHCP target
Primary DNS / DNS 1: 192.168.1.10
Secondary DNS / DNS 2: empty or second AdGuard Home instance
Do not use a public resolver here if strict filtering is required:
Primary DNS / DNS 1: 192.168.1.10
Secondary DNS / DNS 2: 1.1.1.1
AdGuard Home upstream can still use:
ISP DNS resolver
Quad9 plain DNS: 9.9.9.9 / 149.112.112.112
Quad9 Bootstrap DNS: 9.9.9.9 / 149.112.112.112