Кратко

  • RFC 2167 привязывал иерархические метки к областям полномочий: запрос мог получить направление к родителю или к более узкой дочерней области.
  • Объект howard.md.us, помещённый в область va.us, физически хранится в базе, но не обнаруживается через предусмотренное дерево RWhois.

Есть существенная разница между работающим сервером и сервером, уполномоченным отвечать на конкретный вопрос. Если область va.us получает запрос о howard.md.us, RFC 2167 требует направить клиента выше — к us либо к корню. Ответ «здесь нет» был бы притязанием на знание вне своей области. Переадресация честно отмечает предел компетенции, но сама не подтверждает существование записи.

Затем авторы документа предлагают почти канцелярскую ошибку: положить запись о howard.md.us в базу va.us. Она не утрачена как последовательность байтов. Однако путь, построенный из имени, ведёт по другой ветви. Спецификация называет такой объект ошибочно размещённым и недоступным для обнаружения в дереве. Размещение в области уровнем выше, менее точной, иногда ещё позволяет его найти. Поэтому важно проверять не только факт отклонения от самой узкой области, но и то, пересекается ли место хранения с маршрутом поиска.

Версия 1.5 Referral Whois, опубликованная в июне 1997 года, отвечала на трудность поддержания единой центральной базы Whois. Доменное имя и сеть в записи CIDR содержат иерархию, которую можно извлечь из обозначения; имя человека без дополнительных сведений не содержит такого адреса в дереве. Область полномочий связывает метку с серверной базой. Родитель знает о дочерних областях, а дочерняя область может указать путь назад. Система находила предполагаемого хранителя, а не проводила независимую проверку его утверждений.

Переход к родителю документ называет punt, к потомку — link. Указатель содержит имя или адрес сервера, порт и область. Следующий сервер может вернуть объект, ошибку либо новые указатели. Клиент вправе обрабатывать несколько направлений в разном порядке. Для неиерархического поиска предусмотрен отдельный индексный сервер. Такая гибкость полезна, но делает бессмысленным вывод «получен указатель — значит, получен достоверный ответ». Даже отрицательный результат следует читать вместе с пройденными областями и правилами размещения.

У каждой области могла быть своя схема классов и атрибутов. Общие базовые поля рекомендовались для совместимости, но схема дочерней области не обязана была полностью копировать родительскую. Указатель связывал название области и URL сервера RWhois; он не удостоверял содержание контактной записи. Совпадение названий полей также не превращало различные местные базы в единый источник подтверждённой личности.

Регистрация данных в области закреплялась ровно за одним главным сервером. Подчинённые серверы получали копии и могли отвечать от имени области, но не регистрировать данные. Полная и инкрементальная репликация использовала номер серии SOA, интервалы обновления и повторной попытки; копироваться могли лишь отдельные классы и атрибуты. Ответ «от области» не означает, что копия свежа в любую секунду или что записанное право действительно. Объекты guardian задавали условия изменения или закрытого просмотра, включая методы с паролем и PGP. Допуск редактора к записи не удостоверяет факты, внесённые им.

RFC 2167 имеет статус Informational и прямо не претендует на установление стандарта интернета. Это свидетельство об описанном механизме, не статистика его внедрения и не наблюдение за нынешними WHOIS или RDAP. Исторический пример полезен как проверка собственной уверенности: маршрут, правильное место хранения, право изменять запись, состояние копии и доказательство реального обстоятельства требуют разных оснований.

Источники и пределы вывода

Основной текст — RFC 2167, разделы 2 и 4; статус подтверждает карточка RFC Editor. RFC 1714 — заменённая предшествующая версия, RFC 954 — ранний контекст централизованного Whois. Они не подтверждают конкретную потерянную запись, личность, правомочие или успешную доставку ответа.