I have configured simple DNS redirection, which force all client to use Mikrotik as DNS server regardless what DNS the client is using. It works fine on Mikrotik 6.49, but after upgrading to 7.20.4, the DNS redirection stops working.
The rules:
/ip firewall nat
add action=redirect chain=dstnat disabled=yes dst-address-type=!local dst-port=53 protocol=udp
I can’t figure out how to make this works on newer router OS
Thank you!
The obvious one is that disabled=yes rules are... disabled.
Also, check that the things you're testing with actually use port 53 udp dns. Many applications nowadays don't.
I disabled it because it wasn’t working when I turn it on. Internet stop working, DNS on PC won’t resolve if I enable the rules
First, verify that Allow Remote Requests is turned on under IP -> DNS.
Then create an interface list (LAN for example, if not already exists) and make sure your LAN interfaces (bridges and VLAN interfaces) are members of that interface list.
Modify the DSTNAT rule above and add the condition in-interface-list=LAN (adjust with the name of the list you created above).
Make a copy of the rule, in the copy, change protocol=tcp and save it, so that there are two redirect rules.
If you have a non standard firewall configuration (not with defconf rules), make sure you added action=acceptrules on the chain=input for traffic coming from those interfaces, in-interface-list=LAN (adjust with the name of the list you created above) and dst-port=53, TCP and UDP. Move the new rules above other action=drop rules of the chain=input.
If you want to forbid the clients to use alternative DNS protocols, add rules to drop forwarding for port 853, TCP and UDP (this is for DoT and DoQ), as well as use a list like this GitHub - crypt0rr/public-doh-servers: A simple list with public DNS-over-HTTPS (DOH) providers so you can easily block them. to block common DoH providers (port 443 TCP and UDP).
Must be looking at rextendeds posts........... Was it your intention to redirect the internet bots DNS too....
You should at least indicate that this DNS handling is for LAN clients only
in-interface-list=LAN
Ahh I see cggx covered that..........
First, verify that Allow Remote Requests is turned on under IP -> DNS.
I did this already
Modify the DSTNAT rule above and add the condition
in-interface-list=LAN(adjust with the name of the list you created above).
I tried this one no luck, still not forcing client to use Mikrotik to resolve the DNS
Bottom line, the configuration I posted initially was working fine on ROS 6, but not on ROS 7.
Then you should post the rest of your (with sensitive information censored) configuration export. Because in ROS 7 it still works as I described above. If it doesn't work on your device, then the cause might be located in other parts of your configuration.
The rules was placed on the top, so it should be processed first before processing anything else. Therefore, I was not include other parts because it was not relevant.
I am just wondering if the configuration for DNS redirection is different between ROS 6 and ROS 7, because I noticed it is major upgrade
The redirect rules, with in-interface / in-interface-list restriction, with copies for both UDP and TCP, still work fine in the latest RouterOS 7 version. I am using them on my guest VLANs.
The problem is probably with other parts of your configuration.
Well, then you are able to figure out the problem yourself,
if you also know which parts are relevant or not.
Very diplomatic of you Sir!.
What is disturbing is the OP coming here asking for advice, CGGX gives very good advice ( far better than I ) and yet the OP says, No I dont need your advice, I only need to show this............... Arrogance or ignorance your pick.
More likely ignorance and by that I mean the OP does not realize that the RoS config is very much interrelated and life and success is not just found in the firewall rules.
We are interested evidence and facts, thus the config needs to be posted. Otherwise all we have is opinion, which is not worth that much.
Not sure about that redirect rule, but this works and always worked for me
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=53 in-interface-list=!WAN protocol=udp to-addresses=192.168.88.1 to-ports=53
and same for TCP
The to ports is redundant and your redirecting the packets to the router which is the same as saying redirect................ Why I like yours better is because I never know what redirect uses for the dns gateway LOL
better
in-interface-list=LAN
LAN is... LAN
!WAN is for sure not WAN and is for sure LAN, but are ALSO all undefinded other sources that not are WAN or LAN...
Thanks everyone for the answer!
I will try to test the same rule I had with ROS 6 to factory reset on ROS 7 mikrotik to see if it is working.
I just want to confirm that nothing major change on DNS redirection rule between ROS 6 and ROS 7.
The one I noticed that has major change so far, is OSPF config, I had to re-configure again in order to make it to work on ROS 7, plus the configuration is different from ROS 6
Thank you
I have the same problem, DNS-Redirects work under v6, after migrating to v7 it stops working. I see frames against the DNAT rule and I see these frames in the Filter > Forward-Chain. Is this normal? I would assume they should go the input chain?
I think I found the issue. Do you use Mangling and/or Multi-WAN?
It seems in v6, if you Mangle (in prerouting chain) traffic fom a host in the LAN and say “you go out via WANx”, this matches also for DNS (eg 8.8.8.8:53) or NTP traffic… V6 was so intelligent that if a successive NAT/DST-Chain/Redirect-Rule was added, it moved these packets from the own routing-tabel (mangle, Routing Mark) back to the main-table.
In v7 it seems (obviously) these packets stay hard in their table.
My solution is now to exclude all redirect-traffic from the Mangling (PBR). Then, everything works as expected. But I have to keep my NAT/DST-Chain/Redirect-Rules and the Mangling-Exclude from PBR rules in sync.
Maybe someone can say if MT changed here something fundamental?!
The default order for routing table lookup is documented here:
As you can see, mangle is above local. So, if a packet was affected by mangle mark-routing and the routing mark is correct (match a routing table), then from the default policy rule order, when routing lookup is performed for the packet, processing will stop at the 1st step and local address lookup will not be performed.
From 7.22 you can change that. If you don't want to have to manually duplicate the condition for DSTNAT in your mangle rules, you can edit /routing settings policy-rules and move local above mangle in the list (see the example that move mangle even lower, below user - items under /routing rule by default are put in the user chain).
Good catch! I updated from 7.20.8 long-term to 7.22.1 stable to have these options.
It works as you said, I moved “local” on top and “mangle” on position two (deleted “local” from lower position). Can we “mimic” with this the behaviour of v6 in v7? Or has this some unwanted side-effects? I dont think so, but I had to read the linked documentation 5 times to understand it at least a bit.
Yes, moving local above mangle in policy-rules effectively mimics the v6 behavior. In v6, DSTNAT/redirect rules always took priority over mangle routing marks when a packet matched both - in v7 they made the routing table lookup order explicit and configurable, which is actually more correct but breaks the implicit behavior a lot of us relied on. The side effect you're asking about is subtle but worth knowing: with local first, any traffic destined for the router itself (DNS queries to the router, management access, etc.) bypasses mangle routing marks entirely. So if you have PBR rules that were supposed to route management traffic through a specific WAN, those marks won't apply to traffic hitting the router's own address. For a typical home or SMB setup where you're just doing DNS redirection this is exactly what you want - the router's services should always be reachable regardless of PBR. Where it could bite you is if you have deliberate PBR that routes traffic TO the router through a specific path, which is unusual. In short: your setup is sound and you're not losing anything you need.
Let me know how you get on.