I think a nice feature would be to specify the source address to use for DNS queries made by the Mikrotik DNS Server.
I use DNS based content filtering for several of my clients - many of these clients have multiple IP addresses with different policies for each IP (hotspot network, corporate network, etc). I cannot use the MT for DNS in a lot of these scenarios because it doesn’t allow me to specify which IP should make the request. This affects which policy is being applied to the DNS request and either blocks or allows content which shouldn’t be.
If you don’t want to hard-code the gateway field then you might be able to get away with using another IP on the MT box so it routes to itself and then on to final destination.
Would this not redirect ALL traffic destined to that DNS server with the preferred source IP specified? If so, this wouldn’t work for my application - need to allow certain requests (say from inside LAN AD server) to come from one source IP and other requests using the MT as DNS server to come from another.
Honestly, it would be nice to be able to specify source IP for any service where the router is making a query or request - including NTP client and others.
We are using OSPF where routers communicate via small subnets between each other and this subnet is not NATed on main router. Thus OSPF routers can’t connect to internet. But if they would use different source-ip they could.
/ip firewall nat add action=src-nat chain=srcnat dst-address={IP adr. of DNS upstream} dst-port=53 protocol=udp to-addresses={SRC IP which you want to use}
remember the SRC IP you want to use here has to be a local ip address on the router which can reach the DNS upstream (routing-wise) for the srcNAT to work correctly
Maybe I’m totally confused, but I understand OP to mean that he wants to make the DNS server’s queries (when recursing) to come from a different source address depending on who the request was received from.
The in-built resolver doesn’t support anything like this. This would also necessarily involve having separate caches, upstream/filtering/forwarding/static entry configurations, so in essence it would mean running several DNS recursor processes. This is not necessarily invalid and can be done in containers, on your on-prem servers or in case you prefer in the cloud (maybe over an encrypted channel e.g. wireguard). The appropriate resolvers can be advertised via DHCP to the separate networks, even filtered (or port 53 dst-natted) in the firewall.
Routers generally provide an in-built DNS resolver only to be a “one-stop shop” for setting up simple networks and generally don’t include the full feature set of a complete DNS server (and they do similarly with other in-built services.)