Force Users to Use Specific DNS Server

Greetings,

I’d like to force all users on my single home LAN to use my own Pi-Hole DNS server just in case they’ve manually configured another DNS server.

I found this entry in the MikroTik WiKi which seems like a simple solution: https://wiki.mikrotik.com/wiki/Force_users_to_use_specified_DNS_server

It states…


This is just simple firewall rule which will force all Your users behind RB to use DNS server which You will define.

In /ip firewall nat

add chain=dstnat action=dst-nat to-addresses=192.168.88.1 to-ports=53 protocol=tcp dst-port=53
add chain=dstnat action=dst-nat to-addresses=192.168.88.1 to-ports=53 protocol=udp dst-port=53

>
> This rule will force all users with custom defined DNS server to use 192.168.88.1 as their DNS server, this rule will simply redirect all request sent to ANY-IP:53 to 192.168.88.1:53

Unfortunately it doesn't work!  When I add and enable these two  rules on my router's NAT exactly as shown (except I specify the Pi-Hole's IP as the "to-address") DNS stops working.  As soon as I disable the rules, DNS works fine.

The Pi-Hole DNS server is also on my LAN.

Can anyone please tell me what I'm missing?

Thank you,

John

You’ve got to setup hairpin nat for the pihole. Change 192.168.1.2 to your pihole ip.

/ip firewall nat  

add chain=dstnat action=dst-nat to-addresses=192.168.1.2 protocol=udp src-address=!192.168.1.2 dst-address=!192.168.1.2 dst-port=53 in-interface=!ether1
add chain=dstnat action=dst-nat to-addresses=192.168.1.2 protocol=tcp src-address=!192.168.1.2 dst-address=!192.168.1.2 dst-port=53 in-interface=!ether1 

add chain=srcnat action=masquerade protocol=udp src-address=192.168.1.0/24 dst-address=192.168.1.2 dst-port=53 
add chain=srcnat action=masquerade protocol=tcp src-address=192.168.1.0/24 dst-address=192.168.1.2 dst-port=53

were does your pihole get its dns?
you must allow requests from pihole ip to reach the dns resolver the pihole uses

Good point! I knew I must be overlooking something obvious.

Pi-Hole’s DNS resolver is OpenDNS at 208.67.222.222 and 208.67.220.220.

So without additional NAT rules to clear Pi-Hole’s DNS resolver queries, I take it they would also get routed right back to itself?

Thank you,

John

Thank you HzMeister. I’ll give this a try.

Regards,

John

Greeting!
I also just want to provide “opendns” DNS Server to block porno!

i used this code

/ip firewall nat

add chain=dstnat action=dst-nat to-addresses=208.67.222.123 protocol=udp src-address=!208.67.222.123 dst-address=!208.67.222.123 dst-port=53 in-interface=!bridge-GF
add chain=dstnat action=dst-nat to-addresses=208.67.222.123 protocol=tcp src-address=!208.67.222.123 dst-address=!208.67.222.123 dst-port=53 in-interface=!bridge-GF

add chain=srcnat action=masquerade protocol=udp src-address=192.168.50.0/24 dst-address=192.168.50.2 dst-port=53
add chain=srcnat action=masquerade protocol=tcp src-address=192.168.50.0/24 dst-address=192.168.50.2 dst-port=53

Buy its not working for me (:
In one of the user PC i can change DNS server to 8.8.8.8 and can load all porno content.
I would be glad if some one can point me where i am making a mistake.

I have the exact same issues.
World you mind sharing all the steps necessary to achieve this?
Peace :victory_hand:t2:

kaherdin,

Are you looking for the exact steps needed to have RouterOS use Pi-Hole for DNS?

Or are you looking for the steps required to FORCE users behind RouterOS to use Pi-Hole for DNS?

If the former, I can post the steps. Just let me know.

If the later, I can’t help because I decided it wasn’t necessary on my LAN so I never implemented it.

John L.

If you are using OPEN DNS, why bother with pi-hole???
Just set up open dns as the static DNS setting
Then use redirect function on the dstnat rules and the dns queries will be forced to one of the router interfaces and since the router has been told to use open dns it should work.

/ip dns static
add address=208.67.222.222 name=OpenDNS1
add address=208.67.220.220 name=OPENDNS2


remove any other servers…

Then add to nat rules…
/ip firewall nat

add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp

I’m using a pihole, and i want to try to force as many DNS requests to it, despite devices trying to circumvent it using hard coded DNS settings…
dro.txt.rsc (8.1 KB)

Either do what @anav posted and force clients to use router as resolver (which is configured to use pihole as its upstream resolver). Or if you want to send queries to pihole directly, then:

/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

Is this, shown below, done on a client per client basis?

/ip dns static
add address=208.67.222.222 name=OpenDNS1
add address=208.67.220.220 name=OPENDNS2

Is this code going to block the answers from getting back to my Pi-Hole?

/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

****For starters dont mix and match ideas…

My point and I wish Sob would clarify was to NOT use pi-hole at all if not needed.
If you can direct users via MT config to use open dns as a service then pi-hole is not needed.

Q1 OP: So is pi-hole the requirement or is open dns the requirement???
(in other words is there something else pi-hole is doing that you want included or not)/

Q2 SOB: Please confirm/deny what I proposed will work to send all users directly to open dns bypassing Pi hole.

Q3. Sob: using your method to get folks to pi-hole… why the sourcenat rule??? (this is not a port forwarding scenario?)

For start, people should not reply to years old posts with “I have the same problem”, because they usually don’t have exactly the same problem, and someone always gets misled by old posts. Anyway…

There are two ways:

a) Use @anav’s rules with action=redirect to redirect all queries to router itself, and it will use whatever resolvers it has in “/ip dns servers” (not “/ip dns static”, that was error).
b) Use my rules with action=dst-nat to redirect queries to external resolver. If it’s in same LAN, it needs also hairpin NAT rule (the one in srcnat chain).

@anav: Q2: yes; Q3: of course it is

Okay some progress,
Why not put the open dns servers as static entries.
Does that not mean they take precedence over any other DNS server noted??
Stated otherwise, why put them under Servers?
and if you put them under Servers do you need then to check off the box, allow remote requests??

“/ip dns static” is locally defined static records, they do have precedence, but this:

/ip dns static
add address=208.67.222.222 name=OpenDNS1
add address=208.67.220.220 name=OPENDNS2

means that if someones asks router to resolve hostname “OpenDNS1”, it will return address 208.67.222.222, and same for the other one. Problem is, no one will ever ask router to resolve hostname “OpenDNS1”. If you want router to use OpenDNS resolvers, it’s:

/ip dns
set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220

And allow-remote-requests=yes is required when router should serve as resolver for anyone else. If it’s allow-remote-requests=no, then it’s only for router’s internal use, e.g. if it needs to resolve server hostname used by VPN client, some MikroTik’s url for upgrades, etc.

Crystal clear!!

Then the solutions become.
A. Force Redirect to OPENDNS (without PI hole)
/ip dns
set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220

/ip nat
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp

B. Force OPEN DNS (via PI hole)
/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

I have seen problem with devices like Chromecast when redirecting port 53. These devices has hard coded DNS to for example 8.8.8.8

If they send query to 8.8.8.8, they will get response from 8.8.8.8 (not really, but it will seem to them to be from there). One possible problem I’m aware of is that RouterOS v6 doesn’t keep the case of letters, so if you ask for “MikroTik.com”, the answer will contain “mikrotik.com” and some devices may not like that. It’s fixed in v7.

TO be pedantic was it a case of not keeping letter or was it correcting non-standard confirming domain names coming from smart devices??? (in either case client device rejects return traffic)