MikroTik routers running RouterOS power everything from home labs to ISP edge infrastructure, and when you need to swap DNS resolvers the procedure is fast but riddled with non-obvious gotchas: cached responses serving stale data, DHCP clients ignoring the new servers, and RouterOS 7's DNS-over-HTTPS layer sitting quietly in the middle. This guide covers every method to change DNS on RouterOS v6 and v7, verifies the change actually took effect, and addresses the 2026-specific wrinkles including DoH, IPv6 resolver configuration, static local overrides, and hardcoded-DNS bypass techniques.
Why This Change Affects More Than Just the Router
RouterOS has a built-in DNS resolver and cache. When you set upstream DNS servers under IP > DNS, you configure what RouterOS itself queries. But unless you also push those servers to your DHCP clients, every device on your LAN may still point at ISP resolvers or hardcoded Google DNS — completely bypassing your MikroTik's cache and any filtering or logging you've put in place. The router resolver setting and the DHCP-pushed DNS setting are independent, and forgetting that distinction is the root cause of most I changed DNS but nothing happened support threads.
Check Your RouterOS Version First
CLI syntax and available features differ between v6 and v7. Run this to confirm what you're working with:
Look for the version: line. RouterOS 7.x — current stable in 2026 is 7.15 and above — adds DNS-over-HTTPS, improved DNSSEC pass-through, IPv6 RDNSS via ND, and container support for running your own resolver (Unbound, Blocky). If you're still on v6, the commands below for basic DNS changes all apply, but DoH and the IPv6 ND DNS options are absent. Upgrading to v7 is strongly recommended for any router in active use.
Method 1: CLI via SSH or Winbox Terminal
The CLI is the fastest, most scriptable, and most reliable approach. SSH into the router or open the terminal panel inside Winbox.
View Current DNS Settings
Sample output on a factory-default RouterOS 7 device:
Set New Upstream Resolvers
Common resolver choices in 2026 and their strengths:
- Cloudflare (1.1.1.1, 1.0.0.1): consistently lowest latency in North America, strong privacy policy, DNSSEC validating
- Google Public DNS (8.8.8.8, 8.8.4.4): largest anycast footprint globally, excellent uptime — see Google's Public DNS documentation for resolver details and privacy disclosures
- Quad9 (9.9.9.9, 149.112.112.112): blocks known malware and phishing domains via threat intelligence feeds, DNSSEC validating
- NextDNS or AdGuard DNS: account-based filtering; use the custom resolver IPs from your dashboard — they differ per account
Multiple servers are comma-separated with no spaces. RouterOS queries them in order, failing over to the second only if the first fails to respond within the timeout. It does not load-balance between them.
Enable Remote Requests for LAN Clients
This tells RouterOS to answer DNS queries sent to the router's own IP by LAN clients. Without it, any client configured to use the router as its resolver will time out silently even though the router itself resolves correctly.
Flush the DNS Cache
Always flush immediately after changing servers. Stale cache entries from the previous resolver survive the server change and continue serving outdated or incorrect answers until each record's TTL naturally expires — which could be hours or days depending on the TTL values involved.
Method 2: Winbox GUI
Open Winbox and connect to the router. Navigate to IP > DNS. In the Servers field, clear the existing IPs and enter your new resolvers. Check Allow Remote Requests if LAN clients resolve through the router. Click OK, then return to IP > DNS and click Flush Cache to clear stale entries immediately.
On RouterOS 7, Winbox shows two additional fields: Use DoH Server and Verify DoH Cert. Leave them at defaults unless you're intentionally enabling DNS-over-HTTPS, which is covered in its own section below.
Method 3: WebFig Browser Interface
Open a browser and go to http://192.168.88.1 — the default MikroTik LAN IP; adjust if you've changed it. Log in and follow the same path: IP > DNS > Settings. Fields and behavior are identical to Winbox. WebFig is useful when Winbox isn't available (Linux without Wine, mobile device, or corporate machine with Winbox blocked).
Pushing New DNS Servers to DHCP Clients
Changing IP > DNS only affects the router's own resolver. Your LAN clients receive their DNS server addresses through DHCP leases, which is an entirely separate setting. This is the step most tutorials skip.
CLI
The [find] selector updates all DHCP networks at once. To target a specific network by its index number:
Winbox
- Go to IP > DHCP Server
- Click the Networks tab
- Double-click your network entry
- Update the DNS Servers field
- Click OK
Existing clients keep their old DNS assignment until the DHCP lease renews. Force an immediate update without waiting: on Windows run ipconfig /renew; on Linux run sudo dhclient -r && sudo dhclient; on macOS open System Settings > Network > [interface] > Details > Renew DHCP Lease; on iOS or Android toggle Wi-Fi off and back on.
Static DNS Entries for Internal Hostnames
RouterOS lets you create local A records that resolve before hitting any upstream server. This is useful for giving friendly names to NAS boxes, printers, and internal servers without running a full local DNS service:
Static entries take precedence over upstream resolver responses. If a client queries your MikroTik for nas.home, the answer comes from the local table immediately. RouterOS 7 also supports wildcard static entries:
This resolves any *.internal hostname to the router — handy for admin panels accessed via a local vanity domain. Remove static entries that accidentally shadow real external domains if users report being unable to reach a site by name.
DNS over HTTPS on RouterOS 7.x
RouterOS 7.1 introduced native DoH support. It encrypts all upstream resolver queries so ISPs and on-path observers cannot see which domains you're resolving — the biggest DNS privacy improvement MikroTik has shipped since the platform's inception, and the feature most worth enabling in 2026.
Enable DoH via CLI
Setting a plain-text bootstrap server alongside the DoH URL is important on first configuration. RouterOS needs to resolve the DoH hostname before it can send queries over DoH — the plain-text server handles that initial lookup. Once the DoH endpoint's IP is cached, all subsequent queries go over HTTPS. Other valid DoH endpoints in 2026:
- Cloudflare: https://cloudflare-dns.com/dns-query
- Quad9: https://dns.quad9.net/dns-query
- NextDNS: https://dns.nextdns.io/<your-id>
If DoH certificate verification fails — the most common causes are a wrong router clock or a missing root certificate chain — RouterOS silently falls back to plain-text DNS with no on-screen indication. Run /system clock print to verify the time is current. Check /log print where topics~"dns" for errors. If the clock is correct and verification still fails, temporarily set verify-doh-cert=no to confirm DoH is otherwise working, then investigate the certificate chain before re-enabling verification.
IPv6 DNS Configuration
If your WAN connection is dual-stack — now standard with most residential and business ISPs in 2026 — configure IPv6 DNS resolvers separately from IPv4:
Those are Cloudflare's IPv6 resolvers. For Google: 2001:4860:4860::8888 and 2001:4860:4860::8844.
To push IPv6 DNS to SLAAC clients via Router Advertisement (RDNSS per RFC 8106):
Compatibility note: Windows 10 build 1903 and later, and all recent macOS versions, honor RDNSS. Older Android versions (pre-Android 8 Oreo) ignore it entirely and require DHCPv6. If your LAN has mixed clients, deploy both RA RDNSS and a DHCPv6 server with the DNS option set to cover all device types.
DNSSEC Behavior in RouterOS 7
RouterOS 7 does not perform independent DNSSEC validation from scratch. It passes through the Authenticated Data (AD) flag returned by your upstream resolver. If your upstream — Quad9, Cloudflare's 1.1.1.1, or Google 8.8.8.8 — validates DNSSEC and sets the AD flag, that signal reaches your clients. For fully independent stub-resolver-level DNSSEC validation, you'd need to run Unbound inside RouterOS 7's container feature. For the vast majority of production environments, selecting a DNSSEC-validating upstream resolver is sufficient and far simpler to maintain.
DNS for WireGuard Peers
If you run a WireGuard VPN server on RouterOS 7 and want tunnel clients to use your MikroTik as their DNS resolver, set the WireGuard interface IP as the DNS in each peer's client config file:
Replace 10.6.0.1 with your WireGuard interface IP on the router. For this to work, allow-remote-requests=yes must be set, and the input chain must accept UDP and TCP port 53 from the WireGuard interface. Add a masquerade rule if tunnel clients need to reach external resolvers through the router's WAN:
Verifying the Change Worked
Test from both the router and a LAN client to confirm the full resolution chain is functioning — not just the router's local resolver.
From the Router
From Linux or macOS on the LAN
Replace 192.168.88.1 with your MikroTik's LAN IP. The dig output shows which server answered in the SERVER: line — confirm it shows the router's address, not an ISP or external resolver IP.
From Windows
Check What Resolver Clients Are Actually Using
Common Misdiagnoses
These are the failure modes that make it look like the DNS change didn't take when the problem is actually elsewhere:
- Cache not flushed: the router keeps serving stale answers from the previous resolver. Run /ip dns cache flush every time you change servers, without exception.
- DHCP clients not renewed: devices still carry old DNS assignments from their existing lease. Force renewal or wait for natural expiry — it will not happen automatically on its own the moment you save the DHCP network setting.
- Firewall blocking port 53 on the router's input chain: LAN queries directed at the router's IP are silently dropped. Add an accept rule for UDP and TCP 53 from your LAN interface to the input chain.
- ISP-pushed DNS overriding your static config: the WAN DHCP client accepts DNS from the ISP by default. Fix with /ip dhcp-client set [find] use-peer-dns=no.
- DoH silent fallback: DoH cert verification fails and RouterOS falls back to plain-text DNS with no visible error. Check the system log for DNS entries.
- Hardcoded DNS on smart devices: Chromecast, smart TVs, and many IoT devices ignore DHCP-pushed DNS and hardcode 8.8.8.8. They require a NAT redirect to intercept.
NAT Redirect for Hardcoded DNS Devices
Replace bridge with your actual LAN bridge or interface name. This intercepts all DNS queries leaving the LAN on port 53 and redirects them to the router regardless of what resolver IP the device is targeting.
Disable ISP-Pushed DNS on WAN DHCP Client
Firewall Rules for DNS Outbound
If you've locked down the router's output chain, ensure the router itself can reach your upstream resolver. For DoH, TCP 443 outbound must be open to the provider:
Place these accept rules above any drop rules in the output chain. If you use address-list-based geo-filtering, whitelist your DoH provider's IP range explicitly — otherwise DoH fails silently because the HTTPS connection to the resolver is dropped before it's established.
Backing Up Your Config After Changes
RouterOS does not preserve DNS settings through a factory reset. Export your configuration immediately after any DNS change so you can restore it in seconds rather than reconstructing it from memory:
Download both files from the Files panel in Winbox, or pull them off via SCP:
The .rsc export is plain text and re-importable with /import file=dns-config-2026.rsc. The .backup binary captures the full router state including credentials. Keep both copies in a location outside the router itself. For fleets managed with The Dude or a simple cron script, automate nightly exports using /tool fetch and /export so config drift is always recoverable.