+1 for advanced DNS server

I love mikrotik and I use it every day but standard DNS feature is simply poor.
I definitely need built-in advanced DNS in new ROS.

Current RouterOS can't do much with DNS, that's for sure. But I don't think it's helpful to ask for "advanced DNS" without providing further details. That can mean a lot of different things.

IMHO there are two possible ways:

1) Don't try to make RouterOS a full-featured DNS server. Just add few additional features like more types of static records and per-domain forwarding. No more L7 hacks for basic stuff. It's simple, easy to implement, useful and should make a lot of users happy.

2) Provide full-featured DNS server as separate package, with all possible features (master/slave authoritative server, recursive resolver, dynamic updates, DNSSEC, ...). But it's a lot of work and target audience is limited, compared to 1). Instead of creating something from scratch, they would probably have to integrate something like BIND (but rather something else then BIND itself, as it doesn't have the best history).

I wouldn't say "no" to 2), but given the current state of things, the priority should be 1).

I wouldn't say "no" to 2), but given the current state of things, the priority should be 1).

You're right to say that there are other areas that need attention.
And I wholeheartedly agree that they should probably add the ability to specify RR type in the static DNS entries.
I'd say they need CNAME, AAAA, and PTR the most.

-----: BEGIN RANT :------

I would say "no" to 2. If someone needs a full DNS server then they should set up a Bind server or whatever daemon they like - do it on a WRT virtual if it really, really, really must be kept all on a single device. There comes a point in time when reality must be faced - this is a router operating system, not a server operating system.

There's a huge difference between a basic lightweight implementation of a protocol to fill a few niche needs (dns cache / static-only httpd to server "access denied" pages, etc), and fully-featured server packages. There are many things that need fixing in ROS that are core routing things (IPv6 needs lots of love, bugs in routing protocols, etc.). And I think a worldwide holiday would be declared if they implemented IGMP snooping on the bridge and atheros switch chips.

RouterOS can't be everything for everyone. I've seen feature requests for print server functionality.... really?

It's easy to get caught up by how feature-rich and powerful a Mikrotik can be, but remember that it is actually a router before it's anything else. It doesn't need to be a SQL cluster node. It doesn't need to be a bitcoin mining node. It doesn't need to be a print server. It doesn't need to be a web server or a DVR for your security cameras or anything else.

There's something that can do all of that - it's called Linux.

(drops the microphone on the floor)

------: END RANT :------

You can do everything with Linux, but RouterOS gives it to you in such nice user/admin friendly package. It comes with some limitations, but mostly it's worth it. It's only natural to want to push the limits a little further and get the same comfort for more services. The question whether something belongs to RouterOS or not, now that even whole network monitoring system is included... can you really say that DNS server does not belong?

I see no problem with few extensions to what we have now. The basics are already there, it does not require much effort to add the rest. I myself would like to see two:

1) Per-domain forwarding. When you have some internal domain handled by your server, but don't want to depend on it completely for DNS, i.e. if it happens to go down, you still want to be able to use public internet. You could use router as DNS cache, use ISP's resolvers by default, but define an exception that queries for company.lan should be send to your server. A proper alternative to old L7 hack.

2) Allow to set static records of *any* type. Few most popular can have specific WinBox dialogs/CLI options. The rest can be supported using generic syntax (DNS server does not need to understand all records it serves, you can sometimes see unknown types in current DNS cache and it's no problem at all). You can stop here and it will make many people happy.
But as bonus (I'm not actually asking for this, just saying that it's nothing complicated), you can add a simple option to send replies for selected domains marked as authoritative and you have proper DNS server, even though it would be just a very basic one. Add AXFR transfers for master/slave operation and you'll start to get out of scope of simple extensions. No, what I wanted to write was that you'd have everything you need for basic server, if you don't require anything special like DNSSEC.

Real full-featured DNS server is a different story. And there's also difference between authoritative server and resolver. Authoritative server with all bells and whistles is not needed by most people. Resolver could be more interesting, e.g. if you want to validate DNSSEC by yourself in the name of security (you might not trust ISP or fear evil hackers between ISP and you), it would be nice thing to have. You can get dedicated machine, but why couldn't your shiny new $3000 CCR handle such relatively simple task.

But as I wrote before, simple extensions first. MikroTik can save full-featured DNS server for later, when they fix all bugs, add all more important features, dominate the router world and have nothing better to do.

The question whether something belongs to RouterOS or not, now that even whole network monitoring system is included... can you really say that DNS server does not belong?

Yeah - you have a point there, but I've kind of felt like running NMS from a router is a bit 'strange' but hey, it's there and it only took a little more than half a decade to get any work done to it.

Things like this (and Userman - another 'outside the box' package) are interesting additions to ROS, and I think Mikrotik's intent is for packages like these to be run on dedicated boxes that only function as the Dude or Userman.

But as I wrote before, simple extensions first. MikroTik can save full-featured DNS server for later, when they fix all bugs, add all more important features, dominate the router world and have nothing better to do.

In the mean time - low capacity, fully featured DNS appliance sounds like a Raspberry Pi to me......
(or a WRT image - certainly there's one posted)

What I am actually missing are zones or DNS instances, assigned to specific interfaces or even requester IP ranges. And of course, static CNAME, MX and AAAA entries.
This would allow e.g. to resove internal requests to internal hosts (and maybe put the loopback issues at rest), while allowing external requests to be resolved to public IPs. And this would maybe allow to disable forwards on external interfaces, while keeping it for the internal ones, and other nice use cases.

At the very least, they need to let you define CNAME, PTR, and AAAA records in the Mikrotik. The thing already knows how to cache and serve up such records anyway - at least they could add the ability to specify RR type in the UI.

I'm guessing they didn't want to have to validate more input types than IPv4 addresses. It seems that free-form string with the "don't mess up" disclaimer would be enough, right? If you specify something bad, then the clients' failure to function should be some clue that there is garbage in the DNS entries.....

You can already add AAAA, just enter IPv6 address. But together with A (and automatic PTR) that's it so far.

You can already add AAAA, just enter IPv6 address. But together with A (and automatic PTR) that's it so far.

(hand smacks forehead)

Why did I never try that?


Just for fun I tried to specify a CNAME kind of record in the same way (entered a hostname as the IP) - it resolved the hostname and created the A & PTR records for that name.

yea, both DNS for IPv6 and DNSSec can be cool/useful in ROS.

i think actual dns on ROUTEROS accomplish the role of a local cache for dns queries

if you need to get full dns implementation the only thing you need to do is to put a little and inexpensive linux box as the root of your dns infrastructure, this plus your mikrotiks doing cache can do a very good scalable dns solution

or use opendns or norton dns to custom your dns behavior

i think routeros must focus on polishing wireless routing and networking functionalities to deal with serious competition.

i think actual dns on ROUTEROS accomplish the role of a local cache for dns queries

if you need to get full dns implementation the only thing you need to do is to put a little and inexpensive linux box as the root of your dns infrastructure, this plus your mikrotiks doing cache can do a very good scalable dns solution
or use opendns or norton dns to custom your dns behavior
i think routeros must focus on polishing wireless routing and networking functionalities to deal with serious competition.

but even as "local cache" its need support of such features, ironically. to do it properly in those tech-aware/depnding environment/solutions.
generally some networkers - avoid NS on routers, simply because security issues and just forward DNS traffic.
(which is important partialy both because broken/outdated/vulnerable/bloated code in some of them or incomplete implementations(especially in security context and "becoming essential" things like IPv6 native support "from top to down")
ironically - that start becomeing common for some security-conscient companies - for Linux and Windows hosts aswell.
(mostly because DNS implementation - remain as insecure as in all router and "caching" feats - seriously simplify exploitation)
also as "local cache" built-in DNS services - lack management options. to easier tweak/manage options, overrides(both for A, PTR, MX resources, TTL(both directions in many styles) and to enable/disable certain things in DNS traffic/configuration itself.
would you miss ability to tune "old-fashioned" DNS traffic in "passive" style(ie 53<->53) for example. in firmwares with open config(either they use bind, dnsmasq, nsd, djb(my favorite aside unbound) or other things code with combinations between) - you can simply edit config and fire it up/restart again.
someone - would probably like something else for DNS aswell, likely. its remain untouched in ROS for really long time.
personally i would like to see improved performance of it(compared to bypassing DNS - difference is staggering, sometimes

so far DNSSec support is sparse/broken, because incomplete implementation and lot of complex workarounds, necessary to make it working in most platforms.
partially cause since TCP Cookie Transactions - removed from kernel again(due same issues/reasons, ie incompletion/buggy status), long ago.
https://en.wikipedia.org/wiki/TCP_Cookie_Transactions

almost just like how SCTP - require both timestamps and ECN support(presently disabled in RouterOS).

A lightweight DNS server like "maradns" would be fine for Mikrotik devices.
The configuration could be done through text files like on any OpenWRT device.

Why such a service will not be offered by Miktrotik?

I think the problem is not to obtain the required software. There are more than enough open source DNS servers/resolvers available.
(if anything, the problem would be to select one instead of ending in a religious discussion which one to use and which one to absolutely avoid)

It would likely be more work to make the RouterOS configuration front-end.
I have often wondered what is going on behind that. Is there a very powerful "configuration interpreter" that does all he command-line, web and API
interpretation and is table-driven to support the commands we see and write the Unix-style text confguration that most of the used software needs?
Or is it all custom C/C++ programming that is to be done for each new feature being added?

It is difficult to know without some explanation by MikroTik employees, and I have not encountered that yet on this forum.

Depending on the situation, it could be quite easy to add a new package that simply consists of installing an existing open-source program,
and creating the configuration tables for it. But it could also be a lot of work. We don't know.

Such of these features would make Mikrotik more popular and additional hardware would not be necessary.

All of us trust on RB software although we do not know anything about the source code and possible backholes. Here the OpenWrt was the better solution but the UI is clearer and easier (faster) to use.

this: https://tools.ietf.org/html/draft-tale- ... lientid-01

i know the draft already expired. tbh we're talking about a 7 yr old feature that is in dnsmasq since 2011.
this is hell of a tool to get stuff under control.

Are there any news about this feature request?

I believe that MikroTik is preparing full-featured DNS server package as Christmas surprise. To be released a year or two after RouterOS v7.

I believe that MikroTik is preparing full-featured DNS server package as Christmas surprise. To be released a year or two after RouterOS v7.

Wow, that would be great!!

I guess I should have added some fitting smiley like this one:

Because in reality, there are some problems with my optimistic vision. It's not exactly true, at best I can go for "I want to believe". And also, I'm probably not the only one who uses "release date of RouterOS v7" as original synonym for "never". I'm pretty sure that it will change eventually, but don't hold your breath. That's for v7, DNS is yet another matter.

Truth is, I don't really think there's enough demand to warrant development of DNS server for RouterOS. If they would integrate some existing software, maybe. But it looks like they (for quite some time already) prefer do make things themselves.

Dear Mikrotik developer

are there any news about this feature?

Any news about this feature?

maradns or powerdns (both open source) would be perfect for ROS.

It's sad.
On OpenWrt based devices it's no problem to compile any package you need.

Mikrotik should begin to integrate some additional packages which the community want to use.
They offer some packages like ntpd, hotspot, ups, advanced-tool and etc. but I miss socks proxy (srelay) or an authoritatived dns server (maradns or powerdns). All of this helpful tools are lightweight and could be used on non-busy Mikrotik routers.

If they add more packages maybe people with only 16MB flash will start complaining.

Optional packages not installed by default wouldn't be an issue.

People will complain when they realize they cannot install everything that they want.

That's when you tell them to upgrade to a device with more storage.

MT has many devices with only 16MB. They will avoid having to discontinue them.

@vortex

Once again:
Could you be so kind and stop filling forum with such consecutive selfanswering "comments".
You just make huge amount of "posts" with no clearly visible sense.

It's not like everyone has to install everything (*). Even if there would be too many packages for 16MB, in a way it would be still win-win. Users would get the features they want. If they need more than would fit, they'd buy better device and MikroTik would get more money. And if it helps to force MikroTik to make devices with more storage, it would be even better.

(*)I understand that they want to reduce number of packages in v7, which makes sense for basic stuff like IPv6 or DHCP, where there's either no good reason to disable it, or it brings unnecessary troubles with dependencies. But they still intend to keep some optional packages separate. So any advanced DNS server, if there would be one, would be fine as separate package. I think they should rather just add few simple improvements to built-in DNS cache (which would not significantly increase the size), instead of going for full-blown thing. The latter is unlikely anyway, it's too much work for too small target group.

I have given up on ever getting something simple as a capability to add a record that replies with NXDOMAIN.
Instead I filed an enhancement request at Firefox so I can work around it use the specific case of use-application-dns.net, and it was accepted surprisingly easily.
I still would like to have that feature in MikroTik, e.g. to reply on requests for *.168.192.in-addr.arpa but as it appears to be impossible to get them doing it we will have to live with it.

I disagree with this feature request
The included DNS features are as functional as they realistically need to be, for what MikroTik routers are

You need to keep things in perspective. At the end of the day it is a router, not a server. MikroTik already has a huge amount of quality of life improvements that make things easier, but adding additional functionality to DNS is a niche thing that would take a lot more dev time for something that lets be honest 99% of people don't need. If you need those improved DNS features you can easily spin up a raspberry pi with whatever packages you want and deploy them to a site. Or use a proper onsite server

Realistically the 'next step' for both DHCP and DNS is to use an actual server. A router is a 'good enough' implementation of those but that should be the migration path, to move to a proper purpose built server for those functions. In the same way a small business starts off with workgroups then moves to domains. Would you expect MikroTik to now function as an Active Directory server? Really? Or just make provisions to install a server onsite

The included DNS features are as functional as they realistically need to be, for what MikroTik routers are

C'mon, thats not true and you know it. If there is ability to put a static A entry, why not ability to put static MX or NS or other entries? It is literary one parameter in CLI/GUI. No real change of functionality is needed... all is already there and working fine.

And that would be enough to make many people happy.

Let us assume that RouterOS could have a better DNS server in the future. How about compiling a must-have minimal set of features that would make everyone happy. Please post your wishlist

Just remember that this will run on home wifi routers etc, so no crazy stuff.

I think it should have the following functionality in addition to what it can do now:
- for static records, add the capability to install a CNAME, MX, TXT, NS or SRV record (in addition to the A and AAAA that it can do now).
- allow to forward queries for a statically inserted domain to a specified nameserver (similar to having an NS, but also handle the resolving. could be an option flag for an NS record or it could just be always enabled when an NS record is present and a name below such a domain is queried)
- have a static record that replies with NXDOMAIN. can be a special case of the above static records.

When you would go "fancy" (but still this is supported in many other home routers):
- have an an automatic zone for each DHCP server (a specified domain name, could be .local but can be anything) where assigned addresses are automatically populated with their hostname (forward and reverse)

I think it should have the following functionality in addition to what it can do now:
- for static records, add the capability to install a CNAME, MX, TXT, NS or SRV record (in addition to the A and AAAA that it can do now).
- allow to forward queries for a statically inserted domain to a specified nameserver (similar to having an NS, but also handle the resolving. could be an option flag for an NS record or it could just be always enabled when an NS record is present and a name below such a domain is queried)
- have a static record that replies with NXDOMAIN. can be a special case of the above static records.

Sounds good. My answer would looks very similar, so just ACK!

When you would go "fancy" (but still this is supported in many other home routers):
- have an an automatic zone for each DHCP server (a specified domain name, could be .local but can be anything) where assigned addresses are automatically populated with their hostname (forward and reverse)

The domain ".local" is use by avahi/bonjour/zeroconf. If you expect this to be returned from a nameserver it will cause havoc. So NACK.

I have scripts for this functionality, so this is of no interest for me.

Totally with pe1chl. For the conditional forwarders I'd love to see having this possibility for reverse lookups as well. Like
That would be perfect.
The ability to match subnets from certain AS numbers would be awesome.

-Chris

When you would go "fancy" (but still this is supported in many other home routers):
- have an an automatic zone for each DHCP server (a specified domain name, could be .local but can be anything) where assigned addresses are automatically populated with their hostname (forward and reverse)

The domain ".local" is use by avahi/bonjour/zeroconf. If you expect this to be returned from a nameserver it will cause havoc. So NACK.

Note that the domain name should be specified by the user and can be anything, I have also seen routers use .lan or .manufacturername but it really should not matter.
(and it should be configured per DHCP server instance anyway)

Totally with pe1chl. For the conditional forwarders I'd love to see having this possibility for reverse lookups as well. Like

That is not different functionality. To have reverse working for subnet 172.16.16.0/24 you configure an NS record for 16.16.172.in-addr.arpa.
(and the router should forward queries for *.16.16.172.in-addr.arpa to that server either by default or as an option to that record)

Totally with pe1chl. For the conditional forwarders I'd love to see having this possibility for reverse lookups as well. Like

That is not different functionality. To have reverse working for subnet 172.16.16.0/24 you configure an NS record for 16.16.172.in-addr.arpa.
(and the router should forward queries for *.16.16.172.in-addr.arpa to that server either by default or as an option to that record)

So true. So simple :-)

If we are dreaming about added dns features, dns over https & tls (then whole network even for devices that don't support it can use it) , split horizon dns would be nice, and if it would be possible to to specify a ns (more than one for redundancy would be awesome) for a particular domain, eg *.mydomain goes to domain controller 1, *.mydomain2 goes to domain controller 2. Split horizon to only allow requests for particular domain from specific networks, etc. Situations like this haven't come up often, I have normally just dealt with it. But have been running into this more often lately. Would help isolate guest/insecure networks away from the protected networks, not reveal dns information to the guest/insecure networks. Anything more complicated than that I think really needs to use it's own server to manage a custom solution. We don't need a full featured internet dns server running on a router, just a little bit more security and flexibility. I think this would help adoption in the small to medium sized business market, or just at home to help with securing dns information from iot devices. As a further thought add on to this, would be nice to be able to easily black hole some domains and return failed responses, random example block all dns lookups for say *.ebay.* or maybe a regex. Wouldn't want to make that too complicated or would get rediculous quickly, if you really need to block alot run dedicated server or pihole. Doing much more than this is asking too much for a router to do, will get abused and cause performance issues.


Sent from my SM-A520W using Tapatalk

Please don't spoil the opportunity of having some functionality enhancements by coming up with so many proposed features that it is going to be put on a "too hard - look at it for v8" list!
I purposely have omitted any features that would be required to run an internet-facing DNS server. A router just isn't the place to do that!
"blocking" lookups for wildcard domains (by returning bogus info) is already possible now.

To have some more constructive input:
- instead of the "automatic zone for DHCP-assigned addresses" an option would be to have the capability to insert records only in the cache and not in the fixed configuration, by specifying a timeout value. that can be used by a lease script to add records in a local domain without causing many flash writes.

- when the code is going to be worked on anyway: please make the maximal reply size settable. there now is a fixed maximal reply size (I think it is 32KB), any request resulting in a longer reply than that is going to be truncated. in large routers like CCR the reply size can be much larger without overflowing memory.
use case: I want to have a DNS name (outside of the router) that returns like 5000 A records to populate an address list for a whitelist or blacklist. this is currently exceeding this limit. I have to split the list in multiple names each returning max like 1000 records, and it causes issues when the list is changed (not all parts are getting updated synchronously so sometimes items temporarily disappear)

I'll keep all the crazy stuff to myself for now and only expand a little on few things:

Conditional forwarding

I'm running into this repeatedly and I'm not alone. Usually it's remote network connected using VPN and it uses some local private domain (I know they are kind of wrong, but they are everywhere) or split DNS config with real domain. I need to be able to resolve names from there, but I can't depend solely on their resolvers, because if VPN goes down, I'd have no DNS at all. Or there can be more unrelated networks and using resolvers from just one of them wouldn't work, because I wouldn't be able to resolve names from others. The problem could be solved with something like:
Queries for <anything>.home.lan should use only 192.168.89.10 or 192.168.89.11 (because public resolvers would return NXDOMAIN and mess things up). Same for other defined domains. All other queries should go to 8.8.8.8 or 8.8.4.4. Current very limited workaround is L7 hack and it's not good. This feature is nothing complicated that would not have a place on router, quite the opposite, it's only a simple hint where to look.

It should not be linked to NS records, it's different thing. I should still be able to override individual records (even if I currently don't have any good example why I would need it). This, if configured, would have priority (it makes sense, because all static records are put in cache and router does not ask upstream if it has valid cached records):
More types of static records

Personally I don't need this, except maybe in few rare cases, but if you add it, don't limit it to few selected types. It's understandable that you wouldn't want to create UI for every single obscure type. You can add few common ones if you want. Or not. And for the rest you can do the same you did with DHCP options:
Hooray, SRV record! While not the most admin-friendly way, it does allow to add records of any type, there would be no limits.

I wish most features from maradns.
maradns is open source - and offers simple configuration as an authoritatived dns server.
It also can be used for internal dns server (non-authoritatived).

dnssec extension would be fine for feature but it is not very important at moment.

Also no dns-server feature in RouterOS7?

The fastest an easiest way would be to adapt maradns to RouterOS.

There's planned support for containers, so you'll have your chance with that. I wouldn't expect much from MikroTik directly.

Sure, they added some new features since last time this thread was active, it's better than before, but still not all that great. And I'm talking just about basic ones. Forwarding using FWD records is limited to only one server and for some strange reason requires use of regexp for subdomains. For another strange reason it doesn't work at all when DoH is used. Processing of other static records is inconsistent between when DoH is used and when it isn't, and it again doesn't make sense. It's fixable, but nobody knows if or when it's going to happen.

I think, you are asking for too much. RoS is a routers operating system.
As an alternative, in case you need DNS-Server functionality, use openwrt, which also runs on a few selected MTs.
It also does routing, of course. But I even run powerdns on it. dnsmasq is standard, but you can also use unbound. The choice is yours.
RoS unfortunately is "closed", so no possibility of simple adaption of common Linux packages. openwrt is different.

As Sob already wrote, the new "container" functionality in RouterOS v7 (which is not available in the current version but it was in a beta and it will come back) allows you to run an abitrary external program that provides network functions, like a DNS server of your own preference.
Alternatively, you can add a Raspberry Pi to the network and run this (and other specific applications) there. Then you can leave the MikroTik running standard RouterOS (v6 or v7).