`refreshNames` does not work with `listen-address`

[n12c]

This is a: Bug

Details

I changed the dnsmasq listen port to 2053 using pihole.toml, then also changed the listen address to 127.0.0.53 using etc_dnsmasq_d = true and listen-address=127.0.0.53 and bind-interfaces. pihole-FTL now listens for DNS queries on 127.0.0.53:2053/udp and 127.0.0.53:2053/tcp as I intend.

Due to what I assume is the functioning of refreshNames I now see:

2026-02-19 17:52:30.626 UTC [68/T71] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2026-02-19 17:52:30.626 UTC [68/T71] INFO: Tried to resolve PTR "1.0.0.127.in-addr.arpa" on 127.0.0.1#2053 (UDP)
2026-02-19 17:52:32.642 UTC [68/T71] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2026-02-19 17:52:32.642 UTC [68/T71] INFO: Tried to resolve PTR "1.0.0.127.in-addr.arpa" on 127.0.0.1#2053 (UDP)
2026-02-19 17:52:34.658 UTC [68/T71] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2026-02-19 17:52:34.658 UTC [68/T71] INFO: Tried to resolve PTR "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" on 127.0.0.1#2053 (UDP)

in the container logs. Note that 127.0.0.1:2053 is being queried, and there is no resolver listening on that IP and port.

Related Issues

• I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

1. Environment data

• Operating System: Docker
• Hardware: N100
• Kernel Architecture: amd64
• Docker Install Info and version:
  • Software source: Debian
  • Supplimentary Software: N/A
• Hardware architecture: amd64

2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here
3. any additional info to help reproduce

These common fixes didn't work for my issue

• I have tried removing/destroying my container, and re-creating a new container
• I have tried fresh volume data by backing up and moving/removing the old volume data
• I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
• I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
• I have tried running without my volume data mounts to eliminate volumes as the cause

If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.

[rdwebdesign]

I changed the dnsmasq listen port to 2053 using pihole.toml, then also changed the listen address to 127.0.0.53 using etc_dnsmasq_d = true and listen-address=127.0.0.53 and bind-interfaces. pihole-FTL now listens for DNS queries on 127.0.0.53:2053/udp and 127.0.0.53:2053/tcp as I intend.

This is not the correct way to use Pi-hole container.

You should not change the DNS to something different than 53.
If you change Pi-hole port to 2053, no clients will sent queries to this port. Also, inside a container the IP 127.0.0.53 points to the container itself.

If you are running Pi-hole in a container, please post the compose file (or docker run command) used to start the container.

Also, please post a debug token:

• run docker exec -it <Pi-hole container name> pihole -d command.
• when asked to upload the log, answer Y.
• copy only the token and paste here.

[n12c]

You should not change the DNS to something different than 53.

Then why does the port = setting exist :p

If you change Pi-hole port to 2053, no clients will sent queries to this port.

Sure. Unless there is something else listening on 53 and proxying traffic to Pi-hole.

Also, inside a container the IP 127.0.0.53 points to the container itself.

Unless --network host is used.

The docker run command was:

docker run -d --restart=always --name=pihole6 --network host \
  -v /var/lib/pihole6/etc/pihole:/etc/pihole \
  -v /var/lib/pihole6/etc/dnsmasq.d:/etc/dnsmasq.d \
  -e FTLCONF_webserver_api_password= \
  -e 'FTLCONF_dns_upstreams=::1#1053;127.0.0.1#1053' \
  pihole/pihole:latest

I'll skip the debug logs as this is not actually causing any breakage for me, everything is working great. Just a little noise in the logs.

My motivation for filing this is that it seemed to me that, if the intention was for refreshNames to query Pi-hole itself, then more work needs to be put into "self-discovery" -- the port setting in pihole.toml is discovered and respected but there is an assumption that Pi-hole listens on 127.0.0.1 which is fairly safe but not 100% guaranteed.

If the intention was for refreshNames to avoid Pi-hole and just query the system resolver provided by Docker (go through libc/resolv.conf in the container), then the port should be ignored too.

[rdwebdesign]

Unless there is something else listening on 53 and proxying traffic to Pi-hole.

If there is something else listening to port 53, you need to disable it.

DNS protocol always use port 53.

If you change this port, the container will start, but your clients will still send DNS queries to port 53 and Pi-hole will never receive queries.

You need to disable the service currently using port 53. Pi-hole will replace it and work as your DNS server.

---

Unless --network host is used.

You didn't post the docker command on the original post, so I imagined you were using the default bridge network.
With host network your FTLCONF_dns_upstreams are correct, but you usually don't need to change listen-address to 127.0.0.53.

Please address the first issue (disabling the service using port 53) and try again without making changes to listen-address.

[n12c]

I have nginx sitting in front of Pi-hole:

stream {
  upstream pihole {
    server 127.0.0.53:2053;
  }

  server {
    listen [::]:853 ssl reuseport ipv6only=off;
    listen [::]:53 udp reuseport ipv6only=off;
    listen [::]:53 reuseport ipv6only=off;
    proxy_pass pihole;
  }
}

Unconventional maybe, but it works for me. In any case, I'm understanding this configuration to be out of scope, which is fair enough. Feel free to close.

[darkexplosiveqwx]

Since you are already using a non-standard port, what is stopping you from simply binding to 127.0.0.1:2053 then?

[n12c]

Nothing, that would indeed work. But that is orthogonal to the question of whether it is correct for Pi-hole to be hard-coded to expect itself to be listening on 127.0.0.1. This is just a corner case I discovered while being more "creative" than necessary.

[yubiuser]

Pinging @DL6ER

[rdwebdesign]

I'll skip the debug logs as this is not actually causing any breakage for me, everything is working great. Just a little noise in the logs.

Without a log, we need to ask many many questions to find out exactly what settings were selected and how Pi-hole is working. We help users on our free time and a debug log will help us to help you.

Please, generate the log and upload here only the token.

[n12c]

Further to @darkexplosiveqwx's suggestion I changed the listen address from 127.0.0.53 to 127.0.0.1 which resolves the spurious errors in the container logs.

Please, generate the log and upload here only the token.

Sorry I'm not comfortable with this, there is too much internal info in the debug output. I understand if this is not acceptable; I feel no entitlement. If my report is too unintelligible to action without the debug output, or if the issue reported is actually the designed behaviour, or if the issue is real but too trivial to be worth fixing, please close with my blessing and my apologies.