What is required to safely enable DNS Allow Remote Requests?

My overall objective is to be able to communicate with hosts on my local network using hostnames rather than ip addresses.

For example, rather than having to use an ip address with ssh

ssh user@192.168.1.10

I want to be able to do

ssh user@servername

Or something similar.

I have set several hosts on my local network to use static ip addresses. I have also set the corresponding static routes.

However, this is not enough to be able to ssh to these devices from other hosts on the same private network.

I believe this is because the Mikrotik router is not functioning as a DNS server.

My understanding is that to enable it I need to enable “Allow Remote Requests”. However, my understanding is that this is quite dangerous, because it will listen on all interfaces including requests which come from the internet.

So - what is required to make this safe? Is it simply a case of adding the correct firewall rules to drop all traffic on port 53 except traffic from local address space?

Here is a list of my current firewall rules.

 /ip firewall export
# 2025-11-21 09:04:32 by RouterOS 7.20
# software id = ZTIS-3ZFL
#
# model = E50UG
# serial number = HJ2**removed
/ip firewall filter
add action=accept chain=input comment="accept established, related, untracked" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept icmp" protocol=icmp
add action=accept chain=input comment="accept from LAN" in-interface-list=LAN
add action=drop chain=input comment="drop everything else"
add action=fasttrack-connection chain=forward comment="fasttrack established, related" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="accept established, related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=accept chain=forward comment="accept from LAN to any WAN" in-interface-list=LAN out-interface-list=WAN_ALL
add action=accept chain=forward comment="accept from LAN to any LAN" in-interface-list=LAN out-interface-list=LAN
add action=accept chain=forward comment="allow reverse-nat" connection-nat-state=dstnat in-interface-list=WAN_ALL
add action=drop chain=forward comment="drop everything else"
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN_ALL

Is the solution simply to add the following two rules here?

add action=drop chain=input comment="drop DNS requests not from local IP space" src_address=!192.168.1.0 port=53
add action=drop chain=forward comment="drop DNS requests not from local IP space" src_address=!192.168.1.0 port=53

You already have this rule which blocks everything not coming from LAN.

1 Like

Addendum:

Service inside Router do not use at all forward.

But RouterOS DNS do not accept registration, so you must add manually all name.local on the static section,
or with advanced scripting and DHCP server events you can add/remove dynamically the entry on DNS.

Mistakes around exposing DNS are very common, so it's very good that you ask these questions. For this reason, these things bear repeating. So...

  • The default firewall is totally sufficient for protection against this, as @rextened explained. The default firewall gives DNS the same protection as the HTTP Webfig interface and all the other services, that is: they are blocked from anywhere except from the LAN interfaces. Of course this is only true if you haven't (inadvertently) modified the firewall in such a way as to make this ineffective.
  • The block rules you have given are a good start, but there are some things that should be modified.
  • Again, as @rextended said, packets to the router traverse the input chain, not forward, so for this purpose rules should only be added to the input chain. (Adding these rules to the forward chain as well have other unintended consequences.)
  • When using the src-address=!192.168.1.0, although the form is generally correct, you most probably want to allow access from the entire subnet. In this case the correct form would be src-address=!192.168.1.0/24
  • Should you want to access DNS from several subnets, you could add all of them to an address list and then use src-address-list=!dns-allowed to handle it. Similarly, should you want to restrict by interface instead of address, in-interface=!bridge could be used. For multiple interfaces, similarly, interface lists can be a good idea.
  • The port parameter in the firewall can only be used when specifying the protocol as udp or tcp, such as protocol=udp.
  • DNS uses both udp and tcp. It is idiomatic to always add the same rule for both of them. (The main danger in exposing DNS only applies to UDP, but in order to have a well-working and well-protected setup, it's a very good idea to always have both rules, and to make sure that they are actually the same.)
1 Like

Ok, thank you all for the replies so far. Let me address a few things:

I started with a blank setup, with no rules. So the rules listed above are the ones I have configured myself, although most of them are probably very similar to the defaults.

Good point. Thanks for the reminder.

Given all of the above information, it seems that I do not need to add any additional rules?

My reasoning:

  • We only need to consider the input chain, since packets will be going to the Mikrotik device itself, which is where the DNS server instance will be running.
  • Since I accept packets from LAN, and drop all others, these rules are already sufficient and nothing else port/protocol/ip address range is required.

Are my conclusions correct?

You don’t need additional config lines except those already existent in default MikroTik firewall config (which you already have).

It's a good idea to be aware of the default firewall even if you're starting off with a bare setup. You may of course want to change/discard/add things, but it's a good point to start off from. (To put it another way: until you can explain to yourself what each of the rules in the default firewall mean, it's best to not discard them altogether.)

This observation is not specifically directed at you, you seem to have done exactly this.

Yes. Your conclusion is correct.

@lurker888 is our local AI. Therefore his advice may contain unnecessary information.

1 Like

Maybe you should remove software id and serial number from your export.