Locking Down DNS on MikroTik: How to Force Local DNS and Block Bypass Attempts
July 17, 2026
When you set up a filtering DNS server—whether it’s a self-hosted Pi-hole, AdGuard Home, or a secure upstream provider like Cloudflare Families or NextDNS—you quickly run into a frustrating problem: smart clients bypass it. Many modern devices, web browsers, and apps come hardcoded with their own DNS servers (like Google’s 8.8.8.8). Even worse, modern protocols like DoT (DNS-over-TLS) and DoH (DNS-over-HTTPS) encrypt DNS queries, allowing devices to completely slip past your network policies. If you want your DNS filters to actually work, you have to force everyone onto your MikroTik router’s DNS. Here is exactly how to do it using RouterOS.
The Blueprint: Our 3-Step Strategy
To successfully lock down DNS on a network, we need a multi-layered approach:
- Intercept traditional unencrypted DNS (Port 53) and force-redirect it to the MikroTik.
- Block DoT (Port 853) at the firewall level to force clients to fall back to standard DNS.
- Address DoH (Port 443) using your upstream filter, since it cannot be cleanly blocked by a standard port firewall.
Step 1: Force-Redirect Traditional DNS (Port 53)
First, we need to ensure the MikroTik itself is ready to handle queries by enabling allow-remote-requests=yes.
Next, we create a destination NAT (dst-nat) rule. Instead of blocking rogue DNS requests, we redirect them. If a device tries to query 8.8.8.8, the MikroTik intercepts the packet, answers it locally, and sends it back. The client thinks it talked to Google, but it actually got your filtered local response. Run these commands in your MikroTik terminal (replace LAN with your specific interface list):
# 1. Enable the local DNS cache
/ip/dns/set allow-remote-requests=yes
# 2. Redirect UDP and TCP DNS traffic from the LAN to the router itself
/ip/firewall/nat
add chain=dstnat action=redirect to-ports=53 protocol=udp in-interface-list=LAN dst-port=53 comment="Force Local DNS (UDP)"
add chain=dstnat action=redirect to-ports=53 protocol=tcp in-interface-list=LAN dst-port=53 comment="Force Local DNS (TCP)"
Step 2: Slam the Door on DNS-over-TLS (DoT)
DNS-over-TLS is smart, but it has an architectural flaw which allows easy blocking: it uses a dedicated port (Port 853). Because it has its own lane, we can easily block it entirely for our LAN interface list. When devices realize they cannot establish a secure DoT handshake, 99% of them will gracefully fall back to traditional port 53 DNS—right into the trap we set up in Step 1.
/ip/firewall/filter
add chain=forward action=drop protocol=tcp in-interface-list=LAN dst-port=853 comment="Block DoT - Force fallback to local DNS"
add chain=forward action=drop protocol=udp in-interface-list=LAN dst-port=853 comment="Block DoT - Force fallback to local DNS"
⚠️ Important: Make sure to drag these rules near the top of your Filter Rules list in WinBox, securely above any general “Allow LAN to Internet” rules.
Step 3: Dealing with the Boss Fight: DNS-over-HTTPS (DoH)
This is where things get tricky. DNS-over-HTTPS wraps encrypted DNS queries inside normal HTTPS traffic on Port 443. If you try to block port 443 on your MikroTik, you will break the entire internet, because normal web browsing uses the exact same port. You cannot differentiate a DoH query from a regular website visit just by looking at the port or IP header.
The Solution: Handle DoH at the Upstream Server
Because the router cannot easily peek inside encrypted HTTPS traffic, DoH must be managed directly at your upstream DNS server level. If you use a filtering upstream provider (like NextDNS, AdGuard, or a local Pi-hole), you need to look for two features in their dashboard configuration:
- Enable “Block Bypass Methods”: Most professional filtering DNS providers have a single-click toggle that blocks known DoH bootstrap endpoints and common DoH provider domains.
- Rely on Canary Domains: Major browsers (like Firefox and Chrome) check specific “canary domains” (such as use-application-dns.net) before turning on DoH automatically. Your upstream filtering server can be configured to return a “NXDOMAIN” (does not exist) response for these queries, telling the browser: “Hey, this network has custom policies active. Turn off automatic DoH.”
Summary
By combining MikroTik’s NAT redirection for traditional traffic, Port blocking for DoT, and Upstream domain filtering for DoH, you create a seamless, inescapable net for your network traffic. Your network devices stay fast, secure, and—most importantly—properly filtered.
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress
Entries and comments feeds.
Valid XHTML and CSS.
47 queries. 0.060 seconds.