DNS in RouterOS

DNS in RouterOS

Summary

Domain Name System (DNS) is the internet’s system for translating human-readable hostnames (like www.mikrotik.com) into IP addresses (like 159.148.147.196). MikroTik RouterOS includes a full-featured DNS implementation that can serve as a caching resolver, authoritative server for static entries, DoH client, ad blocker via Adlist, and mDNS repeater.

A RouterOS device with DNS enabled can act as the DNS server for all clients on the network. When combined with the built-in DHCP server, clients automatically receive the router’s address as their DNS server. The DNS cache stores responses from upstream servers, reducing query latency and external traffic. Static DNS entries allow administrators to define custom name-to-address mappings, override external records, or redirect traffic for specific domains.

RouterOS supports DNS over HTTPS (DoH) for encrypted DNS queries, Adlist for network-level ad blocking, domain-based forwarding with type=FWD, and mDNS repeater for cross-subnet service discovery.

DNS Configuration

DNS facility provides domain name resolution for the router itself and for connected clients.

Sub-menu: /ip/dns

Property	Type	Description	Default
allow-remote-requests	yes | no	Allow the router to serve as a DNS cache for remote clients. When disabled, only the router itself uses the DNS configuration.	no
address-list-extra-time	time	Extra time added to TTL when creating address list entries.	0s
cache-max-ttl	time	Maximum time-to-live for cache records. Cache records expire unconditionally after this time regardless of the TTL received from upstream DNS servers.	1w
cache-size	integer [64..4294967295]	DNS cache size in KiB.	2048
max-concurrent-queries	integer	Maximum number of concurrent DNS queries allowed.	100
max-concurrent-tcp-sessions	integer	Maximum number of concurrent TCP sessions allowed.	20
max-udp-packet-size	integer [50..65507]	Maximum size of allowed UDP packets.	4096
query-server-timeout	time	How long to wait for a query response from a single server.	2s
query-total-timeout	time	Total time to wait for query response across all servers. Configure based on query-server-timeout and the number of DNS servers.	10s
servers	list of IPv4/IPv6 addresses	List of upstream DNS server addresses.
cache-used	integer	Currently used cache size in KiB (read-only).
dynamic-server	IPv4/IPv6 list	Dynamically added DNS servers from services like DHCP (read-only).
doh-max-concurrent-queries	integer	Maximum concurrent DoH queries.	50
doh-max-server-connections	integer	Maximum concurrent connections to the DoH server.	5
doh-timeout	time	Timeout for DoH server query response.	5s
use-doh-server	string	DoH server URL for DNS queries (must start with https://). Overrides standard servers when active. Only one DoH server supported.
verify-doh-cert	yes | no	Validate the DoH server certificate using /certificate list.	no
vrf	vrf	VRF for DNS resolver. The resolver processes only requests from the designated VRF or from itself.	main

Basic DNS Setup

Enable the router as a DNS cache for LAN clients:

/ip/dns set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8

View current DNS configuration:

/ip/dns print

Example output:

                      servers: 1.1.1.1,8.8.8.8
              dynamic-servers: 10.155.0.1
               use-doh-server:
              verify-doh-cert: no
   doh-max-server-connections: 5
   doh-max-concurrent-queries: 50
                  doh-timeout: 5s
        allow-remote-requests: yes
          max-udp-packet-size: 4096
         query-server-timeout: 2s
          query-total-timeout: 10s
       max-concurrent-queries: 100
  max-concurrent-tcp-sessions: 20
                   cache-size: 2048KiB
                cache-max-ttl: 1w
                   cache-used: 48KiB

DNS Server Processing Order

Servers are processed in queue order: static servers first (ordered list), then dynamic servers (ordered list). When the DNS cache needs to send a request, it tries servers one by one until one responds. That server is then used for all subsequent queries (both A and AAAA types).

If you use only dynamic servers, DNS results can change after reboot because servers may load in a different order depending on how fast they are received from DHCP, VPN, or other facilities.

If the active server becomes unavailable, the DNS cache restarts the server lookup process and cycles through the list again.

DHCP Integration

When the router serves as a DHCP server, DNS behavior depends on configuration:

• No DNS servers configured in DHCP network: The router forwards DNS server addresses received from the ISP to LAN devices.
• DNS servers specified in DHCP network (requires allow-remote-requests=yes): The router provides the configured DNS servers to LAN devices.
• dns-none configured: The router does not forward any dynamic DNS server addresses to LAN devices.

DNS Cache

Sub-menu: /ip/dns/cache

The DNS cache stores resolved DNS records to speed up subsequent queries. RouterOS provides two cache views:

• /ip/dns/cache — cached DNS entries the router can reply with to client requests.
• /ip/dns/cache/all — complete list of all cached records including PTR records.

Flush DNS Cache

Clear all cached DNS entries:

/ip/dns/cache/flush

This forces the router to re-query upstream servers for all subsequent requests.

DNS Static Entries

Sub-menu: /ip/dns/static

DNS static entries allow you to create custom DNS records on the router. These entries are served to any DNS client using the router as its DNS server, without querying upstream servers. Static entries take precedence over cached records for matching domain names.

Overview of Static DNS

The RouterOS DNS cache includes an embedded DNS server that supports multiple record types (A, AAAA, CNAME, FWD, MX, NS, NXDOMAIN, SRV, TXT). Static entries provide several capabilities:

• Map hostnames to specific IP addresses for internal services
• Override external DNS records for specific domains
• Redirect DNS queries for domains to your own servers
• Create regex-based entries to match multiple domain names
• Block domains by returning NXDOMAIN
• Forward specific domain queries to designated DNS servers

Adding a Static DNS Entry

Add a simple A record:

/ip/dns/static/add name=www.example.com address=10.0.0.1

Add an AAAA record for IPv6:

/ip/dns/static/add name=www.example.com address=2001:db8::1 type=AAAA

Add a CNAME record:

/ip/dns/static/add name=mail.example.com type=CNAME cname=mx.example.com

Viewing Static DNS Entries

List all configured static DNS entries:

/ip/dns/static/print

Example output:

Columns: NAME, REGEXP, ADDRESS, TTL
# NAME             REGEXP       ADDRESS   TTL
0 www.mikrotik.com               10.0.0.1  1d
1                  *mikrotik*  10.0.0.2  1d

Static DNS Entry Properties

Property	Type	Description	Default
name	string	Domain name for the record.
address	IPv4/IPv6	IP address for A or AAAA records.
type	A | AAAA | CNAME | FWD | MX | NS | NXDOMAIN | SRV | TXT	DNS record type.	A
cname	string	Alias name for CNAME records.
forward-to	string	IP address of a DNS server to forward this query to (for FWD type).
mx-exchange	string	Domain name of the MX server.
mx-preference	integer	Preference of the MX record.	0
ns	string	Authoritative domain name server for this record.
srv-port	integer	TCP or UDP port for SRV records.	0
srv-target	string	Canonical hostname providing the service (for SRV records).
srv-priority	integer	Priority for SRV records.	0
srv-weight	integer	Weight for SRV records.	0
text	string	Textual information for TXT records.
regexp	regex	Regular expression for matching domain names.
ttl	time	Time-to-live for the record.	24h
address-list	string	Firewall address list to dynamically add matching addresses to. Entries are removed when TTL expires.
comment	string	Comment for the record.
disabled	yes | no	Whether the record is active.	no
match-subdomain	yes | no	Whether the record matches requests for subdomains.	no

Regex-Based DNS Matching

Static entries that do not conform to DNS naming standards are treated as regular expressions. Regex entries are checked first, then plain records, in list order (top to bottom).

Add a regex-based entry:

/ip/dns/static/add regexp="*mikrotik*" address=10.0.0.2

Caution

Regex is case-sensitive but DNS requests are case-insensitive. RouterOS converts DNS names to lowercase before matching. Write regex patterns using only lowercase letters. Regex matching is slower than plain text entries — minimize the number of regex rules and optimize expressions.

Caution

Be careful when configuring regex through mixed interfaces (CLI and GUI). Adding entries may require escape characters when using CLI. Always verify with print after adding.

Static Entry Behavior with Record Types

When a static entry matches a domain name, the router assumes responsibility for all record types for that name. If only an A record exists in the static list but an AAAA request arrives, the router:

1. Replies with the A record from the static list
2. Queries the upstream server for the AAAA record
3. Forwards the upstream AAAA reply if found, or replies with an empty “ok” response

To override upstream records with unusable entries, add a static entry with a dummy IPv6 address (e.g., ::ffff).

For each static A and AAAA record, a corresponding PTR record is automatically added to the cache.

Wildcard DNS Entries

RouterOS supports two methods for matching multiple domain names with a single static entry: wildcard syntax using *. prefixes and match-subdomain=yes on a named entry.

Wildcard Prefix Syntax

Use a leading *. to match any single-level subdomain of a domain:

/ip/dns/static/add name=*.example.com address=192.168.1.10

This entry matches www.example.com, mail.example.com, and api.example.com, but does not match example.com itself or multi-level subdomains like deep.sub.example.com.

To also catch the bare domain, add a second entry:

/ip/dns/static/add name=example.com address=192.168.1.10
/ip/dns/static/add name=*.example.com address=192.168.1.10

Wildcard CNAME entries are also supported:

/ip/dns/static/add name=*.example.com type=CNAME cname=example.com

match-subdomain Property

The match-subdomain=yes property on a named entry matches both the exact name and all subdomains at any depth:

/ip/dns/static/add name=example.com address=192.168.1.10 match-subdomain=yes

This matches example.com, www.example.com, mail.example.com, and deep.sub.example.com.

Precedence: When match-subdomain=yes is set and a more specific entry also exists, the more specific entry takes precedence. For example, if mail.example.com is defined separately, that entry answers queries for mail.example.com while the wildcard entry answers everything else.

Regex-Based Wildcard Matching

For more complex patterns, use the regexp property with regular expressions:

/ip/dns/static/add regexp=".*\.example\.com$" address=192.168.1.10

RouterOS CLI regex patterns use single backslashes for escaped dots. After adding a regex entry, verify the stored value with /ip/dns/static/print detail.

Caution

Regex is case-sensitive but DNS names are converted to lowercase before matching. Use only lowercase patterns. Regex matching is slower than plain entries — prefer wildcard prefix syntax or match-subdomain=yes where possible.

Lookup priority: Regex entries are checked first (in list order), then plain name entries, then wildcard (*.) entries. Within each group, entries are matched top to bottom.

Split-Horizon DNS for Internal Domains

Split-horizon DNS serves different DNS answers for the same domain depending on whether the query is for an internal zone or a public zone. In RouterOS, split-horizon is implemented at the domain level using static entries and FWD forwarding — not at the client level (RouterOS does not support per-client DNS views).

How RouterOS Split-Horizon Works

RouterOS answers DNS queries by checking entries in this order:

1. Static entries matching the queried name (exact, wildcard, or regex)
2. Cached upstream responses
3. Upstream DNS servers (configured via servers or use-doh-server)

By defining static entries or FWD rules for internal domains, those domains are answered locally while all other queries go to public upstream resolvers. This creates effective split-horizon by domain.

Pattern 1: Authoritative Static Entries for Internal Hosts

Define static A records for internal hostnames. Queries for these names are answered directly from the router without contacting upstream:

/ip/dns/set allow-remote-requests=yes servers=1.1.1.1,9.9.9.9

/ip/dns/static/add name=nas.corp.example.com    type=A address=192.168.10.20
/ip/dns/static/add name=vcenter.corp.example.com type=A address=192.168.10.21
/ip/dns/static/add name=ldap.corp.example.com    type=A address=192.168.10.22

Clients using the router as their DNS server receive the internal addresses. Queries for any other domain go to 1.1.1.1 or 9.9.9.9.

Pattern 2: Forwarding an Internal Zone to an Internal DNS Server

Use type=FWD to forward an entire domain zone to an internal DNS server such as Active Directory:

# Forward corp.example.com zone to internal AD DNS
/ip/dns/static/add name=corp.example.com type=FWD forward-to=192.168.10.2

# Forward reverse DNS for the internal subnet
/ip/dns/static/add name=10.168.192.in-addr.arpa type=FWD forward-to=192.168.10.2

Any query for corp.example.com or its subdomains is forwarded to 192.168.10.2. All other queries use the upstream servers configured under /ip/dns.

To match all subdomains of the zone automatically, combine FWD with match-subdomain=yes:

/ip/dns/static/add name=corp.example.com type=FWD forward-to=192.168.10.2 match-subdomain=yes

Pattern 3: Using FWD Entries with Multiple Upstream Targets

If the forwarded zone is served by multiple internal DNS servers, list both IPs in forward-to:

/ip/dns/static/add name=corp.example.com type=FWD forward-to=192.168.10.2,192.168.10.3 match-subdomain=yes
/ip/dns/static/add name=10.168.192.in-addr.arpa type=FWD forward-to=192.168.10.2,192.168.10.3

RouterOS 7.15.3 does not provide a separate /ip/dns/forwarders submenu. Domain-based forwarding is configured directly on static type=FWD entries.

Blocking Internal Names from Resolving Externally

Return NXDOMAIN for internal-only domains that should never resolve externally:

/ip/dns/static/add name=internal.corp type=NXDOMAIN

Clients that try to resolve internal.corp receive a “does not exist” response, preventing accidental external leakage.

Directing Clients to Different DNS Servers by VLAN

For true per-client split-horizon (same FQDN returning different answers for different clients), RouterOS’s built-in DNS is insufficient. Use DHCP to steer different subnets to different DNS resolvers:

# Internal VLAN uses internal DNS (AD)
/ip/dhcp-server/network set [find where address=192.168.10.0/24] dns-server=192.168.10.2

# Guest VLAN uses public DNS
/ip/dhcp-server/network set [find where address=192.168.20.0/24] dns-server=8.8.8.8

Note

RouterOS does not implement BIND-style DNS views where the same FQDN returns different answers based on client source IP. Domain-based forwarding (FWD entries) is the built-in mechanism for split-horizon DNS.

DNAT DNS Hijacking

DNS hijacking via DNAT intercepts DNS queries leaving the network and redirects them to the router’s own DNS resolver. This prevents clients from bypassing network-level DNS policies by using hardcoded external servers (such as 8.8.8.8 or 1.1.1.1).

How It Works

Without DNAT, a client configured with a hardcoded DNS server sends queries directly to that external IP on port 53, bypassing the router’s static entries, adlists, and any filtering applied to the router’s DNS. A dstnat NAT rule rewrites the destination of those packets before they leave the LAN, forcing them to the router’s DNS service.

Prerequisites

The router must be configured to accept DNS queries from LAN clients:

/ip/dns/set allow-remote-requests=yes

Redirect All LAN DNS to the Router

The examples below use in-interface-list=LAN. That interface list does not exist by default, so create it and add your LAN-facing interface first:

/interface/list/add name=LAN
/interface/list/member/add list=LAN interface=bridge

Replace bridge with your actual LAN interface, or replace in-interface-list=LAN in the firewall rules with a specific interface such as in-interface=bridge.

Use action=redirect — the router automatically rewrites the destination to its own address on the same interface:

/ip/firewall/nat/add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 \
    action=redirect to-ports=53 comment="Force LAN DNS UDP to router"

/ip/firewall/nat/add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 \
    action=redirect to-ports=53 comment="Force LAN DNS TCP to router"

Both UDP and TCP rules are required — DNS uses UDP by default but falls back to TCP for large responses (e.g., DNSSEC, zone transfers).

Alternatively, specify the router’s LAN IP explicitly:

/ip/firewall/nat/add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 \
    action=dst-nat to-addresses=192.168.88.1 to-ports=53

/ip/firewall/nat/add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 \
    action=dst-nat to-addresses=192.168.88.1 to-ports=53

Note

Place DNAT rules above any existing dstnat rules for the same traffic, or they will not be evaluated. Check rule order with /ip/firewall/nat/print.

Excluding Trusted Hosts

To allow specific devices (e.g., a local DNS server or admin workstation) to use their own DNS, add an exception rule before the redirect rules:

/ip/firewall/nat/add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 \
    src-address=192.168.88.5 action=accept comment="Trusted host — skip DNS redirect"

Handling DoH and DoT Bypass

Port-53 hijacking does not affect DNS over HTTPS (DoH) or DNS over TLS (DoT). Clients running browsers or applications with built-in DoH send encrypted DNS queries over TCP/443 to known resolver IPs, entirely bypassing the router’s DNS. Mitigation requires blocking known DoH/DoT endpoints:

# Block DNS over TLS (port 853)
/ip/firewall/filter/add chain=forward in-interface-list=LAN \
    protocol=tcp dst-port=853 action=drop comment="Block DoT TCP"

/ip/firewall/filter/add chain=forward in-interface-list=LAN \
    protocol=udp dst-port=853 action=drop comment="Block DoT UDP"

# Block known DoH resolver IPs on port 443
/ip/firewall/address-list/add list=known-doh-servers address=1.1.1.1  comment="Cloudflare"
/ip/firewall/address-list/add list=known-doh-servers address=1.0.0.1  comment="Cloudflare"
/ip/firewall/address-list/add list=known-doh-servers address=8.8.8.8  comment="Google"
/ip/firewall/address-list/add list=known-doh-servers address=8.8.4.4  comment="Google"
/ip/firewall/address-list/add list=known-doh-servers address=9.9.9.9  comment="Quad9"
/ip/firewall/address-list/add list=known-doh-servers address=149.112.112.112 comment="Quad9"

/ip/firewall/filter/add chain=forward in-interface-list=LAN \
    protocol=tcp dst-port=443 dst-address-list=known-doh-servers \
    action=drop comment="Block known DoH servers"

Caution

The known-doh-servers list requires ongoing maintenance. DoH providers may change IPs or use CDN addresses. This approach is a best-effort control, not a complete guarantee. For strict enforcement, combine with TLS inspection or endpoint policy (MDM/Group Policy).

Verify Hijacking Is Working

After adding the rules, check that NAT counters are incrementing:

/ip/firewall/nat/print stats where comment~"DNS"

Test from a client configured with an external DNS server — the query should resolve correctly (served by the router) rather than timing out.

DNS over HTTPS (DoH)

Sub-menu: /ip/dns (properties: use-doh-server, verify-doh-cert)

DNS over HTTPS encrypts DNS queries using HTTPS to prevent man-in-the-middle attacks and provide privacy. When DoH is active, it overrides all standard DNS servers.

Configuring DoH

Step 1: Import the root CA certificate of your DoH provider:

/certificate/import file-name=cloudflare-root-ca.pem

Tip

Always download certificates from the Certificate Authority’s own website. Do not use third-party download links.

Step 2: Configure the DoH server:

/ip/dns/set use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes

Step 3: Ensure at least one regular DNS server is configured (needed to resolve the DoH hostname itself):

/ip/dns/set servers=1.1.1.1

If no dynamic or static DNS server is configured, add a static entry for the DoH server:

/ip/dns/static/add address=104.16.248.249 name=cloudflare-dns.com

Note

Only one DoH server is supported. When active, DoH is the only DNS service used — standard servers from /ip/dns are not queried.

Compatible DoH Services

Service	Status
Cloudflare	Compatible
Google	Compatible
NextDNS	Compatible
OpenDNS	Compatible
Mullvad	Incompatible
Yandex	Incompatible
UncensoredDNS	Incompatible
Quad9	Incompatible (HTTP/2 not supported in RouterOS)

Adlist (DNS-Based Ad Blocking)

Sub-menu: /ip/dns/adlist

Adlist provides network-level ad blocking by intercepting A and AAAA DNS requests for known ad-serving domains and returning 0.0.0.0 instead of the actual address. This null-routes ad requests, preventing advertisement content from loading on all devices using the router as their DNS server.

Caution

Increase the DNS cache size before configuring Adlist, as Adlist entries are stored in the cache. If the limit is reached, an error is logged: "adlist read: max cache size reached". Adlist data is stored on the device’s internal memory — ensure sufficient free space.

Adlist Properties

Property	Type	Description	Default
url	string	URL of an external Adlist.
file	string	Local file path for Adlist data.
ssl-verify	yes | no	Validate SSL certificate of the Adlist URL server.
match-count	integer	Count of matched DNS name requests (read-only).
name-count	integer	Count of DNS names imported from the Adlist (read-only).
pause		Temporarily pause all Adlist usage.
reload		Check for updates. Only necessary changes are applied — lists are not re-downloaded in full. Lists auto-update every four hours.

Configuring Adlist from a URL

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

Verify the Adlist:

/ip/dns/adlist/print

Flags: X - disabled
0 url="https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts" ssl-verify=no match-count=122 name-count=164769

Configuring a Local Adlist

Create a text file with domains in the format 0.0.0.0 domain.com:

0.0.0.0 example1.com
0.0.0.0 eu1.example.com
0.0.0.0 ex.com
0.0.0.0 com.example.com

Create and edit the file on the router:

/file/add name=host.txt
/file/edit host.txt contents

Add the file to Adlist:

/ip/dns/adlist/add file=host.txt

Whitelisting Domains from Adlist

To exempt a domain from ad blocking, create a static DNS FWD entry:

/ip/dns/static/add name=allowed-domain.com type=FWD

The query will be answered by the router if a relevant static entry exists, or forwarded to the next DNS server (dynamic or configured under /ip/dns/set servers=). FWD entries work with DoH as well.

Domain Forwarding with FWD Records

There is no separate /ip/dns/forwarders submenu in RouterOS 7.15.3. To forward a domain or zone to another resolver, create a static DNS entry with type=FWD under /ip/dns/static.

FWD Forwarding Example

Forward a specific domain to an internal DNS server:

/ip/dns/static/add name=mikrotik.com type=FWD forward-to=192.168.10.2

Forward a zone to multiple upstream DNS servers:

/ip/dns/static/add name=corp.example.com type=FWD forward-to=192.168.10.2,192.168.10.3 match-subdomain=yes

These entries make RouterOS forward matching queries to the IP address list in forward-to. All other queries continue to use the global upstream servers configured under /ip/dns.

mDNS Repeater

The mdns-repeat-ifaces property documented in some RouterOS materials was not present on the RouterOS 7.15.3 CHR build used to verify this page. Running /ip/dns/set mdns-repeat-ifaces=... returns expected end of command, so this page does not document mDNS repeater configuration as a generally available /ip/dns feature.

RouterOS supports Multicast DNS (mDNS) for local network service discovery within a local broadcast domain. If MikroTik exposes mdns-repeat-ifaces on a later release or different platform, verify the command syntax against that target system before enabling it in production.

mDNS Use Cases

• Apple ecosystem (AirPrint, AirPlay)
• Smart home devices (Thread, IoT)
• Chromecast and media streaming
• Avahi (Linux/Unix service discovery)

mDNS Considerations

• mDNS traffic can increase multicast load, potentially causing congestion in larger networks.
• Requires multicast-capable interfaces (Ethernet, VLAN, bridge). Tunnel interfaces like WireGuard are not supported.

Common Queries and Scenarios

How do I add a static DNS entry on MikroTik?

Use /ip/dns/static/add with the name and address properties:

/ip/dns/static/add name=server.local address=192.168.1.100

This creates an A record that resolves server.local to 192.168.1.100 for any client using this router as its DNS server.

How do I redirect a domain to a different IP address?

Add a static entry with the domain name and the desired address:

/ip/dns/static/add name=blocked-site.com address=192.168.1.1

All clients querying blocked-site.com through this router will receive 192.168.1.1 instead of the real address.

How do I block a domain using DNS?

Use the NXDOMAIN record type to make a domain appear non-existent:

/ip/dns/static/add name=malware-domain.com type=NXDOMAIN

Alternatively, point it to 0.0.0.0:

/ip/dns/static/add name=malware-domain.com address=0.0.0.0

How do I create a wildcard DNS entry for all subdomains?

Use match-subdomain=yes to match the domain and all its subdomains:

/ip/dns/static/add name=example.com address=10.0.0.1 match-subdomain=yes

This matches example.com, www.example.com, mail.example.com, and any other subdomain.

How do I set up DNS for internal services?

Create static entries for each internal service:

/ip/dns/static/add name=nas.home address=192.168.88.10
/ip/dns/static/add name=printer.home address=192.168.88.20
/ip/dns/static/add name=camera.home address=192.168.88.30

Ensure allow-remote-requests=yes is enabled and clients use the router as their DNS server.

How do I forward DNS queries for a specific domain to another DNS server?

Use the FWD record type with forward-to:

/ip/dns/static/add name=corp.example.com type=FWD forward-to=10.0.0.53

All queries for corp.example.com are forwarded to the DNS server at 10.0.0.53.

How do I use DNS with address lists for firewall rules?

Static entries can automatically populate firewall address lists:

/ip/dns/static/add name=streaming-service.com address-list=streaming-sites

When a client queries streaming-service.com, the resolved address is added to the streaming-sites address list, which can be used in firewall rules. The entry is removed when the TTL expires.

How do I flush the DNS cache?

/ip/dns/cache/flush

How do I view what is in the DNS cache?

/ip/dns/cache/print

For all cached records including PTR:

/ip/dns/cache/all/print

Troubleshooting

DNS Not Resolving

1. Verify DNS servers are configured: /ip/dns/print
2. Check that allow-remote-requests=yes if clients use the router as DNS
3. Test resolution from the router itself: /ping www.google.com count=1
4. Check firewall rules are not blocking UDP/TCP port 53
5. Verify upstream DNS servers are reachable: /tool/ping 1.1.1.1

Adlist Cache Full

If you see "adlist read: max cache size reached":

1. Increase cache size: /ip/dns/set cache-size=16384
2. Check current usage: /ip/dns/print (look at cache-used)
3. Consider using a smaller Adlist or splitting across multiple routers

DoH Not Working

1. Verify the DoH server URL is correct and starts with https://
2. Ensure at least one regular DNS server is configured to resolve the DoH hostname
3. Check that the root CA certificate is imported and valid
4. Verify verify-doh-cert=yes is set and the certificate chain is complete
5. Check that the DoH provider is in the compatible list above

Static Entry Not Being Used

1. Verify the entry is not disabled: /ip/dns/static/print
2. Check entry order — regex entries are checked first, then plain records
3. Flush the cache after adding static entries: /ip/dns/cache/flush
4. Verify the client is actually using this router as its DNS server

DNAT DNS Redirect Not Working

1. Verify allow-remote-requests=yes — without it, redirected queries are refused
2. Check NAT rule order: /ip/firewall/nat/print — DNAT rules must appear before any masquerade or other matching rules
3. Confirm the rule references the correct interface list containing the LAN interface
4. Check rule hit counters: /ip/firewall/nat/print stats — zero hits indicate traffic is not matching
5. If using FastTrack, already-established connections bypass NAT rules; only the first packet in a flow is redirected. This is expected behaviour.

See Also

• DHCP Server — configure DHCP to distribute DNS settings
• Firewall Filter — secure DNS access with firewall rules
• Firewall NAT — DNAT rules for DNS hijacking and port redirection
• Certificates — manage certificates for DoH