It would be very nice if the built-in DNS server could selectively forward domains to servers. In dnsmasq this is done with the syntax:
server=/lan/10.1.2.3
This will send all requests ending in .lan to 10.1.2.3.
This is especially useful when e.g. the Active Directory servers are behind a VPN connection. If the VPN connection breaks, it is still possible to reach the rest of the Internet. Without this feature, all DNS requests have to go to the Active Directory servers.
I second this request
I had the same problem, but found at least temporary solution.
Copy&paste from my blog: http://brainsuckerna.blogspot.com/2010/02/mikrotik-routeros-and-domain-active.html
I’m using mikrotik router at home, with RB150 constantly handling connection to provider (PPPoE) and to my office (VPN over internet).
However since router is using provider’s DNS, it is not possible to work with shared folders or perform any other domain tasks (while office IPs are readily accessible). Anything using active directory will fail, since any computer in home won’t be able to resolve domain controllers.
How to fix this:
/ip firewall layer7-protocol
add comment=“” name=activedirectory regexp=
“\x06\x5Fmsdcs\x06itsoft\x02by”
/ip firewall mangle
add action=mark-packet chain=prerouting comment=“” disabled=no dst-address=
192.168.0.200 dst-port=53 layer7-protocol=activedirectory
new-packet-mark=activedirectory passthrough=yes protocol=udp
/ip firewall nat
add action=dst-nat chain=dstnat comment=
“forward active directory DNS requests” disabled=no dst-port=53
packet-mark=activedirectory protocol=udp to-addresses=10.10.0.201
to-ports=53
that’s all. it works, at least in my particular configuration.
may be there are easier solutions, but I wasn’t able to find any.
I’m deeply impressed by your ingenuity. I don’t think we’ll be able to support that solution for our customers, but it’s really really clever.
Hopefully Mikrotik will come up with something simpler.
I had similar problem, not with Active directory, but I also had need to have internal DNS resolving.
I solved it bu setting everything to used my internal DNS server which responds to all requests. If requests for internal domain, it proper information as he knows it, but if request is for regular internet domains, it would then ask ISP DNS about it and then pass on the response.
You can already do this with regular expression matching in DNS on RouterOS.
To resolve everything ending in .lan to 10.1.2.3:
/ip dns static add name=".*\\.lan\$" address=10.1.2.3
Ex.
my.domain.lan → 10.1.2.3
domain.lan → 10.1.2.3
sever.lan.com → not resolved
server.lann → not resolved
Router OS uses POSIX basic regular expression matching:
http://en.wikipedia.org/wiki/Regular_expression#POSIX_Basic_Regular_Expressions
Nice to know, but that’s not it. In fact, there are three different things here:
It will return an A record pointing at 10.1.2.3 for any A record query with hostname ending with “.somedomain”
It will forward any query with hostname ending with “.somedomain” do different dns server. Then different domains can resolve correctly e.g. mail.somedomain to 10.1.2.3, www.somedomain to 192.168.1.2, etc.. as long as the given server controls all of them, including subdomains.
I’d tell RoS that domain “.somedomain” is controlled by dns server 10.1.2.3. Then client sends question for “www.subdomain.somedomain”. RoS asks 10.1.2.3 for it and 10.1.2.3 replies “I don’t know, whole subdomain.somedomain is controlled by 10.20.30.40”. RoS sends original query to 10.20.30.40 and gets reply that www.subdomain.somedomain has ip address 192.168.44.11.
There is no way how to do this in current RoS and the only solution is recursive resolver, not just forwarding as the current one.
Ahh I see. Sorry for my misunderstanding of the original post.
Personally, I use Bind DNS server and it handles DNS very well (as it’s a DNS server). If you have a RouterBoard that supports MetaRouter, or x86 using KVM, you could install OpenWRT and use Bind on top of RouterOS.
I’ll second this as well, it shouldn’t really be that complicated to implement.
First post in this topic was created 2 years ago, but this wanted feature didn’t realized yet. It’s make me depressed. 
I second Wakko, that would be a great functionality for remote sites that uses VPN to access servers… They would not loose dns resolution when the VPN fail.
We currently use the brainsucker’ workaround for small sites but it is somewhat hard to maintain.
Just for closing this post:
We need to resolve server1.office.local, work.office.local for remote users
Create l7
/ip firewall layer7-protocol add name=remote_office regexp=office.local|[0-9]+.[0-9]+.168.192.in-addr.arpa
Create 2 NAT rues
/ip firewall nat add action=masquerade chain=srcnat disabled=no protocol=udp dst-port=53
/ip firewall nat add action=dst-nat chain=dstnat disabled=no dst-address-type=local dst-port=53 layer7-protocol=remote_office protocol=udp to-addresses=192.168.1.1 to-ports=53
This info was taken from WIKI site of Netair.by
Erm, do you really think this was worth digging up a thread after six years? And how exactly is this info supposed to close it?
It’s still the same old and ugly (even though it’s pretty smart, no doubt about that part) L7 hack, which does bypass router’s DNS cache, doesn’t work with tcp, can’t be used with IPv6, and it’s just not admin-friendly at all. And as a bonus, your regexp is wildly inaccurate, it matches office.local, but also notoffice.local, office-local.com, …
Your only excuse is that any exposure for this missing feature is a good thing. 
I have two questions:
1.) Is there any chance to make it work for TCP? I guess the reason is that the actual content is in the packets after SYN, SYN-ACK, ACK so that the first three packages of the connection cannot be marked?
2.) I now have this setting:
[admin@ugate] /ip firewall layer7-protocol> print
# NAME REGEXP
0 localdns (intra.mydomain.net|168.192.in-addr.arpa|7.10.in-addr.arpa)
This works. However, if I replace “.” by “.” or “\.” it does not work any more. Shouldn’t this be a valid regex?
No, because when you get match for your L7 filter, connection is already established and can’t be redirected elsewhere. Luckily, clients don’t seem to use TCP (but it can happen).
It should be proper regexp, sure. But DNS packets do not contain dots. Instead, they have single bytes containing length of next name part. For your individual domains it’s:
\x05intra\x08mydomain\x03net
\x03168\x03192\x07in-addr\x04arpa
\x017\x0210\x07in-addr\x04arpa
To help with false positives, you can also add this to the end:
.\x01
where “.” matches record type (with exception of some non-common ones with code > 255) and \x01 is query class, which is always 1 (for normal use). It’s not too important with complex enough domains like yours. Without it, you’d get false positive for e.g. intra.mydomain.net.someotherdomain.com, but it’s unlikely to ever have query for such name.
Sob, you just made my day, i was having issues with CNAMES that had my domain name as part of it, like domain.com.s3.amazonaws.com… your tip of .\x01 fixed it!
I’m voting for this feature. Easy to implement - still not implemented.
Voting for this feature
Do not vote for features that I propose. This feature request (from 2008) is a good example of why my current score is zero feature requests accepted.
Find someone with more influence with Mikrotik to propose the features you need.
This is available now in RouterOS 6.47beta60!