DNS is a very important component of cross-forest (and cross-premises) migrations.  Failure to consider and configure for DNS resolution not only can create issues for migration, but can also negatively impact end users.
Here’s Priasoft’s guidance on DNS setup:

1. The migration host must be able to resolve server names in both the source and target environments.
   1. The migration host must be able to resolve fully qualified DNS names, like server01.domain.com
   2. The migration host must also be able to resolve single-label names like server01
      1. For single-label names, windows will attempt a NetBIOS lookup first, before using DNS.  If WINS is being used, it must work properly.
      2. If NetBIOS lookups fail, or are not configured, windows will append DNS suffixes to the name before send the request to the DNS server.  As such, proper configuration of DNS suffixes that support both the source and target environments are necessary.
      3. The migration host (at a minimum) should have DNS suffixes for all the target domains first, followed by suffixes for all the source [windows] domains.  However, it is better to make this an organizational configuration via Group Policy or DHCP (or both).  It is quite likely that there are other hosts in the target environment that will need to access source computers.
2. Conditional Forwarding is best
   1. Windows 2008 and later DNS support the use of Conditional Forwarders.  This feature allows a DNS server in one environment to forward domain specific queries to one or more hosts that are likely responsible and authoritative for the request.
   2. DNS servers in the target environment should be configured for Conditional Forwarders for each source [windows] domain that is part of the migration.  Be sure to include children and parent domains in the forwarding.
   3. When an application (such as the Priasoft tools) cause a name lookup, the FQDN of the name will be sent to the DNS server.  If that server sees a domain specific forwarder for the domain in the request, it can immediately forward that request to the other side.
   4. Conditional forwarders are simpler to setup and are more relevant than a secondary or stub zone since no zone replication is necessary.
3. Client hosts (computers, laptops, mobile devices) will need to be able to resolve the names of the target exchange servers and domain controllers.
   1. The configuration of DNS is not exclusive to the target domain nor to just the migration host(s).
   2. Very often there will be computing devices in the source environment that still receive DNS server IPs from the source environment.  If the source is not also configured with suffixes and conditional forwarding, those devices may not be able to connect to the target exchange servers after migration.
   3. Client devices then should also receive, via Group Policy or DHCP (or both), the DNS suffixes of the target environment.

 
Name resolution is even more important in new versions of exchange due to the heavy reliance on SSL and Certificates.  Then name of the host that an application is to use to connect to a server is compared to the names on the certificate from that server.  If DNS (or a ‘hosts’ file) attempts to point a name like ‘server01.domain.com’ to the IP address of ‘server04.domain.com’, the connection will fail because the name ‘server01’ does not exist on the certificate for ‘server04’.  Do not attempt to ‘trick’ applications by hard-coding IP addresses to names that don’t match.
Specific to Exchange 2013 configurations, Priasoft recommends using the same URL for both the Internal Host Name and External Host Name.  Local DNS can provide one or more IP addresses that relate to the local servers and public DNS can point to addresses at the company’s edge and DMZ.
Alternatively, if two separate values are to be used [to avoid split-DNS], setting the internal name to a generic common name is more appropriate, like: ‘internal.mail.domain.com’.  Then local DNS would supply multiple IP addresses for that generic name, each pointing to an exchange server.  Public DNS would server the external name, like ‘mail.domain.com’.
 
Note that Outlook receives both the internal and external values in the AutoDiscover response.  Outlook ALWAYS tries the internal hostname value FIRST, and if that fails will then try the external value.  Given this behavior, Priasoft highly recommends configuration values for both fields in Exchange 2013.
 
-Support