Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bind9 not recovering after receiving NXDOMAIN for HTTPS pi.hole #2330

Open
AliveDevil opened this issue Mar 4, 2025 · 3 comments
Open

Bind9 not recovering after receiving NXDOMAIN for HTTPS pi.hole #2330

AliveDevil opened this issue Mar 4, 2025 · 3 comments

Comments

@AliveDevil
Copy link

AliveDevil commented Mar 4, 2025

Versions

  • Core version is v6.0.4 (Latest: N/A)
  • Web version is v6.0.1 (Latest: v6.0.1)
  • FTL version is v6.0.3 (Latest: v6.0.3)

Platform

  • Platform: Docker

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

  1. Setup lancache-dns Docker container (with UPSTREAM_DNS set to IP of pi.hole-container) - this requires static IPs for containers
    Named configuration: https://github.com/lancachenet/lancache-dns/blob/55bc29e286ddaa9ea65f27eef9dae0c023685517/overlay/etc/bind/named.conf.options
  2. Start both, lancache-dns and pihole
  3. dig A pi.hole lancache-dns.IP --> NOERROR
  4. dig HTTPS pi.hole lancache-dns.IP -> NXDOMAIN, because this is forwarded to DNS Forwarders in PiHole
  5. dig A pi.hole lancache-DNS.ip -> NXDOMAIN

Debug Token

Relevant log entry:

   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.

Additional Context

Further dig logs at lancachenet/lancache-dns#147

@yubiuser
Copy link
Member

yubiuser commented Mar 4, 2025

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.

@AliveDevil
Copy link
Author

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?

@yubiuser yubiuser transferred this issue from pi-hole/pi-hole Mar 4, 2025
@DL6ER
Copy link
Member

DL6ER commented Mar 4, 2025

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants