Nextdns-cli: Ability to change min-cache-ttl to custom values accounted by stub-cache

Donald24
2 yrs ago
15replies
Completed

As I would definetely be able to lower the upstream dns-lookups, I'd like to be able to raise the min-cache-ttl that is accounted by the stub-cache to decide wether or not to make a new to request to upstream-server or serving from cache. I do not want to let the clients decide when TTL is over, as some do not care anyway.

I understand the risks of doing this (and all of the side-effects), and would like this feature to be made able for premium-users to further reduce the monstrous amount of requests that are taking place.

Right now the Nextdns-cli cache obeys every upstream TTL of a min-cache with a manual forced maximum of six minutes. I'd like to to experiment with much more cache-time!

Thanks!

- bombshell
- 2 yrs ago
- Reported - view
can we increase the TTL to more than 6 minutes?
- NextDNs
- 2 yrs ago
- Reported - view
This is already implemented. Settings > Cache Boost.
- bombshell
- 2 yrs ago
- Reported - view
NextDNS The cache Boost does it set the dns cache on client-side? Also what is the interval now? I want to minimize dns request to nextdns ,example for 1 month client should not send request to nextdns?
- NextDNs
  
  2 yrs ago
  
  Reported - view
  ritik it is setting a minimum limit on record TTL to maximize client cache for dynamic records. You can’t set it to high otherwise things will start to break. One month TTL on a dynamic record may lead to unreachable domains and most clients wouldn’t keep a record in their cache for so long anyway.
- yokoffing
  
  1 yr ago
  
  Reported - view
  One month is way too high lol
- Donald24
- 2 yrs ago
- Reported - view
Why not let the user experiment with this? I have another DNS-server sitting behind the nextdns-cli, that is doing manually caching of 3600s of age and there is nothing breaking whatsoever. One month though seems to be foolish....

What I understand that it should be only available to paying customers....
- yokoffing
  
  1 yr ago
  
  Reported - view
  I would like the option of setting for an hour as well!
- rktChip
- 10 mths ago
- Reported - view
Seems like setting min TTL between 5-60 minutes is reasonable. Can we edit the CLI source ourselves if nextdns does not want to provide this flexibility for customers?
- R_P_M
  
  10 mths ago
  
  Reported - view
  You are free to build your own custom version for personal use, it’s on GitHub after all.
- rktChip
  
  10 mths ago
  
  Reported - view
  understood.
  
  With everything *else* being so easy with Nextdns, I'm just surprised id have to build my own custom version to do something as basic as extend the cache time beyond 5 minutes.
  
  For the sake of my sanity and free time, does anyone know if this has already been accomplished and a fork exist?
- R_P_M
  
  10 mths ago
  
  Reported - view
  Having not looked into this problem at all I can’t give you anything specific. Maybe check the issues on GitHub, closed ones as well, see if someone else has posted something on this.
  
  Just checking, I assume you tried setting the min ttl with the CLI to something higher than 5mins?
- NextDNs
- 10 mths ago
- Reported - view
As said above, setting a min TTL over 5 minutes can break services relying on DNS for load balancing, auto scaling or failover. We won’t expose features that could break user’s experience.
- BigDargon
  
  10 mths ago
  
  Reported - view
  Thank you! In the past, I used Unbound as a recursive resolver. And 5 minutes for TTL is reasonable!
- Pro Subscriber
  
  Jorgen_A
  
  9 mths ago
  
  Reported - view
  Do you make some exceptions (like known CDN's or failover clusters etc.) with known low TTL's of 1-60 seconds or do you set a 5 min TTL for ALL returned queries?
- NextDNs
  
  9 mths ago
  
  Reported - view
  there is no exception. Anything that would require such manual exceptions wouldn't be reliable. Most CDN will return several IPs on different stacks to limit occurrences of all return IPs to go away at the same time in case of scale down or red/black deployments. That's why 5 min is reasonable and unlikely to lead to unreachability, going above will substantially increase such risk.