How to Flush DNS Cache on a MikroTik Router Using CLI and Winbox

Your MikroTik router acts as the DNS resolver for every device on your network, and by default it caches every answer it receives. That is usually a good thing — it cuts latency and reduces upstream query load. But when you have just changed a domain's DNS records, migrated a server, fixed a split-horizon zone, or corrected a static entry, that cache becomes the problem. Clients get stale answers, websites fail to load, and no amount of flushing the Windows or macOS DNS cache helps because the router is handing out the old data before the request even leaves your network. This guide covers every method to flush the MikroTik DNS cache, verify the result, and prevent the issue from recurring.

Why MikroTik Caches DNS Responses

RouterOS includes a built-in caching resolver that activates whenever you enable Allow Remote Requests under IP > DNS. Every A, AAAA, CNAME, MX, and TXT record fetched from upstream is stored locally for the duration of the record's TTL, capped by the router's Max Cache TTL setting (default: 1 week in RouterOS 6, also 1 week in RouterOS 7 unless changed). The Max Cache Size defaults to 2 MB in RouterOS 6.x and 4 MB in RouterOS 7.x.

This resolver sits between every LAN client and the internet. When a client asks for example.com, the MikroTik checks its cache first. A valid unexpired entry is returned immediately without touching the upstream resolver. That behaviour is efficient until the record changes upstream and the cached version is now wrong, or until a bad static entry is corrected but the old answer remains in cache.

Root Causes That Require a Cache Flush (Ranked by Frequency)

1. Server migration or IP address change — The most common trigger. A site moved to a new host, the A record was updated at the registrar, but the router cached the old IP for the full TTL duration. Every client on the network still reaches the old server.
2. Static DNS entry correction — A hostname under IP > DNS > Static pointed to the wrong address. You corrected it, but the router already cached the bad answer. The static entry change alone does not evict the cached record.
3. Cached NXDOMAIN response — A hostname that did not exist now does, but the router cached a negative NXDOMAIN response. Clients continue getting resolution failures even though the record is now live upstream.
4. Upstream resolver change — You switched from ISP DNS to 1.1.1.1 or 8.8.8.8. Some records cached under the old resolver may differ from what the new one returns; the cache needs clearing to start fresh.
5. DNSSEC validation failure (RouterOS 7.x) — A zone re-keyed or had a key rollover issue, and the router cached a SERVFAIL response. After the zone is corrected upstream, the cached SERVFAIL continues blocking resolution until flushed.
6. DoH provider change — The DoH server URL was updated. Old entries fetched via the previous provider may have different TTLs or subtly different answers that need to be cleared.

Method 1: Flush via RouterOS CLI (Fastest)

SSH is the most reliable method because it works regardless of Winbox connectivity and is scriptable. Connect to your MikroTik at its LAN IP (default 192.168.88.1 on factory-fresh units):

Once at the RouterOS prompt, issue the flush command:

No output is the expected response — it means the flush succeeded. The command is immediate. All cached DNS entries are wiped. If you are on RouterOS 7.x and prefer the newer hierarchical syntax:

Both syntaxes are accepted on RouterOS 7. On RouterOS 6.x, only the legacy form works. To confirm the cache is now empty:

You should see empty output or just column headers. If entries are already reappearing, that is normal — client queries are re-populating the cache with fresh data from upstream. What matters is that the old stale records are gone.

Removing a Single Hostname (RouterOS 7.4 and Later)

On RouterOS 7.4+, targeted removal of one cached entry is possible. This avoids wiping everything when only one record is stale:

On RouterOS 6 there is no targeted removal — a full flush is the only option.

Viewing Cache TTLs Before Flushing

Before flushing, confirm the stale entry is actually present and see how long it would linger without intervention:

On RouterOS 7, filter by hostname:

Check the TTL column. An entry with 5 days remaining will serve the wrong answer for five more days without a manual flush. The Address column shows the IP the router is currently handing out.

Method 2: Flush via Winbox GUI

Winbox is MikroTik's native desktop management client and makes the cache flush a two-click operation. Ensure you have a recent version installed, then connect by MAC address or IP.

1. Open Winbox and connect to the router.
2. In the left navigation panel, click IP.
3. Select DNS from the submenu.
4. In RouterOS 6: click the Cache button in the lower portion of the DNS window. In RouterOS 7: click the Cache tab at the top of the DNS window.
5. Click Flush Cache.
6. Confirm the dialog that appears.

The cache list clears immediately. No additional save or apply step is required. The action is persistent — the cache stays empty until new queries arrive and re-populate it with fresh upstream answers.

Method 3: Flush via WebFig (Browser-Based)

WebFig is MikroTik's browser interface, accessible at http://192.168.88.1 from any device on the LAN without installing software — useful when Winbox is not available or you are working from a phone or tablet.

1. Navigate to http://192.168.88.1 and log in.
2. Click IP in the top menu bar.
3. Select DNS.
4. Click Flush Cache on the DNS configuration page.

WebFig is slower for complex configuration tasks but works from any browser. The flush result is identical to the CLI or Winbox methods.

Verifying the Flush Worked

Never assume the flush fixed the problem without checking. Query the router directly from a client machine to confirm it is now returning the correct IP.

Linux and macOS

The @192.168.88.1 flag targets the MikroTik directly, bypassing any local OS DNS cache. You should see the new correct IP. To check the TTL and confirm a fresh upstream fetch:

Look at the ANSWER SECTION. A TTL close to the record's full published value (e.g., 3600 seconds) confirms the router just fetched it fresh from upstream. A very low TTL means the entry was cached quickly after the flush, but still with the current correct answer.

Windows

Or in PowerShell for more structured output:

Confirm the IPAddress field matches the expected new address.

Linux with systemd-resolved

On Ubuntu and other systemd-resolved systems, flush the local stub resolver too — otherwise it may serve its own cached copy even after the router is clean:

Use the DNS Lookup tool to cross-check what authoritative nameservers are returning. If that matches what your router now returns, resolution is consistent end-to-end.

Per-Device Cache Considerations

Flushing the MikroTik clears the network-level cache, but each operating system maintains its own DNS cache. After the router flush, you may need to clear client machines as well to force them to re-query the router immediately.

• Windows 10/11: Run ipconfig /flushdns in an elevated Command Prompt.
• macOS Sequoia / Ventura: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Ubuntu / Debian (systemd-resolved): sudo resolvectl flush-caches
• Ubuntu (nscd): sudo systemctl restart nscd
• iOS / iPadOS: Toggle Airplane Mode on then off to force a DNS re-query. Avoid Reset Network Settings unless necessary, as it wipes Wi-Fi passwords.
• Android: Toggle Wi-Fi off and on. In Chrome, navigate to chrome://net-internals/#dns and click Clear host cache for browser-level clearing.

Chromium-based browsers maintain their own DNS cache independent of the OS. After flushing both the router and the OS, clear the browser cache at chrome://net-internals/#dns if the browser is still resolving incorrectly. Firefox relies on the OS resolver and clears with a restart.

Scheduling Automated Cache Flushes

For environments where stale DNS is a recurring problem — particularly split-horizon setups, dynamic internal hostnames, or networks with frequent server changes — a scheduled flush removes the issue systematically. RouterOS's built-in scheduler handles this without any external scripting:

Verify the entry was created:

Tune the interval to match the network. Use 1h for volatile split-horizon zones and 7d for stable environments. Remove the scheduler when no longer needed:

Common Misdiagnoses

Flushing the Windows DNS cache but not the router. Most help desk runbooks default to ipconfig /flushdns as the first step. On networks where MikroTik is the resolver, this has no effect — Windows then queries the router, which hands back the stale cached answer unchanged. Flush the router first, then the client.

Blaming propagation when the router is the culprit. If public resolvers (8.8.8.8, 1.1.1.1) already return the correct answer but internal clients do not, the issue is not propagation — it is a local cache problem on the MikroTik. Run dig @8.8.8.8 example.com alongside dig @192.168.88.1 example.com and compare. A discrepancy confirms the router is serving stale data.

Assuming a static entry change takes effect immediately. Updating a record under IP > DNS > Static saves the new entry but does not evict the old cached response. The cache must be flushed separately after every static entry correction.

Misreading Max Cache TTL as a cache duration floor. The MikroTik's Max Cache TTL caps how long a record can be stored — it does not extend short TTLs up to that value. A record with a 60-second TTL is not cached for a week just because Max Cache TTL is set to 7 days. The actual cache lifetime is whichever is lower.

Not flushing after a DoH provider change. When the DoH server URL is updated under IP > DNS > Use DoH Server, cached records from the previous provider remain until they expire or are flushed. Flush immediately after switching providers to ensure all answers come from the new resolver.

DoH, DNSSEC, and IPv6 in 2026

RouterOS 6.47 introduced DNS-over-HTTPS (DoH). If your router is using a DoH server, the cache flush procedure is identical — /ip dns cache flush clears all records regardless of whether they arrived via plain UDP port 53, DoH, or were added as static entries. There is no separate DoH-specific cache store.

RouterOS 7.x added DNSSEC validation. When a zone fails DNSSEC validation, the router caches a SERVFAIL response. After a re-keyed zone or completed key rollover is valid upstream again, the cached SERVFAIL will block resolution until flushed. Check for lingering SERVFAIL entries before a full flush to confirm this is the cause:

For IPv6, the same flush command clears all record types including AAAA and PTR. If your network distributes the DNS server address via RDNSS in Router Advertisements rather than DHCP option 6, some IPv6-capable clients may bypass the MikroTik resolver entirely and query the RA-advertised server directly. Verify with:

Replace the link-local address with your MikroTik's actual IPv6 LAN address. Per RFC 1035, DNS caching semantics are protocol-agnostic — the same TTL rules apply to IPv4 and IPv6 records. If verify-doh-cert=yes is set (the recommended configuration), flushing the cache also triggers re-validation of the DoH provider's certificate chain on the next query — a useful diagnostic step when DoH appears broken after an OS or certificate update.

Reducing Max Cache TTL to Prevent Future Issues

If stale cache entries are a recurring problem, reducing the Max Cache TTL shrinks the window during which wrong answers can linger. The default of 1 week means a record cached Monday morning could serve incorrect data until the following Monday:

For stable networks, 24 hours balances cache efficiency with reasonable freshness. For environments with frequent DNS changes, 1–4 hours limits the blast radius of a bad record without generating excessive upstream query volume. Verify the current DNS configuration including all cache parameters:

The output shows max-cache-size, max-cache-ttl, upstream servers, DoH configuration, and whether remote requests are allowed — a useful snapshot before making changes.