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 
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
and
$ 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/1000Okay, 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 (dnscrypt.me) 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
Do you see anything in the following output?
Dec 28 12:36:30 dnsmasq[657]: query[A] dnscrypt.me from 192.168.5.147
Dec 28 12:36:30 dnsmasq[657]: forwarded dnscrypt.me to 127.0.0.1
Dec 28 12:36:30 dnsmasq[657]: dnssec-query[DS] me to 127.0.0.1
Dec 28 12:36:30 dnsmasq[657]: dnssec-query[DNSKEY] . to 127.0.0.1
Dec 28 12:36:30 dnsmasq[657]: reply dnscrypt.me is 104.31.74.114
Dec 28 12:36:30 dnsmasq[657]: reply dnscrypt.me is 104.31.75.114
Dec 28 12:36:30 dnsmasq[1351]: query[A] dnscrypt.me from 192.168.5.147
Dec 28 12:36:30 dnsmasq[1351]: forwarded dnscrypt.me to 127.0.0.1
Dec 28 12:36:30 dnsmasq[1351]: dnssec-query[DS] me to 127.0.0.1
Dec 28 12:36:30 dnsmasq[1351]: dnssec-query[DNSKEY] . to 127.0.0.1
Dec 28 12:36:30 dnsmasq[1351]: reply . is DNSKEY keytag 19036, algo 8
Dec 28 12:36:30 dnsmasq[1351]: reply . is DNSKEY keytag 20326, algo 8
Dec 28 12:36:30 dnsmasq[1351]: reply . is DNSKEY keytag 16749, algo 8
Dec 28 12:36:30 dnsmasq[1351]: reply . is DNSKEY keytag 2134, algo 8
Dec 28 12:36:30 dnsmasq[1351]: reply me is DS keytag 2569, algo 7, digest 1
Dec 28 12:36:30 dnsmasq[1351]: reply me is DS keytag 2569, algo 7, digest 2
Dec 28 12:36:30 dnsmasq[1351]: dnssec-query[DS] dnscrypt.me to 127.0.0.1
Dec 28 12:36:30 dnsmasq[1351]: dnssec-query[DNSKEY] me to 127.0.0.1
Dec 28 12:36:30 dnsmasq[1351]: reply me is DNSKEY keytag 59048, algo 7
Dec 28 12:36:30 dnsmasq[1351]: reply me is DNSKEY keytag 2569, algo 7
Dec 28 12:36:30 dnsmasq[1351]: reply me is DNSKEY keytag 53233, algo 7
Dec 28 12:36:30 dnsmasq[1351]: reply me is DNSKEY keytag 2735, algo 7
Dec 28 12:36:30 dnsmasq[1351]: reply dnscrypt.me is DS keytag 2371, algo 13, digest 2
Dec 28 12:36:30 dnsmasq[1351]: dnssec-query[DNSKEY] dnscrypt.me to 127.0.0.1
Dec 28 12:36:30 dnsmasq[1351]: reply dnscrypt.me is DNSKEY keytag 2371, algo 13
Dec 28 12:36:30 dnsmasq[1351]: reply dnscrypt.me is DNSKEY keytag 34505, algo 13
Dec 28 12:36:30 dnsmasq[1351]: validation result is SECURE
Dec 28 12:36:30 dnsmasq[1351]: reply dnscrypt.me is 104.31.75.114
Dec 28 12:36:30 dnsmasq[1351]: reply dnscrypt.me is 104.31.74.114
With DNSSEC enabled, same issue (no caching) with Quad9 (filtered, DNSSEC) 9.9.9.9 and 149.112.112.112.
But ... Quad9 (filtered, DNSSEC) 2620:fe::fe is ok, Pi-hole cache is working.
Above tested with FTL v4.1.1
There should be a large block of output that details the cache.
Dec 28 16:42:02 dnsmasq[15343]: time 1546015322
Dec 28 16:42:02 dnsmasq[15343]: cache size 10000, 0/230972 cache insertions re-used unexpired cache entries.
Dec 28 16:42:02 dnsmasq[15343]: queries forwarded 67794, queries answered locally 57024
Dec 28 16:42:02 dnsmasq[15343]: queries for authoritative zones 0
Dec 28 16:42:02 dnsmasq[15343]: DNSSEC memory in use 16192, max 23980, allocated 440000
Dec 28 16:42:02 dnsmasq[15343]: server 149.112.112.112#53: queries sent 44183, retried or failed 1033
Dec 28 16:42:02 dnsmasq[15343]: server 9.9.9.9#53: queries sent 31377, retried or failed 960
Dec 28 16:42:02 dnsmasq[15343]: Host Address Flags Expires
Dec 28 16:42:02 dnsmasq[15343]: smarthomeshopper.com :: 6F I H
<snip extensive list of domains in cache>
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.