Resolves of the FQDN instead of the external IP


DoT/DoH (nginx reverse proxy) ==>> pihole ==>> upstream dnscrypt-proxy
All on remote server. Standart pihole installation on Ubuntu server. systemd-resolved, dhcpcd disabled.
Can not connect to main web site (nginx), because dnsmasq even not forwarding DNS queyry to pihole. But subdomains resolving fine. And all other things works perfectly.
This is from /var/log/pihole.log:

Sep 26 11:31:41 dnsmasq[1567483]: query[A] DOMAIN from
Sep 26 11:31:41 dnsmasq[1567483]: internal DOMAIN is

dig @ DOMAIN +short

Must be server external IP.

Debug Token:

I had a similar problem with my reverse proxy while testing the beta version. See my comments on the commit at: Merge pull request #1111 from pi-hole/new/reply_pihole_hostname. You might check into using REPLY_ADDR4 and/or REPLY_ADDR6 from FTLDNS -> Configuration.

1 Like

Yes, using REPLY_ADDR{4,6} is the way to go for this configuration. I'm still open for ideas. This is an edge case in which Pi-hole cannot reliably determine this IP it should reply with.

To be honest, it feels like a bug in DoT/DoH. Because the proxy asks the Pi-hole for pi.hole, this Pi-hole replies with: "Hey, you are on the same machine, so it is and - instead of detecting that this makes no sense - the proxy happily forwards this answer to some distant machine (where doesn't make much sense any more). To me, the proxy seems in charge for rewriting the reply because it is the only involved party that knows who the client really is.

It`s worked! Thank you.

Additional info:
Earlier was not this problem, I do not understand what changed.
My blocking mode is unspecified IP blocking (default), BLOCKINGMODE=NULL.

Pi-hole documentation REPLY_ADDR4:

When using IP blocking mode

So REPLY_ADDR also actual with blocking mode NULL and this means documentation misleads.

On pihole server, bypassing nginx proxy:

dig @ DOMAIN +short
The same result
nslookjup DOMAIN
After adding REPLY_ADDR4=server_IP problem solved. dig, nslookup resolves server IP.
So it is not proxy fault.

I mostly agree though proxies are often pretty 'dumb' and just pass things through. I'm using a Python project: doh-proxy 0.0.9 which might be updated to do such a thing but the developer has ceased work. I have been using my own fork anyway, so I'm going to look at the code to see if could determine where such a thing might be added.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.