At least once a day MIkroTik stops resolving anything via first DNS server (192.168.10.1 in this example)
[myuser@maplite] /ip dns cache> :resolve gateway.lan
failure: dns name does not exist
[myuser@maplite] /ip dns cache> :resolve desktop.lan
failure: dns name does not exist
It seems that the way how multiple DNS servers, set up in /ip dns, are utilized in ROS, is to use one until it fails then switch over to another one and use that one until it fails, etc. So use of multiple DNS servers is fine as long they all resolve whatever needed.
In your case, the second DNS server doesn’t resolve “your” .lan TLD … so if your application depends on proper resolving of .lan hostnames, you should remove any other DNS srrver from /ip dns configuration.
You haven’t provided much context, but I suppose 192.168.10.1 to be a local one (another Mikrotik?) which can resolve *.lan while 1.1.1.1 is an external one which is obviously unable to resolve *.lan.
The local resolver does use the configured downstream servers as backup of each other, but in a different way than you probably expect - it asks one of them, and if it provides any answer, including an empty one, it uses that answer, caches it if it contains any useful information, and forwards it upstream, i.e. to the querying external client or internal application. Only if no response comes, it tries the other server and if that one answers, the resolver keeps using it also for the subsequent queries, until it eventually doesn’t answer so there is a reason to try with yet another one (which may be the one used previously if you have just two).
Now once you indicate the 192.168.10.1 as a server to be used, its response is cached, but it does not make the resolver start using that server for subsequent queries, it remembers the last one it chose on its own until it stops responding.
To date you cannot tell the embedded resolver to use a particular downstream server for a particular domain suffix. Only ugly workarounds allowing that are possible, which involve layer7-protocol firewall rules and some in-depth knowledge of the DNS protocol packet format and of Mikrotik’s handling of packet data by means of regular expressions.
Hm, ok. But what if someone uses several networks with their own DNS servers and wants to resolve custom domains for appropriate network?
For example:
Network 1: 172.17.1.0/24, DNS server 172.16.1.1, TLD: .lan
Network 2: 172.17.2.0/24, DNS server 172.16.2.1, TLD: .local
Network 3: 172.17.3.0/24, DNS server 172.16.3.1, TLD: .corp
Also I did not find any settings to “reset failed status” for DNS server and start using first one again. During my troubleshooting I have found that MikroTik stops using first DNS after one failed attempt and then switches to another. In my case first server is behind VPN tunnel and sometimes there are delays which can cause such issues, but I still want to resolve “.lan” domains via this network (or at least, get resolve error when VPN is down).
Specifying only first server in DNS settings is not a good idea for me, because when VPN becomes unreachable, DNS resolve stops working for any domains.
And I’m wondering why MikroTik does not try to use another server when gets failed resolve message from one of DNS servers in this list.
As said above, there is no ready-made way for that, only workarounds. This thread has it all, look mainly at @Sob’s posts. If you would like to redirect Mikrotik’s own DNS queries instead of redirecting those received from external clients, it takes an additional layer of headache.
Use regexp=“\x03lan.\x01” instead (3 = length of “lan”). Just the “.” alone means any character, so if there would be TLD .lan, your regexp would match too.
MikroTik ignores all null bytes in any packets, so when I write l7 filter regexp for any type of data, I should just skip any sequence of 00’s.
If it’s wrong, please correct me.
0000 04 74 65 73 74 03 6c 61 6e 00 00 01 00 01 .test.lan.....
^^ null byte
^^ ^^ record type (16 bits)
^^ ^^ class (16 bits)
So a foolproof way (from two posts later in same referenced thread) should be:
\0x03lan...?.?$
Which means “.lan” followed by 2-4 non-zero bytes at the end of packet. In practice, class is always 1 and record types over 255 are only few and nothing you’ll see in regular network.