Bucking is correct, you should not make a resolv.conf and make it read only. The docker image will fail on startup because a docker image does not use 127.0.0.1. It should notify you as an error and say it found a nameserver of 127.0.0.11 or something like that and use that and default to google name servers until it downloads the block lists. Where you guys may be having issues is on your router end if pihole tries to connect to google DNS and your router may be trying to push the request back to pihole. I accidentally did this on DD-WRT by forcing the DNS to pi-hole and it would not start.
Try starting the container and going to details and then the log tab and let us know where exactly on startup that is failing. There are many possible reasons on why startup could fail. Anything from a failed mounting path to router issues.
Interesting information here, thanks all. The reason I had to use the mounted resolve.conf was because it absolutley refused to start with a fresh container in a docker running on a macvlan inside the synology. As Beefyfish rightly pointed out, the pihole was complaining about no DNS resolution and was trying to use 127.0.0.11. Once I added the force mount resolv.conf, the problem immediately went away, the pihole started up and all the traffic was showing as flowing through the pihole.
I do not doubt what you have advised above is correct but for me it was the only way to even get the pihole docker to start in this specific (and granted not the normal) configuration. I have now (based on the above) removed anything from the resolv.conf but 127.0.0.1 and made it writable. This seems to work still as it did before.
Thanks for the correction all, I was just trying to add to the knowledgepool and spent the whole weekend getting this working. I thought my details may help anyone else trying this guide with the same odd set up I have, i.e. teamed network running DNS and a windows domain all from the synology the pihole docker is hosted on.
Many thanks to you Beefyfish, without your guide to the macvlan I would never have figured it out. For me the crucial difference was not to change the Synology NIC DNS but to change the DNS server conditional forwarder to point to the bridge network IP instead.
Ok, just tried removing my resolv.conf mount and I'm back to being unable to start the docker. Yes, I did remember to set the Synology DNS server to forward to 8.8.8.8 after I undid the resolv mount and before I tried restarting the pihole. I KNOW the pihole has resolution as if I put back the resolv.conf with just nameserver 127.0.0.1, it works. Very strange.
Not sure which variables you mean, sorry. My replacement resolv.conf now only has 127.0.0.1. The clients are all looking to the Synology DNS server on 192.168.0.2 which has a forwarder to 192.168.101.2 which is the bridge network to the pihole. This config works. If I change the forwarder in DNS to point to 8.8.8.8 and then start the pihole with no resolv.conf mounted, it will reboot every two minutes as it is unable to resolve any DNS. As soon as I mount the resolve.conf and put the forwarder back to 192.168.101.2 and restart, the pihole works perfectly. I'm just happy it works!
Edit: It looks as you have a pretty untypical layout. The only real advice I can give to you is that the only way anything on your synology(including docker images) can talk to pihole is through the bridge network that you created. Other pieces of equipment can talk to pihole with no issues.
You will have to figure out a way to loop the communications around your network following those rules as the way it is now it is getting stuck somewhere.
You may have to draw a small picture and figure one way for your dns out. Such as everything talk to the domain controller and then it loops it through the bridge to pihole.
Thanks for taking the time to think and post about this. What you suggest is what I have, the Synology runs the domain DNS server which the Synolgy and all the clients use. The Syno DNS server forwards to the gateway to the pihole. The pihole talks to the router and all is good. I just have to force the resolv.conf, which now I've limited to 127.0.0.1 and made writeable, I'm happy with. Clients aren't seeing ads, I broke facebook and youtube (fixed with the whitelist in pihole), so I know it's working Plenty of traffic in the pihole interface (damn you Nvidia!) so it's case closed as far as I'm concerned. Once again, thanks to you and Bucking_horn.
Well hopefully it works as you need. Networks can be very complicated. My synology talks to pihole through the bridge but then pihole goes back through the bridge to talk to my cloudflared https docker image and then that shoots out for internet dns resolution. Adding domain controllers and multiple layer networks can make things very difficult to follow.
Beefyfish Alex_Wright great guide and got me up and running very quickly on my Synology
I followed Alex's guide, just changing my Pi-hole IP and Maclaven network to .20
Its been running great, but I'd like to also use docker Unbound for my pi-hole DNS .
Do I need to put this in the maclaven network as the pi-hole .
I used the /32 when setting this up so it restricted to one IP , I'd need to change this if so, but not sure how ?
Any help would be greatly appreciated ..
Install Unbound on your HOST docker network. Once that is all setup you can point your pihole to the Pihole_Bridge Gateway and Port like shown on THIS POST
I have pihole going back to cloudflared DNS installed on the HOST network but unbound should work the same.
thanks Beefyfish , So I had installed Unbound on by docker bridge network , port 53 mapped to port 5335 on the host (in the 172.172.0.x range in docker)
I have the pihole pointed to the pihole_Bridge gateway and port . 192.168.100.1#5335 .
I am still able to resolve DNS .
Should I redeploy the Unbound docker to the HOST docker network. ?
Hello Beefyfish
Thank you for this amazing how-to which works like a charm on my DS918+.
I followed your advice and ran the visibilityspots/cloudflared image, checked "Use the same Network as Docker Host" and set my upstream DNS to 10.0.100.1#5054.
Everything works well but I would like to understand why does the upstream DNS needs to points towards 10.0.100.1, which, when following your how-to, is the IP of the Macvlan bridge gateway.
Since we checked the "Use the same Network as Docker Host" I have a hard time understanding why we are using this IP address here.
So I'm not reporting any issue here but just trying to understand and learn!
Also, I just noted something strange.
Since I created the "Pi-hole_Bridge" and "Pi-hole network", all containers associated to my original "bridge" network do not have access to internet anymore.
I realized that modifying the container and checking the "Use the same Network as Docker Host" solved the issue, but I do not understand why this "bridge" network is not working anymore.
The docker host is not allowed to talk to the macvlan on your network for security reasons built inside docker. We use a Docker bridge network to circumvent this restriction.
As towards your other bridge network not having internet did you point your synology DNS to the Pihole_Bridge? If you did not do this your synology will ask the router for the DNS location and it will try and send it to the macvlan and timeout because it is not allow to talk to it. Also make sure you set a static IP on your synology if you have not.
If you have all this setup did you reboot? I have had many times when doing complex things that the ip tables would not update on my synology and a simple reboot would correct them.
I did everything, pointing the synology DNS towards 10.0.100.2 (the IP range, not the gateway as indicated in the how-to), my NAS has also a static IP address with DHCP reservation. I also rebooted the NAS and when going to Network -> Static Route, I can see the following in the "Main table" menu:
Yes it seems to as it retrieves the list of community packages.
Also, I rebooted once, it seemed to solve the problem as one of my package connected to the bridge (Ombi) got internet back.
I rebooted once again and am now back to the same situation, but package center still has access to internet.
Plenty of traffic in the pihole interface (damn you Nvidia!) so it's case closed as far as I'm concerned. Once again, thanks to you and Bucking_horn.
