Hey! I feel like I’m just missing something simple. I’ve had this set up before on a different router but now it just won’t work.
I just need the router to act as a DNS Server to redirect any traffic from inside the network to our local server “server.our.local” to the internal IP Address 192.168.1.178 instead of it’s public IP Address.
But any queries to it just time out.
mikrotik-config.rsc (25.2 KB)
Your last NAT rule would redirect all DNS requests (if it was active, it’s disabled in config export) from everywhere to internal router’s DNS server … but your last firewall filter blocks that:
/ip firewall filter
add action=drop chain=input dst-port=53 protocol=udp
/ip firewall nat
add action=redirect chain=dstnat comment=\
"DIRECT ALL DNS REQUESTS TO MIKROTIK INTERNAL DNS SERVER." disabled=yes \
dst-port=53 protocol=udp to-addresses=192.168.1.1 to-ports=53
BTW, DNS also uses TCP protocol, sou for completeness sake you should have additional pair of rules … but with protocol set to tcp instead of udp.
BTW2: if you want LAN (client?) devices to use your Mikrotik as DNS server, why don’t you configure it in DHCP server settings?
Hey! Thanks for your reply.
Yes I disabled it, as it completely blocked all DNS requests on the network when it’s enabled.
That firewall rule should only block traffic from the WAN shouldn’t it?
Also yep I will change the DHCP As soon as I get the DNS to actually resolve from my test machine that has 192.168.1.1 manually set as the only DNS Server
No, there’s no property telling firewall to be selective with this regard. If you change it to
add action=drop chain=input dst-port=53 protocol=udp in-interface=ether1
it would be more selective.
Mind that “chain=input” is not about some fictional packet direction (routers don’t have any idea of what’s WAN, what’s LAN, what’s input etc.), it’s about firewall processing chains. There are 3 of them by default (you can construct additional ones though): input (processes traffic targeting router itself), output (traffic generated by router itself) and forward (traffic that only passes router between any pair of interfaces). So both connections from LAN device and from internet targeting router (any of router’s IP addresses actually) will be handled by input chain.
Alright. That’s been done!
However the DNS Still does not use the Mikrotik to resolve the URL. It goes straight to the fallback 1.1.1.1
You may want to have a look at default firewall setup. Connect as admin user via CLI, make your terminal as wide as possible and execute command /system default-configuration print (command does not wrap wide lines, these get truncated). Then scroll down a bit until you get to the firewall section. Default firewall is pretty decent, quite easy to expand (if you don’t deviate much from “single WAN, single LAN” concept) and safe in the first place.
Are you sure about that? The redirection to router’s own DNS service is completely transparent to DNS client … unlike e.g. URL redirection in HTTP which makes target of redirection known to browser.
Did you remember to enable the redirect rule again?
I used NSLookup to poll the mikrotik directly:
I’ll keep this in mind, though my boss was difficult about “Not being able to debug from home”
Ahh, second-to-last rule in posted firewall config is rule
add action=drop chain=input comment="Drop everything else"
which takes care of … well, everything 
Co add a rule
add action=accept chain=input comment="DNS from LAN" in-interface-list=DHCP protocol=udp dst-port=53
or something like that (adjust in-interface / in-interface-list property) and push it above the previously quoted “drop all” rule. Keep in mind that firewall rules are processed from top to bottom and first matching rule executes (and stops processing of packet).
Or, if you can’t set sensible in-interface / in-interface-list for that rule, go with two rules (again, both above the drop all rule) in this order: first one dropping DNS requests from WAN and second one allowing DNS requests from everywhere (but WAN requests will be dropped already).
Having winbox port open from internet, although with changed port number, and without filtering source addresses, is pretty insecure (not to use some stronger word).
That was it!!
It works now! Thanks!
I used the bridge as the interface
