Summary

  • В техническом отчёте Беркли 1984 года BIND описан как служба имён для распределённых сред Unix; авторы не заявляли, что изобрели DNS или написали его первый сервер.
  • В 1987 году эксплуатационные документы указывали, что BIND поставлялся вместе с 4.3BSD. Два года спустя справочник по Интернету описывал его как встроенный сервис, заменивший поиск имён через /etc/hosts.
  • Изменение было практическим: спецификации задавали совместимое поведение, а поставка программы и локально обслуживаемые зоны позволяли администраторам публиковать имена собственных сетей.

Одной спецификации было недостаточно

Система имён может выглядеть изящно на бумаге и при этом не менять повседневную работу. Кто-то должен установить сервер, загрузить данные, поддерживать их актуальность и направить локальные программы к нужному резолверу. Вклад Беркли в раннюю историю DNS состоял в том, чтобы встроить эту работу в среду Unix.

В 1984 году Douglas Terry, Mark Painter, David Riggle и Songnian Zhou опубликовали технический отчёт о сервере Berkeley Internet Name Domain. В аннотации описан общий способ присваивать имена ресурсам в распределённых средах Unix, хранить и получать сведения, а также делить иерархическое пространство имён на домены, соответствующие административным организациям. Это проект программного обеспечения и эксплуатации, а не претензия на изобретение DNS. Paul Mockapetris ранее написал сервер Jeeves, работавший в USC-ISI и SRI-NIC; в позднейшей истории ISC эта разработка отделена от проекта Беркли.

Практический вопрос BIND заключался в том, как хост Unix может участвовать в системе, данные которой разделены между несколькими административными доменами. Решение объединяло сервер, локальные файлы и уже существующий путь разрешения имён на хосте. Администратор домена обслуживал записи своей части дерева; резолвер обращался к нужным серверам и кэшировал ответы. Распределение означало разделение данных и ответственности, а не необходимость для пользователя помнить, где находится каждый компьютер.

Работающая сеть меняла и документы

Последовательность событий важна. Первые описания DNS появились в RFC 882 и RFC 883 в 1983 году. К январю 1986 года RFC 973, подготовленный Paul Mockapetris, уже фиксировал изменения, эксплуатационные рекомендации, обнаруженные проблемы и недостатки действующей системы. В нём сказано, что широко используемые изменения следует считать частью спецификации. Значит, опыт реализаций и операторов возвращался в текст протокола по мере работы системы.

Пересмотренные документы RFC 1034 и RFC 1035 вышли в ноябре 1987 года. В них описаны концепции DNS и детали реализации. Для совместимости требовались общие правила имён, записей, запросов, кэширования и делегирования. Но RFC нельзя было установить на машину как программу. Нужны были и работающий код, и эксплуатационные инструкции.

Отчёт Беркли 1984 года описывает BIND как службу для распределённых ресурсов Unix. В истории BIND, опубликованной ISC, названа первоначальная команда и сказано, что Computer Systems Research Group сопровождала программу вплоть до версии 4.8.3. Эта ретроспектива показывает линию разработки, но не число установок каждой версии.

Поставка вместе с BSD сделала сервис доступным администраторам

Современное событиям свидетельство содержится в RFC 1033, руководстве по эксплуатации доменов, выпущенном в ноябре 1987 года. Приложение прямо озаглавлено «BIND, распространяемый с 4.3 BSD UNIX». В нём объясняются загрузочные и кэш-файлы BIND, включая named.boot, и приводятся примеры зон. Документ не утверждает, что каждая система BSD запускала сервер имён. Он показывает, что администратор мог получить BIND вместе с привычным дистрибутивом Unix и найти инструкцию по настройке.

Такой способ поставки снижал цену эксперимента. Администратору не требовалось сначала писать сервер DNS, чтобы создать домен. Он мог запустить программу с конфигурационным файлом, загрузить зону, отвечать на локальные запросы и обращаться к другим серверам, когда имя находилось вне его зоны ответственности. При этом записи нужно было поддерживать в точном состоянии, делегирование — согласовывать с родительским доменом, а обновления — контролировать. BIND предоставлял работающий инструмент, но не гарантировал правильность данных.

Самое конкретное описание появилось через два года в RFC 1118. Ed Krol писал, что BIND встроен в 4.3BSD, используется для поиска и хранения имён хостов, адресов, почтовых агентов и других сведений и заменяет поиск через /etc/hosts. Пример Иллинойсского университета в Урбане-Шампейне показывает разницу в масштабе: в таблице хостов, которую распространяла SRI, находились лишь несколько машин, тогда как большинство имён университетского домена хранилось в локальных таблицах BIND. Эти имена оставались доступны другим хостам с BIND или любым резолвером DNS.

Речь шла не о выборе между одной базой данных и полным отсутствием координации. SRI продолжала распространять таблицу хостов; DNS добавил способ вести более крупное локальное пространство имён и публиковать его по общим правилам запросов. RFC 1118 также отмечает, что BIND мог предоставлять сведения о маршрутизации почты для внутренних хостов, недоступных напрямую по IP, включая машины, подключённые через UUCP. Имя услуги могло оставаться прежним, даже если менялось физическое или сетевое расположение хоста.

Что стало локальным, а что осталось общим

Граница эксплуатации была конкретнее, чем иногда подразумевает слово «распределённый». Беркли и последующие сопровождающие распространяли программу. Документы протокола задавали общие правила поведения. Администраторы доменов контролировали записи своей части дерева. Резолверы и серверы обрабатывали запросы. Ни один из этих уровней не заменял остальные. Устаревшая зона могла последовательно отдавать неверный ответ; несогласованное делегирование могло нарушить разрешение имени даже при исправной работе BIND.

Позднейший акцент Heng Lu на работающем коде здесь полезен как аналитический вопрос, но не как утверждение о намерениях авторов BIND: что именно получил администратор и что ему пришлось делать? Источники показывают путь от проектного отчёта через изменения, вызванные практикой, к программе в составе 4.3BSD и локально поддерживаемым именам. Публикация документа имела значение, но сама по себе не заполняла зону университета и не отвечала на запросы его пользователей.

У этих источников есть пределы. RFC 1033 подтверждает распространение с 4.3BSD, а RFC 1118 описывает интеграцию и пример одного университета. Они не доказывают повсеместную установку, единственную причину распространения DNS или исчезновение всех файлов с перечнями хостов. Убедительный исторический вывод уже: BIND помог превратить DNS в службу Unix, которую администратор мог эксплуатировать. Каждый домен получил возможность обслуживать свою часть, сохраняя совместимость с остальным деревом имён.

Источники