>
> 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
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.
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
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:
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).
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.
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)