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 127.0.0.1
Sep 26 11:31:41 dnsmasq[1567483]: internal DOMAIN is 127.0.0.1
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 127.0.0.1 and - instead of detecting that this makes no sense - the proxy happily forwards this answer to some distant machine (where 127.0.0.1 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.
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.
dig @127.0.0.1 DOMAIN +short
returns 127.0.0.1.
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.