2017-11-29 19:57:26 -05:00
|
|
|
[[networkaddress-cache-ttl]]
|
|
|
|
|
=== DNS cache settings
|
|
|
|
|
|
|
|
|
|
Elasticsearch runs with a security manager in place. With a security manager in
|
Override the JVM DNS cache policy (#36570)
When a security manager is present, the JVM will cache positive hostname
lookups indefinitely. This can be problematic, especially in the modern
world with cloud services where DNS addresses can change, or
environments using Docker containers where IP addresses could be
considered ephemeral. This behavior impacts cluster discovery,
cross-cluster replication and cross-cluster search, reindex from remote,
snapshot repositories, webhooks in Watcher, external authentication
mechanisms, and the Elastic Stack Monitoring Service. The experience of
watching a DNS lookup change yet not be reflected within Elasticsearch
is a poor experience for users. The reason the JVM has this is guard
against DNS cache posioning attacks. Yet, there is already a defense in
the modern world against such attacks: TLS. With proper certificate
validation, even if a resolver falls prey to a DNS cache poisoning
attack, using TLS would neuter the attack. Therefore we have a policy
with dubious security value that significantly impacts usability. As
such we make the usability/security tradeoff towards usability, since
the security risks are very low. This commit introduces new system
properties that Elasticsearch observes to override the JVM DNS cache
policy.
2018-12-13 10:23:45 -05:00
|
|
|
place, the JVM defaults to caching positive hostname resolutions indefinitely
|
|
|
|
|
and defaults to caching negative hostname resolutions for ten
|
|
|
|
|
seconds. Elasticsearch overrides this behavior with default values to cache
|
|
|
|
|
positive lookups for sixty seconds, and to cache negative lookups for ten
|
|
|
|
|
seconds. These values should be suitable for most environments, including
|
|
|
|
|
environments where DNS resolutions vary with time. If not, you can edit the
|
|
|
|
|
values `es.networkaddress.cache.ttl` and `es.networkaddress.cache.negative.ttl`
|
|
|
|
|
in the <<jvm-options,JVM options>>. Note that the values
|
2020-07-31 16:16:31 -04:00
|
|
|
https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html[`networkaddress.cache.ttl=<timeout>`]
|
Override the JVM DNS cache policy (#36570)
When a security manager is present, the JVM will cache positive hostname
lookups indefinitely. This can be problematic, especially in the modern
world with cloud services where DNS addresses can change, or
environments using Docker containers where IP addresses could be
considered ephemeral. This behavior impacts cluster discovery,
cross-cluster replication and cross-cluster search, reindex from remote,
snapshot repositories, webhooks in Watcher, external authentication
mechanisms, and the Elastic Stack Monitoring Service. The experience of
watching a DNS lookup change yet not be reflected within Elasticsearch
is a poor experience for users. The reason the JVM has this is guard
against DNS cache posioning attacks. Yet, there is already a defense in
the modern world against such attacks: TLS. With proper certificate
validation, even if a resolver falls prey to a DNS cache poisoning
attack, using TLS would neuter the attack. Therefore we have a policy
with dubious security value that significantly impacts usability. As
such we make the usability/security tradeoff towards usability, since
the security risks are very low. This commit introduces new system
properties that Elasticsearch observes to override the JVM DNS cache
policy.
2018-12-13 10:23:45 -05:00
|
|
|
and
|
2020-07-31 16:16:31 -04:00
|
|
|
https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html[`networkaddress.cache.negative.ttl=<timeout>`]
|
Override the JVM DNS cache policy (#36570)
When a security manager is present, the JVM will cache positive hostname
lookups indefinitely. This can be problematic, especially in the modern
world with cloud services where DNS addresses can change, or
environments using Docker containers where IP addresses could be
considered ephemeral. This behavior impacts cluster discovery,
cross-cluster replication and cross-cluster search, reindex from remote,
snapshot repositories, webhooks in Watcher, external authentication
mechanisms, and the Elastic Stack Monitoring Service. The experience of
watching a DNS lookup change yet not be reflected within Elasticsearch
is a poor experience for users. The reason the JVM has this is guard
against DNS cache posioning attacks. Yet, there is already a defense in
the modern world against such attacks: TLS. With proper certificate
validation, even if a resolver falls prey to a DNS cache poisoning
attack, using TLS would neuter the attack. Therefore we have a policy
with dubious security value that significantly impacts usability. As
such we make the usability/security tradeoff towards usability, since
the security risks are very low. This commit introduces new system
properties that Elasticsearch observes to override the JVM DNS cache
policy.
2018-12-13 10:23:45 -05:00
|
|
|
in the
|
2020-07-31 16:16:31 -04:00
|
|
|
https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html[Java
|
Override the JVM DNS cache policy (#36570)
When a security manager is present, the JVM will cache positive hostname
lookups indefinitely. This can be problematic, especially in the modern
world with cloud services where DNS addresses can change, or
environments using Docker containers where IP addresses could be
considered ephemeral. This behavior impacts cluster discovery,
cross-cluster replication and cross-cluster search, reindex from remote,
snapshot repositories, webhooks in Watcher, external authentication
mechanisms, and the Elastic Stack Monitoring Service. The experience of
watching a DNS lookup change yet not be reflected within Elasticsearch
is a poor experience for users. The reason the JVM has this is guard
against DNS cache posioning attacks. Yet, there is already a defense in
the modern world against such attacks: TLS. With proper certificate
validation, even if a resolver falls prey to a DNS cache poisoning
attack, using TLS would neuter the attack. Therefore we have a policy
with dubious security value that significantly impacts usability. As
such we make the usability/security tradeoff towards usability, since
the security risks are very low. This commit introduces new system
properties that Elasticsearch observes to override the JVM DNS cache
policy.
2018-12-13 10:23:45 -05:00
|
|
|
security policy] are ignored by Elasticsearch unless you remove the settings for
|
|
|
|
|
`es.networkaddress.cache.ttl` and `es.networkaddress.cache.negative.ttl`.
|
