Кратко

  • RFC 1101 предложил связывать имена сетей, номера и вложенные подсети через PTR у имён IN-ADDR.ARPA с нулевой хостовой частью; если следующий уровень существовал, запись A несла маску для продолжения поиска.
  • Документ отделял локально выбранное имя от записи номеров, выделенных NIC. Ответ DNS описывал ограниченную связь: он не выделял номер, не отслеживал автоматически последующее переименование и не подтверждал текущий контроль или результат работы сервиса.

То, чего DNS ещё не получила от HOSTS.TXT

P. Mockapetris начинает RFC 1101 с очень конкретного пробела. DNS была расширяемой и уже перенесла в распределённую форму многие функции HOSTS.TXT, но преобразование между именем сети и номером сети оставалось за её пределами. Меморандум апреля 1989 года предлагает для этого частный метод, а отдельно — экспериментальные идеи более общих указателей «Yellow Pages» между идентификаторами и числами. Разница статуса существенна: метод для сетевых имён был Proposed Standard, общие YP — экспериментом. Речь не шла о том, чтобы каждое число обрело единый человеческий смысл; администратору давали возможность опубликовать выбранную метку рядом с числом в пределах ясно очерченной ответственности.

Диагностический экран мог показать не только непрозрачную последовательность цифр, но и понятное имя. Это не делало метку актом выделения номера и не доказывало, кто эксплуатирует сеть, какой маршрут выберет пакет или какой сервис ответит. Карта полезна именно потому, что не выдаёт себя за ответ на эти другие вопросы.

Имя оставалось рядом с тем, кто его поддерживает

За синтаксисом стоял вопрос управления. Прежнее плоское пространство сетевых имён естественно тяготело к центральному регулированию, подобному регулированию номеров. RFC 1101 фиксирует другое мнение большинства: локальный контроль имён сетей. Поэтому документ использует расширенный синтаксис имён узлов и позволяет администратору создавать имя сети в домене, который он контролирует. Цена названа прямо: сетевые имена станут столь же сложны, как имена узлов. Выигрыш — контекст и обязанность поддерживать метку остаются у того, кто этот контекст знает. ARPANET.ARPA. в тексте — исторический пример такого выбора, а не вечное определение ресурса и не передача права на номер.

Для движения от IP-адреса в обратную сторону требовалась другая точка входа. Локальное имя само не говорит, какой домен следует спрашивать. RFC поэтому использует уже делегированное по адресам дерево IN-ADDR.ARPA. Существующее распределение ответственности могло хранить и обратное описание, без сооружения второй мировой иерархии ради столь узкого факта.

Нулевой хост был карточкой, а не машиной

Предложенная форма имела вид <перевёрнутый-номер-с-нулевым-хостом>.IN-ADDR.ARPA. PTR <имя-сети>. У имени сети размещался обратный PTR. Если сеть делилась дальше, в той же записи с нулевым хостом находилась запись A, содержащая маску подсети. 0.0.0.10.IN-ADDR.ARPA. и 0.0.2.128.IN-ADDR.ARPA. — напечатанные в RFC учебные примеры формы, а не утверждения о современном состоянии.

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

Запись A здесь тоже надо читать в её узкой роли. В данном предложении она несёт маску, когда есть следующий уровень подсети. По тогдашней процедуре классов A/B/C адрес IP маскируется, октеты меняются местами и запрашивается PTR. Если ответ содержит A-маску, она применяется к исходному IP и поиск повторяется; если A нет, вложение заканчивается. Это исторический алгоритм чтения, а не свидетельство текущей топологии, маршрута или достижимости.

Три направления не создают единую власть

RFC 1101 допускал и PTR от имени организации к одной или нескольким сетевым записям с нулевым хостом. Так получались три направления: имя сети к числоподобной записи, числоподобная запись к выбранному имени и имя организации к нескольким сетевым записям. Каждая стрелка полезна именно как ответ на отдельный ограниченный вопрос. Связь, опубликованная в домене, — факт о публикации. Сетевое имя — факт о выборе именования. Ответ — факт о запросе, алгоритме и времени.

Ни один из них, по отдельности или в простом сложении без новых доказательств, не подтверждает нынешнюю собственность, корпоративную связь, физическое владение, разрешение, BGP-маршрут, получение пакета или успех приложения. В документе признаётся и практическое напряжение: централизованные таблицы могли быть более согласованными, распределённые данные — более своевременными и поддерживаемыми. Формат записи не отменяет работу по сохранению корректности фактов; он показывает происхождение, ответственность и предел утверждения.

Выделенный номер не предписывал последующее имя

Раздел YP формулирует границу особенно ясно. RFC представлял доменные деревья для пар вроде мнемоники порта и номера порта, идентификатора автономной системы и номера, имени выделенной сети и IP-адреса. Ключ должен был указывать исходный и целевой тип: число без контекста ещё не имеет смысла сопоставления.

NIC мог поддерживать YP-домены, фиксирующие его собственные решения о выделении. Но RFC оговаривает: такие домены сопоставляли бы выделенные имена и номера, а не имена, которые организации выбирают впоследствии. Они не отслеживали бы автоматически переименование новыми владельцами. История выделения и локальное именование намеренно были разными фактами.

Центральный список может быть сильным доказательством собственного решения центра. Локальная зона может быть сильным доказательством опубликованной ею метки. Но ни то ни другое не сокращает путь к выводу о нынешнем операторе, доступном сервисе, политике маршрута или результате транзакции. Реестр описывает реальность в своей границе; он не создаёт остальные факты, которые читателю хотелось бы вывести.

Читать документ в его историческом масштабе

RFC 1101 — свидетельство предложения 1989 года. Его классовая процедура, YP-домены и примеры не являются сами по себе описанием современного развёртывания DNS. Но дисциплина остаётся полезной: у сопоставления должны быть происхождение, направление и область действия; запись не должна нести решения, которых в ней нет. Опубликованное имя, выделенный номер, наблюдённый маршрут и доказанный результат — разные утверждения.

Источники и граница доказательств

В анализе используются RFC 1101, RFC 1034 и RFC 1035. Они подтверждают предложение 1989 года, формы записей и различие между выделенным и локальным именем; они не подтверждают текущие данные DNS, контроль, идентичность, собственность, маршрут, достижимость, полномочие или производительность сервиса.