Откройте терминал и выполните cat /etc/hosts. Скорее всего, там лежит пара строк про localhost и, может быть, несколько ваших локальных записей… А когда‑то этот файл содержал адреса всех компьютеров интернета и обновлялся по телефонному звонку. Под катом расскажу, как весь интернет работал через один текстовый файл, кто его обновлял и куда он в итоге делся. 

В 1985 году, чтобы подключить машину к сети, администратор строго в рабочие часы звонил в Калифорнию по номеру 800–235-3155 и диктовал имя хоста человеку на том конце провода. Через пару дней имя появлялось в новой версии главного файла интернета, который назывался hosts.txt…

Телефонная книга на весь интернет

В 1972 году американская исследовательница Элизабет Фейнлер присоединилась к команде Network Information Center в Стэнфордском исследовательском институте (признан нежелательным в РФ). К 1974 году она стала главным исследователем проекта и фактически возглавила NIC. Там была справочная служба, репозиторий документов и, что важнее всего, hosts.txt — единственный список всех машин в сети.

Если кто‑то заводил новую машину, то он должен был позвонить в NIC или написать на почту HOSTMASTER@SRI‑NIC.ARPA. После администраторы со всей сети заходили по FTP на хост SRI‑NIC, забирали NETINFO:HOSTS.TXT и раскладывали его по своим системам. Здесь были и адреса, и синонимы имени, и модель машины, и ОС, и поддерживаемые протоколы. Этакий паспорт хоста получался.

Кстати, NIC вёл и отдельную базу данных с контактами пользователей и администраторов. Доступ к ней предоставлял сервис NICNAME, который позднее стал известен как WHOIS.

Пока сеть была маленькая, схема работала идеально, но, к сожалению, у hosts.txt не было запасного варианта развития.

Файл, треснувший по швам

В мае 1982 года в таблице насчитывалось около 235 хостов, в августе 1983 года — 562, а к концу 1987 года число хостов уже превысило 28 тысяч. За пять лет порядок цифр изменился более чем в сто раз, а механизм учёта по‑прежнему опирался на централизованную таблицу…

1 января 1983 года, когда ARPANET перешла с протокола NCP на TCP/IP, сеть перестала быть клубом больших машин и начала заполняться персональными рабочими станциями. И тут с hosts.txt начались проблемы: 

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

• Во‑вторых, копия файла устаревала в ту же секунду, когда её скачивали. Организации уже сами администрировали свои локальные сети, но чтобы переезд машины увидел весь интернет, нужно было ждать, пока NIC внесёт правку и соберёт новую версию.

• В‑третьих, пространство имён оставалось плоским — каждому хосту требовалось уникальное имя во всей сети, а проверять эту «уникальность» приходилось централизованно. Чем больше становилась сеть, тем сложнее было придумывать имена, разбирать конфликты и поддерживать единый реестр. 

• Наконец, весь учёт имён мировой сети держался на одном офисе с одним телефоном. NIC также закрывались на праздники, например, есть информация, что сотрудники уходили на новогодние каникулы. То есть иногда интернет жил без техподдержки по именам. Отдыхать же нужно всем…

Ирония в том, что схему убил рост, то есть ровно то, ради чего сеть и строили.

Мокапетрис и идея масштабирования

К 1982 году внутри тогдашнего интернет‑сообщества уже было понятно, что файл долго не протянет. Первые наброски будущей системы появились в RFC 819 от августа 1982 года, где Зоу‑Синг Су и Джон Постел предложили доменное соглашение об именах с точкой как разделителем уровней. 

В октябре того же года вышел RFC 830 с идеей распределённой службы имён. А в ноябре 1983 года Пол Мокапетрис из Института информационных наук при USC опубликовал RFC 882 и 883 — это был DNS (к слову, я специально добавляю ссылки на спецификации, чтобы вы смогли поглядеть, как они формировались). 

Теперь вместо одного файла «на всех» появилась иерархия — имена делятся точками на уровни, каждый уровень отвечает только за свой кусок и делегирует нижние уровни тем, кто ими владеет. Данные хранятся распределённо, а запросы кэшируются на время TTL, поэтому один и тот же ответ не нужно таскать через полмира по сто раз. 

Первый рабочий DNS‑сервер назывался JEEVES. Мокапетрис написал его в 1983–1984 годах под машины DEC с ОС TOPS-20, и крутился он как раз в USC‑ISI и в том самом SRI‑NIC. 

В октябре 1984 года Джон Постел и Джойс Рейнольдс выпустили RFC 920 со списком доменов верхнего уровня — в памятке были повторно изложены и уточнены требования к созданию домена. К слову, Постел тогда вообще был человеком, который в одиночку вёл реестр всех чисел интернета.

Почему порты стали «дверями» в сервер, и кто решил, что SSH будет 22 рассказывал тут. 

Через пару лет, в 1986 году, Крейг Партридж выпустил RFC 974, который закрепил маршрутизацию почты через MX‑записи DNS. 

Четыре аспиранта и BIND

В 1984 году в Беркли четыре аспиранта, Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Соннян Чжоу, на грант DARPA разработали DNS‑сервер для Unix — он получил имя BIND. В 1985 году программу начали распространять за пределами университета, а позднее BIND вошёл в состав 4.3BSD. 

С 1985 по 1987 год над BIND работал Кевин Данлоп, сотрудник DEC, командированный в исследовательскую группу Беркли. Он значительно переработал ранний код и помог превратить студенческий проект в пригодную для повседневной эксплуатации реализацию DNS. 

Калифорнийский университет в Беркли (тоже нежелательный в РФ) и стал первой организацией, которая перевела все свои машины исключительно на DNS. Случилось это весной 1985 года, а осенью на доменные адреса переключили почтовые шлюзы кампуса. С января 1986 года по февраль 1987 года кампус добавил 735 хостов за 250 рабочих дней, то есть в среднем по три новые машины в день. С такой скоростью никакой hosts.txt уже не поспевал бы даже в масштабе одного университета.

Потом BIND поддерживали Майк Карелс и Эйвинд Куре, а в 1988 году к проекту пришёл Пол Викси. Он основал Internet Software Consortium, и BIND стал их главным проектом на следующие тридцать лет. Параллельно с развитием DNS‑сервера происходила и эволюция спецификаций.

Переход, который занял годы

В отличие от перехода на TCP/IP, переход на DNS растянулся на годы. Первые тестовые корневые серверы заработали летом 1984 года, и это были три машины на TOPS-20 с JEEVES.

1 января 1985 года появилось первое доменное имя — nordu.net — оно обозначало сервер nic.nordu.net. А 15 марта 1985 года зарегистрировали первый в истории домен.com — symbolics.com. Компания Symbolics делала лисп‑машины, и, между прочим, на её софте рендерили сцены для «Звёздного пути III». Сама компания давно ушла с рынка, домен в 2009 году продали, и теперь там музей истории интернета (поглядите, прикольно). 

Рубежным стал 1987 год — 31 марта из hosts.txt удалили все имена старого, недоменного формата, а в ноябре вышли RFC 1034 и 1035, которые остаются действующими стандартами DNS по сей день. Тогда же, в ноябре 1987 года, вышел RFC 1031 с планом перевода MILNET на домены и пара новых руководств для администраторов (RFC 1032 и 1033).

Почему это было неизбежно, думаю, уже понятно. Против hosts.txt играла математика роста трафика и сама логика эпохи, ведь сеть стала распределённой, а её реестр имён остался централизованным…

Что с этого админу сегодня

Теперь практика, потому что наследие той эпохи у нас (и вас) под рукой каждый день. Компьютер спрашивает рекурсивный резолвер, тот идёт к корневому серверу, корень отвечает адресами серверов зоны верхнего уровня, те указывают на авторитетный сервер домена, и только он даёт адрес. Весь путь видно одной командой:

dig +trace example.com

Важно, команда сама выполняет итеративные запросы, начиная с корневой зоны, и показывает полученные делегирования. Поэтому результат может отличаться от обычного DNS‑запроса, который часто обслуживается из кэша. Подробнее об этом можно почитать в документации BIND. 

Корневых серверов тринадцать, от A до M. Цифра появилась из предела в 512 байт на UDP‑ответ в раннем DNS (больше адресов туда не влезало). Сегодня за этими тринадцатью именами стоят многочисленные физические инстансы, распределённые по миру с помощью anycast. Проверить, кто ваш резолвер и в каком порядке система резолвит имена, можно так:

cat /etc/resolv.conf

Если там указан адрес 127.0.0.53, система, скорее всего, использует локальный stub‑резолвер systemd‑resolved. Реальные DNS‑серверы в этом случае покажет команда:

resolvectl status

В свою очередь, файл /etc/hosts по‑прежнему полезен для локальных подмен. Например, можно проверить сайт на новом сервере до переключения DNS:

203.0.113.10 example.com www.example.com

После такой записи приложения, использующие системный механизм разрешения имён, будут открывать домен с указанного IP. Проверить результат можно так:

getent ahosts example.com

Для временной блокировки домена можно прописать:

0.0.0.0 example.com

0.0.0.0 www.example.com

:: example.com

:: www.example.com

Первые две строки блокируют разрешение через IPv4, последние две нужны для IPv6. Редактировать системный файл безопаснее через:

sudoedit /etc/hosts

В Docker аналогичную запись можно передать при запуске контейнера:

docker run --add-host=example.test:203.0.113.10 nginx 

В Kubernetes для этого в спецификации пода предусмотрено поле hostAliases:

spec:

  hostAliases:

    - ip: "203.0.113.10"

      hostnames:

        - "example.test"

        - "api.example.test"

Послесловие

Команда Фейнлер разошлась, телефон 800–235-3155 давно недоступен, а функции NIC перешли к ICANN. Но файл, который та команда вела, живёт в каждой операционке, да и формат из RFC 952 читается до сих пор… По мне, довольно показательная часть истории ИТ. 

А вы когда в последний раз правили /etc/hosts и для чего? Делитесь сценариями в комментариях.

© 2026 ООО «МТ ФИНАНС»