CUCM deployment and DNS

Network Services
The deployment of an IP Communications system requires the coordinated design of a well structured,
highly available, and resilient network infrastructure as well as an integrated set of network services
including Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Trivial File
Transfer Protocol (TFTP), and Network Time Protocol (NTP).

Domain Name System (DNS)
DNS enables the mapping of host names and network services to IP addresses within a network or
networks. DNS server(s) deployed within a network provide a database that maps network services to
hostnames and, in turn, hostnames to IP addresses. Devices on the network can query the DNS server
and receive IP addresses for other devices in the network, thereby facilitating communication between
network devices.
Complete reliance on a single network service such as DNS can introduce an element of risk when a
critical Unified Communications system is deployed. If the DNS server becomes unavailable and a
network device is relying on that server to provide a hostname-to-IP-address mapping, communication can and will fail. For this reason, in networks requiring high availability, Cisco recommends that you do
not rely on DNS name resolution for any communications between Unified CM and the Unified
Communications endpoints.

For standard deployments, Cisco recommends that you configure Unified CM(s), gateways, and
endpoint devices to use IP addresses rather than hostnames. For endpoint devices, Cisco does not
recommend configuration of DNS parameters such as DNS server addresses, hostnames, and domain
names. During the initial installation of the publisher node in a Unified CM cluster, the publisher will
be referenced in the server table by the hostname you provided for the system. Before installation and
configuration of any subsequent subscribers or the definition of any endpoints, you should change this
server entry to the IP address of the publisher rather than the hostname. Each subscriber added to the
cluster should be defined in this same server table via IP address and not by hostname. Each subscriber
should be added to this server table one device at a time, and there should be no definitions for
non-existent subscribers at any time other than for the new subscriber being installed.
During installation of the publisher and subscriber, Cisco recommend that you do not select the option
to enable DNS unless DNS is specifically required for system management purposes. If DNS is enabled,
Cisco still highly recommend that you do not use DNS names in the configuration of the IP
Communications endpoints, gateways, and Unified CM servers. Even if DNS is enabled on the servers
in the cluster, it is never used for any intra-cluster server-to-server communications and is used only for
communications to devices external to the cluster itself.
Cisco Unified CM 5.0 and later releases do not permit the manual configuration of HOSTS or LHOSTS
files. A local version of the HOSTS table is automatically built by the publisher in each cluster and
distributed to all subscriber nodes via a secure communications channel. This local table is used for
managing secure intra-cluster communications and does not contain addresses or names of any endpoints
other than the Unified CM servers themselves. LMHOSTS files do not exist and are not used by Cisco
Unified CM 5.0 and later releases.

Deploying Unified CM with DNS
There are some situations in which configuring and using DNS might be unavoidable. For example, if
Network Address Translation (NAT) is required for communications between the IP phones and
Unified CM in the IP Communications network, DNS is required to ensure proper mapping of NAT
translated addresses to network host devices. Likewise, some IP telephony disaster recovery network
configurations rely on DNS to ensure proper failover of the network during failure scenarios by mapping
hostnames to secondary backup site IP addresses.
If either of these two situations exists and DNS must be configured, you must deploy DNS servers in a
geographically redundant fashion so that a single DNS server failure will not prevent network
communications between IP telephony devices. By providing DNS server redundancy in the event of a
single DNS server failure, you ensure that devices relying on DNS to communicate on the network can
still receive hostname-to-IP-address mappings from a backup or secondary DNS server.
Hostname resolution within the cluster via either the local HOSTS file or DNS queries is performed only
at subsystem initialization (that is, when a server is booted up). As a result, in order for a server within
the cluster to resolve a DNS name that has been changed in either the HOSTS file or the DNS server,
the Cisco CallManager Service must be restarted on all servers within the cluster.

Reference:

CUCM7 SRND