From version 3.5, Cisco Meeting Server can use other validations Hostname/IP Address If you are deploying or upgrading to version 3.6 (or 3.5). The database cluster nodes might fail to connect to each other. The reason is that each server will try to resolve the server's name (or hostname) of each node in the cluster, which is not available in version prior 3.5.
![12.PNG 12.PNG](https://community.cisco.com/t5/image/serverpage/image-id/163271iE50C7F00AD3ABC7C/image-size/large?v=v2&px=999)
![9.PNG 9.PNG](https://community.cisco.com/t5/image/serverpage/image-id/163277iDAF36A44BDD3592E/image-size/medium?v=v2&px=400)
To solve this issue, You need a DNS Record, fortunately a DNS RR record can be created on CMS to resolve the server identity locally.
Let's take an example, if you have three Nodes running the database cluster with 3.6 version with hostname CMS1 10.1.5.61, CMS2 10.1.5.62 and CMS3 10.1.5.63, CMS1 as the primary or the master node, you need the following DNS RR Records as follow:
![topo.PNG topo.PNG](https://community.cisco.com/t5/image/serverpage/image-id/163272i7B7EF9AF1395E2EB/image-size/medium?v=v2&px=400)
On CMS1:
dns add rr "cms2. IN A 10.1.5.62"
dns add rr "cms3. IN A 10.1.5.63"
![18.PNG 18.PNG](https://community.cisco.com/t5/image/serverpage/image-id/163273i3CDA4D6C23E88C40/image-size/large?v=v2&px=999)
On CMS2:
dns add rr "cms1. IN A 10.1.5.61"
dns add rr "cms2. IN A 10.1.5.63"
![20.PNG 20.PNG](https://community.cisco.com/t5/image/serverpage/image-id/163275iDEFD8893EAD153F3/image-size/large?v=v2&px=999)
On CMS3:
dns add rr "cms1. IN A 10.1.5.61"
dns add rr "cms3. IN A 10.1.5.62"
![20.PNG 20.PNG](https://community.cisco.com/t5/image/serverpage/image-id/163276iCC518B4C351B3DC2/image-size/large?v=v2&px=999)