## Description RabbitMQ post start actions might fail because `getent hosts <ip>` sometimes returns an unexpected hostname starting with a '-' separated IP address. Later, running `rabbitmqctl join_cluster <peer>` with that hostname will fail. It will also stop the post start actions before the stream replication can be executed. #### Steps to reproduce the issue Get the IP address of RabbitMQ pod and run the following in a different RabbitMQ pod of the same cluster: ``` watch -n1 'getent hosts <ip>' ``` #### Result It can take some time, but the output will switch between (example) `10-225-107-93.nova-waveforceone-nova-cell1-mq.waveforceone.svc.cluster.local` and `nova-waveforceone-nova-cell1-mq-1.nova-waveforceone-nova-cell1-mq-rdy.waveforceone.svc.cluster.local` #### Expected Result We always need to get a hostname with the subdomain being the podname, not the IP, and the address must point to the headless service/`ready_service`. #### Additional Information Most recent source code of getent I could find: https://codebrowser.dev/glibc/glibc/nss/getent.c.html The same thing also occurs within MariaDB clusters. Probably related to CoreDNS: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#a-aaaa-records-1 ## Resolution t.b.d. ### Proposal To be discussed. ### Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this issue are to be interpreted *in the spirit of* [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119), even though we're not technically doing protocol design. <!-- Bullet-point list of MUST, SHOULD, MAY, SHOULD NOT and MUST NOT. will be added as a result of the proposal discussion process. -->