You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mar 4 11:57:08 dnsmasq[52]: query[HTTPS] pi.hole from 10.88.0.1
Mar 4 11:57:08 dnsmasq[52]: forwarded pi.hole to 172.17.17.1#5353
Mar 4 11:57:08 dnsmasq[52]: reply pi.hole is NXDOMAIN
Mar 4 11:57:13 dnsmasq[52]: query[A] pi.hole from 10.88.0.1
Mar 4 11:57:13 dnsmasq[52]: Pi-hole hostname pi.hole is 172.17.17.4
The Debug Token was created for a dig HTTPS pi.hole pi-hole.IP, followed by dig A pi.hole pi-hole.IP.
I'm not sure if I understand your setup. The dnsmasq log looks fine. Pi-hole received a HTTPS type query for domain pi.hole. It does not know the answer, so it forwards it to its upstream, which replies with NXDOMAIN and Pi-hole passes this to its client.
Then an A queries follows, which Pi-hole answers. (Pi-hole only knows pi.hole for A and AAAA queries)
If your bind9 caches the NXDOMAIN for all query types, you should check its confguration.
Right, the setup is lancache-dns/bind9 forwarding to pi-hole.
From my understanding, pi-hole should return NODATA (NOERROR, with empty answer section) instead of forwarding domains it is an authority of (in this case „pi.hole“).
Should pi.hole be forwarded to DNS resolvers?
You are right, we are missing the declaration of zone pi.hole being purely-local (hence, us authoritative) for. I'm just wondering if we should hard-code pi.hole here or whether it needs to be configurable. We'd have webserver.domain (defaulting to pi.hole) but defining this domain as "purely local" may have adverse effects. I will open a PR to make us authoritative for pi.hole (hard-coded).
Versions
Platform
Expected behavior
Downstream Bind9 servers shouldn't irrevocably fail on "dig HTTPS pi.hole".
Actual behavior / bug
When pi.hole forwards the HTTPS pi.hole to the upstream resolver, and receives a NXDOMAIN, downstream Bind9 won't recover, and always return NXDOMAIN.
Steps to reproduce
Named configuration: https://github.com/lancachenet/lancache-dns/blob/55bc29e286ddaa9ea65f27eef9dae0c023685517/overlay/etc/bind/named.conf.options
dig A pi.hole lancache-dns.IP
--> NOERRORdig HTTPS pi.hole lancache-dns.IP
-> NXDOMAIN, because this is forwarded to DNS Forwarders in PiHoledig A pi.hole lancache-DNS.ip
-> NXDOMAINDebug Token
Relevant log entry:
The Debug Token was created for a
dig HTTPS pi.hole pi-hole.IP
, followed bydig A pi.hole pi-hole.IP
.Additional Context
Further
dig
logs at lancachenet/lancache-dns#147The text was updated successfully, but these errors were encountered: