Кратко

  • RFC 3088 извлекал домен из подходящей последовательности компонентов DC, запрашивал SRV для _ldap._tcp и возвращал построенные LDAP URL как ссылки-перенаправления.
  • Корневая служба помогала начать или продолжить поиск, но не была всемирной базой каталога: документ советовал сначала обращаться к локальной службе.

Первый ответ в распределённом поиске иногда означает только «дальше спросите здесь». В апреле 2001 года проект OpenLDAP описал экспериментальную корневую службу, которая помогала находить LDAP-серверы для имён, основанных на DNS-доменах. Она не собирала записи людей и организаций в единую корневую базу.

Поиск начинался с Distinguished Name (DN). RFC 2247 описывал доменные компоненты DC; RFC 3088 задавал правила извлечения DNS-имени из DN. Алгоритм обходил RDN слева направо и накапливал подходящие одиночные компоненты DC. Если последовательность прерывалась компонентом другого типа, накопление сбрасывалось. Поэтому результат зависел от формы конкретного DN — нельзя было просто отбросить начальный UID и считать остаток доменом.

Для example.net служба запрашивала _ldap._tcp.example.net. Ответы DNS SRV могли указывать цели и порты. OpenLDAP строил для каждой цели LDAP URL и отдавал эти адреса в referral. Важная деталь реализации: URLs возвращались в порядке резолвера; сама служба не применяла приоритеты и веса SRV из RFC 2782. Наличие этих полей в DNS не доказывает, что приложение ими руководствовалось.

После referral поиск не завершался. Клиент или промежуточный сервер должен был перейти по URL, а целевой LDAP-сервер — выполнить операцию. Корневая служба не объединяла ответы разных серверов и не подтверждала существование записи. Её ответ обозначал возможный следующий узел, но не доказывал актуальность, полноту или достоверность конечных данных.

RFC 3088 настаивал на локальном начале поиска. LDAP-серверы могли настроить переадресацию вышестоящих запросов на OpenLDAP Root Service; прямой доступ клиента допускался, но не рекомендовался. Клиенту следовало использовать местную службу и обращаться к корню только по полученному referral. DNS снижал стоимость стыковки разрозненных каталогов, не превращая одну точку в обязательное хранилище для всех запросов.

Документ прямо относил механику к экспериментальной и незавершённой. Описанная служба поддерживала LDAPv3 и LDAPv2+ поверх TCP/IPv4; LDAPv2 не умел передавать referrals. Служба принимала анонимное bind-соединение, отклоняла другие варианты и не обеспечивала шифрование или целостность информации. RFC отмечал риски DNS spoofing и отказа в обслуживании и предупреждал: защита LDAP-сеанса не проверяет DNS-данные, из которых была построена ссылка.

В разделе об опыте автор сообщил, что служба работала на одном хосте и, по его оценке, при росте нагрузки её можно было бы масштабировать обычной балансировкой. Это ограниченное заявление о той экспериментальной инсталляции, а не независимый тест ёмкости, гарантия доступности или оценка широкого внедрения.

Источники