I implemented Coudflared DoH yesterday and since then my cache has shrunk to zero. Anyone know why this might be, or is it expected behaviour.
1 Like
There have been some recent threads on this topic, related to DNSSEC and its implementation in the version of dnsmasq currently used by pihole-FTL (2.79 with bug fixes).
Do you have DNSSEC enabled in Pi-Hole?
No (deliberately), DNSSEC is not enabled as that is doing something quite different to DoH. I read those threads and they did not seems to apply because of that. I'm simply doing my DNS queries via a proxy which then does the lookup via DNS-over-HTTP. Could it be how the cloudflared service is returning the result?
If you switch your upstream DNS to one of the third party servers, does your cache re-populate?
Left it running for 24 hrs back on the old servers and yes, the cache started to populate, though not as quickly as I'd expect. What time period is the dashboard 'Queries answered by' wheel chart?
Could it be something to do with UFW? I have all ports for local subnet open so it shouldn't be. I'll leave it to run for a while as it is and see if previous behaviour is replicated.
Couple of related questions:
- I am not seeing any entries when I tail the FTL log (in the web interface) - is that normal?
- How often should I see a cached entry in the main log? It seems to repeatedly do a DNS lookup for the same domain which strikes me as odd. I though the point is to do the lookup once until the TTL expires.
- How could I tail the logs from the command line so I can filter through grep - not sure of the log locations.
- should
dig 127.0.0.1 -p 53 bbc.co.ukwork? It times out.
[edit] I switched back to normal DNS servers and the cache started to populate (insertion numbers) and the dig command above started working. Definitely something not right just no idea what 
A few quick answers, as I'm on mobile:
From memory, without referring to the code, 24 hours.
This can be normal. There are not many items written to the FTL log, unless you have REGEX_DEBUGMODE=true.
Logs are in directory /var/log, as files pihole.log and pihole-FTL.log. You can tail and grep the logs with a command of this form:
tail -f /var/log/pihole.log | grep {expression}
or, if you don't need the live tail and want to search the entire log,
sudo grep {expression} /var/log/pihole.log
1 Like
Ok so I have solved it - I was being a little too clever.
I had put the IP address into the custom resolver as the local IP rather than 127.0.0.1. When I use the localhost IP (as per instructions) it works. I think the reason is the way cloudflared is set up to listen to port 5053:
@DietPi-PiHole:~# netstat -lnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5053 0.0.0.0:* LISTEN 1982/cloudflared
tcp 0 0 127.0.0.1:4711 0.0.0.0:* LISTEN 49613/pihole-FTL
tcp 0 0 127.0.0.1:38319 0.0.0.0:* LISTEN 1982/cloudflared
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 812/lighttpd
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 49613/pihole-FTL
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 558/dropbear
tcp6 0 0 ::1:4711 :::* LISTEN 49613/pihole-FTL
tcp6 0 0 :::80 :::* LISTEN 812/lighttpd
tcp6 0 0 :::53 :::* LISTEN 49613/pihole-FTL
tcp6 0 0 :::22 :::* LISTEN 558/dropbear
udp 0 0 127.0.0.1:5053 0.0.0.0:* 1982/cloudflared
udp 0 0 0.0.0.0:53 0.0.0.0:* 49613/pihole-FTL
udp 0 0 0.0.0.0:59549 0.0.0.0:* 1139/avahi-daemon:
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1139/avahi-daemon:
udp6 0 0 :::44505 :::* 1139/avahi-daemon:
udp6 0 0 :::53 :::* 49613/pihole-FTL
udp6 0 0 :::5353 :::* 1139/avahi-daemon:
I do not know enough about this (I will investigate further), but it does now work.