Кратко

  • RFC 3663 оценивал, что не нормализованное представление реляционного набора примерно из 20 миллионов объектов могло превратиться в более чем 115 миллионов объектов каталога LDAP.
  • Ссылки должны были сохранять связи и операционные границы, но клиенты обрабатывали их по-разному, иногда попадая в циклы. Эксперимент перешёл к нормализованному хранилищу с денормализованным представлением для клиента; при этом клиенту всё равно требовалось знать конкретную структуру каталога.

Сначала изменилась форма данных

Запись домена не существует отдельно от связанных с ней объектов. У домена может быть несколько контактов и серверов имён, а один сервер имён может обслуживать множество доменов. У регистра и регистратора также разные административные обязанности. Если каждую связь напрямую развернуть в дереве каталога, общие контакты и серверы начнут повторяться в разных ветвях.

Опубликованная в декабре 2003 года RFC 3663 имеет статус Experimental и описывает запущенный VeriSign сервис Referral LDAP. Это была проверка того, можно ли применять LDAP и распространённые типы LDAP для поиска административных сведений о доменах. Оценка проектировщиков была заметной: около 20 миллионов реляционных объектов могли дать более 115 миллионов объектов в предложенном ненормализованном дереве информации каталога (DIT). RFC приводит это как оценку при выборе архитектуры, а не как результат развертывания системы такого масштаба. Структура каталога стала вопросом хранения и эксплуатации, а не только соглашением об именах. RFC 3663

У эксперимента была более ранняя предыстория. Первоначальный контракт InterNIC предусматривал каталог X.500 для административных данных доменов. Из-за сложностей с доступными серверными реализациями временно появился сервис NICNAME/WHOIS. Позднее RWhois попытался расширить этот подход, но, по словам RFC 3663, не получил широкого применения для доменных данных. Цель Referral LDAP была уже: дать структурированные запросы и результаты, удобные для машинной обработки, и направлять запрос от данных регистра к нужному регистратору на фоне разделения их функций. RFC 954 RFC 2167 RFC 3663

Ссылки переместили сложность

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

Первые тесты с ldapsearch выявили, что клиенты по-разному трактовали ссылки и управляли их обработкой; некоторые легко попадали в циклы. Итогом стало специальное серверное хранилище: данные оставались нормализованными, а клиент получал денормализованное представление без внутренних межсерверных ссылок. RFC предполагает, что большой набор данных, скорее всего, потребовал бы такого специального backend, а небольшой мог бы работать на готовом серверном ПО. Граф связей не исчез — изменился компонент, который собирал его в нужную клиенту форму. RFC 3663

Межсерверные ссылки решали другую задачу: отражали разделение между регистром и регистратором, которые могли работать в разных организациях, сетях и на разных машинах. Но такие ссылки могли попасть в выдачу, даже если не соответствовали фильтру поиска, и заполнить обычный лимит в 50 записей. Вместо нужных данных пользователь мог получить список дальнейших адресов. RFC описывает это как проблему распределения запросов, а не как доказательство общего дефекта LDAP. RFC 3663 RFC 2251

Общий протокол не создал универсальный клиент

LDAP давал общий способ доступа, но графическим клиентам требовалось знать DIT и схему именно этого сервиса. Нельзя было без изменений подключить их к другому LDAP-каталогу и ожидать, что они полноценно используют его данные. Универсальный клиент, скрывающий все различия структуры, либо показывал бы меньше сведений, либо становился бы слишком сложным для обычного пользователя. Повторно использовать протокол было проще, чем модель данных, на которую опиралось приложение. RFC 3663

Проблема проявилась и в интерфейсе. RFC сообщает, что некоторые пользователи считали веб-клиент единственным способом доступа к данным и не понимали роль LDAP или связи между регистром, регистратором и регистрантом. Библиотеки C и Java умели выполнять вложенные запросы и сложную обработку ссылок, но многие трудности были связаны с удобством работы. В документе также признаётся, что популярность клиентов нельзя было точно измерить. Это наблюдения пилотного проекта, а не репрезентативный опрос пользователей. RFC 3663

Структурированный формат не устранял стоимость запросов и опасения по поводу сбора данных. Любой LDAP-запрос мог оказаться слишком дорогим для публичного сервиса, поэтому эксперимент разрешал лишь ограниченный набор поисковых операций. Пользователи всё равно спрашивали о рекурсивных словарных запросах для обхода ограничений; многие операторы WHOIS считали это сбором данных. Раздел безопасности прямо предупреждает: показанная в эксперименте проверка по отличительному имени и паролю не подходит как модель для промышленного сервиса. RFC 3663 RFC 2026

Вопрос был в том, кто выполнит преобразование

Историческая ценность RFC 3663 — в откровенном описании компромиссов. Общая технология каталогов сама по себе не давала переносимого опыта для пользователей. Нормализация ограничила дублирование объектов, но потребовала специального backend, который восстанавливал нужное клиентам представление. Ссылки сохраняли границы между операторами, но делали успешность поиска зависимой от клиентского ПО и правил каждого уровня.

RFC отмечала, что поиск начинался на уровне регистра даже тогда, когда он относился к конкретному регистратору или регистранту. Обнаружение через DNS SRV или NAPTR не было реализовано. Ограниченным был и опрос LDAP-серверов: использовались файлы зон .com, .net, .org и .edu, проверялись порт 389 у доменных имён и узлов ldap либо dir, но поиск SRV-записей не выполнялся. Оценку примерно в 0,5% активных доменов с LDAP-сервером можно относить только к этой выборке и методике, но не ко всему Интернету или нынешнему состоянию. RFC 3663

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

Источники