Mikrotik DNS Improvement

RouterOS General
1

I’m not sure if this forum is the best place to submit feature requests for RouterOS, so please let me know if there is an official channel for proposing improvements to the DNS stack or other core components. If such a channel exists, I would appreciate guidance on where to send this suggestion.

I would like to formally request the implementation of ECS (EDNS Client Subnet) support in RouterOS.
Reference: https://en.wikipedia.org/wiki/EDNS_Client_Subnet

At a high level, ECS allows a DNS forwarder to include part of the client’s subnet information in DNS queries, enabling upstream resolvers to make more accurate, context‑aware decisions. While this is often discussed in the context of CDN geolocation, there is another critical use case that strongly affects MikroTik deployments: internal user identification when the router is used as a DNS forwarder.

In many network architectures, especially those prioritizing security and segmentation, it is far safer to use the MikroTik router itself as the DNS forwarder rather than exposing internal DNS servers directly to clients. This design reduces attack surface, centralizes DNS policy enforcement, and simplifies logging. However, without ECS support, upstream internal DNS servers lose visibility into which client originated the request. All queries appear to come from the router’s IP, which breaks auditing, per‑user filtering, and fine‑grained access control.

This limitation becomes even more problematic in environments where internal applications rely on DNS‑based user identification or where administrators need accurate logs for compliance. In these scenarios, RouterOS becomes the bottleneck, because it cannot forward the necessary subnet information to internal DNS servers.

ECS support would solve this cleanly and elegantly. It would allow MikroTik to continue acting as a secure DNS forwarder while still preserving the ability of internal DNS servers to identify and differentiate users. This is especially important in enterprise, campus, hospitality, and ISP‑grade deployments where MikroTik is often used as the central DNS forwarder for thousands of clients.

I know this feature has been requested in the past, but it never seems to gain traction. I want to emphasize that ECS is no longer a niche capability, it is a foundational feature for modern DNS‑aware architectures. Competing platforms and open‑source DNS forwarders already support it, and its absence in RouterOS forces administrators to choose between security and visibility, which should not be necessary.

Adding ECS to the roadmap would significantly enhance RouterOS’s role as a secure, intelligent DNS forwarder and would remove a long‑standing limitation that affects real‑world deployments.

If there is any additional information I can provide, or if there is a more appropriate place to submit this request, please let me know.

2

No bro, thats a stupid idea…

3

Hello bro… Since you described the idea as “stupid”, I’d like to understand your point of view better. Could you explain why you believe implementing ECS (EDNS Client Subnet) in RouterOS would be a bad idea?

I’m genuinely interested in hearing the reasoning behind your position, whether it’s related to performance, privacy, architectural concerns, or something else. Without understanding the specific arguments, it’s difficult to have a productive discussion or evaluate whether the concerns are valid.

If you can share the technical basis for your opinion, it would help everyone in the thread understand your perspective and contribute more meaningfully to the topic.

4

You might contribute to people's thinking if you told us why you think that rather than just expecting us to fall in line behind you.

5

https://mikrotik.com/support

by mail or Jira.

6

This is actually a very solid and well-explained feature request. The point about losing client visibility when using RouterOS as a DNS forwarder is especially relevant for enterprise and segmented environments. ECS support would definitely make MikroTik more competitive in modern DNS-aware infrastructures.

7

Yeah, certainly seems enterprisish, certainly not a concern I have for my home network.
If there is value in the work needed to add to the code, test the code etc etc………………. then I am sure it will be looked at seriously, especially if its a known standard. Don’t get too many hopes up as mikrotik doesn’t necessarily attempt to achieve enterprise goals ( no MT cloud IDS IPS functionality for example ).

If your request came with a six figure or more ORDER, I would hazard implementation may be faster. :slight_smile:

8

EDNS ECS certainly is a very common standard that is implemented by all major recursors.

What I don't really get is the rationale. Why is it better to use a Mikrotik as a forwarder for "security and segmentation"? If anything, I would believe that a proper resolver such as unbound accessed directly would be much better than forwarding it through a router.

9

What lurker, I have been using the MT as DNS all this time, should I change???
What is unbound, never heard of it. Recommended?? How does it compare to using 1.1.1.1 or 9.9.9.9 etc..

10

Unbound is light and feature rich DNS server, using it for a while in container for DoT upatream requests, never had issues with it.

> /tool/profile    
Columns: NAME, USAGE
NAME        USAGE
networking  0%   
management  0.5% 
ethernet    0.6% 
console     0%   
routing     0.2% 
bridging    0%   
wireless    0.3% 
firewall    0.1% 
profiling   0.3% 
dns         0%   
kernel      0%   
pihole-FTL  0%   
ssh         0%   
led         0%   
unbound     0.2% 
total       2.2%
11

There's nothing wring with using Mikrotik's built-in resolver. It's cheap in every sense: fully built-in, low resource usage, no additional hardware, not even a container necessary. But: I don't think I'm amiss in saying that it's very far from feature complete. But if it works for you there's nothing wrong with that.

The one that's usually run on other routers is dnsmasq, which is also a proper implementation.

Unbound is also one of the very popular ones. This one is still small (thrifty), but it actually can be considered feature complete.

All of these can be configured to use any set of upstream DNS servers such as 8.8.8.8 or 1.1.1.1. When unbound is configured like this it's responses won't differ from any other resolver using the same.

Unbound can be used (and is used) in a variety of way:

  • Some routers (usually above the consumer range) use it simply in the exact place where Mikrotik's own implementation site. You simply point it to 8.8.8.8, 1.1.1.1 or wherever and it serves the same function.
  • Some configure it to validate DNSSEC and only return answers that it funds trustworthy. (This allows devices which themselves don't do DNSSEC to enjoy its benefits while remaining dumb.)
  • Sometimes it's used to do forwarding for split dns scenarios. (Similarly to how Mikrotik's built-in is capable of.)
  • Sometimes it's programmed to recurse from the root servers. In this case it replaces 8.8.8.8 or 1.1.1.1 and the others.

The last one is actually a pretty usual use case for it. Sometimes you want answers from the "real DNS", not Google's or Cloudflare's version of it. Admittedly it's a niche requirement, but when you need it, you really do. (One application is issuing certificates or validating other trust relationships that somehow depend on DNS.)

EDIT: Just to actually answer your question :slight_smile: If you ever find yourself in need of a fully featured DNS resolver, definitely take a look.

12

Consider Authoritative DNS Server on RouterOS with CoreDNS

13

Yeah I wonder why it is not in the standard app collection, while so many other silly things are.

Also it would be an idea to offer it as an optional package for use on routers with enough storage, so it can be better integrated with winbox etc.

All the time new DNS requirements pop up, those established DNS resolvers already have them implemented, but MikroTIk keeps clinging to their own resolver…

14

Another feature that I find missing is the support for AdLists (dns blocklists) with wildcard entries. All the popular lists are published in this format, yet Mikrotik has chosen to create an implementation that only matches exact domains host file style, making these unusable. (Of course unbound supports these fully.)

15

And of course then there is DNSsec validation…

16

Maybe I need to send to MT my Terminal Doom ARM64 build so that they can put ti in app list :slight_smile: - Doom running on ROS

17

Yeah, that sounds like fun actually.

18

IMO, MikroTik DNS with AdLists (HaGeZi Pro + additional HaGeZi lists) is a very good way to handle DNS without additional expose to containers. I've used Blocky on MikroTik container but sometimes it goes out of memory and DNS resolution just stuck. For me now, MikroTik DNS with AdLists it's set and forget solution.

It would be great if MikroTik make it even better:

  • Multiple DoH upstreams with health-check and failover. Sometimes CloudFlare DoH failed like DoH server connection error: timeout waiting data [ignoring repeated messages]
  • CNAME chain inspection/blocking. Biggest practical filtering improvement.
  • Basic wildcard domain matching for a modern DNS Blocklists format - this would improve filtering efficiency.
19

Well it seems, that there are some basic improvements MT can make to its own DNS offering OR better integrate well known AND light, solutions. Why the eff dont they???

20

Control ...

Unbound is the perfect DNS solution ...