Support DNS Caching

[armon]

We have some use cases where people want to hit DNS very hard, and in those cases some caching would be very useful. The 0 TTL default is sane, but does not scale well. Instead, support:

• dns_ttl: Set a TTL for DNS results (default 0, same behavior)
• dns_stale: Enable stale reads, allows for higher throughput / lower latency (default false, same behavior)
• dns_max_stale: Bound the maximum staleness. If the result is too old, retry on leader. (default like 1s).

We can provide these as a map, so that each different values can be provided on a per-service level. There will be some wildcard to set the default values for all services.

[twirrim]

I would discourage you from doing that. If they're going to be hitting DNS hard, they should be considering using something like dnsmasq or similar as a local caching name server (fairly standard practice on things like email servers that do a lot of lookups, and extremely easy to setup and use).

Applications that do their own DNS caching re a common source of unexpected behaviour and operational pain. Whenever someone changes a DNS record, they should have extremely high level of confidence that every application will honour it by the time the record TTL has expired.

[armon]

@twirrim I agree, which is why default the 0 TTL. Mostly, for performance reasons we need to allow stale DNS reads, and to allow setting a TTL. If we set some TTL, then an upstream system, like dnsmasq / bind can do the caching.

[ijin]

@twirrim dnsmasq can not cache a record if the original TTL is 0. As @armon mentioned, having the TTL 0 by default but making it configurable makes sense.

This feature is necessary for my applications which already have a local dnsmasq running to reduce read latency.

[andrewwatson]

So, I wrote up a guide for getting BIND to forward to Consul exactly for this reason. http://www.consul.io/docs/guides/forwarding.html 😄

[ijin]

👍