I recently found a way to recompile dnsmasq with the purpose of raising the cache limit but i was also wanting to raise the limit for min-cache-ttl and i can't seem to find the value like the cache limit was defined.
Does anyone know where this might be?
I did find this set of code.
int ttl;
if (!atoi_check(arg, &ttl))
ret_err(gen_err);
else if (option == LOPT_NEGTTL)
daemon->neg_ttl = (unsigned long)ttl;
else if (option == LOPT_MAXTTL)
daemon->max_ttl = (unsigned long)ttl;
else if (option == LOPT_MINCTTL)
{
if (ttl > TTL_FLOOR_LIMIT)
ttl = TTL_FLOOR_LIMIT;
daemon->min_cache_ttl = (unsigned long)ttl;
}
else if (option == LOPT_MAXCTTL)
daemon->max_cache_ttl = (unsigned long)ttl;
else if (option == LOPT_AUTHTTL)
daemon->auth_ttl = (unsigned long)ttl;
else if (option == LOPT_DHCPTTL)
{
daemon->dhcp_ttl = (unsigned long)ttl;
daemon->use_dhcp_ttl = 1;
}
else
daemon->local_ttl = (unsigned long)ttl;
break;
}
Sorry I neglected to mention that portion. Yes, FTLDNS does everything dnsmasq does, plus our special Pi-hole stuff. All the config flags that work with dnsmasq will continue to function.
Thanks guys i will give this a shot, any chance on removing the min-cache-ttl limit in the future?
Reason why I ask is i have some IOT devices that query cloud dns entries like 3x a second and even though i have a gbit connection it seems to slow things down.
So i am looking to implement over 3600 value for min-cache-ttl to get my cache hits way more up, really just playing around with it but so far 3600 has had zero ill effects and has been great for cache stats.
Just trying to get my cache hits up and keep forwarding requests down.
These services that are doing this don't need to ask that often anyways they aren't critical services.
It would only enhance the performance of pihole and it would allow people to walk that fine line between performance optimization and service usage which we all know is different for everyone's needs.
I think a forced minimum TTL of one hour is more dangerous than advantageous. Overriding the TTL with 3600 for all domains will already limit the forwarding to happen at most 24 times a day...
But maybe I'm missing something here - what do you think @DanSchaper?
TTL of 3600 is way too high for most of our users. It would cause issues with people temporarily disabling the Pi-hole and not clearing client cache, they would have to wait an hour to get a new query response. Really anything greater than 600 is kind of big.
I would use 3600 for TTL on a DNS record at the actual DNS server, but for cache that's just not something I think is feasible for the general usage.
I'm good with allowing user override for min-ttl. I think it's set currently as a drop in from the config file template, but I don't see why that shouldn't be editable by the user. Might remove that from the config file we use, and allow users to override with custom config. DL, do you know what the compiled default is for TTL if it's unset in the configuration?
The default is to use the TTL the upstream provider told us. For local ones, I cite the dnsmasqman page:
When replying with information from /etc/hosts or configuration or the DHCP leases file dnsmasq by default sets the time-to-live field to zero, meaning that the requester should not itself cache the information. This is the correct thing to do in almost all situations.
Just wanted to stop by and provide an update, been running with 3600 value for neg-ttl, local-ttl, min-cache-ttl, and auth-ttl. I even had to add a domain to the whitelist yesterday and it did take an hour to update but i could have easily just restarted dnsmasq and flushed my local cache if i really wanted it right away.
I feel like this is a pretty good setup once you have all of your blocklists, whitelists, and blacklists setup and haven't touched them in a while.
I would be willing to bet that i could even push this to 4 hours and maybe even 24 hours without any real negative effect and with much better performance and cache hit stats.
BTW my cache hit % is around 80 right now with following domains (these stats from the last 24 hours)
This is precisely what I meant, if this would be allowed, then less tech-savvy users might stumble over this discussion and change their settings as they think it would maybe increase performance bit it will only cause trouble for them.
I'd bet against it. The advantage would be minimal/negligible. Instead of forwarding 24 times a day wyou would reduce that to 6 times a day. So 18 queries less in your 24hrs query log. Would you really see this?....
Understand you not wanting to create issues, I am good with 3600, what about the possibility of allowing cname results to be cached, would this be a possibility?
I have noticed sometimes the cname results are cached and sometimes they do not follow cache rules.
We do include dnsmasq in our code but we keep any changes to an absolute minimum to be able to easily absorb future security and feature updates of dnsmasq. If we would start to change the resolver code ourselves, then every migration to a higher version of dnsmasq would be an awful amount of work in resolving merging conflicts and ensuring that our modifications still all work with the upgraded version of dnsmasq.