Hi, every time my router reboot (programmed or forced) on Log I see this error (see screenshot below), but everything seems running OK and if I test CloudFlare DoH is on. Maybe is something of no importance but I would like to know if this might be an issue or my router is misconfigured.
Any comment appreciated.
This are some screenshots from my router:
dns error after reboot:
DNS config
DNS Static
NTP Client
Note /IP/cloud/update-time is disabled
Happens to me too, seems to have no difference in the functioning of the dns, it just shows the error because the clock probably gets a little out of sync or something, i'm not sure.
The DoH does work tho and the websites do resolve and it works normally for me despite it giving me that error after updating/rebooting.
Those error lines at #4 and #5 are totally normal. As you can see at that moment after boot, the real interfaces (except for lo - the loopback interface, and the WireGuard interface WG_CORE) are not yet running. The router has no addresses and routes assigned other than what provided by those two interfaces with hardcoded IP addresses. It certainly has no internet connectivity, because the ethernet interfaces are not up, and nothing like DHCP client of PPPoE client are active yet (for the case where you don't use static WAN addresses and routes, but even with static everything, the interfaces still need to be running first).
The IPv4 routing table at that moment only has one active connected route with the destination address being the subnet of the WG interface. The IPv6 routing table only has a ::1/128 active route with gateway being the lo interface. No active 0.0.0.0/0 or ::/0 routes exist yet. Even if you added static default routes, those are not reachable because the interfaces they require are not yet in the running state.
At that moment, some internal part of RouterOS needs to resolve some domain name (I have no idea which part, maybe NTP?), so the dns process tries to establish a TCP connection to Cloudflare. But because there is no active and reachable default route available yet, the routing lookup for the Cloudflare IP addresses all fail and you get the multiple "Network unreachable" result (unreachable because there is no possible routes).
DNS resolution only works once the router has at least one active default route to the internet (one with dst-address=0.0.0.0/0 or dst-address=::/0). Which requires at least one of the ethernet interfaces being running (plus probably some working DHCP/PPPoE, unless your WAN has static IP address and route assignment). And those events are not yet in the log.
MikroTik support #[SUP-225859]: DNS startup errors (RouterOS boot dependencies)
Support reply:
RouterOS services start without waiting for link-up, so any service that needs internet access shows a few such connection failures in the log at startup. The behavior is harmless and no action is needed for the network itself.
The improvement to keep DoH quiet until the device has connectivity - has been passed to our development team, will be considered in the future.
No ETA can be given.
This sort of failure/retry at startup is considered totally normal, and it is very unlikely that it's going to be "fixed". (At most, the error message may be suppressed, which I wouldn't be really be happy about.)
Let's consider a setup where WAN connectivity is provided through an interface in a bridge with DHCP, and we tunnel everything through a public wireguard vpn, and we use their dns.
In this instance, the dhcp client should wait for a link up on the relevant interface before trying to acquire an address. But wireguard should only attempt a handshake once the dhcp client has inserted a default. Then, dns resolution should only be attemtped once the wireguard handshake is done.
You can see that even for a simple case, untangling these dependencies (especially automatically) is not easy. The usual way is for every service to just fail and retry, which is what you're seeing.
@lurker888 Looks like you missed the Reply button. 
I messaged support (about the lack of dependencies) specifically to get this on the developers' radar.
It's not a critical error, but the service definitely launched incorrectly.
Let's hope they get it fixed soon, regardless of "No ETA can be given."
@lurker888
Then maybe such service start related messages (provided that the service re-tries automatically) could be simply sent to null for a given initial time at boot, let's say for 10 or 15 seconds.
That's what I meant by "suppressed". Sometimes it's done with a delay for starting up the service, sometimes (as you suggest) only the error output is hidden. There are implementations where e.g. if there is no route, the error is not produced, etc.
As I said, I'm not a huge fan of these, because regardless of whether it's logged or not, a query was submitted, and a SERVFAIL was returned (or for delayed startup, there's no response), so the error doesn't go away.
Well, seems that conclusion is that this is not an error to worry about. RouterOS developers should solve this to avoid this annoying msg.