Hello everyone.
It would great to have split DNS features. That is common practice in an enterprise, to redirect DNS request for own domain from internal network to local DNS server, and passthrough other requests to a global DNS server. Workaround with DNAT DNS request with layer7 haven't enough flexible and don't provide DNS failover.

It has been requested many times.
Probably the easiest thing to implement would be the addition of static NS records (no idea why that has not been done yet, it has been asked for so many times), but also multiple DNS server instances like I described here: viewtopic.php?f=1&t=45934&p=741880&hili ... es#p741880
would be very welcome.

For the record, failover with L7 should be doable. If you give two or more different resolvers to clients, you can do L7 and forward each address to different internal resolver. If one fails, there will be regular timeout and client will try another. It's of course not an argument against proper support for this, because L7 way is still severely limited.

The worst is that (almost) all requested DNS improvements should be easy to implement, no major changes required, and still nothing is done. Different servers for different domains need one additional check against some list, to decide whether to ask global servers or different ones. Different resolver instances mean taking existing server and running it twice, bound to different addresses (ok, and some work on configuration interface). Sometimes requested additional static record types can be added using generic syntax like DHCP options, and even though it's not exactly user friendly, it allows to add anything. And that should be it for basic stuff. Anything else can wait after ROS v7 is out.

It seems that it is all for nothing anyway, as now the browser manufacturers have started phasing out DNS.
They will use DNS-over-HTTPS by default, which makes it impossible to host your own DNS service with local additions...
And even the "canary domain lookup" performed by them cannot be set in MikroTik routers (the A/AAAA lookup of use-application-dns.net should return NXDOMAIN, they don't permit some fixed IP address like 127.0.0.1/::1 as an answer)

It looks like running your own DNS resolver on your router is ending...

That seems like a horrible idea. Thumbs up for privacy, but sending all users' DNS queries to some other party chosen by browser makers is much less exciting. Now I can have independent DNS resolver in my network, don't rely on any other parties than I have to, be sure that I validate DNSSEC, etc. Then all queries will go to someone else, I'll have to rely on them (even though they probably won't have outages), trust them to not fiddle with results (because application-level validation won't happen anytime soon, if ever).

And as a extra bonus, those governments that like to censor stuff and so far were fine with the soft way (DNS filter on ISP's own resolvers only, so anyone switching to e.g. 8.8.8.8 could get around it), will now have reason to find some more annoing way how to force their views. I'm a little affraid about what they will come up with, as I don't believe they would just give up.

Anyway, I don't see any reason to bury router's DNS resolver yet. We just got one more quick feature request, to be able to add NXDOMAIN static records, and that's not difficult. And in longer term, support for own DoH client, to be able to use it with some trusted remote resolver.

It sure is a horrible idea, but it fits in the line of horrible ideas that the browsermakers have launched in the past years (and this forum shows the problems they have caused).

I already filed a feature request for NXDOMAIN static records some time ago for another purpose: to allow answer NXDOMAIN to *.168.192.in-addr.arpa via regexp static DNS entry instead of forwarding those queries to the global DNS system.

the feature made available in RouterOS v6.47 stable according to source