New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DNS queries from other docker containers fail when server IP is used in resolv.conf #230
Comments
Has this been resolved by v3.3? |
Nope. I'm trying to run smokeping next to pi-hole and got the same error w/ pihole 3.3 |
I have the same events with the armhf. The workarounds ( pihole docker private ip 172.... Or external dns server (ie my router dns)) . I tried a "docker network connect pihole_default mycontainer". I could ping on container's name but not on external names. Embedded dns may be a point to analyze. I did not find the latest version of that point (18.03)
I noticed that problem after an unwanted reboot last tuesday (07/17/18) :( the container was created beginning of june. Raspberry Updates are installed as they re out. The probleme seems to be because we are running containers on the same host that run pihole in a container. |
I recently had to do this for work. I faked out some DNS records for other containers using a docker pi-hole container containing the desired dns records. The trick was just editing the docker host service (https://docs.docker.com/config/daemon/#configure-the-docker-daemon) to use localhost as DNS (I also added a backup dns because chicken before egg). the first There's no worry about what networks are connected to which with this approach or configuring individual containers' DNS. It's not exactly pretty but it worked short term for the testing I was doing. |
edit: changed daemon dns from 127.0.0.1 to pihole docker network's ip 172.20.0.2 + need to join pihole's network for each container that need name resolution as I'm using docker-compose to create containers.
I wanted to be able to resolve public servers names and local names stored in a file hosts.domain in containers running on the same host as pihole. a custom file for dnsmasq is already defined containing:
i got a result with this 3 steps fix:
|
I'm basically using the docker compose config example file. To this (webservice runs behind Nginx):
I created a daemon.json file,
Pi-hole is running fine. I restart docker via: $ docker run busybox cat /etc/resolv.conf
nameserver 192.168.1.20
nameserver 1.0.0.1 Which looks fine by me. However, when I try to do a nslookup for example, it will not use 192.168.1.20 😢
As you can see it will try to actually use the secondary DNS server (1.0.0.1) instead as fail-cover.
Some extra info.
I want to that all my Docker images will use my Pi-Hole DNS. How? What do I wrong? |
Docker networking is a little weird and is blocking hairpin port forwards by default. edgd1er covered how to do this accurately as far as I can tell after experimenting a little, look over his instructions and try those. I would recommend adding a static IP to the pi-hole container and making sure you join all containers that need to use Pi-hole's DNS to the network your docker-compose created : melroy_default. |
TLDR; I need a working solution without manual steps in between. This is not acceptable for every container that need Pi-Hole DNS. Since the Docker containers that need this are created by another program (called Gitlab Runner). Which is out my control, Gitlab Runner has control of the creation as well as maintenance of those containers. So, currently by Gitlab continuous integration can't access it's own host, which is due to the missing bridge-mode support on my router/modem of my ISP (https://community.t-mobile.nl/t-mobile-thuis-internet-492/hg659-bridge-mode-298267). Long story short, I can NOT use global DNS servers (like 1.1.1.1 or 8.8.8.8) for my local network services (I run a server with some services like Nginx, Gitlab, Nextcloud, etc and of course Pi-Hole). If you port forward a port in your router, you can access it out of your LAN and use a domain name (DNS to my external IP address), normally you can also use it internally using the same domain name. However, with my T-mobile modem/router, I can't. Therefor I need to use my own DNS server, which resolves my domain-name to my local IP address of the server in order to get it working. Without using my DNS it will resolve to my external IP address, and this can not be handled by my router/modem. Meaning, a continuous integration Docker image from my own Gitlab server, can't find it's own Gitlab server (it will not able to resolve it), and therefor can not |
Add it to your docker-compose list of external networks. |
Is there a proper fix for this yet? |
hi @ramblingenzyme , I recently set up a second pihole on a debian system. For an unknown reason, the ipv4_address setting in the pihole docker-compose was inufficient.
One change, and all dns resolutions in containers are more quicker. |
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days. |
This is an issue with the latest debian dev tag. May also be present in other tags, haven't tested these.
DNS queries initiated by any docker container (including pihole) on the host fail when the hosts /etc/resolv.conf is set to the local server IP (in my case, 10.50.10.3), despite pi-hole logs showing a successful lookup event.
I verified another container can see port 53 on the host IP:
All DNS queries from any other client outside of Docker are successful - pihole is correctly configured, no errors in pihole.log.
I was able to fix this by updating the hosts /etc/resolv.conf to point to the docker interface (instead of the IP of the host, 10.50.10.3):
Setting Google DNS on the hosts /etc/resolv.conf also appears to be a valid workaround.
Below is my Docker container config. Since the DNS server picks up and responds to the DNS query, it seems there's something odd going on with routing that prevents containers from receiving DNS responses back from pihole.
Unsure on if this would be classified as a bug with this container or is expected behavior due to Dockers routing design.
If expected behavior, it may be useful to document this as a note for other users within README.md
The text was updated successfully, but these errors were encountered: