No, I meaned if we use routerIP in dhcp dns for both case (adguard home up/down), then seems mobile clients Ip not seen only routerIP, maybe Becouse they use also adguard on it.
So the question is if it good idea to switch also dhcp dns for netwatch (becouse mobiles can stuck with old dns Ip server) even if we switched to new one?
I have only default firewall rules for now. With some disabled that was sujestion from copilot .
Copilot was sujestion was to use routerIP in dhcp and use vlan for adguard home for clients can be seen by adguard home if using routerIP in dhcp dns. will try it later when will make vlans.
But for now i made two examples :
/tool/netwatch add name="DNS Failover Monitor" comment="Monitors AdGuard DNS - [ switches DHCP, firewall, and router DNS to DoH on failure ]" \
type=dns dns-server=$AdGuardIP record-type=A host=$TestDomain interval=10s \
down-script="\
#down-script
:global RouterDNS "192.168.0.1"
:global DoHServer "https://security.cloudflare-dns.com/dns-query"
/ip dns set servers=1.1.1.1,1.0.0.1 use-doh-server=$DoHServer verify-doh-cert=yes
/ip dhcp-server network set [find] dns-server=$RouterDNS
/ip firewall filter enable [find comment="Block DNS to AdGuard when DOWN"]
/ip firewall filter disable [find comment="Block DNS to Router when AdGuard UP"]
:log warning "DNS FAILOVER: AdGuard DOWN Router DoH + AdGuard DNS blocked"
#up-script
:global AdGuardIP "192.168.0.198"
/ip dns set servers=$AdGuardIP use-doh-server="" verify-doh-cert=no
/ip dhcp-server network set [find] dns-server=$AdGuardIP
/ip firewall filter disable [find comment="Block DNS to AdGuard when DOWN"]
/ip firewall filter enable [find comment="Block DNS to Router when AdGuard UP"]
:log info "DNS RESTORED: AdGuard UP → AdGuard DNS allowed + Router DNS blocked"
/tool/netwatch add name="DNS Failover Monitor-2" comment="Monitors AdGuard DNS - [ switches router DNS on failure ]" \
type=dns dns-server=$AdGuardIP record-type=A host=$TestDomain interval=10s \
up-script="\
:global AdGuardIP \"192.168.0.198\"; \
/ip dns set servers=\$AdGuardIP; \
:log info \"DNS RESTORED: AdGuard UP → Router using AdGuard DNS\"; \
" \
down-script="\
:global RouterDNS \"9.9.9.9,149.112.112.112,1.1.1.1,1.0.0.1\"; \
/ip dns set servers=\$RouterDNS; \
:log warning \"DNS FAILOVER: AdGuard DOWN → Router using Quad9 + Cloudflare\"; \
"
19 X ;;; Block DNS to Router when AdGuard UP
chain=forward action=drop protocol=udp dst-address=192.168.0.1 dst-port=53
20 X ;;; Block DNS to Router when AdGuard UP
chain=forward action=drop protocol=tcp dst-address=192.168.0.1 dst-port=53
21 X ;;; Block DNS to AdGuard when DOWN
chain=forward action=drop protocol=udp dst-address=192.168.0.198 dst-port=53
22 X ;;; Block DNS to AdGuard when DOWN
chain=forward action=drop protocol=tcp dst-address=192.168.0.198 dst-port=53
23 X ;;; Block external DNS
chain=forward action=drop protocol=udp dst-port=53
24 X ;;; Block external DNS
chain=forward action=drop protocol=tcp dst-port=53
No. More just clarifying since I'm not sure what subnet the adguard lives on.
If clients have adguard, then yeah perhaps they be a reason the router's DNS might not see it since it may have already convert it to DoH.
Well, IDK. If you want a more deep dive, you might want to start a new thread with your config.
To be honest, I'm not sure why there is any firewall rules, perhaps you have your reasons (e.g. if adguard also does other filtering/blocking). But if the goal is to re-set /ip/dns to use Quad9/CF when your local AdGuard is down, then you don't need to mess with firewall filters. And if DHCP server send client device through the MikroTik DNS, there should always be a valid one there with the netwatch rule. And you would not want to block access to MikroTik's DNS since that what DHCP is telling clients to use.
One thing is you cannot use the variables $AdGuardIP and $TestDomain in the /tool/netwatch add since they don't exist. Now perhaps they do since you were testing and were already when you did the add, in which case they be saved...
No matter what scripts you use, the clients need to renew the leases before they can see any changes to the DHCP server configuration, thus making these scripts useless, unless you’re lease time is in seconds, which is another bag of worms.
, but official image.