Cache issue with v4.1.2?

I'm on

Pi-hole Version v4.1.1 Web Interface Version v4.1.1 FTL Version v4.1.2

Is there a known cache issue?

The command

dig +short chaos txt insertions.bind

returns 0 even after hours. Even 'DNS cache insertions' in the Web UI keeps on 0 (clearing browser cache doesn't help) and also the graph on the Dashboard is abnormal regarding "Queries answered by Cache".

A restart of the Pi doesn't change anything.

I'm not sure, but there was no problem with v4.1.1.

What is the output of: echo ">cacheinfo" | nc 4711

Fresh restart of FTL and I'm showing immediate cache activity.

dschaper@nanopim1plus:~$ dig +short chaos txt insertions.bind @
dschaper@nanopim1plus:~$ dig +short chaos txt version.bind @
dschaper@nanopim1plus:~$ pihole-FTL --version

Output is

$ echo ">cacheinfo" | nc 4711
cache-size: 10000
cache-live-freed: 0
cache-inserted: 0

It seems the issue appeared in the past 24 hours (noticed it last night).

The Query Log only shows "OK (forwarded)", but no "OK (cached)" anymore.

Don't know what is happening here, but I don't have a cache anymore :thinking:

What does free -h show for available memory, and df -h for available disk space?

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           976M        141M        703M         14M        131M        775M
Swap:           99M          0B         99M


$ df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  1.6G   13G  12% /
devtmpfs        484M     0  484M   0% /dev
tmpfs           489M     0  489M   0% /dev/shm
tmpfs           489M  6.5M  482M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           489M     0  489M   0% /sys/fs/cgroup
/dev/mmcblk0p1   42M   23M   20M  54% /boot
tmpfs            98M     0   98M   0% /run/user/999
tmpfs            98M     0   98M   0% /run/user/1000

Okay, a debug token would help as well.

Debug token: sufehc2m6j

Ah, here is a hint: after disabling "Use DNSSEC" on DNS tab the cache is working again.

But that option was enabled for month, without problems so far.

pihole-FTL is still based on the 2.79 version of dnsmasq. There are issues with the DNSSEC implementation that are expected to be resolved when the FTL moves to the 2.8 branch of dnsmasq. We anticipate that happening with Pi-hole version 4.2. Until then there is the chance of unexpected results from implementing DNSSEC.

You may be able to gather some more information on why DNSSEC is causing complications by dumping the cache while tailing the log.

In one screen/terminal, sudo tail -f /var/log/pihole.log and in a second terminal trigger the dump with sudo pkill -USR1 pihole-FTL.

Ok, but strange that there are suddenly problems after month with that option enabled and several hundreds of thousands successful cached queries (with "OK (cached)" in the Query Log). All is working fine and as expected, then at one morning the cache isn't working anymore.

When did you upgrade to V4.1.1 / V4.1.1.2? That's when some bug fix changes were made to the embedded dnsmasq 2.79.

Can you try setting your upstream to Quad 9 (filtered, DNSSEC) and enable DNSSEC to check that configuration. I'm able to get cache population with that configuration, and with DNSSEC disabled. I am seeing an upstream issue that causes no response what so ever if DNSSEC is enabled with an upstream that doesn't reply correctly.

The oldest entry with "4.1.2" I can find in one of the pihole-FTL.log-files is

[2018-12-22 14:00:25.238] FTL version: v4.1.2

It seems it has to do with my DNS server, even if I didn't change any configuration on the server.
I'm using my own DNS server ( in Pi-hole, so far with enabled DNSSEC option in the Pi-hole webinterface. But for whatever reason, I have to disable that option now to have a cache again.

Do the corresponding queries show up as INSECURE in your dashboard when you enable DNSSEC in the Pi-hole settings?

No, only "OK (forwarded)" - no "SECURE", "INSECURE", "BOGUS".

I'll let it disabled for now, until pihole-FTL is based on dnsmasq 2.8x (released October 2018).

The development branch is using dnsmasq 2.80 if you would like to try that out.

1 Like