If you have a Pi-hole configured on your home lab and you’re anything like me, there’ll be occasions in which you’ll be tinkering with your Pi-hole and affecting your home network.<\/p>\n\n\n\n
But this shouldn’t be the case. You can configure your MikroTik so it automatically takes over DNS resolution upon Pi-hole failure \u2014 seamlessly, with zero manual intervention, and with a Telegram notification so you know exactly what happened and when.<\/p>\n\n\n\n
The setup relies on a MikroTik Netwatch rule that monitors a secondary IP on the Pi-hole VM. When that IP stops responding, MikroTik assumes the DNS service is down and activates a fallback \u2014 by enabling a dormant IP address directly on the router that answers DNS queries itself. When the Pi-hole comes back, the process reverses.<\/p>\n\n\n\n
Here’s the full flow:<\/p>\n\n\n\n
Normal state (Pi-hole up):<\/strong><\/p>\n\n\n\n Failover state (Pi-hole down):<\/strong><\/p>\n\n\n\n Recovery (Pi-hole back up):<\/strong><\/p>\n\n\n\n The reason for the separate monitoring interface is important: you don’t want Netwatch pinging the DNS IP itself ( These are the addresses MikroTik will enable during failover. Replace the interface name with your actual LAN bridge or interface.<\/p>\n\n\n\n Netwatch monitors the Pi-hole’s dedicated monitoring IP. Adjust the interval and timeout to your preference.<\/p>\n\n\n\n Replace This is the detail that makes the whole thing work cleanly. When MikroTik enables a new IP address, clients on the network may still have the old ARP entry cached \u2014 pointing to the Pi-hole’s MAC address. By clearing the ARP entries for both IPs immediately after the switch, you force clients to re-resolve, and they’ll get the MikroTik’s MAC address instead. Without this step, clients could experience a gap in DNS resolution even after the failover has technically completed.<\/p>\n\n\n\n The same logic applies on recovery \u2014 you clear the ARP entries so clients stop pointing at the MikroTik and pick up the Pi-hole again.<\/p>\n\n\n\n With this in place, a Pi-hole restart, a VM crash, or any maintenance you do on the DNS server will cause a seamless failover in under 30 seconds (or whatever interval you set). Your network keeps resolving DNS, your devices never notice, and you get a Telegram message telling you exactly what happened.<\/p>\n\n\n\n When you bring the Pi-hole back up, everything switches back automatically \u2014 including your ad-blocking and local DNS records \u2014 again without touching anything manually.<\/p>\n\n\n\n Tested on RouterOS 7.x. The Netwatch tool and script engine behave consistently across recent RouterOS versions, but always test in your own environment before relying on it in production.<\/em><\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" MikroTik DNS Failover Script for Pi-Hole If you have a Pi-hole configured on your home lab and you’re anything like me, there’ll be occasions in which you’ll be tinkering with your Pi-hole and affecting your home network. But this shouldn’t be the case. You can configure your MikroTik so it automatically takes over DNS resolution … Continue reading “Mikrotik DNS failover script, for Pi-Hole”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[29,11,28],"_links":{"self":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts\/92"}],"collection":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=92"}],"version-history":[{"count":2,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts\/92\/revisions"}],"predecessor-version":[{"id":148,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts\/92\/revisions\/148"}],"wp:attachment":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=92"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=92"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=92"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
10.1.1.10<\/code>) and one dedicated to monitoring (10.1.100.2<\/code>) with no gateway, on a separate VLAN only the MikroTik can reach<\/li>\n\n\n\n10.1.100.2<\/code>) at regular intervals<\/li>\n\n\n\n10.1.1.10\/24<\/code> and 10.1.100.2\/24<\/code><\/li>\n\n\n\n10.1.1.10<\/code><\/li>\n<\/ul>\n\n\n\n\n
10.1.1.10<\/code> and 10.1.100.2<\/code> addresses, effectively impersonating the Pi-hole on the network<\/li>\n\n\n\n94.140.14.14<\/code>, 94.140.15.15<\/code>) \u2014 which still blocks ads and trackers, keeping the experience close to normal even during failover<\/li>\n\n\n\n\n
10.1.1.10<\/code> and 10.1.100.2<\/code> addresses<\/li>\n\n\n\n10.1.1.10<\/code><\/li>\n\n\n\n10.1.1.10<\/code>), because MikroTik would be impersonating that IP during failover \u2014 which would make Netwatch think the Pi-hole is back up when it isn’t. The monitoring IP on its own isolated VLAN can only be answered by the real VM, never by the MikroTik fallback.<\/p>\n\n\n\n
\n\n\n\nPrerequisites<\/h2>\n\n\n\n
\n
\n\n\n\nMikroTik Configuration<\/h2>\n\n\n\n
Step 1 \u2014 Add the fallback IP addresses (disabled by default)<\/h3>\n\n\n\n
\/ip address\nadd address=10.1.1.10\/24 interface=bridge-home disabled=yes\nadd address=10.1.100.2\/24 interface=bridge-mgmt disabled=yes\n<\/code><\/pre>\n\n\n\nStep 2 \u2014 Configure Netwatch<\/h3>\n\n\n\n
\/tool netwatch\nadd host=10.1.100.2 interval=30s timeout=5s \\\n up-script=dns-up \\\n down-script=dns-down \\\n comment=\"Pi-hole DNS monitor\"\n<\/code><\/pre>\n\n\n\nStep 3 \u2014 The down script (Pi-hole unreachable)<\/h3>\n\n\n\n
\/system script\nadd name=dns-down source={\n:global telegramMessage \"DNS Server not detected, backup DNS enabled\"\n:log error \"$telegramMessage\"\n\/ip dns set servers=94.140.14.14,94.140.15.15\n\/ip address enable [find address=\"10.1.1.10\/24\"]\n\/ip address enable [find address=\"10.1.100.2\/24\"]\n\/ip arp remove [find address=10.1.1.10]\n\/ip arp remove [find address=10.1.100.2]\n\/tool fetch url=\"https:\/\/api.telegram.org\/bot<YOUR_TOKEN>\/sendMessage?chat_id=<YOUR_CHAT_ID>&text=$telegramMessage\" keep-result=no\n}\n<\/code><\/pre>\n\n\n\nStep 4 \u2014 The up script (Pi-hole restored)<\/h3>\n\n\n\n
\/system script\nadd name=dns-up source={\n:global telegramMessage \"DNS Server detected, DNS Service Restored\"\n:log warning \"$telegramMessage\"\n\/ip dns set servers=10.1.1.10\n\/ip address disable [find address=\"10.1.1.10\/24\"]\n\/ip address disable [find address=\"10.1.100.2\/24\"]\n\/ip arp remove [find address=10.1.1.10]\n\/ip arp remove [find address=10.1.100.2]\n\/tool fetch url=\"https:\/\/api.telegram.org\/bot<YOUR_TOKEN>\/sendMessage?chat_id=<YOUR_CHAT_ID>&text=$telegramMessage\" keep-result=no\n}\n<\/code><\/pre>\n\n\n\n<YOUR_TOKEN><\/code> with your Telegram bot token and <YOUR_CHAT_ID><\/code> with your chat ID.<\/p>\n\n\n\n
\n\n\n\nWhy Clear the ARP Table?<\/h2>\n\n\n\n
\n\n\n\nResult<\/h2>\n\n\n\n
\n\n\n\n