As the info center documentation implies, if the DR server uses a different host name or IP address than the primary server, then a failover is not transparent to CDC and this has an impact on the replication.
There are broadly three scenarios that can apply to CDC in any failover or switchover procedure in a clustered or HADR environment, irrespective of platform or database type
1) The CDC engine (binaries) connects to the database in the same ways on both DR and primary servers via the instance configuration, AND the other components (Access Server and the partner instance) connect to the DR and the primary server in the same way AND CDC is installed and configured on a SAN or equivalent which is attached to whichever server is acting as primary. In this case the failover is "transparent" to CDC and the only requirememt is probably to script some sort of restart script after a failover
2) T he CDC engine (binaries) connects to the database in the same ways on
both DR and primary servers via the instance configuration, AND the
other components (Access Server and the partner instance) connect to the
DR and the primary server in the same wayBUT CDC ins installed and configured on each server separately. In this case the engine is installed on each server (and maintained separately as regards applying of fixes and upgrades), and the instance is configured on the primary server. The instance data is copied to the DR server before the failover (recreating the instance with the same schema would overwrite the configuration for the production server). So in this case scripts are required to copy the instance data and to restart CDC
3) The primary and DR servers use a different host name and IP address. In this case for a target you can create an alias and change the target datastore details in the subscriptions in MC, but this is not scriptable (unless you resort to Java). For a source you would have to create a separate instance for primary and D/R servers and have a process to copy the configuration periodically. You could also do this for a target as well as this would allow scripting without using Java.
In many cases it is also possible to install and configure CDC on a separate server to the source or target database server, This has the virtue of simplifying the failover process for CDC where scenario 3 applies as the other CDC components still connect to the same server for CDC after a failover and presumably the CDC instance would be configured to connect to the database using some form of virtual address or host name in a similar manner to a conventional database client. However it may make the initial configuration more complex, and unless DR provision is made for the CDC server, we now have a single point of failure in an otherwise resilient environment..
If CDC is installed within a clustered or HADR type environment then a script will probably used to automate the switchover:
1) The instance may need to be started
2) If running on a source, it will be necessary probably to clear the staging store
3) If a separate set of subscriptions are used it will be necessary to query the TS_BOOKMARK table in the CDC schema in the target database to determine the bookmarks so that these bookmarks can be set on the source for the DR subscription set
4) The subscriptions will be started. If the failover is on the source, the CDC OS commands (dmstartmirror) can be used; if on the target, then the MC commands can be used to avoid executing a remote script (assuming the Access Server component is installed-