I'm looking at dashboard reports and noticing that 83,5% of queries are answered by forward, and only 7,7% are answered by cache.
Top permitted and top blocked domains lists show that top ones are very frequently queried, so I'd expect a bigger share of queries being answered by cache.
On /etc/dnsmasq.d/01-pihole.conf I see cache-size=10000.
Might there be some issue?
Nope.
lol tnx, do you have idea of why they aren't being answered by cache?
Because Pi-hole's DNS cache doesn't hold them (anymore).
In DNS, an authoritative DNS server sets the TTL for a given DNS record to tell a client like a recursive or local resolver how long it should cache such a record for.
Pi-hole honors that value.
IPs are held in cache only for the duration of the TTL, and TTLs assigned by authoritative nameservers are rarely more than 300 seconds (and frequently much less, in 10s of seconds).
"Frequent" needs to be evaluated in that context.
In the specific case of blocked domains, these are served locally and the TTL is 2 seconds. Even if these exit the cache, the time to resolve them is still less about a msec or so. Repeated queries for blocked domains will typically not be answered from the cache.
Last week I migrated pihole from my old server to new one. I used Teleporter to migrate most settings, some I had to migrate manually, IP address changed. I also added cloudflared proxy and am using DoH now.
Before the migration, cache was close to 50%.
Are you seeing cache evictions? I'm betting no.
yeah, dig +short chaos txt evictions.bind tells 0.
So, is it all right and just my impression?
Domains served from cache varies on an hourly basis. Comparing prior results to today's results doesn't show anything worthwhile in general.
No cache evictions. Your cache is working as intended. Just let Pi-hole run and don't worry about your cache numbers.
You can use the min-cache-ttl configuration option. I recommend setting it to at least 60 seconds, since that's the DNS cache time in Firefox anyhow, any webmasters setting a lower DNS cache time are fooling themselves. Yes, there are providers that use a lower TTL than 60.
Having pihole do it, and not just relying on Firefox's internal caching, means that if two apps running on my system both query DNS for the same name (this happens quite often, too), they'll only hit the recursive resolver once. To turn this on, add a file into /etc/dnsmasq.d/02-timeout.conf with the content min-cache-ttl=60
" --min-cache-ttl=
Extend short TTL values to the time given when caching them. Note that artificially extending TTL values is in general a bad idea, do not do it unless you have a good reason, and understand what you are doing. Dnsmasq limits the value of this option to one hour, unless recompiled."
This is the part that should be bolded.
Yeah, that's why I was considering odd so few queries being answered by cache. I understand it suggests that most domains are having a short TTL.
That includes no-ip domain, dropbox and torrent domains, which are queried more often. I also have some domains used on monitors.
I'd expect them to make cache usage rate to be bigger. But if everything is fine, I think I don't need to artificially increase TTL just to see cache being more used.
To sum it up.
dig +nocmd +noall +answer duckduckgo.com
These parameters make dig show only the resolved IP and TTL of the queried domain.
If it's queried local or against our DNS server, it shows the remaining TTL. If it's queried against the domain's authoritative nameserver, or against our DNS server while the domain isn't on cache, it shows its TTL.
I tested my top domains, and all of them weren't cached and have very short TTL. Some only 60s.
So, yeah, cache doesn't have much chance to be used.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
