MVV

Если КД имеет возможность (на шлюзе и провадером не запрещено) посылать запросы DNS в интернет на любой сервер (т.е. открыт исходящий доступ по 53/UDP), то можно не указывать ничего: DNS Server на КД сам может послать все нужные запросы, начиная с корневых серверов. Иначе в пересылке следует указать тот сервер DNS, куда доступ открыт.

Вариант 2 несет риск отказа единственного КД в в процессе замены второго КД. Вариант 1 в этом плане безопаснее. Оставлять тот же адрес IP и имя, чаще всего, не обязательно (для проверки можно выключить второй КД и посмотреть, что все в организации функционирует нормально).
PS Для отказоустойчивости DHCP можно поднять DHCP на другом КД, а зону(ы) для локальной сети настроить отказоустойчивыми через DHCP Failover.

Вот вам ссылка на рекомендации изготовителя (Microsoft). Там - целый раздел, ссылка ведет на первую статью раздела. Если испытываете трудности с английским, то эти рекомедации переведены (как-то) и на русский язык.
Резюме:

1. встроенного средства архивирования Windows для резервного копирования и восстановления AD достаточно, но в плане удобства использования коммерческие решения лучше;
   
2. одиночные контроллеры домена, не несущие других функций, восстанавливать нецелесообразно: никакой уникальной информации на них нет, и куда лучше просто добавить в AD новый КД с другим именем;
   
3. берегитесь средств снятия и восстанвления образов диска, не поддерживающих AD специально, как средства резервного копирования и восстановления, такие средства безопасно использовать только в системе с ровно одним КД в лесу (по крайней мере - для физических КД, с виртуальными полегче - многие гипервизоры поддерживают идентификатор VM, а AD обучена правильно реагировать на его смену - но можно нарваться); однако при нужде использовать их можно - надо только отдельно копировать и восстанавливать до подключения в сеть Состояние системы.
   

В дополнение: есть такая утилита от Sysinternals (это уже давно часть Microsoft), она показывает все места, откуда возможен автоматический запуск, и что в этих местах содержится.

1. Чтобы Exchange Server принимал почту для другого домена, этот домен в нем должен быть прописан в Обслуживаемых доменах с типом "Внутренняя ретрансляция". А для фактической отправки почты на другой домен нужно создать соединитель отправки для этого домена с назначением (smarthost) на сервер, фактически обслуживающий этот домен. Сервер на том конце может быть совершенно любым сервером SMTP.
2. Адреса для п/я в Exchange настраиваются политиками адресов: в политике должен быть прописан первичный домен для адреса SMTP (используется и для отправки и для приема) и может быть несколько вторичных доменов. На той стороне, где нужно поменять адреса, просто добавьте в политику нужный домен с нужным типом. Кстати, если политика поменяет первичнй адрес п/я, то его бывший первичный адрес останется в качестве вторичного, так что, если новым пользователям не нужно добавлять адреса из старого домена, то в политике можно просто заменить первичный домен на новый, не оставляя старый вторичным.
3. Чтобы письма с Exchange с адресом его обслуживаемого домена могли отправляться на другой сервер SMTP (в том числе - в Exchange в другом лесу), нужно сменить тип этого домена с полномочного на внутреннюю ретрансляциию и создать соединитель отправки аналогично п.1
4. Вам наверняка потребуется синхронизировать адресные книги обоих Exchange. Раньше для этого можно было использовать бесплатный упрощенный вариант Microsoft Identity Integration Server (названия у него были разные, но суть одна: синхронизация AD между разными лесами, так чтобы пользователи с п/я из одного леса отображались как контакты в другом). Остался ли он сейчас - не интересовался. Но, в принципе, это может делаться и скриптом.
5. Вариантов совместного использования Exchange много разных (например, можно сделать общие календари). Но тут я их рассматривать не буду - вы все равно, скорее всего, захотите все это поскорее мигрировать в один лес. Но если интересно - ищите книги/документацию по Exchange 2007: эта функция (называется "федерация") в современном виде появилась там, и лучшие описания относятся именно к этой версии. С тех пор мало что поменялось, потому что MS пошла в облака.
6. При миграции есть возможность заводить п/я в одном лесу для пользователей из другого, доверенного леса (называется это Linked Mailbox, как по-русски - точно не помню). Для этого, кстати,в Exchange есть скрипт (его использовали для подготовки миграции с ADMT или ему подобными).