Container still has invalid /etc/resolv.conf about docker-pi-hole

[rdwebdesign]

This is a duplicate of #1507

Look at the suggestion in this comment: #1507 (comment)

[github-actions]

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.

[bcjmk]

127.0.0.11 is the internal DNS forwarder for Docker. One resolution for pi_hole is to use an entry of
dns: 127.0.0.1
In the compose file. This mimics the desired behavior to resolve queries with dnsmasq internally and avoids the loopback situation.

[PromoFaux]

This mimics the desired behavior to resolve queries with dnsmasq internally and avoids the loopback situation.

Out of interest, what is the desired behaviour?

[bcjmk]

This mimics the desired behavior to resolve queries with dnsmasq internally and avoids the loopback situation.

Out of interest, what is the desired behaviour?

The pi-hole container needs to use itself (127.0.0.1) as the resolver. Then, inside of pi-hole, there is a separate setting for the upstream resolver. When left to the Docker resolver (127.0.0.11) , the upstream never resolves. Adding in the "dns" entry into docker-compose file allows the gravity updates to work across upgrades of the container.

[PromoFaux]

I guess what I'm trying to understand is what part of the process needs for the container to use itself as the resolver?

As I'm working on clarifying the readme for V6, it helps to have a greater understanding of what/how people are using the image!