Should http.publish_host resolve the CNAME configured.

[Mpdreamz]

http.publish_host is resolved while starting the node but I'm not entirely sure this makes sense.

This setting is a great way to advertise CNAME to http clients that might not be resolvable on the network the nodes themselves live on or the firewall they are behind.

http.publish_host: elastic.co

GET /_nodes/http?pretty=true

{
  "_nodes" : {
    "total" : 1,
    "successful" : 1,
    "failed" : 0
  },
  "cluster_name" : "testtesttest",
  "nodes" : {
    "PTUZtqXjSY-mjPiQPWGXPg" : {
      "name" : "PTUZtqX",
      "transport_address" : "10.2.42.55:9300",
      "host" : "10.2.42.55",
      "ip" : "10.2.42.55",
      "version" : "5.0.0",
      "build_hash" : "253032b",
      "roles" : [
        "master",
        "data",
        "ingest"
      ],
      "http" : {
        "bound_address" : [
          "127.0.0.1:9200",
          "[::1]:9200",
          "10.2.42.55:9200"
        ],
        "publish_address" : "35.160.254.14:9200",
        "max_content_length_in_bytes" : 104857600
      }
    }
  }
}

It also advertises the resolved IP and not the CNAME which might not play well with DNS caching, the lazy transport resolving coming in 5.1 as per #21630 does not seem to extend to these settings.

[Mpdreamz]

Ok digging a bit further back it seems something has changed in how this is returned

Elasticsearch 2.1.1 used to return:

"publish_address" : "elastic.co/35.160.254.14:9200"

But in 2.4.6 and 5.x the cname part is dropped

"publish_address" : "35.160.254.14:9200"

In the .net client sniffing we give precedence to the part returned before the / as the hostname for the calls that we do.

[soenkeliebau]

This behavior can create issues in environments where sniffing is used in conjunction with ssl certificates.

We currently have set up Logstash with ssl certificate checking and sniffing enabled. However our server certificates only contain the fqdns, not the server ip addresses, which I believe is not unusual (even if I don't condone it).
Since ES always returns the ip address in publish_address, Logstash will try connecting to the ip address and reject the certificate, as it is only valid for the fqdn.

I think it is fine for the publish_address to be resolved to an ip if it is inherited from network_host. But if it is explicitly configured to be something else I think we should presume that the user knows what he/she is trying to accomplish and return the configured string. If that breaks communication - well, shouldn't have fiddled with it :)

[honzakral]

Since the user here explicitly asked for publish_host to be set, there is a clear expectation of what should happen - the node should be reached via that value (0). By resolving it into an IP address elasticsearch made that impossible in many cases like when using ssl. This is clearly a bug.

0 - https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html#advanced-network-settings

[soenkeliebau]

I'm happy to work on this if everybody agrees on the behavior as stated above:

• keep behavior as is if publish_address is not set
• return the configured value if publish_address is set

[inqueue]

Also impacts sniffing in the Java client: #26125

[andrewvc]

@javanna / @jasontedor is there any plan to address this issue in ES? This is a pretty nasty situation we're in, where clients can't use TLS in the predominant way its used, with domains, when using sniffing, which is a feature we highly encourage our users to use?

Should I direct this issue to someone in particular?

[jasontedor]

You can direct it to me. I'm on the tail-end of a vacation and will be available again next Monday; I'll take a look when I'm back.

[Dinomoe]

Hey Party People,
Any word on this?
Thanks
-Kobar