[Dnsmasq-discuss] Ignore TTL if "upstream" DNS server is not available
Simon Kelley
simon at thekelleys.org.uk
Fri Nov 24 16:56:18 GMT 2017
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.
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.
Cheers,
Simon.
On 23/11/17 14:02, Akram Ben Aissi wrote:
> Hi all,
>
> I would be interrested by the following feature:
>
> In case we have a dns forward for a given domain and upstream dns server
> is not available for this domain (connection refused on UDP port 53) , I
> want TTL to be ignored (or countdown restarts to old TTL value or
> to *min-cache-ttl*) and still have the old record to be returned.
>
>
> I am interrested in this feature to be used by our OpenShift
> infrastructure in which we use dnsmasq to forward queries to our
> internal skydns.
>
> In case of skydns not being available, for example, in case of a major
> crash, we still want dnsmasq to return old values, until skydns is back
> again.
>
>
> Any thhougths ?
>
> Akram
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20171124/007e711a/attachment.sig>
More information about the Dnsmasq-discuss
mailing list