Рекомендации по проектированию домена Active Directory (AD) с использованием зарегистрированного имени домена в качестве имени домена AD. К возможным альтернативным вариантам относятся использование непубличного суффикса DNS (например,Local или . LAN, например) в имени домена Active Directory, или создание дочернего домена AD Domain a для зарегистрированного домена (например,Corp.domain.com).
Вы не всегда сможете выбирать в любом случае. возможно, вы обнаружите, что домен AD с таким же именем, как у зарегистрированного домена компании, и управление, возможно, не желаете изменять какое бы то ни было имя. Это называется сценарием разделенного DNS (или разделением DNS), в котором имеется два различных пространства имен DNS — внутреннее пространство имен, используемое службой AD, и внешнее пространство имен, используемое регистратором публичного домена с таким же именем. Этот сценарий может представлять некоторые уникальные задачи. В этой статье обсуждаются некоторые распространенные проблемы, возникающие в среде с разделением DNS и действия, которые можно выполнить для их устранения.
Во всех примерах ниже, домен Active Directory и зарегистрированный домен с именем domain.comи веб-сайт компании под названием www.domain.com.
Неполадка 1. Веб-сайт компании, размещенной извне, недоступен изнутри офиса
Это наиболее частая проблема, связанная с разделенной DNS средой: веб-сайт компании или другой ресурс, принадлежащий к Интернету, не может быть достигнут внутри офиса по компьютерам, подключенным к домену Active Directory, но на машинах, находящихся за пределами офиса, нет проблем с доступностью к веб-сайту. Это может быть показано в следующих случаях: Проверка того, что происходит, когда внутренний пользователь пытается просмотреть веб-сайт компании.
Эта проблема возникает из-за того, что сервер DNS с определенной зоной поиска в своей базе данных — зона domain.com в этом примере — не отправляет запросы для записей в этой зоне где-либо еще; Он просто возвращает ответ «не найден», если нет записи, соответствующей данному запросу. В этом примере имеется другой DNS сервер с правильной записью: сервер DNS, на котором размещается открытая зона domain.com , принадлежащая регистратору домена, как очевидно на тот факт, что компьютеры, находящиеся за пределами офиса, могут получить доступ к веб-сайту. Однако запросы с внутренних машин никогда не доходят до этого сервера.
Решение для этой проблемы просто: Создайте запись хоста с именем www в зоне domain.com на контроллере домена и ВЫдайте этой записи IP-адрес веб-сайта. Машины, которые запрашивают DNS сервер, получат правильный ответ и смогут просматривать веб-сайт.
Проблем 2. Внутренний размещенный общедоступный веб-сайт недоступен изнутри офиса
Это могло рассматриваться как вариант в описанной выше причине 1. Разница в этом случае заключается в том, что веб-сайт размещен на внутреннем ресурсе либо позади брандмауэра в внутренней сети компании, либо в DMZ. Он должен быть доступен как внутренним, так и внешним пользователям, но внутренние пользователи не могут получить к нему доступ, а внешние пользователи не будут сообщать о проблемах.
Причина проблемы аналогична описанной в вопросе 1, но внутренние пользователи в этом случае могут правильно разрешить имя веб-сайта в общедоступный IP-адрес. Тем не менее, они по-другому не смогут получить доступ к веб-сайту из-за способа настройки брандмауэра. Он ожидает, чтобы пользователи во внутренней сети имели доступ к веб-сайту с использованием своего частного адреса, а не его общедоступного адреса.
Опять же, существует простое исправление: создание записи хоста с именем www в зоне domain.com на контроллере домена, но на этот раз ВЫдается частный IP-адрес веб-сайта. Внутренние машины разрешают имя веб-сайта на этот частный адрес, а внешние машины по-прежнему разрешают это имя в общедоступном адресе веб-сайта.
Неполадка 3. Веб-сайт загружается не полностью или не загружается после выполнения указанных выше изменений
Это может происходить, если код веб-сайта перенаправляет браузеры с www.domain.com на domain.com или если внутренние ссылки ссылаются на площадку как domain.com , а не www.domain.com. Такие же симптомы наблюдаются на внутренних машинах, где размещается внутренний или внешний узел:
Проблема, описанная в данном случае, немного сложнее. Чтобы машины могут разрешать domain.com в IP-адрес, в зоне domain.com в DNS необходимо иметь пустую запись хоста. Имя этой записи отображается как (как родительская папка) в консоли Windows DNS. Однако в этом случае существует проблема: AD использует пустые записи хостов в зоне domain.com для представления контроллеров домена domain.com . Участники домена используют эти записи при поиске контроллера домена для проверки подлинности, а также если в зоне domain.com имеются лишние записи хостов, могут возникать задержки или проблемы с проверкой подлинности.
По причине, описанной выше, эта проблема не может быть устранена только в DNS. Создание пустой записи хоста с IP-адресом веб-сайта периодически решает проблему доступа к веб-сайту для внутренних пользователей, поскольку уже имеются другие пустые записи хостов с IP-адресами контроллеров домена, и это приводит к проблемам с проверкой подлинности домена.
Самый простой способ решить эту проблему — изменить код веб-сайта, чтобы либо удалить перенаправление, либо исправить внутренние ссылки так, чтобы все элементы ссылались на площадку как www.domain.com , а не domain.com. Если изменение кода невозможно, единственным другим вариантом решения проблемы является переименование домена AD. Это может быть сложной задачей, в зависимости от размера и сложности среды.