On 24/11/17 19:46, Akram B.A wrote: > Hi Simon > Some answers inline sorry for the netiquette > > Sent from my iPhone > >> On 24 Nov 2017, at 17:56, Simon Kelley <si...@thekelleys.org.uk> wrote: >> >> A couple of possible problems with this are as follows. >> >> 1) It may not be possible to determine that the upstream server is not >> answering in a tinely manner. "Connection refused replies work, but >> don't arrive in many otherwise reasonable network config, and without >> those, you're relying on timeouts. > I think it is ok to fallback on timeouts and consider connection refused or > NXDOMAIN as the primary time of failure.
Certainly NOT on NXDOMAIN. That's a valid answer to the query, and shouldn't be changed. The problem with connection refused is that it's fragile: if the server is down, you won't see it. If the network is down you won't see it. >> >> 2) Once you've determined that the upstream server is not answering, >> there's no guarantee that the record you need will be in the cache, even >> with a stale TTL. Cache entries can easily be evicted even before the >> end of the TTL by newer entries, as the system uses LRU cache >> replacment. I get the feeling that you want some guarantees, and this >> doesn't give that, just a lower probability of failure. >> > You probably mean that cache eviction happens even if a query is not made and > is probably made on a timer basis. If so, such a behavior for sure would > require to handle cache eviction differently and probably at query time or at > a max ttl value, 86400 for example. The cache is of fixed size. When a new name is cached, space is made by evicting an existing cache entry. First, entries that have expired TTLs are evicted. If there are none, then an entry is chosen to evict by finding the entry which was used (or installed) the longest time ago. To make something which could guarantee an answer, rather than improving "best effort" would be a large change from the existing implementation. Simon. > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss