My Mikrotik can’t use other IP Addresses than my ISP’s on IP->DNS setting.
Basically outgoing port 53 is blocked TCP/UDP by my ISP. I’m forced to use theirs. I want to use Google / Cloudflare’s DNS 8.8.8.8/1.1.1.1
On Windows, I can use DNSCrypt, but that’s not the case. I’m sure Mikrotik can use other non-standard port so it can resolve properly? How to do that?
Nevermind.
What about DST-NAT rule which changes router’s DNS queries from ISP_IP:53 to NEW_IP:OTHERDNSPORT ?
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=53 protocol=udp to-addresses=208.67.222.222 to-ports=5353
add action=dst-nat chain=dstnat dst-port=53 protocol=udp to-addresses=208.67.220.220 to-ports=5353
add action=dst-nat chain=dstnat dst-port=53 protocol=tcp to-addresses=208.67.222.222 to-ports=5353
add action=dst-nat chain=dstnat dst-port=53 protocol=tcp to-addresses=208.67.220.220 to-ports=5353
OpenDNS example
Is there any benefit in having two dst-nat rules for same connection criteria? If here applies same principle as with firewall filters, then the second rule (the one with to-address=208.67.220.220) will never be used? Or are these rules used in round-robin fashion?
The first one will cacth all DNS queries but you can add src-address to pass queries to different DNS servers.
E.g. all traffic from LAN devices could be sent to OpenDNS, queries originating from router itself could be send to the second DNS server … etc.
@BartoszP … but in that case, those NAT rules would not be exactly as shown. There would be some other criteria involved, such as src-address-list or something similar. My question was about the exact rules as posted by @poizzon.
And constructing rules as per your suggestion: if “first-rule-match” principle applies here, one would have to be very careful about proper order of rules, e.g. place more specific first and more general later.
The first one catches all for UDP traffic to port 53 and the third one all for TCP queries to port 53
Exactly.
So why would one put also 2nd and 4th rule as they are?
My guess is that they are simply misleading (or redundant at best), but I may well be wrong and there might be somebody who knows it better.
IMHO they are dummy rules as 1st and 3rd will catch all traffic.
To funny mkx, you are asking BARTOZ about rules somebody else (poizzon) posted.
It seems clear that piozzon was just listing the two often cited/recommended addresses for OPEN DNS.
In case the first one was not available the traffic could be sent to the second is I suppose the thinking.
The right question is… if the first DNS query rule does not work because the OPEN DNS adddress is not functional will the router still pass the traffic using the second rule (address)???
No, it won’t. Dstnat only changes destination address, router has no way how to monitor if server responded or not (well, maybe some hack would be possible).
But if poizzon’s config would be changed from to-addresses=208.67.222.22x to dst-address=208.67.222.22x, and two 208.67.222.22x would be configured on client as resolvers, then the failover would work.
Hey, I swear there was a new post here just now and it dissapeared before I finished the reply…
Anyway, what I meant was:
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=53 protocol=udp dst-address=208.67.222.222 to-ports=5353
add action=dst-nat chain=dstnat dst-port=53 protocol=udp dst-address=208.67.220.220 to-ports=5353
add action=dst-nat chain=dstnat dst-port=53 protocol=tcp dst-address=208.67.222.222 to-ports=5353
add action=dst-nat chain=dstnat dst-port=53 protocol=tcp dst-address=208.67.220.220 to-ports=5353
So only requests to specified servers will get destination port changed from 53 to 5353.
What I don’t like is that router will be left out (not just with this, but anything you can currently do), it won’t be able to use these resolvers and you can’t use it as cache. It could be done, but unlike Linux, RouterOS doesn’t support dstnat in output chain.