Last updated: 2026-05-31
| LXC | 102 on proxmox2 |
| IP | 10.0.2.15 |
| URL | pihole.pittsfamily.me |
| Credentials | Vaultwarden → Pi-hole — Account — Admin |
| Version | Pi-hole v6 (pihole-FTL) |
| Upstream DNS | 8.8.8.8, 1.1.1.1 |
Pi-hole serves as the authoritative local DNS resolver for all of Pitts LAN. Every device on the network is configured to use it via DHCP, and the UDM's own WAN resolver also points to Pi-hole.
Device → 10.0.2.15:53 (Pi-hole)
├─ pittsfamily.me zone → LOCAL (returns NPM or direct IP)
└─ everything else → upstream (8.8.8.8 / 1.1.1.1)
UDM gateway (10.0.2.1:53) also forwards to Pi-hole (WAN DNS = 10.0.2.15)
DHCP DNS on all VLANs (set in UniFi):
| Network | DNS 1 | DNS 2 |
|---|---|---|
| Pitts LAN | 10.0.2.15 | 10.0.2.15 |
| Pitts Guest | 10.0.2.15 | 10.0.2.15 |
| Kellerman Cameras | 10.0.2.15 | 10.0.2.15 |
| Pitts IoT | 10.0.2.15 | 10.0.2.15 |
Pi-hole is configured to be authoritative for the pittsfamily.me zone. All *.pittsfamily.me subdomains return local IPs (NPM at 10.0.2.14 or a direct backend), not Cloudflare's proxy IPs.
All pittsfamily.me subdomains → 10.0.2.14 (NPM), except:
mnemosyne.pittsfamily.me → 10.0.2.22 (direct)All pittsfamily.me subdomains → fd33:b1c2:abf6:4157:be24:11ff:fe11:e37a (NPM's LAN IPv6)
NPM's IPv6 is a SLAAC address derived from its MAC (BC:24:11:11:E3:7A). It is stable unless the NIC changes. The Mac and other devices share the same fd33:b1c2:abf6:4157::/64 subnet (provided by the Proxmox bridge RA).
# in pihole.toml → misc.dnsmasq_lines
"local=/pittsfamily.me/"
This makes Pi-hole authoritative for pittsfamily.me. Without this, browsers break.
Modern browsers (Chrome, Safari, Firefox) query the HTTPS record type (RFC 9460 / SVCB) before issuing A or AAAA queries. Cloudflare's DNS returns an HTTPS record for all orange-clouded domains that embeds Cloudflare proxy IPs as ipv4hint/ipv6hint. Browsers use those IP hints directly, bypassing the A and AAAA overrides entirely.
With local=/pittsfamily.me/, Pi-hole answers HTTPS queries from its local records instead of forwarding to Cloudflare. Since there are no local HTTPS records, browsers get NODATA and fall back to A/AAAA — which point to NPM locally.
Symptom of a missing local= directive: On-network clients resolve to Cloudflare IPs even though Pi-hole A records are correct.
All settings live in /etc/pihole/pihole.toml on the Pi-hole LXC. The key sections:
# DNS hosts (A + AAAA records for pittsfamily.me)
dns.hosts = [
"10.0.2.14 homeassistant.pittsfamily.me",
"fd33:b1c2:abf6:4157:be24:11ff:fe11:e37a homeassistant.pittsfamily.me",
# ... all other subdomains ...
]
# dnsmasq directives injected into FTL
misc.dnsmasq_lines = [
"local=/pittsfamily.me/", # zone authority — blocks HTTPS forwarding
"address=/homeassistant.pittsfamily.me/10.0.2.14",
# ... address= entries for all subdomains ...
]
The address= entries in dnsmasq_lines are a belt-and-suspenders backup for the pihole.toml dns.hosts entries.
Check if Pi-hole is serving correct local DNS:
# Should return 10.0.2.14 (not a Cloudflare IP)
dig A homeassistant.pittsfamily.me @10.0.2.15
# Should return NPM's IPv6 (fd33:...), not Cloudflare IPv6
dig AAAA homeassistant.pittsfamily.me @10.0.2.15
# Should return NODATA (not Cloudflare SVCB record)
dig HTTPS homeassistant.pittsfamily.me @10.0.2.15
Add a new pittsfamily.me subdomain:
# SSH to proxmox2, then:
pct exec 102 -- pihole-FTL --config dns.hosts "[..existing entries.., "10.0.2.14 new-service.pittsfamily.me", "fd33:b1c2:abf6:4157:be24:11ff:fe11:e37a new-service.pittsfamily.me"]"
pct exec 102 -- systemctl restart pihole-FTL
Also add address=/new-service.pittsfamily.me/10.0.2.14 to misc.dnsmasq_lines.
Check Pi-hole query log:
ssh proxmox2 'pct exec 102 -- tail -30 /var/log/pihole/pihole.log'
If clients are bypassing Pi-hole (going to Cloudflare):
Possible causes: