It would be good to have an option to set NS, not just A records as static entries in Mikrotik DNS. That would be really helpful for managing internal DNS for larger networks.

for larger networks you can opt for bind server and use routers as DNS cachers, as what they are.

For example, run BIND server in virtual machine with 256MB of ram and some storage space (enough to install os and store some config)

What about not so large networks where dedicated machine would be overkill? It would be really cool feature there.

E.g. small company with one internal Windows SBS server and MikroTik router as internet gateway. There's internal company.lan domain and you want to use it to give various other devices DNS names, because it can save few headaches in the future, compared to using numeric addresses. But you don't want to use the server as DNS resolver for client computers, because in unfortunate case when something happens to it, they would lose internet access (there's not much joy without DNS). So you need MikroTik router to be resolver for clients, but you also want it to be able to resolve names under company.lan.
It's possible to solve it using L7 trick, but it in fact sucks, because in most cases it means redirecting queries from client computers, not the queries sent by router (router's regular DNS servers are reachable through WAN and the outgoing DNS packets are decided to go there from the beginning, while the internal server is on LAN and it's too late to redirect the packets there). And generally there are enough ugly NAT rules in firewall already, even without this.

Per domain forwarding in ROS DNS cache would be real nice and clean solution. It can't be so hard to implement. And IMHO it's much less crazy than static entries using regular expressions that are already supported.

Strange, allowing NS records is just matter of good will, and it requires almost no efforts to be implemented.

Oh well, SMB features are so higher level priority than DNS features for a router, you know... ahem.

You've got the point. SMB requires lots of resources so it is likely to be run on separate hardware scaled to provide what is needed. Local DNS does not require much resources and it is unlikely one will install separate server with too complex BIND or something else just to get basic DNS functionality.

I never understood why static DNS in Mikrotik is limited to only A records. I guess Mikrotik stuff decided that is not money making option as they decided that SMB is.

not the same person works on all these things, you know.

and __bind__ as it is does not require a lot of resources to work exceptionally well.

I am running one that is heavily used with 256MB RAM 1GB hdd as a virtual guest.

there were few older threads about the subject. But now when you know it for sure, maybe you could do something about it, given how easy to implement it should be? It's exactly the same mechanism as you already have in place for static A records. Just instead of returning fixed answer, you'd forward query to other resolver.

and __bind__ as it is does not require a lot of resources to work exceptionally well.

For this simple use, bind would be overkill even in smallest Metarouter on slowest RB. But fine, sometimes I'd gladly do it that way, unfortunately I'm one of those people who didn't see a stable MR yet.

+ 1
Fully featured DNS server

I do not need full featured NS. A, NS and maybe CNAME will do.

Fully featured DNS server would be too much work for too small target audience, so there's no chance to get it in ROS, I guess. Unless MikroTik decided to include e.g. BIND, but I don't think so. Not that I would protest against optional package with this functionality.

But they could at least add these simple features:

1) Allow to add more types of static records. Now they allow A records, so the required ground for adding more is there. It's simply a matter of adding user interface for few other common types.

2) Add support for per-domain forwarding to external resolvers, so user could say that e.g. everything under company.local should be forwarded to resolver 192.168.1.10, instead of to default resolvers configured under /ip dns.

Neither requires any big changes, the basic framework is there already. And once it's done, it doesn't need to be touched again for years. It's so simple there's not even any place for bugs.

I kind of want to be in the Mikrotik meeting where they decided to add Samba server and not fully functional NS. Just to hear how that conversation went.

I kind of want to be in the Mikrotik meeting where they decided to add Samba server and not fully functional NS. Just to hear how that conversation went.

+1000000

Such meetings never take place (where one feature is put against another). The reason is simple - our home routerboard models, such as RB751G are ideal for using as home file sharing servers. You keep your files there, for everyone else in the home to be able to use. Many other brand routers in this class also have such features, some even include built in HDD drives.

The rest of missing home features includes DLNA (miniDLNA for ex.) and printer sharing (p910nd for ex.). For now only choice is OpenWRT.

Yes, I know is offtopic :)

Keeping it off topic in happyness and love of everyone

Shouldn't buyers/customers decide if a router is supposed to be a "home router" or... a "networking router"? I mean, is there some distinction that should be made based upon the price the customer paid? If he paid too much, it's not a "home router" anymore? Not enough, and he has no valuable opinion and should keep it shut?
That said, if both "home routers" and "really serious networking routers" are running the very same software... isn't it even more stupid to make such a distinction?

So please, don't tell me what I need and I don't need, I'm pretty sure I know that better than you.

Still, all repect due to support crew here

Slowly but surely RoS is becoming more and more of an consumer / SOHO device, rather than an enterprise device...

Given what was posted above already, I seriously think that when v6 reaches the masses, it's going to be time to investigate alternatives for enterprise services. How more bloatware is added, how more overhead is added, how more potential problems is created. -sigh-

Either split RoS into two version trees, or provide specific NPK packages which can be installed / uninstalled at will. Whether active or not, I'm -definately- not happy about having services 'forced' on to me in RoS that is not used.

The SMB server in v6 was only pointed out (partly in jest) to highlight MikroTik's absurd priorities. Doesn't look like it even installs SMB server unless the device has USB. And I assume it's disabled by default even if USB is present, in which case it's not really bloatware. In and of itself, I don't even care that RouterOS is getting new features for home users, since it doesn't appear to have effected any existing functions within RouterOS.

well, if that gives you all any peace - addition of SMB as a feature did not impact speed of development of so called "serious" features you see in RouterOS v6 change-log. And definitely sped up addition of full NS functionality if that is someday added to RouterOS.

Howerver, using firewall rules you can simulate behavior of different zones:

It does work, but:
1) it redirects queries from clients directly to target nameserver, so it bypasses cache on ROS (ok, it's probably not such a big deal)
2) for the same reason, redirected domain can't be resolved by router itself
3) if target server is on the same subnet as client, you need another srcnat rule (hairpin)
4) if target server is on separate subnet which is not supposed to be able to communicate directly with client's subnet, you need another exception (probably rare, but still..)

Simply put, it's not nice nor admin friendly. But better than nothing of course.

+1000 to allow NS record in dns static cache.

+1 for native zone forwarding with caching (without layer7)!

+1000 this for me too.

Use case:

I install Mikrotik and Ubiquity Unifi combination for medium to large (but simple) networks with off site Unifi Controller. The Unifi access points do a lookup on "unifi" to find the controller for adoption with is in the cloud with an IP address that occasionally changes.

Yes I can SSH into each AP to assign the location of the controller, which is ok when there are a handful, but when there are 30+ its a long tedious process.

Would be very useful to have "unifi" = unifi.controller.com. Then all the AP's will appear for adoption without sitting for long periods assigning.

add address=unifi.mycontroller.com name=unifi

or maybe even

add alias=unifi.mycontroller.com name=unifi

Im sure this cant be a hard? Seems like a minor but very useful feature to me.

Two years later and I still need NS in DNS and NEVER EVER needed SMB.

I guess I am not professional enough when I need DNS and do not need SMB.

Funny thing is this is so simply to add and it s just matter of somoene's good will.

I would like to sign this request as well, but depending on the local network setup NS entries are not sufficient so I would like to add the option (as an option for the NS record) for the NS entry to behave as forwarder as well.

This means that if I add an NS entry for "local.mydomain.net" into the static list without this option, any NS record request for local.mydomain.net would return the given entry as expected. With the "forwarder" option enabled however, any request for *.local.mydomain.net for any record type (including NS,MX,...) where there is no matching static entry (currently only for A record) would be directed to the given name server instead of normal processing.

My scenario is for medium networks with quite some IP devices requiring a DNS setup but with only one dedicated server being able to be the DNS server and where internert access is the primary DNS use. In this configuration setting the DNS to the internal DNS server is at risk iof that one is down. Even with a secondary DNS entry at the client level (not available in all cases) this is not really practiable as tests did confirm.

Since internet access is the primary use and the router is required for it it is preferebale to have the router being the primary DNS server for my clients. Previously I did set the internal DNS as primary DNS and the router as secondary but this showed as a bad solution as many clients seem to stick with th epriomary DNS when it fails requiring a timeout at each (or each other) non-cached request.

So I came back to a configuration where most of my clients arte configured for using the router as primary DNS and written a script on my Linux DNS server that parses the DNS configuration and uploads static entries to the router.

Just so everyone knows, this was a feature request long before this thread. We asked for this back when we were using RoS v2. They were able to add RegEx capabilities to the DNS proxy, but nothing yet in over 10 years about being able to specify the record type...

I'm working on an issue for a customer right now in China where we need to do queries across a VPN for some domains and locally for others. Even though we have a big bad Cloud Core Router over there, we're having to setup a virtual machine so we can run dnsmasq... unneeded infrastructure because our favorite router vendor won't add a simple feature to an already amazing router platform.

I will throw out some huge kudos for all the other amazing features that have come out over the years... Mikrotik is still the best!!!

Another two years later and I still need NS in DNS.
I guess I am stil not professional enough when I need simple DNS.

Funny thing is this is so simply to add and it s just matter of somoene's good will.

Another argument:

Imagine small company that has three offices, so small that each deals fine with single Mikrotik in each office. Office are connected via VPN. Each office has some static DNS entries for local services. But they also need to access services in other offices via VPN using human readable addresses instead of IP's. For this to work now whole set of static DNS entries must be copied and synchronized among offices.

Simple option to set NS records to point to other offices would be tremendous.

To think I responded to this in 2012, and probably sooner in other threads, ... oh the memories. And I still need it all the time. Maybe we should get more radical, do a leaflet campaign or something.

+1 for NS records in DNS static cache, but also I would like to have SVR records there.

It's two things:

1) Most people don't want ability to add actual NS records but conditional DNS forwarding (nicely summed up in this thread)

2) Adding records of various types could be useful too. With that, I understand that MikroTik might not want to specifically support all of them, but they could easily add support for generic syntax (raw bytes) and you could enter any record that way. They have the same thing for DHCP options. It's not the most user friendly way, but allows people to do anything they want.

We finally got our wish! I'm not sure when this was added, but in v6.47 you can now specify the record type!!!

Thank you Mikrotik! It only took 12 years.

Well, yes. It's definitely much better than it was before. But the requirement to use regexp if you want subdomains for type=FWD, that's not the greatest solution. I hope that there's still a chance that they will rethink that, but I'm not sure how likely that is.

A very interesting bug with FWD DNS.

1. Add FWD to handle local reverse zones.
We get DNS from ISP. 2. We use the utility several times /tool tracerout with flag use-dns=yes

3. PROFIT! Your DNS is breaking. Moreover, it breaks down in a strange way. Sites (A / CNAME records) convert normally, but reverse zones (PTR) break. Only reboot helps.

Problem playable on devices: hAp lite, CCR1016 (version 6.48).