There is a network structure like this:

Location A
Has internal DNS server (virtual server acting as cache and serving internal zones of local names)
All clients in tha Location has DNS pointed to that internal DNS server so all can resolve local names without knowing IP addresses which is obvious.

Latelly I added a new location with site-to-site vpn to mikrotik and connected second Location B

In that Location B there are no internal servers but I'd like to have dns resolving of internal hostnames which can provide DNS server from Location A.
Yeah I know, I can set in /ip dhcp-server network , the dns-server= with IP of DNS server from Location A, but when that server goes down for a while , clients in Location B can't surf on local hostnames. Need use IP instead. So is it possible to set mikrotik on Location B as DNS slave which will have all zones from DNS server on location A?

Is your A dns a MIkrotik too? Then you could just sync (scripted) the static entries from A to B, and still have A as remote of B.

You can set A als the DNS server for B but it means that DNS won't work when DNS server A is down.
There is no such thing as a secondary DNS server that transfers zones from server A and works when server A is down in RouterOS.

(not that would be any use in "surfing the Internet", of course!)

Is your A dns a MIkrotik too? Then you could just sync (scripted) the static entries from A to B, and still have A as remote of B.

It's linux machine with bind

If A isn't frequently updated with internal dns changes, you could define these manually as static in B. For internal servers this would preserve name resolution.
Otherwise some bash scripting to export bind local zone and push to Mikrotik as a file, to be processed by internal script maybe?

Seriously? So why we put second, third server in /ip dns ?
If we set two servers in router in location B - One from location A and second can by any server I would like for example 1.1.1.1 so if server in Location A goes down , users in location B should still be able to surf Internet using name resolution from 1.1.1.1

Note that this configuration is not guaranteed to work.
The DNS in MikroTik is basically a caching resolver with the option of a few static names for local use.
It cannot do a zone transfer from your local DNS, unless you hack it together with scripting and some usable DNS zone format.
(e.g. run some export on your local DNS server, convert it to MikroTik commands, then download those on the router and execute them)

But a caching resolver with a number of next-level DNS resolvers configured like in MikroTik is usually not guaranteed to use
these in the fixed order that they appear in the config. So it is not sending all the queries to the first server, when there is no reply
send them to the second server, and so on until there is a reply or there are no more servers.
Doing so would be inefficient in the case a server (the first server) is down, because then from that moment all queries will first
have to time out before the second server is tried, and the DNS would become very slow.

So what most resolvers do: whenever a timeout occurs move on to the next server. From then on send all queries to that server
first, until another timeout occurs. Then set server 3 as the first to try. This will proceed in a round-robin fashion: when the last
server has a timeout, set the first as active again.

Now here is your problem: timeouts are quite regular in DNS. They are not caused by your own infrastructure or your ISP's.
Some queries just don't return a response. The DNS servers of the domain may be all dead, may have gone out of existence,
whatever. Each time you hit such a badly configured domain (and it is even more prevalent in reverse-DNS lookups!) your
resolver will move on to the next server. Not a problem normally, actually quite good: it will balance the load over the different
servers. When everyone sets 8.8.8.8 as first server and 8.8.4.4. as second (or maybe 1.1.1.1 and 1.0.0.1) that first address would
get much more load than the second. But in reality they are both used.

Now here is your problem: when you query your local domain on 1.1.1.1 instead of your local DNS, the resolver will return
NXDOMAIN (no such domain) and the MikroTik will just forward that to your user. NXDOMAIN is a failure code, it will NOT
make the resolver try another server. A timeout will, but such a response will not.

So by adding an external resolver to a setup like you have (where there is an internal DNS that serves some local-only zone(s)
but also is a resolver for external names) will make the system unreliable or outright fail.

What you actually want is to tell RouterOS to send queries for specific domain(s) (your local one(s)) to DNS server in location A, while using resolver(s) from /ip dns for everything else. It's basic feature supported by probably every other DNS software, but unfortunately not by resolver in RouterOS.

Current sort-of-usable better-than-nothing solution for RouterOS is old L7 hack, where you use L7 matcher on client's udp packets with queries and redirect them to the right server using dstnat. It bypasses cache on router, doesn't work for tcp queries, can't be used with IPv6, but if you can live without these things, it's usable.

It was requested several times in this forum over the years, but the only response from some MikroTik's employee I remember was something like "just set up a server with bind", which is ridiculous solution. It's huge overkill if resolver in RouterOS was otherwise enough for user, and also because this feature is mainly attractive for smaller users without proper DNS infrastructure. If you set up server with bind, you might as well setup proper zone transfers and everything.

Try to send feature request to MikroTik's support. I plan to do it myself, because it's crazy that this feature is still not there, but I don't know when I'll get to it (I'd like to make it really convincing). But the more people ask for it, the better.

So conditional forwarders, send everything for X domain to X ip and all else to public dns, can't be done on mikrotik but you can use your primary dns as a dns-server in the mikrotik and in bind allow the mikrotik to query internal zones, recursion and access the cache so if bind already knows the A record for a host then don't query it again, and i suppose you have an internal zone and external using views so bump up the global $ttl to a few days that way even if bind goes down the mikrotik will cache local dns records for longer but you won't be able to query external hosts if primary dns goes down.
You could also do something very sloppy but it would work, the above plus add a public dns to mikrotik aswell, if clients query an internal ip not in your mikrotik cache it might query internal or publicdns according to which dns it chooses(round robin) obviously internal queries to the public will fail but if it goes to the internal it'll get a reply and cache the record, in this scenario if primary site were to go down you'd still have working name resolution but some queries will fail, users might have to refresh a page and such because it fail getting an internal dns record from a public dns.

Basically you described what I was asking. When primary dns (for external and internal zones) goes down, second will provide queries for the new names which are not cached and rest will go from mikrotik cache.

@RoadkillX: Trouble is, it's all wrong (it's nothing against you).

If you make DNS server in Location A (which can resolve both private and public names) your main resolver, then Location B becomes dependent on Location A. And it's not about those local names, that's just a small, less-important part. The tunnel must not ever go down, because when it does, Location B is effectively without internet, except for few already cached records, but many sites use very short TTLs, so it won't last for long (Location B would have complete internet access of course, but there's not much joy without DNS).

"DNS lottery" with combined internal and external resolvers is hardly usable.

Dedicated DNS resolver in Location B, while in fact a proper solution, has major downsides too. First it's overkill, you need another machine for that. Anything would do, even an old RasPi or something, that's not a problem. But you need to keep it alive, because it becomes the single point of failure. Unless you want to add more than one, but it's double overkill, when you remember that access to those local names was supposed to be only a little extra.

Conditional forwarders is the way to go.

@RoadkillX: Trouble is, it's all wrong (it's nothing against you).

If you make DNS server in Location A (which can resolve both private and public names) your main resolver, then Location B becomes dependent on Location A. And it's not about those local names, that's just a small, less-important part. The tunnel must not ever go down, because when it does, Location B is effectively without internet, except for few already cached records, but many sites use very short TTLs, so it won't last for long (Location B would have complete internet access of course, but there's not much joy without DNS).

"DNS lottery" with combined internal and external resolvers is hardly usable.

Dedicated DNS resolver in Location B, while in fact a proper solution, has major downsides too. First it's overkill, you need another machine for that. Anything would do, even an old RasPi or something, that's not a problem. But you need to keep it alive, because it becomes the single point of failure. Unless you want to add more than one, but it's double overkill, when you remember that access to those local names was supposed to be only a little extra.

Conditional forwarders is the way to go.

I see you know the theory very well, i know both downsides and i believe i explained them both, if you can live with them implement it if not then find a better solution, i was just trying to provide a possible solution however imperfect, i'd never do dhcp or dns on a router.

And i think you misunderstood option 2 which is using site A and public as dns forwarders on the router if Site A goes down they'll still have internet name resolution with public dns and local name resolution from cache but some queries will be dropped since when the router looks for a DNS server to query it will be delivered with round robin if he gets the public dns for an internal host lookup it'll fail and return an NXDOMAIN since public dns won't know a private record. It all sounds much worse then it actually is.

And i think you misunderstood option 2 which is using site A and public as dns forwarders on the router if Site A goes down they'll still have internet name resolution with public dns and local name resolution from cache but some queries will be dropped since when the router looks for a DNS server to query it will be delivered with round robin if he gets the public dns for an internal host lookup it'll fail and return an NXDOMAIN since public dns won't know a private record. It all sounds much worse then it actually is.

Well, I would consider random NXDOMAIN replies on local names a pretty fatal problem (remember this happens all the time, not only when something is down!)
but of course you will have to decide that yourself. It depends on what the local names are for, of course.

That's the thing I referred to as "DNS lottery", and no, it's not good. It's recipe for constant complaints that it doesn't randomly work.

One more thing that could be done, but it's a little desperate too, is to really turn RouterOS in Location B into poor man's slave DNS. Assuming that only basic A/AAAA records would be enough, it wouldn't be too hard to write an external script to do AXFR from master server, and then either feed A records to router in Location B using API, or publish them on some http(s) server (in Location A or public one, it doesn't matter) from where it could be downloaded by script running on Location B router and processed by that. It could be pretty reliable, without unwanted side effects, as long as no "advanced" record would be required.