Hostname resolution affecting Resilient DR

Steps

A customer had an issue enabling DR. The following was written to the cli. Note the IP addresses referenced.

TASK [pg_receiver : create a basebackup of the primary] *************************************************************************************************************************************************************************************
fatal: [receiver.example.com]: FAILED! => {"changed": true, "cmd": "PGPASSWORD=\"*********\" pg_basebackup -h \"master.example.com\" -D \"/var/lib/pgsql/9.6/basebackup\" -U res_rep -v -P -x -w", "delta": "0:00:00.080224", "end": "2019-10-10 10:29:24.538250", "msg": "non-zero return code", "rc": 1, "start": "2019-10-10 10:29:24.458026", "stderr": "pg_basebackup: could not connect to server: FATAL: no pg_hba.conf entry for replication connection from host \"10.10.10.10\", user \"res_rep\", SSL on\nFATAL: no pg_hba.conf entry for replication connection from host \"10.10.10.10\", user \"res_rep\", SSL off", "stderr_lines": ["pg_basebackup: could not connect to server: FATAL: no pg_hba.conf entry for replication connection from host \"10.10.10.10\", user \"res_rep\", SSL on", "FATAL: no pg_hba.conf entry for replication connection from host \"10.10.10.10\", user \"res_rep\", SSL off"], "stdout": "", "stdout_lines": []}
...ignoring

TASK [pg_receiver : pg_basebackup failed (this task is skipped if no failure occurred)] *****************************************************************************************************************************************************
fatal: [receiver.example.com]: FAILED! => {"changed": false, "msg": "pg_basebackup failed. Database archive has been restored."}

The file, /var/lib/pgsql/9.6/data/pg_hba.conf on the Master has an entry for receiver.example.com not the IP address referenced above, hence why Postgres cannot access the database on the receiver server and the process fails.

The problem was related to name resolution for their servers. After updating /etc/hostname and adding entries to /etc/hosts the above error did not occur and DR was enabled.