Записи DNS для LDAP: какие нужны и как их настроить

Базовый набор зависит от архитектуры каталога. Для обычного LDAP-сервера обычно создают запись A для IPv4 или AAAA для IPv6, например имя узла каталога внутри корпоративной зоны. Эта запись связывает доменное имя с адресом сервера и используется клиентами при подключении к портам 389 или 636.

Для автоматического обнаружения службы применяются записи SRV. Наиболее распространенный формат имени — _ldap._tcp.example. Для защищенного подключения используется _ldaps._tcp.example. В имени записи указываются протокол, транспорт и доменная область поиска. Поля SRV включают приоритет, вес, порт и целевой хост.

• Приоритет определяет порядок выбора серверов: меньшее значение имеет преимущество.
• Вес распределяет запросы между серверами с одинаковым приоритетом.
• Порт обычно равен 389 для LDAP и 636 для LDAPS.
• Цель должна указывать на полное имя хоста, для которого существует A или AAAA.

Запись CNAME допустима для удобного пользовательского имени, но в качестве цели SRV рекомендуется использовать каноническое имя сервера. Прямая ссылка SRV на IP-адрес недействительна: поле цели должно быть именем, а не числовым адресом.

Предположим, что каталог обслуживается узлами ldap01 и ldap02 в домене corp.example. Для каждого узла создаются адресные записи A или AAAA. Затем в DNS публикуются записи служб:

• _ldap._tcp.corp.example указывает на порт 389 и узлы ldap01.corp.example и ldap02.corp.example;
• _ldaps._tcp.corp.example указывает на порт 636, если клиенты поддерживают поиск защищенной службы через SRV;
• _gc._tcp.corp.example может использоваться в средах Active Directory для поиска глобального каталога;
• _kerberos._tcp.corp.example и связанные записи нужны Active Directory для взаимодействия с Kerberos.

Для двух LDAP-серверов можно назначить одинаковый приоритет, например 10, и разные значения веса. Это позволяет распределять новые подключения, но не гарантирует равномерную балансировку: конкретное поведение зависит от DNS-резолвера и LDAP-клиента. Если один узел должен быть основным, ему назначают меньший приоритет, например 10, а резервному — 20.

Важна конечная точка записи SRV. Для имени с точкой в конце DNS-сервер воспринимает значение как полное доменное имя. Без завершающей точки некоторые панели управления могут автоматически добавить имя текущей зоны и сформировать неправильный адрес.

В Active Directory записи DNS создаются и обновляются контроллерами домена через динамическую регистрацию. Поэтому удаление или ручное изменение служебных записей может нарушить обнаружение контроллеров, репликацию и вход пользователей. В типичной конфигурации DNS-зона домена интегрирована с каталогом, а разрешение динамических обновлений ограничено доверенными узлами.

Клиентам Active Directory недостаточно одной записи A. Они ищут контроллеры по специальным SRV-записям, включая записи LDAP для конкретного сайта и общие записи домена. Если DNS-сервер клиента указывает только на публичный резолвер или на сервер, не обслуживающий внутреннюю зону, контроллер домена может быть недоступен даже при исправном сетевом соединении.

Для LDAPS имя, указанное клиентом, должно соответствовать имени в сертификате сервера. Если клиент подключается к ldap.corp.example, это имя должно присутствовать в Subject Alternative Name сертификата. Наличие записи CNAME не устраняет требование к сертификату: фактическое имя, используемое в соединении, также должно быть разрешено и учтено в сертификате.

Начинайте проверку с DNS-разрешения имени узла и SRV-запроса. На Linux и macOS для этого применяют системные средства поиска DNS, а в Windows — команду проверки записей SRV. В результате нужно убедиться, что возвращается правильное имя хоста, порт, приоритет и вес. Затем отдельно проверьте, что целевое имя имеет запись A или AAAA и что адрес доступен с клиентского компьютера.

Частая ошибка — размещение записи _ldap._tcp не в той зоне. Если клиент ищет службу для corp.example, запись должна находиться именно в этой DNS-области или в соответствующей делегированной зоне. Другая проблема — перепутанные значения порта: LDAP на 389 обычно работает без шифрования или с переходом на TLS, а LDAPS на 636 устанавливает TLS сразу после подключения.

Если SRV-запись корректна, но соединение не устанавливается, проверьте межсетевой экран, маршрутизацию, прослушивание порта и настройки самого каталога. Для LDAPS дополнительно проверяются цепочка доверия, срок действия сертификата, имя узла и поддерживаемые версии TLS. При наличии нескольких DNS-серверов убедитесь, что зона синхронизирована между ними и разные резолверы возвращают одинаковые данные.

Размещайте LDAP-серверы в отказоустойчивой схеме и публикуйте несколько целевых узлов в SRV. Уменьшайте TTL только на время миграции или изменения адресов: слишком короткий TTL увеличивает нагрузку на DNS, а слишком длинный замедляет распространение исправлений. После изменения записей учитывайте кэширование на клиенте и промежуточных DNS-серверах.

Разделяйте внутренние и внешние зоны. Служебные записи LDAP, адреса контроллеров домена и сведения о внутренней структуре каталога не должны публиковаться в общедоступном DNS без обоснованной необходимости. Ограничивайте динамические обновления и регулярно контролируйте появление устаревших записей.

Документируйте назначение каждой SRV-записи, используемый порт, приоритет и владельца зоны. При замене сервера сначала добавьте новый узел и проверьте его доступность, затем измените приоритет или удалите старую цель после истечения согласованного периода кэширования.