Force refresh of one dedicated CNAME?

RouterOS Scripting
1

My setup includes a “main” router and a travel router (both MikroTik) which creates a WireGuard tunnel to the main one, the main router is “known” via DDNS.
When v7.19.2 came out, I did a remote update of the main router.

After the main router restarted, the travel router was not able to re-establish a WireGuard tunnel. The reason was that the travel router cached the old DDNS entry.

Is there a better way to force the resolution of the DDNS name before attempting to establish the WireGuard tunnel (on the travel router side) than

/ip dns cache flush

?

Maybe

:put [:resolve domain-name="your-cname.ddns-provider.com" server=IP_of_DNS_server_of_DDNS_provider]

Would this also update the internal cached name?

2

Hi,

Isn’t the simplest solution solve your problem?

/ip dns cache flush
3

It won’t since your :resolve command doesn’t query it’s own internal DNS server. Are you sure the original problem was because of your router cache? I’m inclined to think that your main router got a new public IP, and there was a delay in DDNS update throughout global DNS network.

To answer your question in general, probably the easiest solution is to avoid caching for one entry. You can configure DNS forwarders and then add a static FWD entry for your DDNS name.

4

You could also schedule a script on the travel “client” router to periodically (on a schedule) check remote WireGuard IP and toggle the connection off and on to re-initiate the connection.

:local peername "xxxx.sn.mynetname.net"
:if ([/ping 10.11.11.2 interval=1 count=5] = 0) do={
/interface/wireguard/peer disable [find where endpoint-address ~ $peername]
:delay 5
/interface/wireguard/peer enable [find where endpoint-address ~ $peername]
log info "WireGuard peer $peername toggled"
}

This would be a more reliable way to avoid these issues and covers both local or remote DNS issues.

Actually, as I think more about it, the issue was most likely not DNS at all. WireGuard peer resolves the target peer DNS only once upon bringing the connection up. After that it just keeps using the same IP. Since there is no concept of session with WG, it never attempts to re-resolve DNS. Hence the need to toggle the peer.

5

It feels a bit disruptive (and might not help, if the DNS server of the ISP has also stale data).

6

Flushing cache is not disruptive, the responses might come a few nanoseconds later due to being re-requested.

7

As it was said, it’s a normal procedure as cache is for speeding up DNS queries so there HAVE TO be a procedure to refresh them manualy.
That is why Linux, Windows, MacOS, … allow it …

sudo systemd-resolve --flush-caches
ipconfig /flushdns
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

If you suspect that your ISP has invalid cached data then switch to other DNS source however there is always a chance that your DNS would be served by “bad” server.

8

This sounds very much like what could have happened. Thanks.

Is there a way I could use the logic from your script to trigger a WireGuard reconnect?

9

Not sure I fully understand what you are asking. My script above does exactly that—reconnects WireGuard if pings to the remote router are not going through.