From 893349a6159f9dbe6dc0fd372dfe7bcf35f71d3e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 24 Sep 2025 11:09:23 +0200 Subject: [PATCH 1/4] dns cache settings page moved to ES configuration section --- .../important-settings-configuration.md | 1 + .../important-system-configuration.md | 1 - .../security/unused-texts-eedugon.md | 88 +++++++++++++++++++ deploy-manage/toc.yml | 2 +- 4 files changed, 90 insertions(+), 2 deletions(-) create mode 100644 deploy-manage/security/unused-texts-eedugon.md diff --git a/deploy-manage/deploy/self-managed/important-settings-configuration.md b/deploy-manage/deploy/self-managed/important-settings-configuration.md index 00e5f12744..83f6f4e596 100644 --- a/deploy-manage/deploy/self-managed/important-settings-configuration.md +++ b/deploy-manage/deploy/self-managed/important-settings-configuration.md @@ -23,6 +23,7 @@ products: * [Temporary directory settings](#es-tmpdir) * [JVM fatal error log setting](elasticsearch://reference/elasticsearch/jvm-settings.md#error-file-path) * [Cluster backups](#important-settings-backups) +* [](networkaddress-cache-ttl.md) ## Path settings [path-settings] diff --git a/deploy-manage/deploy/self-managed/important-system-configuration.md b/deploy-manage/deploy/self-managed/important-system-configuration.md index 8be74ed3fe..10328cd381 100644 --- a/deploy-manage/deploy/self-managed/important-system-configuration.md +++ b/deploy-manage/deploy/self-managed/important-system-configuration.md @@ -18,7 +18,6 @@ The following settings **must** be considered before going to production: * [](setup-configuration-memory.md) * [](vm-max-map-count.md) * [](max-number-of-threads.md) -* [](networkaddress-cache-ttl.md) * [](file-descriptors.md) (Linux and MacOS only) * [](executable-jna-tmpdir.md) (Linux only) * [](system-config-tcpretries.md) (Linux only) diff --git a/deploy-manage/security/unused-texts-eedugon.md b/deploy-manage/security/unused-texts-eedugon.md new file mode 100644 index 0000000000..f0c6256df3 --- /dev/null +++ b/deploy-manage/security/unused-texts-eedugon.md @@ -0,0 +1,88 @@ +Connection modes determine how a local {{es}} cluster establishes network access to a remote cluster. + + +% need to think and decide the next paragraphs of the intro. + +% is this too obvious? +If the destination cluster of a remote cluster connection doesn't have network security enabled, all traffic is allowed, hence there's no need to create this type of filter in such case. + +% is this too obvious? +If you apply this type of filter to a deployment that didn't have network security enabled, all other traffic will be denied if you don't have other Network Security policies or filters applied to the deployment. + +% This maybe to Remote clusters doc and not here we have already mentioned that this only applies to API key based. +::::{note} +When remote clusters are configured using the deprecated TLS certificate based authentication method, there's no need to create this type of filter to allow the connection, as the connection will already be accepted regardless of the destination cluster to have Network Security enabled. +:::: + +In remote filter creation doc + + % Not sure if we want any of this + ::::{important} + Network security filtering for remote cluster traffic from ECE to ECH is not supported. These filters apply only to {{ecloud}} resources, so the values must be {{ecloud}} IDs. + + If you require network security policies in the remote deployment for remote cluster connections coming from ECE, consider configuring the remote clusters with the deprecated [TLS certificate–based authentication model](/deploy-manage/remote-clusters/ece-remote-cluster-ece-ess.md). Traffic with this model is authenticated through mTLS and is not subject to network security filters. + + Refer to [Remote clusters and network security](/deploy-manage/remote-clusters.md#network-security) for more information. + :::: + + + +---> Para Remote clusters and network security!!! + +## Context + +% Maybe better for remote clusters new introduction + +With API key–based authentication, remote clusters functionality requires the local cluster (A) to trust the transport SSL certificate presented by the remote cluster server (B). However, when network security (traffic filtering) is enabled on the destination cluster (B), it's also necessary to ensure that traffic to B is allowed. This can be done using either IP-based traffic filters or remote cluster filters. + +IP-based traffic filters are not ideal for orchestration systems when allowing traffic for remote cluster functionality, since tracking the source IP address of individual {{es}} instances can be complex. + +Remote cluster filters provide a more reliable alternative: they inspect the client’s certificate to extract the `organization_id` and {{es}} `cluster_id` and decide whether to allow the traffic, adding an extra layer of security (mTLS). + +% The replacement could simply be: +Traffic filtering for remote clusters incoming connections using API key authentication supports two methods: + +* [Filtering by IP addresses and Classless Inter-Domain Routing (CIDR) masks](/deploy-manage/security/ip-filtering.md). +* Filtering by Organization or {{es}} cluster ID with a [Remote cluster type filter](/deploy-manage/security/remote-cluster-filtering.md). + + +NOT ADDED TO RCS PAGE: + +::::{note} +When setting up traffic filters for a remote connection to an {{ece}} environment, you also need to upload the region’s TLS certificate of the local cluster to the {{ece}} environment’s proxy. You can find that region’s TLS certificate in the **Security** page of any deployment of the environment initiating the remote connection. This is regardless of whether you are using API key or TLS Certificates (deprecated) to authenticate remote connections. +:::: + + +::::{important} +Because this type of filter operates at the proxy level, if the local deployments or organizations in the filter belong to a different ECE environment or to ECH, you must add the transport TLS CA certificate of the local environment to the ECE proxy: + +* Find the TLS CA certificate in the **Security -> Remote Connections -> CA certificates** section of any deployment of the environment that initiates the remote connection. In {{ecloud}}, each provider and region has its own CA certificate, while in ECE a single CA certificate is used per installation. + +* To add a CA certificate to the ECE proxy, go to **Platform -> Settings -> TLS certificates** in the UI and update the certificate chain used when configuring your ECE installation. Append the required CA certificates to the end of the chain. The final chain should look like this: `Proxy private key`, `Proxy SSL certificate`, `Proxy CA(s)`, followed by the remaining CAs. For more details, refer to [Add a proxy certificate](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md#ece-tls-proxy). +:::: + +NOT ADDED FOR THE MOMENT +### Filter types and context + +With API key–based authentication, remote clusters functionality requires the local cluster (A) to trust the transport SSL certificate presented by the remote cluster server (B). However, when network security (traffic filtering) is enabled on the destination cluster (B), it's also necessary to ensure that traffic to B is allowed. This can be done using either [IP-based traffic filters](/deploy-manage/security/ip-filtering.md) or [remote cluster filters](/deploy-manage/security/remote-cluster-filtering.md). + +* IP-based traffic filters are not ideal for orchestration platforms when allowing traffic for remote clusters functionality, since tracking the source IP address of individual {{es}} instances can be complex. + +* Remote cluster filters provide a more reliable alternative: they inspect the client’s certificate to extract the `organization_id` and {{es}} `cluster_id` and decide whether to allow the traffic, adding an extra layer of security (mTLS + API key authentication). + + +% this could replace the previous if we don't want to give any explanation +% Traffic filtering for remote clusters incoming connections using API key authentication supports two methods: +% +% * [Filtering by IP addresses and Classless Inter-Domain Routing (CIDR) masks](/deploy-manage/security/ip-filtering.md). +% * Filtering by Organization or {{es}} cluster ID with a [Remote cluster type filter](/deploy-manage/security/remote-cluster-filtering.md). + + + + + +NO AÑADIDO AUN: + +(aqui hay que aclarar que si NO hay NS todo el trafico se permite, y si hay NS todo el trafico se deniega por lo que seria obligatorio añadir una regla. +tambien explicar que IP based is not feasible). + diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 5e5b188629..4cf91ffa39 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -283,7 +283,6 @@ toc: - file: deploy/self-managed/file-descriptors.md - file: deploy/self-managed/vm-max-map-count.md - file: deploy/self-managed/max-number-of-threads.md - - file: deploy/self-managed/networkaddress-cache-ttl.md - file: deploy/self-managed/executable-jna-tmpdir.md - file: deploy/self-managed/system-config-tcpretries.md - file: deploy/self-managed/bootstrap-checks.md @@ -302,6 +301,7 @@ toc: children: - file: deploy/self-managed/important-settings-configuration.md - file: deploy/self-managed/plugins.md + - file: deploy/self-managed/networkaddress-cache-ttl.md - file: deploy/self-managed/install-kibana.md children: - file: deploy/self-managed/install-kibana-from-archive-on-linux-macos.md From 69f0217895f9d0fc8503e4b97a140072223eac0f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 24 Sep 2025 20:48:52 +0200 Subject: [PATCH 2/4] deleting file --- .../security/unused-texts-eedugon.md | 88 ------------------- 1 file changed, 88 deletions(-) delete mode 100644 deploy-manage/security/unused-texts-eedugon.md diff --git a/deploy-manage/security/unused-texts-eedugon.md b/deploy-manage/security/unused-texts-eedugon.md deleted file mode 100644 index f0c6256df3..0000000000 --- a/deploy-manage/security/unused-texts-eedugon.md +++ /dev/null @@ -1,88 +0,0 @@ -Connection modes determine how a local {{es}} cluster establishes network access to a remote cluster. - - -% need to think and decide the next paragraphs of the intro. - -% is this too obvious? -If the destination cluster of a remote cluster connection doesn't have network security enabled, all traffic is allowed, hence there's no need to create this type of filter in such case. - -% is this too obvious? -If you apply this type of filter to a deployment that didn't have network security enabled, all other traffic will be denied if you don't have other Network Security policies or filters applied to the deployment. - -% This maybe to Remote clusters doc and not here we have already mentioned that this only applies to API key based. -::::{note} -When remote clusters are configured using the deprecated TLS certificate based authentication method, there's no need to create this type of filter to allow the connection, as the connection will already be accepted regardless of the destination cluster to have Network Security enabled. -:::: - -In remote filter creation doc - - % Not sure if we want any of this - ::::{important} - Network security filtering for remote cluster traffic from ECE to ECH is not supported. These filters apply only to {{ecloud}} resources, so the values must be {{ecloud}} IDs. - - If you require network security policies in the remote deployment for remote cluster connections coming from ECE, consider configuring the remote clusters with the deprecated [TLS certificate–based authentication model](/deploy-manage/remote-clusters/ece-remote-cluster-ece-ess.md). Traffic with this model is authenticated through mTLS and is not subject to network security filters. - - Refer to [Remote clusters and network security](/deploy-manage/remote-clusters.md#network-security) for more information. - :::: - - - ----> Para Remote clusters and network security!!! - -## Context - -% Maybe better for remote clusters new introduction - -With API key–based authentication, remote clusters functionality requires the local cluster (A) to trust the transport SSL certificate presented by the remote cluster server (B). However, when network security (traffic filtering) is enabled on the destination cluster (B), it's also necessary to ensure that traffic to B is allowed. This can be done using either IP-based traffic filters or remote cluster filters. - -IP-based traffic filters are not ideal for orchestration systems when allowing traffic for remote cluster functionality, since tracking the source IP address of individual {{es}} instances can be complex. - -Remote cluster filters provide a more reliable alternative: they inspect the client’s certificate to extract the `organization_id` and {{es}} `cluster_id` and decide whether to allow the traffic, adding an extra layer of security (mTLS). - -% The replacement could simply be: -Traffic filtering for remote clusters incoming connections using API key authentication supports two methods: - -* [Filtering by IP addresses and Classless Inter-Domain Routing (CIDR) masks](/deploy-manage/security/ip-filtering.md). -* Filtering by Organization or {{es}} cluster ID with a [Remote cluster type filter](/deploy-manage/security/remote-cluster-filtering.md). - - -NOT ADDED TO RCS PAGE: - -::::{note} -When setting up traffic filters for a remote connection to an {{ece}} environment, you also need to upload the region’s TLS certificate of the local cluster to the {{ece}} environment’s proxy. You can find that region’s TLS certificate in the **Security** page of any deployment of the environment initiating the remote connection. This is regardless of whether you are using API key or TLS Certificates (deprecated) to authenticate remote connections. -:::: - - -::::{important} -Because this type of filter operates at the proxy level, if the local deployments or organizations in the filter belong to a different ECE environment or to ECH, you must add the transport TLS CA certificate of the local environment to the ECE proxy: - -* Find the TLS CA certificate in the **Security -> Remote Connections -> CA certificates** section of any deployment of the environment that initiates the remote connection. In {{ecloud}}, each provider and region has its own CA certificate, while in ECE a single CA certificate is used per installation. - -* To add a CA certificate to the ECE proxy, go to **Platform -> Settings -> TLS certificates** in the UI and update the certificate chain used when configuring your ECE installation. Append the required CA certificates to the end of the chain. The final chain should look like this: `Proxy private key`, `Proxy SSL certificate`, `Proxy CA(s)`, followed by the remaining CAs. For more details, refer to [Add a proxy certificate](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md#ece-tls-proxy). -:::: - -NOT ADDED FOR THE MOMENT -### Filter types and context - -With API key–based authentication, remote clusters functionality requires the local cluster (A) to trust the transport SSL certificate presented by the remote cluster server (B). However, when network security (traffic filtering) is enabled on the destination cluster (B), it's also necessary to ensure that traffic to B is allowed. This can be done using either [IP-based traffic filters](/deploy-manage/security/ip-filtering.md) or [remote cluster filters](/deploy-manage/security/remote-cluster-filtering.md). - -* IP-based traffic filters are not ideal for orchestration platforms when allowing traffic for remote clusters functionality, since tracking the source IP address of individual {{es}} instances can be complex. - -* Remote cluster filters provide a more reliable alternative: they inspect the client’s certificate to extract the `organization_id` and {{es}} `cluster_id` and decide whether to allow the traffic, adding an extra layer of security (mTLS + API key authentication). - - -% this could replace the previous if we don't want to give any explanation -% Traffic filtering for remote clusters incoming connections using API key authentication supports two methods: -% -% * [Filtering by IP addresses and Classless Inter-Domain Routing (CIDR) masks](/deploy-manage/security/ip-filtering.md). -% * Filtering by Organization or {{es}} cluster ID with a [Remote cluster type filter](/deploy-manage/security/remote-cluster-filtering.md). - - - - - -NO AÑADIDO AUN: - -(aqui hay que aclarar que si NO hay NS todo el trafico se permite, y si hay NS todo el trafico se deniega por lo que seria obligatorio añadir una regla. -tambien explicar que IP based is not feasible). - From d173546988f2a0fc392cddd26cf4188e33228b09 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 24 Sep 2025 21:13:21 +0200 Subject: [PATCH 3/4] removing DNS cache page and embedding content into important config section --- .../important-settings-configuration.md | 13 +++++++++---- .../self-managed/networkaddress-cache-ttl.md | 14 -------------- deploy-manage/toc.yml | 1 - redirects.yml | 2 ++ 4 files changed, 11 insertions(+), 19 deletions(-) delete mode 100644 deploy-manage/deploy/self-managed/networkaddress-cache-ttl.md diff --git a/deploy-manage/deploy/self-managed/important-settings-configuration.md b/deploy-manage/deploy/self-managed/important-settings-configuration.md index 83f6f4e596..cdd27f116e 100644 --- a/deploy-manage/deploy/self-managed/important-settings-configuration.md +++ b/deploy-manage/deploy/self-managed/important-settings-configuration.md @@ -1,6 +1,7 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html + - https://www.elastic.co/guide/en/elasticsearch/reference/current/networkaddress-cache-ttl.html applies_to: deployment: self: @@ -13,17 +14,17 @@ products: {{es}} requires very little configuration to get started, but there are a number of items which **must** be considered before using your cluster in production: * [Path settings](#path-settings) -* [Cluster name setting](elasticsearch://reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md#cluster-name) +* [Cluster name setting](#_cluster_name_setting) * [Node name setting](#node-name) * [Network host settings](#network.host) * [Discovery settings](#discovery-settings) * [Heap size settings](#heap-size-settings) * [JVM heap dump path setting](#heap-dump-path) -* [GC logging settings](elasticsearch://reference/elasticsearch/jvm-settings.md#gc-logging) +* [GC logging settings](#_gc_logging_settings) * [Temporary directory settings](#es-tmpdir) -* [JVM fatal error log setting](elasticsearch://reference/elasticsearch/jvm-settings.md#error-file-path) +* [JVM fatal error log setting](#_jvm_fatal_error_log_setting) * [Cluster backups](#important-settings-backups) -* [](networkaddress-cache-ttl.md) +* [DNS cache settings](#networkaddress-cache-ttl) ## Path settings [path-settings] @@ -242,3 +243,7 @@ In a disaster, [snapshots](../../tools/snapshot-and-restore.md) can prevent perm **Taking a snapshot is the only reliable and supported way to back up a cluster.** You cannot back up an {{es}} cluster by making copies of the data directories of its nodes. There are no supported methods to restore any data from a file system-level backup. If you try to restore a cluster from such a backup, it may fail with reports of corruption or missing files or other data inconsistencies, or it may appear to have succeeded having silently lost some of your data. :::: + +## DNS cache settings [networkaddress-cache-ttl] + +{{es}} runs with a security manager in place. With a security manager in place, the JVM defaults to caching positive hostname resolutions indefinitely and defaults to caching negative hostname resolutions for ten seconds. {{es}} 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](elasticsearch://reference/elasticsearch/jvm-settings.md#set-jvm-options). Note that the values [`networkaddress.cache.ttl=`](https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.md) and [`networkaddress.cache.negative.ttl=`](https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.md) in the [Java security policy](https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.md) are ignored by {{es}} unless you remove the settings for `es.networkaddress.cache.ttl` and `es.networkaddress.cache.negative.ttl`. diff --git a/deploy-manage/deploy/self-managed/networkaddress-cache-ttl.md b/deploy-manage/deploy/self-managed/networkaddress-cache-ttl.md deleted file mode 100644 index d00fc5c592..0000000000 --- a/deploy-manage/deploy/self-managed/networkaddress-cache-ttl.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/networkaddress-cache-ttl.html -applies_to: - deployment: - self: -products: - - id: elasticsearch ---- - -# DNS cache settings [networkaddress-cache-ttl] - -{{es}} runs with a security manager in place. With a security manager in place, the JVM defaults to caching positive hostname resolutions indefinitely and defaults to caching negative hostname resolutions for ten seconds. {{es}} 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](elasticsearch://reference/elasticsearch/jvm-settings.md#set-jvm-options). Note that the values [`networkaddress.cache.ttl=`](https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.md) and [`networkaddress.cache.negative.ttl=`](https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.md) in the [Java security policy](https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.md) are ignored by {{es}} unless you remove the settings for `es.networkaddress.cache.ttl` and `es.networkaddress.cache.negative.ttl`. - diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 4cf91ffa39..14eda45617 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -301,7 +301,6 @@ toc: children: - file: deploy/self-managed/important-settings-configuration.md - file: deploy/self-managed/plugins.md - - file: deploy/self-managed/networkaddress-cache-ttl.md - file: deploy/self-managed/install-kibana.md children: - file: deploy/self-managed/install-kibana-from-archive-on-linux-macos.md diff --git a/redirects.yml b/redirects.yml index 71751347aa..33c9971abc 100644 --- a/redirects.yml +++ b/redirects.yml @@ -466,3 +466,5 @@ redirects: 'solutions/observability/apm/collect-application-data.md': 'solutions/observability/apm/ingest/index.md' 'solutions/observability/apm/jaeger.md': 'solutions/observability/apm/ingest/jaeger.md' 'solutions/observability/apm/monitor-aws-lambda-functions.md': 'solutions/observability/apm/ingest/monitor-aws-lambda-functions.md' +# Related to https://github.com/elastic/docs-content/pull/3142 + 'deploy-manage/deploy/self-managed/networkaddress-cache-ttl.md': 'deploy-manage/deploy/self-managed/important-settings-configuration.md' \ No newline at end of file From bf56c37c2242b4cac7e510a34cce682eb387c749 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 24 Sep 2025 21:21:55 +0200 Subject: [PATCH 4/4] updated link --- .../discovery-cluster-formation/discovery-hosts-providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md b/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md index 70abebaf6a..519d914208 100644 --- a/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md +++ b/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md @@ -25,7 +25,7 @@ Refer to [Troubleshooting discovery](../../../troubleshoot/elasticsearch/discove By default the cluster formation module offers two seed hosts providers to configure the list of seed nodes: a *settings*-based and a *file*-based seed hosts provider. It can be extended to support cloud environments and other forms of seed hosts providers via [discovery plugins](elasticsearch://reference/elasticsearch-plugins/discovery-plugins.md). Seed hosts providers are configured using the `discovery.seed_providers` setting, which defaults to the *settings*-based hosts provider. This setting accepts a list of different providers, allowing you to make use of multiple ways to find the seed hosts for your cluster. -Each seed hosts provider yields the IP addresses or hostnames of the seed nodes. If it returns any hostnames then these are resolved to IP addresses using a DNS lookup. If a hostname resolves to multiple IP addresses then {{es}} tries to find a seed node at all of these addresses. If the hosts provider does not explicitly give the TCP port of the node by then, it will implicitly use the first port in the port range given by `transport.profiles.default.port`, or by `transport.port` if `transport.profiles.default.port` is not set. The number of concurrent lookups is controlled by `discovery.seed_resolver.max_concurrent_resolvers` which defaults to `10`, and the timeout for each lookup is controlled by `discovery.seed_resolver.timeout` which defaults to `5s`. Note that DNS lookups are subject to [JVM DNS caching](../../deploy/self-managed/networkaddress-cache-ttl.md). +Each seed hosts provider yields the IP addresses or hostnames of the seed nodes. If it returns any hostnames then these are resolved to IP addresses using a DNS lookup. If a hostname resolves to multiple IP addresses then {{es}} tries to find a seed node at all of these addresses. If the hosts provider does not explicitly give the TCP port of the node by then, it will implicitly use the first port in the port range given by `transport.profiles.default.port`, or by `transport.port` if `transport.profiles.default.port` is not set. The number of concurrent lookups is controlled by `discovery.seed_resolver.max_concurrent_resolvers` which defaults to `10`, and the timeout for each lookup is controlled by `discovery.seed_resolver.timeout` which defaults to `5s`. Note that DNS lookups are subject to [JVM DNS caching](/deploy-manage/deploy/self-managed/important-settings-configuration.md#networkaddress-cache-ttl). #### Settings-based seed hosts provider [settings-based-hosts-provider]