Pi-hole v6 silently ignores the v5 environment variables

FTLCONF_LOCAL_IPV4 does nothing in Pi-hole v6, and the "Primary IP addresses" panel is detection-only. The setting that controls what pi.hole resolves to is dns.reply.host.IPv4.

Pi-hole’s Settings > System page showed “Primary IP addresses” as the pod IP, and I wanted it to show the address of the web service. I already had FTLCONF_LOCAL_IPV4 set, so I went looking for why it had no effect.

It has none because that variable belongs to Pi-hole v5. Version 6 doesn’t know it and doesn’t warn. I confirmed it on v6.7.1 with pihole-FTL --config, which lists the real keys: there is no LOCAL_IPV4, and nothing in the container refers to it. Use that command to check any variable name before trusting it.

The panel can’t be changed

The panel shows what FTL detects on the interface that carries the default route. In Kubernetes that is the pod’s eth0, so it shows the pod IP and changes every time the pod restarts. I treat it as cosmetic.

What does control the answer

What pi.hole and the host’s own name resolve to is a separate setting, dns.reply.host.IPv4. In a container it is set with environment variables:

- name: FTLCONF_dns_reply_host_IPv4
  value: "<web service IP>"
- name: FTLCONF_dns_reply_host_force4
  value: "true"

After the rollout, dig +short pi.hole against the DNS service and against the pod itself both returned that address, while the ingress hostname still resolved to the ingress controller.

One warning from the same session: kubectl exec ... env prints FTLCONF_webserver_api_password in clear text. Filter the output or avoid it.