Некоторые проблемы Split DNS

Если вы собираетесь внедрить или уже внедрили Split DNS в своей ИТ-инфраструктуре, то перед вами стоит задача следить за непротиворечивостью DNS-записей на внутренних и внешних DNS серверах.

 

Для наглядности возьмем схему:

На схеме выделены три вида DNS записей одного домена domain.ru:

Область A – записи относятся только к внутренним объектам (сервисы, компьютеры, принт-серверы и т.п.) и находятся только на внутренних DNS серверах; из внешней сети они недоступны как видно на следующей схеме:

B – эти записи находятся и на внутренних, и на внешних DNS серверах, ссылаясь на один и тот же сервис, например, почтовый сервер, но внутренние клиенты получают внутренний адрес сервиса, а внешние – внешний адрес как показано на следующей схеме:

C – это записи только внешних объектов – сервисов, серверов во внешней сети; внешние адреса прописаны также и на внутренних DNS; внутренние клиенты могут обращаться к внешним сервисам через фаэрвол или/и NAT-устройство (либо через прокси-сервер, но в этом случае DNS уже не используется внутренними клиентами и это не тема этой статьи). Ситуация отражена на следующей схеме:

Проблема Split DNS

В чем заключается проблема при использовании Split DNS и когда она возникает? Проблема возникает, когда внутренний клиент обращается к внешнему сервису и не получает от внутреннего DNS ссылку на этот сервис или получает от внутреннего DNS ссылку на сервис иной, чем сервис с тем же именем, но который был бы доступен ему в случае обращения из внешней сети. Ситуация отражена на следующей схеме:

Проблемы в конфигурации со Split DNS.

Ситуация 1. На внутреннем DNS сервере нет записи Service1. Ни один внутренний пользователь не получит адрес внешнего сервиса. Следовательно, для всех внешних сервисов нужно обязательно создавать записи на внутреннем DNS сервере (в простейшем случае с тем же внешним адресом).

Ситуация 2. Запись Service1 есть на внутреннем и внешнем DNS серверах (область B). Secure DNS выключен. Любой пользователь корпоративной сети называет свой компьютер Service1, включает его в домен, компьютер регистрирует себя во внутреннем DNS. В результате внутренние пользователи будут получать адрес этого компьютера, а не внешнего сервиса.

Ситуация 3. Запись Service1 есть на внутреннем и внешнем DNS серверах (область B). Secure DNS выключен. К корпоративной сети подключается некое устройство с именем Service1 (например, принт-сервер), которое получает от DHCP сервера адрес и отправляет DHCP серверу запрос на регистрацию своего адреса в DNS. DHCP сервер от своего имени регистрирует устройство во внутреннем DNS сервере. Возникает проблема как в предыдущем случае.

Ситуация 4. Запись Service1 есть на внутреннем и внешнем DNS серверах (область B). Secure DNS включен и защищает DNS записи от перезаписи невладельцем. В домене нет учетной записи Service1 (но может быть DNS имя для нужд SPN). Пользователь с административными правами видит, что такой учётной записи нет и включает сервер с именем Service1 в домен. После этого он обнаруживает, что его сервер пингуется неправильно и удаляет «мусор» из внутреннего DNS сервера. Всё – проблема создана.

Что можно сделать для защиты от проблем со Split DNS?

1. Всегда используйте Secure DNS для защиты записей от неавторизованного изменения.

2. Для защиты особо важных DNS записей используйте технику pin-point: вместо создания записи типа A создавайте одноименную запись типа NS — поддомен. В этом случае, ограничив административные права на управление DNS сервисом, можно исключить несанкционированное изменение важных записей практически полностью.

3. Всегда создавайте фиктивные учетные записи компьютеров в Active Directory для сервисов из областей B и C выше приведенной схемы. Защищайте такие учетные записи компьютеров от удаления и перезаписи с помощью выставления прав ACL, оставив пользователям, включая доменных администраторов, права только на чтение (полные права, например, только у Enterprise Admins).

4. Настройте мониторинг изменений важных DNS записей либо с помощью системы мониторинга (SCOM), либо, в простейшем случае, скриптом, который будет проверять как наличие записей, так и правильность ответа (адрес).

5. Регламентируйте внутренние процессы управления DNS серверами.

6. Автоматизируйте перенос изменений из внешнего DNS во внутренний.

Заключение

Как и любая технология Split DNS решает одни проблемы и создает другие. Постарайтесь хорошо вникнуть в работу Split DNS, и это поможет вам построить вашу ИТ инфраструктуру правильно и надежно.

Реклама