MikroTik RouterOS · AdGuard Home · Quad9 DNS Shield

RouterOS DNS Shield
AdGuard Home + Quad9 reference setup

This page describes a clean MikroTik RouterOS configuration where LAN clients use AdGuard Home as their DNS server,
AdGuard Home forwards DNS requests to the MikroTik router, and RouterOS then resolves through Quad9 secure DNS.
The design keeps AdGuard per-client visibility, keeps MikroTik DNS cache / forwarding available, blocks direct DNS
bypass attempts, and limits NAT masquerade only to WAN traffic.

RouterOS DNS
AdGuard Home
Quad9 Secure DNS
DNS Forwarders
DNS Adlist
Firewall Filter
NAT Masquerade

Target design

The clean DNS path

Final architecture

LAN clients
  ↓ DHCP DNS = 192.168.1.10
AdGuard Home
  ↓ Upstream DNS = 192.168.1.1
MikroTik RouterOS DNS cache / resolver / optional DNS adlist / DNS forwarders
  ↓ Upstream DNS = Quad9 secure
Internet DNS resolution

CLIENTS

LAN devices

PCs, phones, NAS devices, smart TVs and IoT devices receive 192.168.1.10
as DNS from DHCP. They do not use the router directly for DNS.

ADGUARD

Per-client DNS filtering

AdGuard Home sees the real client IP addresses, applies blocklists, allowlists and per-client policies,
then forwards allowed queries to MikroTik.

MKT

RouterOS resolver layer

MikroTik provides DNS cache, optional DNS adlist filtering, optional DNS forwarders and Quad9 secure upstream DNS.

Critical rule: If LAN clients use MikroTik directly as DNS, AdGuard will usually see only the router as the client.
To keep AdGuard client visibility, DHCP must give clients the AdGuard Home IP address.

01 · Address plan

Use fixed addresses and explicit interface lists

Router / gateway192.168.1.1

AdGuard Home192.168.1.10

Main LAN192.168.1.0/24

LAN interface listlocal_LAN

WAN interface listISP_WAN

Quad9 secure9.9.9.9

Quad9 secondary149.112.112.112

Why fixed IP addresses matter

DNS infrastructure must not move randomly. The router, AdGuard Home and firewall rules should use stable addresses,
otherwise clients may lose DNS resolution or bypass filtering.

Useful address lists for DNS policy

/ip firewall address-list
add list=dns-clients address=192.168.1.0/24 comment="DNS clients - main LAN"
add list=adguard-dns address=192.168.1.10 comment="AdGuard Home DNS server"
add list=quad9-dns address=9.9.9.9 comment="Quad9 secure DNS"
add list=quad9-dns address=149.112.112.112 comment="Quad9 secure DNS secondary"

02 · DHCP

Give LAN clients AdGuard Home as DNS

Correct DHCP DNS

DHCP should advertise AdGuard Home, not MikroTik and not a public DNS server. This is the key step that makes
AdGuard show real clients in the query log.

DNS 1: 192.168.1.10
DNS 2: empty / none

Do not add a public DNS as DNS 2

Many clients do not use DNS 2 only as an emergency fallback. Some clients may use it in parallel.
If you add 8.8.8.8, 1.1.1.1 or 9.9.9.9 as DNS 2,
those clients can bypass AdGuard.

RouterOS DHCP network example

/ip dhcp-server network
set [find address=192.168.1.0/24] gateway=192.168.1.1 dns-server=192.168.1.10

Result

A Windows, Linux, Android or iOS client should now show 192.168.1.10 as its DNS server after DHCP renewal.

03 · AdGuard Home

Configure AdGuard to use MikroTik as upstream DNS

DNS upstream

In AdGuard Home, go to Settings → DNS settings → Upstream DNS servers
and set MikroTik as the upstream resolver.

192.168.1.1

Private reverse DNS

If you want local reverse lookups and local hostnames to be handled by MikroTik, also set MikroTik as
a private reverse DNS server.

Private reverse DNS servers:
192.168.1.1

AdGuard query log visibility

Client 192.168.1.100 → asks AdGuard
AdGuard logs client as 192.168.1.100
AdGuard forwards allowed query to MikroTik 192.168.1.1
MikroTik resolves through Quad9

Avoid DNS loops: Do not configure MikroTik DNS to forward all requests back to AdGuard while AdGuard uses MikroTik as upstream.
That would create AdGuard → MikroTik → AdGuard → MikroTik.

04 · RouterOS DNS

MikroTik DNS cache, Quad9 upstream and optional DNS adlist

RouterOS DNS role in this setup

MikroTik is not the DNS server advertised to LAN clients. It is the upstream resolver used by AdGuard Home.
This keeps AdGuard client visibility while preserving RouterOS DNS cache, Quad9 upstreams and optional MikroTik DNS adlist filtering.

Enable RouterOS DNS resolver and use Quad9 secure DNS

/ip dns
set allow-remote-requests=yes cache-size=8192KiB servers=9.9.9.9,149.112.112.112
/ip dns cache flush

Security note: allow-remote-requests=yes makes RouterOS listen on TCP/UDP port 53.
Firewall input rules must allow DNS only from AdGuard and block other LAN clients and WAN hosts.

Optional MikroTik DNS adlist

Keeping DNS filtering on MikroTik is valid as a second layer. It can catch domains that pass through AdGuard,
but troubleshooting may be less direct because a domain can be blocked by either AdGuard or RouterOS.

/ip dns adlist
add url=https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts ssl-verify=no comment="ZRG DNS adlist - StevenBlack hosts"

Cleaner diagnostic mode

If you ever need to troubleshoot false positives, temporarily disable the RouterOS DNS adlist and test again.

/ip dns adlist disable [find]
/ip dns cache flush

05 · DNS Forwarders

Use RouterOS DNS Forwarders for selective domain routing

What DNS Forwarders are

RouterOS DNS Forwarders are named resolver targets. They are useful when specific domains should be resolved through
a specific upstream resolver. A forwarder is used by a DNS static entry of type FWD.

Create a Quad9 secure forwarder

/ip dns forwarders
add name=quad9-secure dns-servers=9.9.9.9,149.112.112.112 comment="ZRG DNS forwarder - Quad9 secure"

Example: selectively forward a domain through Quad9

/ip dns static
add name=example.com type=FWD forward-to=quad9-secure match-subdomain=yes comment="Example only - forward this domain through Quad9"

Do not create an all-purpose AdGuard forwarder in MikroTik when AdGuard already uses MikroTik as upstream.
It can create a DNS loop. The clean default path is:
clients → AdGuard → MikroTik → Quad9.

When forwarders are useful

Default DNS:
  MikroTik uses Quad9 secure from /ip dns servers

Selective DNS:
  Some domain or local zone can be routed through a named forwarder by type=FWD

Not required:
  DNS forwarders are not required for ordinary default Quad9 upstream DNS.

06 · Quad9 and bootstrap DNS

Plain Quad9 upstream vs bootstrap DNS

Plain Quad9 secure DNS

This is used by MikroTik as its upstream resolver in the reference design.

9.9.9.9
149.112.112.112

Quad9 encrypted endpoints

If AdGuard Home or another DNS client uses hostname-based encrypted DNS, the hostname must first be resolved.

DNS-over-HTTPS:
https://dns.quad9.net/dns-query

DNS-over-TLS:
tls://dns.quad9.net

Bootstrap DNS

Bootstrap DNS is only needed when the upstream server is configured by hostname, for example
dns.quad9.net. If AdGuard uses only 192.168.1.1 as upstream, bootstrap DNS is not critical,
but it is safe to configure Quad9 bootstrap values for future encrypted upstream use.

Bootstrap DNS servers:
9.9.9.9
149.112.112.112

DNS 1 / DNS 2 in DHCP and Bootstrap DNS are not the same thing.
DHCP DNS is what clients use. Bootstrap DNS is what a DNS resolver uses internally to resolve an upstream resolver hostname.

07 · NAT

Masquerade only traffic leaving through WAN

Correct NAT scope

NAT masquerade is for private LAN traffic going to the internet. It must not hide local traffic between LAN clients,
AdGuard and MikroTik. Therefore, the rule should be limited to out-interface-list=ISP_WAN.

Recommended NAT masquerade rule

/ip firewall nat
add chain=srcnat action=masquerade out-interface-list=ISP_WAN comment="NAT - masquerade LAN to WAN only"

Expected behavior

LAN → WAN          = masquerade yes
LAN → AdGuard      = masquerade no
AdGuard → MikroTik = masquerade no
LAN → LAN          = masquerade no

08 · Input firewall

Allow DNS to MikroTik only from AdGuard

Rule order matters: these DNS input rules must be above the final input drop rule.
If an old broad rule allows DNS from the whole LAN to the router, disable or remove it.

Input DNS policy

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="INPUT 010 - accept established/related/untracked"
add chain=input action=drop connection-state=invalid comment="INPUT 020 - drop invalid"

add chain=input action=accept protocol=udp dst-port=53 in-interface-list=local_LAN src-address=192.168.1.10 comment="INPUT 060A - accept DNS UDP from AdGuard to MikroTik"
add chain=input action=accept protocol=tcp dst-port=53 in-interface-list=local_LAN src-address=192.168.1.10 comment="INPUT 061A - accept DNS TCP from AdGuard to MikroTik"

add chain=input action=drop protocol=udp dst-port=53 in-interface-list=local_LAN src-address-list=dns-clients comment="INPUT 062A - block direct LAN DNS to MikroTik UDP"
add chain=input action=drop protocol=tcp dst-port=53 in-interface-list=local_LAN src-address-list=dns-clients comment="INPUT 063A - block direct LAN DNS to MikroTik TCP"

add chain=input action=drop protocol=udp dst-port=53 in-interface-list=ISP_WAN comment="INPUT 064 - drop DNS UDP from WAN"
add chain=input action=drop protocol=tcp dst-port=53 in-interface-list=ISP_WAN comment="INPUT 065 - drop DNS TCP from WAN"

Meaning

AdGuard can ask MikroTik for DNS. Normal LAN clients cannot ask MikroTik directly.
WAN hosts cannot use the router as an open resolver.

09 · Forward firewall

Allow AdGuard path and block DNS bypass attempts

Allow LAN to AdGuard DNS

This is required when AdGuard is in another routed subnet or VLAN. If clients and AdGuard are in the same L2 bridge/subnet,
this traffic may not hit the IP forward chain, but the rule is still useful in routed designs.

add chain=forward action=accept protocol=udp src-address-list=dns-clients dst-address=192.168.1.10 dst-port=53 comment="FORWARD 050 - allow LAN DNS UDP to AdGuard"
add chain=forward action=accept protocol=tcp src-address-list=dns-clients dst-address=192.168.1.10 dst-port=53 comment="FORWARD 051 - allow LAN DNS TCP to AdGuard"

Block direct external DNS

This prevents clients from bypassing AdGuard with public DNS servers such as Google, Cloudflare, Quad9 or ISP DNS.

add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=udp dst-port=53 comment="FORWARD 060 - drop direct LAN UDP DNS to WAN"
add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=tcp dst-port=53 comment="FORWARD 061 - drop direct LAN TCP DNS to WAN"

Block direct DoT / DoQ on port 853 before LAN to WAN allow

/ip firewall filter
add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=tcp dst-port=853 comment="FORWARD 062 - drop direct external DNS-over-TLS TCP"
add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=udp dst-port=853 comment="FORWARD 063 - drop direct external DNS-over-QUIC UDP"

DNS-over-HTTPS usually uses TCP/443 and cannot be safely blocked by port alone without breaking normal HTTPS.
Handle browser Secure DNS settings by endpoint policy, device policy, known DoH resolver address lists, or client management.

Typical forward chain skeleton

/ip firewall filter
add chain=forward action=accept connection-state=established,related,untracked comment="FORWARD 010 - accept established/related/untracked"
add chain=forward action=drop connection-state=invalid comment="FORWARD 020 - drop invalid"

add chain=forward action=accept protocol=udp src-address-list=dns-clients dst-address=192.168.1.10 dst-port=53 comment="FORWARD 050 - allow LAN DNS UDP to AdGuard"
add chain=forward action=accept protocol=tcp src-address-list=dns-clients dst-address=192.168.1.10 dst-port=53 comment="FORWARD 051 - allow LAN DNS TCP to AdGuard"

add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=udp dst-port=53 comment="FORWARD 060 - drop direct LAN UDP DNS to WAN"
add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=tcp dst-port=53 comment="FORWARD 061 - drop direct LAN TCP DNS to WAN"
add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=tcp dst-port=853 comment="FORWARD 062 - drop direct external DNS-over-TLS TCP"
add chain=forward action=drop in-interface-list=local_LAN out-interface-list=ISP_WAN protocol=udp dst-port=853 comment="FORWARD 063 - drop direct external DNS-over-QUIC UDP"

add chain=forward action=drop connection-nat-state=!dstnat connection-state=new in-interface-list=ISP_WAN comment="FORWARD 090 - drop new WAN traffic not dstnat"
add chain=forward action=accept in-interface-list=local_LAN out-interface-list=ISP_WAN comment="FORWARD 100 - accept LAN to WAN"
add chain=forward action=drop comment="FORWARD 999 - default drop forward"

10 · Management hardening

Keep discovery, MAC access and management services on LAN only

Neighbor discovery and MAC services

/ip neighbor discovery-settings
set discover-interface-list=local_LAN

/tool mac-server
set allowed-interface-list=local_LAN

/tool mac-server mac-winbox
set allowed-interface-list=local_LAN

/tool mac-server ping
set enabled=no

IP services example

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes
set ssh address=192.168.1.0/24
set winbox address=192.168.1.0/24

Disable UPnP / NAT-PMP unless explicitly needed

/ip upnp
set enabled=no

/ip nat-pmp
set enabled=no

11 · Rule order

Correct order is part of the security model

Input chain target order

1. Accept established / related
2. Drop invalid
3. Allow trusted management from LAN
4. Allow AdGuard → MikroTik DNS
5. Drop other LAN clients → MikroTik DNS
6. Drop WAN DNS to router
7. Drop everything else

Forward chain target order

1. Accept established / related
2. Drop invalid
3. Allow LAN → AdGuard DNS
4. Drop LAN → external DNS 53
5. Drop LAN → external DoT / DoQ 853
6. Drop new WAN traffic that is not dstnat
7. Allow LAN → WAN
8. Drop everything else

If a broad accept LAN to WAN rule is placed before DNS bypass drops,
DNS bypass protection will not work.

12 · Verification

Test the complete path

Client DHCP check

On Windows, renew DHCP and verify DNS server.

ipconfig /release
ipconfig /renew
ipconfig /all

Expected DNS server: 192.168.1.10

Normal DNS test

The client should resolve through AdGuard.

nslookup zorgan.cz

AdGuard Query Log should show the real client IP address.

Bypass test

Direct DNS to public DNS should fail or time out.

nslookup zorgan.cz 8.8.8.8

AdGuard → MikroTik test

Run from the AdGuard host.

nslookup zorgan.cz 192.168.1.1

RouterOS counters

/ip firewall filter print stats where comment~"DNS"
/ip dns cache print count-only

13 · Troubleshooting

Typical problems and fixes

AdGuard shows only MikroTik as client

Clients are probably using MikroTik directly as DNS. Fix DHCP DNS.

/ip dhcp-server network
set [find address=192.168.1.0/24] dns-server=192.168.1.10

Clients have no DNS

Check that AdGuard is running and reachable on TCP/UDP 53.

ping 192.168.1.10
nslookup zorgan.cz 192.168.1.10

AdGuard cannot resolve internet domains

Check whether AdGuard can reach MikroTik DNS.

nslookup zorgan.cz 192.168.1.1

Direct DNS bypass still works

Check rule order. DNS drops must be above LAN → WAN allow.

/ip firewall filter print where chain=forward

False positive domain block

Check AdGuard Query Log first. If it is not blocked there, test MikroTik DNS adlist.

/ip dns adlist disable [find]
/ip dns cache flush

DNS loop suspected

Check that MikroTik does not forward back to AdGuard while AdGuard uses MikroTik.

/ip dns print
/ip dns forwarders print
/ip dns static print where type=FWD

Final reference

Stable reference profile

DHCP

LAN clients receive AdGuard Home 192.168.1.10 as the only DNS server.

AdGuard

AdGuard sees real clients and forwards allowed DNS requests to MikroTik 192.168.1.1.

MikroTik

RouterOS uses Quad9 secure DNS, optional DNS forwarders, optional DNS adlist and WAN-only masquerade.

Most important rule

Do not advertise MikroTik as the client DNS server if you want AdGuard per-client logging.
Use AdGuard as client DNS and MikroTik as AdGuard upstream.

Technical references

Mikrotik RouteOS