Well, I actually always try to type trailing dot, because I don't want any resolver to try to interpret whatever I wrote in any other way but exactly what I wrote... unfortunately, I often have to remove it, because crappy software is not up to the standards 
ROS currently supports DHCP Option 119 to specify the search domains. It's having an apparently non-RFC compliant DNS resolver notwithstanding (can't verify - I don't use it . . . I use a full current deployment of bind (fronted by AdGuard in a container to wireless clients), and not just a forwarder . . .). Like a lot of things, they have a place and value for users who truly understand thier use.
Are you saying that the default DNS resolver policy is generally stupid or what??
If you're not happy with the default configuration, just configure the resolver policy the way you want it. On a corporate network, that's something you normally do as part of the basic setup.
Both Windows and Linux let you control search behaviour in detail. If you don't want "mikroti.com" to ever become "mikroti.com.provider.com", then simply configure the resolver accordingly. That's more about knowing how to configure the resolver than a flaw in DNS.
I am unhappy with the general configuration of systems, yes. When you install e.g. Debian Linux it will ask you (or it will get from DHCP/DNS) a hostname and a domainname, and then it will put the domainname in the "search" option of /etc/resolv.com! Stupid! I always remove that and often quite some force is required to prevent some stupid mechanism from putting it back.
This serves no purpose, especially in a modern network. Let the DNS resolver only resolve the names you ask it to resolve, no "AI" to expand that.
I fully agree with that. The DNS resolver in RouterOS should accept domains with trailing dot.
In fact I am in favour of DITCHING THE RESOLVER and replacing it with "unbound", so we do not have to live with, report, and wait for correction of such stupid bugs. The code has been played with enough, and it still doesn't support DNSSEC.
Does this release (7.25beta5) fix CVE-2026-84411 vulnerability?
Version 7.25rc1 has been released: