I did some testing on my end and while it blocks access to google's DNS servers, it doesn't seem to correctly forward the querries to the pihole as I had intended.
I can see all the querries made from my hardcoded devices (google home mini and chromecast) and apps in pihole's querry log since they use the DHCP supplied pihole DNS as fallback option when google's DNS servers are not reachable.
Nevertheless you should now see querries from hardcoded apps in you querry log. I am going to google a bit, but I am not a trained network expert.
I know very little about it, so I try logic. Correct me if I'm wrong. Access to ip 8.8.8.8 goes to gateway 192.168.178.1. This now knows the static route and forwards the request to the pi-hole. Does this know now that he has to answer the original client or does the pi-hole of the Fritz box answer, which cannot do anything with it and rejects it?
I have now used tcp dump to see what goes down with the pihole.
If I access 192.168.178.62, the pi hole replies to 192.168.178.70, which is ok.
If I access 8.8.8.8 the pi-hole sees that. rejects it because it is not for him. there are no answers. The static routes are normal for another router and he now knows where to forward it. but the pi-hole cannot do with packages for 8.8.8.8.
ok, with ** sudo ip addr add 8.8.8.8/24 dev eth0 ** I was able to assign 8.8.8.8 to the pi hole. he answers now. anyway i don't get the side of the pi hole. I have to test whether that works with DNS inquiries.
Instead of rerouting each IP address individually, you could consider to block outbound DNS traffic in your Fritzbox for all or for a selection of your devices (a while ago, I've explained that in more detail in German, see Smarthome Steckdosen im pihole - #8 by Bucking_Horn).
That would block attempts by any device in your network to access any public DNS server via port 53 DNS, leaving Pi-hole and your Fritzbox as the only operational DNS servers.
It would stop all DNS bypass attempts to public servers without having to know any IP addresses upfront, but may incapacitate those devices that insist on using a public DNS server.
I had already done that, and I'm still set that way. but made sure that Netflix no longer worked, for example, because Netflix wants to access Google dns. Feet redirect was just a successful attempt to get Netflix to work again without opening the block again.
So if I run this on my Pi-Hole, it will work w/o the settings in the router? (my router does not support catching port 53 requests, so now I've hard-blocked 8.8.8.8 and 8.8.8.4 in the router)
no, because the pi-hole never gets to see the packets on 8.8.8.8. your switch will not put you on the line to your pi-hole routes. the only solution I see is because Pi-hole with a passive tab adapter can be connected directly to the same line as the router. then he sees the packages and can react.
Because you're calling yourself 8.8.8.8 which is a very bad thing to do. And won't work for any client, since they are going to route to the real 8.8.8.8. Only the device you added the IP address to will have a route to use itself as 8.8.8.8.
I'm sorry, but the explanation doesn't make sense. I have an app that absolutely wanted to address 8.8.8.8:53 directly. but I had blocked port 53. the app did not work. now i have given pi hole 8.8.8.8 and the app works. all is well. so it works. just don't do it is no justification. why not? it works the way it should. it is the point of pi hole to let pi hole handle all DNS traffic what should happen if I give it the IPs of the blocked DNS servers? except that he takes on the task of this.