The router has been updated regularly. It’s one of at least a dozen MikroTik routers on the local network, including a L009UiGS-2HaxD. The local network has redundant uplinks. Routers downstream update properly via this router. The rest of the routers have updated normally.
This router has become stuck at 7.21.3. It has been powered down completely a couple of times, but the the fault remains. DNS has been reconfigured to a single external DNS server, with no effect. As far as I remember there have been no config changes since it was upgraded to 7.21.3. I’ve cleared its cache.
It behaves as if the DNS subsystem is corrupted.
[netadmin@coreb-MikroTik] /system/package/update> print
channel: stable
installed-version: 7.21.3
status: ERROR: could not resolve dns name (timeout)
[netadmin@coreb-MikroTik] /system/package/update>
[netadmin@coreb-MikroTik] /tool> /resolve
domain-name: google.com
failure: dns server failure
I have a pair of raspberry pi based timeservers that have GPS interfaces as local timeservers, synced to STP services on the internet, and to toe PPS signals from the GPS boards.
/ip dns
set allow-remote-requests=yes servers=1.1.1.1
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan type=A
[netadmin@coreb-MikroTik] /system/ntp/client>
You have a default drop policy on the output chain. Now let's look at the accept rules on this chain, there is no rules that make it possible for the router to make outgoing connection to remote port 53, UDP or TCP of 1.1.1.1.
You have one accept rule for dst-address=172.25.25.150 dst-port=514 protocol=udp -> NOT APPLICABLE.
You have one accept rule for connection-state=established,related -> NOT APPLICABLE for new connections.
You have one accept rule for dst-address-list=ospf_traffic protocol=ospf -> NOT APPLICABLE.
You have one accept rule for connection-state=related,new src-address-list=shoka.net-addresses, but the address list shoka.net-addresses is defined nowhere -> NOT APPLICABLE.
You have one accept rule for connection-state=established,related,new,untracked out-interface=ether1-YouFiber src-address-list=private_address -> NOT APPLICABLE because outgoing connections to 1.1.1.1 will not have source IP in private subnets.
You have one accept rule for protocol=icmp -> NOT APPLICABLE.
Conclusion: DNS queries to 1.1.1.1 will be dropped by the rule:
add action=drop chain=output
My guess: You once had address list entries for the list shoka.net-addresses that contained your public IP addresses, so it worked back then. Now the address list is gone and your router can no longer make outgoing connections to the internet (save for a couple of exceptions).
I have internal name servers that all devices in the net use. In the original (designed) set up those are the only DNS devices that the rest of the network uses. Those names servers are dnsmasq(pihole) → unbound for external addresses, and dnsmasq(pihole) → NSD for internal addresses.
Trying to trace the DNS issue, I replaced the normal internal DNS servers with an external server 1.1.1.1
The issue I’m trying to resolve existed while the system was using the normal path.
I’m old and stupid, and that external DNS block has been in place for ages to stop anything leaking past pihole. I’ve gone back to the intended internal servers. Issue still persists.
Even if you change the DNS server to the internal private address, with your output rules the router still won't be able to make queries (packets with connection-state=new on chain output).
Ignoring the rules with non matching connection-state and port or protocol, you have one accept rule left with non existing address list, and one rule with src-address-list=private_address which is ok if talking to internal addresses, but that rule has non suitable out-interface (being the WAN interface).
In the end only the drop rule at the bottom of the output chain would match.
You're still not allowing the device to connect to Mikrotik's servers to download the update packages
If you're so concerned about the router phoning home (which during an auto-download upgrade you're kind of instructing it to do,) why not just upgrade manually?
As @lurker888 said, your router is still not able to make connections to the outside internet (apart from a few exceptions) with the way your output chain is configured. Now you have access to local DNS server, and ping to the outside work because you explicitly have this rule:
If you are paranoid and don't want the router to make arbitrary connections to the internet, you can do this to limit it to the upgrade function of RouterOS:
Add an address list entry for upgrade.mikrotik.com:
after a little thought