It looks like the built in DNS server listens on all interfaces when enabled. Is there a way to specify the interfaces it listens on (not firewalling traffic, but limiting listen interfaces)?
I want to have different DNS servers listen on Internet-facing interface vs internal-facing interfaces. Is dstnat on external interface the right approach here? Is there a way to limit the interfaces the built in DNS server listens on to a subset of interfaces?
ROS DNS service is pretty decent DNS relay but lousy DNS server. And answer to all of your questions is “no”. You need a proper DNS server and configure it according to your needs. You can configure RB firewall to pass/NAT DNS traffic towards your DNS server according to your wishes and that’s about it.
Thanks.
Is there a netstat-like command that lists the ports the router is listening on? I have accidentally discovered it’s listening on internet side of the house when I wanted to run some other DNS server there. I am wondering if there are other ports in listen state on the router that I am not expecting.
Not that I know of.
That’s why you should use a firewall 
Indeed. Preferably following the concept “allow only what needs to be allowed, drop all the rest”. It’s easy to find that something is blocked that should be allowed while it’s nearly impossible to explicitly block everything that needs to be blocked. Not until it’s too late.
It is still not very comforting not knowing the list of open ports on the router. You never know if you are a part of a botnet. Firewall blocks connections, but does not tell you much about processes on the router itself that may be unwanted.
You can’t be a part of a botnet if you allow access to only what you know you need open. The default firewall on a lot of devices does just that (well it treats LAN as “trusted” but that’s your job).
You can always run a port scanner against your router.
I do not agree with your assessment. Router can be protected by firewall, while being infected by botnet and listening on some UDP port. Port scanner would not help either - botnet could ignore and blackhole traffic that does not match specific pattern from control node - port scanner will see no response - as in case of blackholed traffic. Not seeing ICMP connection refused is not an indication that the port is open. It is not an indication that it is closed either.
If what you are saying is that one should do a netinstall followed by a firewall config in an isolated environment, that is still not a guarantee against infections - there may be protocol buffer overflow exploits that are capable to execute code on the router. Not being able to check on listening ports is a serious security miss.
remember you can firewall following traffic:
input: towards the router
forward: across the router
output: from the router
if you don’t trust this platform please use another or build your own like you want
MikroTik is not open source is a commercial product
I dare you to run some code on RouterOS that can listen on some port.
But I didn’t get the firewall part you wrote above, if your firewall blocks everything, how can anything else you’ve said be valid (having some service listening, bypassing the firewall), example, please. Because I can’t sleep tonight knowing that my firewall does nothing.
Exploits running on routers - either Cisco IOS or ROS are nothing new. You could allow access to legitimate ports, which could have 0-day exploits allowing RCE.
http://forum.mikrotik.com/t/routeros-making-unaccounted-outbound-winbox-connections/117836/1
https://www.exploit-db.com/exploits/43450
Burying one’s head in sand is not a good security posture. Firewall rules do not guarantee lack of possible exploits through legitimate traffic. I do not see a valid reason for not having a command showing ports that are listening for traffic, given this proprietary software runs on top of open source kernel that has facilities to provide such information. It’s not like Mikrotik built the whole thing from scratch. No one does it these days. Even Cisco’s monolithic legacy IOS has open source bits and pieces compiled into it.
Recent log4j vulnerability proved that 10-year mature proprietary software can have silly security vulnerabilities that even a kid can exploit.
All of those exploits are .. unexploitable against a device running a properly configured firewall.
Even the thread you linked with the exploit that was fixed in 2017, they all had the management web interface open to the world, the winbox vulns that were found after, they all had winbox port open to the world.
You don’t leave your car with the keys in contact, window open, and go on vacation expecting to find the car in the same place, or at all, when you come back.
You’re talking scenarios, but nothing real.
“hiding behind legitamate traffic”
Ok, so I use port 53 because I run a DNS server, what could possibly be running instead of that DNS server without me noticing that it’s down?
Or instead any other service that I’m allowing the world to talk to it?
It’s not “Burying one’s head in sand” it’s more like sending packets I don’t want in the pit. You should try it.
Unexploitable is a bold claim with no data to support it.
Internet-facing router with NAT is usually running some ALGs at minimum, which process externally-controlled data to patch up the packets in tracked eligible connections. A vulnerability in ALG, which runs in kernel btw, can compromise the router and cause RCE.
In log4j it was the logs that were causing RCE, so if the attacker was in control of the logs (as in your device logging attacker’s actions including strings controlled by attacker like logins or URLs), attacker can take over the vulnerable machine.
Spectre and Meltdown demonstrated side channel attack vectors that were present in pretty much every single device for decades!
You don’t seem to have a good understanding of possible attack vectors if you think that just by limiting the traffic you could make the device safe. There could be vulnerabilities in anything, including connection tracking code that your firewall is using to inspect the packets!
There is absolutely no excuse for not exposing listening ports. It does not cost anything - it is already part of underlying OS. “Nothing to see here” is a silly dismissal of a lack of basic functionality.
Cisco IOS has it - show control-plane host open-ports. Linux has it out of the box with netstat exposing results from Kernel. It is beyond me why people defend the lack of a basic command to show listening ports on a device which has kernel capabilities to expose it out of the box.
Post the IP address of your router. I’ll then tell you which ports are open.
Bwahahah.
But… Really???
Scan this pool…
76.222.0.0/16
BECAUSE SAID DEVICE HAS CAPABILITIES TO BLOCK LISTENING PORTS OUT OF THE BOX.
As previous stated.
As per your topic, submit a proper feature request, which is not done in the forum, but by making a proper feature request submitting a ticket. https://mikrotik.com/support
Ok, this is the best answer of the month, which I prefer… 
Or, the OP can scan the router’s WAN address from outside of the network to expose open ports.