If your rules are on the “input” chain, matching only dst-port, then no - it won’t disable your router from making DNS requests, and/or disable receiving of replies to them.
is IMHO best suited to block outside DNS requests, assuming you have only one local interface (in the example above called “LAN”; adjust accordingly), and one or more outside ones.
No valid traffic ever uses them, but malicious one that tries to do a DDoS attack does.
Also, and this is more optional… perhaps block echo (and other ICMP) requests to your inner devices from the outside? You can still do that AND still allow yourself to do ping FROM the inside to the outside.
In total, my rules look a little something like:
/ip firewall filter
add action=reject chain=forward icmp-options=8
in-interface=!local out-interface=local protocol=icmp reject-with=icmp-host-unreachable
add action=drop chain=forward icmp-options=17
in-interface=!local out-interface=local protocol=icmp
add action=drop chain=forward icmp-options=15
in-interface=!local out-interface=local protocol=icmp
add action=drop chain=forward port=0 protocol=tcp
add action=drop chain=forward port=0 protocol=udpWith the exception of the last two, you’ll again need to duplicate those rules for each public interface, instead of using “!local”.
Note: The first rule blocks ping requests, and instead of dropping them, returns “host unreachable”, so that to an attacker, it looks the same as if you didn’t had a local network… dropping ping requests would alert them something is going on IF they also try various other IPs at your router, only to see some of them go “host unreachable” and others “timeout” due to the drop… Actually, come to think of it… maybe I could just drop them, since I’m blocking ALL ping requests, and not just some… but if you need more fine grained control, you’ll need to use “reject” instead of “drop”.
By default, RouterOS lets everything in, but yes, you could change that by allowing what you need, and then adding a rule that would match everything else (by merely not matching anything specific at all), and have it with action=drop.
With masquerade, AFAIK, RouterOS will proceed with port 0 as with any other port by default, i.e. when it’s a destination from the outside to the inside, it will check if there’s a dst-nat for it, and drop it if not, but if someone from your local network is sending packets with port=0, then by default, RouterOS will just NAT them, as with any other port. The rules above about port=0 would prohibit not only the outside from sending/receiving packets on port=0, but also your local network from trying to do that to the world.