Troubleshooting Causes of "host not found" Error When Using Extension Mobility or Phone Services

There's several common causes for a phone to display "host not found" when pressing the Services or Directories buttons, or accessing Extension Mobility. Contrary to what the error message implies, often it's not actually a DNS issue that's the cause. Phone services rely on HTTP or HTTPS, with services hosted by CUCM handled by the Tomcat web server & using TCP ports 8080 or 8443.

First of all it's important to understand which server the phone is trying to access, as the default services built into CUCM use a load balancing mechanism by default, a detailed explanation of which can be found in the SRND. In summary by default built in services (i.e. service URLs starting Application:) use HTTPS & use a load balancing mechanism so that the phone will rewrite the service URL to point to the CUCM server with which it is currently registered.

DNS
DNS is only an issue if the service URL contains an FQDN or hostname, or in the case of built in services, if the Servers in CUCM are defined as an FQDN or hostname. Confirm that the phone actually has DNS servers configured, that these DNS servers are reachable & can resolve the FQDN or hostname.

SSL
You can confirm whether a service will be accessed via HTTPS by looking at the configuration to see if a Secure Service URL has been set, or for built in services, if the phone's configuration file contains <phoneServices useHTTPS="true">. This will allow you to confirm which port the phone will try to use to access the service.

Web Server
Check if the web server is inaccessible, try telnetting to the relevant port or viewing the service URL. For CUCM's built in services, also confirm that the Tomcat service is running on the relevant server.

Certificate Trust
If the web server's certificate isn't present in the phone's ITL/CTL file, the inability to verify the certificate can cause the host not found error.
Confirm that the phone has learnt TFTP server addresses via DHCP option 150 or manual configuration, otherwise it won't be able to update its configuration & may be caching out of date ITL/CTL files.
For certificates that aren't in the ITL/CTL, the phone should attempt to contact the Trust Verification Service on CUCM via TCP port 2445. If the TVS service isn't enabled or isn't running, or cannot be reached then certificate verification will fail. Note that the TVS service also uses a certificate that must in the ITL for the phone to trust it.

Phone Logs
The phone's logs provide insight into what's happening, for example failure to access the TVS service will show up in the logs. Accessing these logs requires that the phone's web server is enabled, which isn't the case by default in CUCM. Also network settings, such as DNS or TFTP server(s) can be verified via the phone's web server.

6900 & 7800 Series Phone Directories Failing

Sadly the 7800 series phones have multiple known issues with directories (e.g. CSCuq12291 & CSCus20047), resulting in the Personal Directory and Corporate Directory displaying "host not found". I encountered this during a large deployment of 7821 & 7841 phones with CUCM 10.5(2), Cisco TAC issued an engineering special firmware (78xx.10-2-1ES6-1) which failed to resolve the problem. Eventually the problem was resolved by manually editing the service URLs for Personal Directory and Corporate Directory from the default values.

Directory	Default value	Amended value
Corporate Directory	Application:Cisco/CorporateDirectory	http://10.15.0.2:8080/ccmcip/xmldirectoryinput.jsp
Personal Directory	Application:Cisco/PersonalDirectory	http://10.15.0.2:8080/ccmpd/pdCheckLogin.do?

Put your publisher IP address into the amended service URL, click save, click update subscription & then reset your phones.
To avoid affecting other phones I did try setting these URLs in Enterprise Parameters & then setting the 7821/7841 phones to use external service provisioning, however they don't seem to support external service provisioning & thus get stuck showing "requesting". Fortunately using the amended service URLs have no negative affect on other models of phone.

Update: I also recently experienced this exact same issue with 6900 series phones after doing an upgrade to CUCM 10.5(2), fortunately updating the service URLs also fixed the problem.