Знаете эту любимую загадку на айтишных собеседованиях: что происходит после того, как вы набрали адрес сайта и нажали Enter?

Правильный ответ должен занять оставшиеся сорок минут интервью. Браузер разбирает URL, ищет адрес сервера, устанавливает соединение, договаривается о шифровании, отправляет HTTP-запрос. Кандидат рисует на бумаге стрелочки, интервьюер сурово кивает, оба стараются не вспоминать, что вакансия вообще-то на фронтенд.

Ну так вот. Мы набрали URL, нажали Enter, а браузер показывает фигвам: «Не удаётся найти IP-адрес сервера».

Сервер работает и готов принимать запросы. Интернет подключён. Кабель целый. Пакет мог бы добраться до него через полмира, если бы кто-нибудь объяснил пакету, куда именно лететь.

Представьте город, в котором за одну ночь исчезли все адреса. Дома остались на месте, дороги никуда не делись, почтальоны вышли на работу. Пропали только таблички с названиями улиц и справочник, связывающий знакомые имена с точками на карте. Формально город работает. Практически заказанную пиццу курьер вам не привезет, если только он не знает заранее конкретную квартиру, где вы живете.

Люди запоминают www.linkmeup.ru, а компьютеры хотят числовой IP-адрес. Между ними работает огромная распределённая справочная — DNS. Мы замечаем её обычно в тот момент, когда она перестаёт отвечать или, что гораздо интереснее, уверенно называет неправильный адрес.

Меня зовут Иннокентий Солнцев, и это подкаст «До нас дошло». Сегодня мы узнаем, почему адреса всего раннего интернета помещались в один текстовый файл, как справочная служба научилась находить сайты, почтовые серверы и принтеры, и зачем интернет подписывает адреса криптографическими ключами.

Поговорим о системе, которая переводит человеческие имена в машинные маршруты.

В начале семидесятых проблема имён выглядела почти несерьёзно. В ARPANET было несколько десятков компьютеров, и каждый можно было записать в обычную таблицу: слева понятное человеку имя, справа числовой адрес.

Таблица называлась HOSTS.TXT. Хранилась её главная версия в Network Information Center, или NIC, при Стэнфордском исследовательском институте. Администраторы сообщали о новых машинах и изменениях, сотрудники NIC обновляли файл, а остальные участники сети регулярно скачивали свежую копию.

Современный интернет для этой задачи использует распределённую систему из миллионов серверов. Ранний интернет использовал текстовый файл и несколько очень ответственных людей.

Одной из них была Элизабет Фейнлер по прозвищу Джейк. Она руководила NIC и вместе с коллегами поддерживала справочную ранней сети: имена компьютеров, адреса, контакты пользователей, описания протоколов и другую информацию, без которой сеть быстро превращалась в набор дорогих машин, не знающих, как найти друг друга.

В каждой строке стояли две вещи: понятное человеку имя компьютера и его числовой сетевой адрес. Примерно как в записной книжке: «Вычислительный центр Калифорнийского университета — звонить по такому-то номеру».

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

Кстати, этот файл hosts никуда не исчез. Он до сих пор есть в Linux, macOS и Windows. Если записать туда, что linkmeup.ru живёт по определённому адресу, компьютер поверит локальному файлу раньше, чем спросит DNS. Внутри современной операционной системы сохранился маленький кусочек интернета семидесятых.

Для небольшой сети решение было почти идеальным. Файл легко читать человеку, легко обрабатывать программе и несложно обновлять, покуда компьютеров единицы. Загвоздка возникла, когда сеть начала расти.

Новая машина просила имя. Имя нужно было проверить, чтобы оно не совпало с существующим. Изменение попадало в центральную таблицу. Затем все остальные машины должны были скачать новую версию. Кто-то делал это вовремя, кто-то продолжал жить со старой.

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

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

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

К началу восьмидесятых авторы очередной спецификации официально признали: прежняя таблица больше не соответствует потребностям растущего интернета. Новый формат HOSTS.TXT пытался упорядочить имена узлов, сетей и шлюзов, но не менял главный принцип — справочник оставался централизованным файлом.

Интернет перерос свою записную книжку. Оставалось придумать справочную, в которой никто не знает всех адресов, но любой адрес всё-таки можно найти.

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

В 1983 году инженер Пол Мокапетрис предложил систему доменных имён, или ДНС. Единый справочник он заменил деревом, где каждая ветка отвечает только за собственный участок. Представьте обычный почтовый адрес. Страна, город, улица, дом, квартира. Почтальону в другой стране не требуется список всех квартир вашего города. Ему достаточно понять, в какую страну отправить письмо. Национальная почта направит его в нужный город, городская — на улицу, а местный почтальон разберётся с домом.

DNS устроен похожим образом, только адрес читается с конца. В доменном имени (скажем, `www.linkmeup.ru`) более широкая часть находится справа. Сначала идёт зона России — `.ru`. Внутри неё зарегистрирован домен `linkmeup`. Внутри домена может существовать отдельное имя `www`.

Над всем деревом находится **корень**. В записи доменного имени он обозначается точкой в самом конце, просто люди почти никогда её не пишут. Полное имя сайта технически заканчивается так: «подкаст, точка линкмиап, точка ру, и еще одна точка». Корневые серверы не знают адреса каждого сайта. Если спросить у корня, где находится `www.linkmeup.ru`, он ответит примерно так:

— Понятия не имею. За всё, что заканчивается на `.ru`, отвечают вот эти серверы. Спросите у них.

Серверы зоны `.ru` тоже могут не знать адрес нужного сайта. Их задача — сообщить, кто отвечает за домен `linkmeup.ru`.

— Сам сайт www.linkmeup.ru не знаю, но вот серверы зоны linkmeup.ru. Дальше разбирайтесь с ними.

Только **авторитетный сервер** домена даёт окончательный ответ. Он хранит записи, которыми распоряжается владелец зоны, и имеет право заявить: «Да, это имя находится по такому-то адресу».

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

Это называется **делегированием**. Владелец зоны `.ru` не управляет всеми серверами внутри `linkmeup.ru`. Он лишь подтверждает, кому переданы полномочия отвечать за этот домен. Примерно как государственный реестр сообщает, кому принадлежит здание, но не решает, как внутри пронумерованы кабинеты.

Здесь полезно различить домен и зону. Домен — это ветка дерева имён вместе со всем, что растёт ниже неё. Зона — участок, за который отвечает конкретный набор серверов. Владелец может отрезать часть ветки и передать её другому администратору.

Допустим, компания создаёт адрес для отдельного подразделения. Она может продолжать управлять им сама, а может сказать:

— Всё, что находится внутри этого имени, теперь обслуживают другие серверы. Все вопросы к ним.

DNS не требует одного главного администратора, который лично одобряет каждый принтер. Полномочия спускаются по дереву.

Ваш браузер, конечно, мог бы ходить по всем этим инстанциям самостоятельно, но чаще он обращается к специальному посреднику — **рекурсивному резолверу**. Обычно его предоставляет интернет-провайдер, корпоративная сеть или публичный DNS-сервис, и именно его вы прописываете, когда задаете настройки сети на машине вручную.

Ваш компьютер говорит этому посреднику:

— Найди мне адрес `www.linkmeup.ru`, и либо верни мне ответ, либо скажи что такого адреса точно нет.

Резолвер берёт работу на себя. Спрашивает корень, затем серверы `.ru`, затем авторитетный сервер домена и возвращает браузеру готовый ответ. Для приложения это один вопрос. Для резолвера — небольшой обход инстанций.

Сами серверы дерева чаще дают не полный ответ, а направление:

— Я сам не знаю, но вон там вам помогут лучше, чем я.

Такой обмен называется итеративным. Резолвер постепенно приближается к нужной ветке, пока наконец не встречает сервер, который отвечает за неё лично. То есть получается, что при рекурсивном запросе мы один раз спросили свой днс-сервер, и он нам вернул результат, а при итеративном - мы задали вопрос одному серверу, нам вернули не готовый ответ, а направление, потом задали вопрос другому, получили еще одно направление, и так шаг за шагом приближались к цели.

Вот эта распределённая справочная, где главный офис почти никогда не знает номер нужного абонента, но профессионально переводит звонок в правильное отделение, оказалась удивительно живучей. Базовую архитектуру DNS уточнили в 1987 году, хотя с тех пор DNS оброс десятками расширений, но структура, система делегирования и поиска ответа продолжают работать спустя почти сорок лет без изменений.

Интернет избавился от единой записной книжки. Вместо неё появилось дерево, в котором каждый отвечает за свою ветку, а любой адрес можно найти через цепочку рекомендаций.

Оставался следующий вопрос: что именно хранить в этой справочной? Одного IP-адреса интернету очень быстро стало мало.

Первой задачей DNS был поиск адреса. Вы называете компьютер, справочная возвращает число, пакеты отправляются в путь. Довольно скоро выяснилось, что интернет хочет задавать справочной гораздо больше вопросов.

Например: где находится почтовый сервер этого домена? Какое имя настоящее, а какое служит псевдонимом? Кто вообще имеет право отвечать за эту часть дерева?

Для разных вопросов появились разные типы DNS-записей. Самая простая, так называемая “тип А” связывает имя с обычным IP-адресом. Позже к ней добавили отдельную запись для длинных адресов IPv6. Поскольку адреса IPv6 длиннее чем IPv4 в четыре раза, то эти записи получили название “АААА”, или quad-A в англоязычной традиции.

Есть записи-псевдонимы. Они говорят: «Это имя само никуда не ведёт, настоящий адресат называется иначе». Компания может сменить сервер или передать сервис другому оператору, а знакомое пользователям имя продолжит работать.

Отдельная запись указывает, куда доставлять электронную почту. Когда сервер хочет отправить письмо пользователю домена, он не обязан писать на тот же компьютер, где расположен сайт. DNS отвечает: «Веб-сайт находится там, а письма принимают вот эти сервера. Сначала попробуйте первого, если он не ответит — второго».

Другой тип записи сообщает, какие серверы имеют право отвечать за целую зону. Именно через такие указатели работает делегирование из предыдущего блока: зона верхнего уровня не управляет вашими адресами, а называет тех, кому передала полномочия.

Все эти варианты были частью DNS уже в его ранней спецификации. Справочник изначально проектировали не как таблицу «имя — адрес», а как распределённую базу записей разных типов.

Особенно интересная судьба выпала записи **TXT**, то есть текст. Её оставили для произвольной информации, которую некуда больше положить.

Интернет воспринял это как предложение сложить туда всё.

Сегодня в текстовых записях подтверждают владение доменом, перечисляют серверы, которым разрешено отправлять от его имени почту, публикуют криптографические ключи и инструкции для борьбы с поддельными письмами. Поле называется текстовым, хотя читают его в основном программы.

Получился такой ящик с надписью “всякая хрень”. Сначала туда кладут запасные карандаши. Через несколько лет в нем лежат бухгалтерские счета, документы на квартиру и половина системы безопасности электронной почты.

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

Вы купили принтер, подключили его к Wi-Fi и не знаете ни его имени, ни адреса. Вводить настройки вручную не хочется. Требуется задать сети более общий вопрос:

— Здесь вообще есть принтеры?

Для таких случаев появился **многоадресный DNS**, или mDNS. Компьютер не идёт к глобальной иерархии серверов, а отправляет вопрос всем устройствам в локальной сети:

— Кто здесь принтер?

Принтер отвечает сам:

— Я здесь.

Отдельного DNS-сервера и администратора для этого не требуется. Устройства договариваются прямо внутри локальной сети, а их имена обычно заканчиваются на `.local`.

Одного имени всё равно мало. Компьютеру нужно понять, какую услугу предлагает устройство, куда подключаться и что оно умеет. Этим занимается **DNS Service Discovery**, или DNS-SD.

Работа происходит в несколько шагов. Сначала компьютер спрашивает, какие экземпляры нужной услуги есть поблизости. Сеть отвечает: например, «Принтер в кабинете» и «Принтер в коридоре».

Затем запись типа **SRV**, от слова service, сообщает имя машины и номер порта, куда нужно подключиться. Это уже не «у нас есть принтер», а «принтер принимает задания вот через эту дверь».

Рядом приходит текстовая запись с дополнительными параметрами. Поддерживает ли устройство цветную печать, умеет ли принимать PDF, где оно установлено. Наконец, обычная адресная запись переводит имя принтера в IP-адрес.

Вся беседа выглядит примерно так:

— У кого здесь есть принтер? — В кабинете у бухгалтеров. — Куда отправлять задание? — На эту машину, через такой-то порт. — Что она умеет? — Цветную печать и PDF. — Бумага есть? — Протокол не располагает этой информацией.

Набор технологий автоматического поиска устройств и услуг стал широко известен под названием **Bonjour**. Именно благодаря ему ноутбук может увидеть принтер, телефон — колонку, а музыкальное приложение — устройство воспроизведения без ручного ввода адресов.

Получилась альтернативная модель справочной. Глобальный DNS вежливо переводит вас между отделениями: корень, домен верхнего уровня, авторитетный сервер. Локальная сеть просто открывает дверь и кричит: «У кого здесь есть принтер?»

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

Телефонная книга интернета давно перестала хранить только телефоны. Теперь в ней записано, кто принимает почту, кто отвечает за домен, где стоит принтер и умеет ли он печатать в цвете.

Заправлять бумагу справочная по-прежнему отказывается.

У распределённой справочной нашёлся один недостаток. Чтобы открыть сайт, резолвер должен обратиться к корню, затем к серверам домена верхнего уровня, а после — к авторитетному серверу. Повторять эту экскурсию при каждом запросе чудовищно неэффективно.

Поэтому DNS умеет запоминать ответы.

Допустим, мы спросили у резолвера - где находится www.linkmeup.ru. Резолвер уже выяснил, где находится этот адрес, а заодно и `linkmeup.ru`, и .ru. Следующему пользователю он ответит из собственной памяти. Получается быстрее, а корневые и авторитетные серверы не приходится дёргать по каждому поводу. Если кто-то еще в этот момент поинтересуется каким-то еще адресом, например, yandex.ru, то наш сервер уже не пойдет на корень снова спрашивать, где находится сервера зоны .ru.

Вместе с адресом приходит срок годности ответа — **TTL**, Time to Live. Авторитетный сервер может сказать:

— Этот адрес действителен ещё час. До истечения часа можете меня не беспокоить.

Резолвер кладёт запись в кэш и запускает таймер. Каждый следующий запрос получает готовый ответ. Когда время заканчивается, старая запись удаляется, и резолвер снова идёт к авторитетному источнику.

И тут, конечно, кроется засада.

Представьте, что вы позвонили в справочную и узнали телефонный номер ресторана. Оператор добавляет: «Номер будет действителен еще как минимум месяц». Вы записываете его и весь вечер раздаёте друзьям, не отвлекая справочную повторными звонками.

А ресторан завтра переезжает. Владелец домена уже указал новый адрес. Авторитетный сервер честно раздаёт его всем, кто приходит впервые. Ваш резолвер никуда не идёт: у него есть старый ответ, срок которого ещё не истёк.

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

Поэтому перед переездом DNS-записи TTL обычно заранее уменьшают. Старые ответы быстрее исчезают из кэшей, и пользователей можно оперативно перевести на новый адрес.

Ключевое слово — «заранее». Если уменьшить TTL после состоявшегося переезда, резолвер спокойно ответит:

— Спасибо. Я подумаю об этом, когда истечёт срок старой записи.

Короткий TTL позволяет быстро менять адреса, зато заставляет резолверы чаще обращаться к авторитетным серверам. Длинный снижает нагрузку и ускоряет повторные запросы, но превращает любую опечатку в выдержанное решение с гарантированным сроком хранения.

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

Вы создаёте новое имя, проверяете его за секунду до публикации и получаете ответ: «Такого адресата нет». Через секунду запись появляется на авторитетном сервере, но ваш резолвер уже запомнил её отсутствие.

Справочная отвечает:

— Вы только что спрашивали. Такого абонента нет. — Теперь есть. — Очень рада за него. Перезвоните позднее.

Иногда резолверы хранят даже временную неудачу: авторитетный сервер не ответил, сеть оборвалась или поиск закончился ошибкой. Современные спецификации отдельно описывают кэширование таких сбоев, чтобы резолвер не повторял бесполезный запрос непрерывно и не усиливал уже начавшуюся аварию.

Встречается и обратный трюк. Например, если TTL у записи уже истёк, однако авторитетные серверы временно недоступны, то некоторые резолверы могут продолжить выдавать старый адрес: лучше слегка несвежий ответ, чем никакого. Такой режим называют **serve stale** — «отдать протухшее». Его стандартизировали именно как способ повысить устойчивость DNS при сбоях и атаках.

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

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

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

Кэш запоминает ответ и раздаёт его тысячам пользователей. Именно поэтому злоумышленнику не обязательно обманывать каждого из них. Достаточно один раз обмануть резолвер.

Представьте, что справочная отправила запрос: «Какой адрес у банка?» Настоящий ответ ещё летит по сети, а злоумышленник каким-то образом сможет подсунуть свой:

— Банк переехал. Запишите новый адрес.

Резолвер кладёт эту подделку в кэш. После этого он уже без посторонней помощи отправляет клиентов на ложный сайт.

Такая атака называется **отравлением DNS-кэша**. Справочная не взломана в привычном смысле. Она исправно хранит ответ, следит за TTL и честно сообщает адрес каждому посетителю. Проблема лишь в том, что ей подсунули ложный ответ. Теперь вопрос: как именно ему могут ее подсунуть.

Самый простой вариант - бомбардировать резолвер пакетами, которые выглядят точь-в-точь как ответ, который он ожидает увидеть на свой вопрос. Например, если мы знаем, что у него есть клиенты из России, скорее всего рано или поздно он будет обращаться к корневым серверам с вопросом “а где взять сервера за зону .ру”, и если посылать ему тысячи пакетов в секунду с ответом “зона ру живет вот здесь”, то велик шанс, что такой один из таких пакетов будет получен в том коротком промежутке, когда вопрос уже отправлен, а легитимный ответ еще не получен.

Чтобы сопоставить ответ с запросом, DNS использует короткий идентификатор. Заодно он служит одним из немногих признаков того, что ответ не прилетел случайно или от злоумышленника. Резолвер задаёт вопрос и добавляет к нему короткий идентификатор: условно, «запрос номер 42 731». Настоящий сервер должен вернуть тот же номер.

У злоумышленника этого номера нет, и поэтому он вынужден быстро отправлять множество ответов:

— Номер один, банк находится у меня. — Номер два, банк находится у меня. — Номер три…

Если один вариант совпадёт до прихода настоящего ответа, подделка может попасть в кэш.

Идентификатор DNS-запроса занимает шестнадцать бит — всего около шестидесяти пяти тысяч вариантов. Это много для человека, который перебирает числа вручную, и для интернет-каналов восьмидесятых, когда доступные скорости измерялись десятками пакетов в секунду, служил достаточной защитой от отравления. Дополнительным элементом защиты была случайность окна для самой попытки отравления. Если настоящий ответ уже пришёл и попал в кэш, новый запрос к авторитетному серверу до истечения TTL не отправляется. У атакующего было одно короткое окно возможностей - лотерея с очень небольшим шансом выиграть.

В 2008 году специалист по безопасности Дэн Камински понял, как устраивать эту гонку снова и снова. Вместо попытки отправить ответ на вопрос про известный адрес атакующий каждый раз спрашивает новое случайное имя внутри нужного домена. Например: «Где находится сервер банка номер сто двадцать три?» Такого имени в кэше ещё нет, поэтому резолвер вынужден отправить запрос к настоящему серверу.

Следом атакующий посылает тысячи поддельных ответов с разными номерами. Внутри написано не просто: «Случайный сервер находится у меня». Сообщение гораздо серьёзнее:

— “Я точно не знаю, но за весь домен банка теперь отвечает вот этот сервер. Все дальнейшие вопросы отправляйте ему”.

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

Неудачная попытка ничего не портит. Если сто двадцать третья попытка не получилась, атакующий спрашивает следующее случайное имя, которого заведомо нет в кэше: «Где находится сервер банка номер сто двадцать четыре?». Резолвер снова отправляет запрос, и гонка начинается заново. Сама лотерея не изменилась, только билетов у атакующего теперь бесконечно много.

Камински не придумал саму подмену DNS-ответов. Он нашёл способ быстро повторять попытки и при удаче отравлять не одну запись, а делегирование целого домена. Уязвимость затрагивала множество распространённых реализаций DNS. Публиковать подробности немедленно было нельзя. В тот же день злоумышленники получили бы инструкцию, а обновления ещё не существовали бы.

Камински связался с разработчиками DNS-серверов, операционных систем и сетевого оборудования. Конкурирующим компаниям пришлось втайне договориться об общей дате исправления. Патчи вышли почти одновременно.

Быстро переделать весь DNS было невозможно. Поэтому инженеры увеличили количество случайности. Резолверы начали выбирать не только случайный номер запроса, но и случайный исходящий порт. Раньше атакующий подбирал ключ к одному замку. Теперь пришлось одновременно угадывать комбинации двух. Это не сделало подделку математически невозможной. Зато перебор стал намного сложнее, а у настоящего ответа появилось больше шансов прийти первым.

Исправления усложнили атаку, но не решили главный вопрос. Как резолверу проверить, что ответ действительно пришёл от владельца домена, а не от незнакомца, который первым выкрикнул правильный номер?

От справочной требовались не просто справки, но справки с подписью и круглой синей печатью.

Обычный DNS умеет сообщить адрес, но исторически почти не умел доказать, кто этот адрес сообщил. Резолвер задавал вопрос, получал правдоподобный ответ и проверял несколько технических признаков: совпадает ли номер запроса, пришёл ли пакет с ожидаемого адреса, и, в общем, все.

После истории Дэна Камински стало очевидно, что этого явно недостаточно. Если злоумышленник может угадать служебные числа, справочной требуется не ещё одно число, а подпись, которую нельзя подобрать перебором. По счастью, решение этой проблемы уже было готово несколько лет, просто не было стимула его внедрять. Речь про расширения безопасности DNS, или DNSSEC. Владелец зоны создаёт пару криптографических ключей. Секретным ключом он подписывает DNS-записи, а открытый публикует, чтобы любой резолвер мог проверить подпись.

Окей, а откуда резолвер знает, что открытый ключ действительно принадлежит банку? Раз злоумышленник может подделать адрес банка, он точно так же может и приложить собственный открытый ключ в качестве ключа банка. Математика подтвердит, что документ не менялся после подписания. Она не подтвердит, что подписал его правильный сервер.

Поэтому DNSSEC строит **цепочку доверия** по тому же дереву, что и обычный DNS. Зона банка публикует свой ключ. Вышестоящая зона подтверждает: «Да, этому ключу можно доверять». Её ключ, в свою очередь, подтверждает следующий этаж.

Цепочка поднимается до самого корня DNS. Резолвер заранее знает открытый ключ корневой зоны и начинает проверку от него: корень подтверждает домен верхнего уровня, тот подтверждает следующий домен, а тот — конкретные записи.

Получается матрёшка из подписей. Каждая справочная предъявляет удостоверение, подписанное справочной этажом выше.

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

Интернет начинался с текстового файла, который поддерживала небольшая команда. Через несколько десятилетий для обновления его корневого доверия люди собираются в защищённом помещении и достают ключевые компоненты из сейфов. Масштабирование прошло успешно.

Ключи нельзя использовать вечно. Алгоритмы устаревают, оборудование меняется, а длительное применение одного секрета увеличивает риск его компрометации. Поэтому корневой ключ приходится периодически менять.

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

Сайт продолжит работать. Адрес останется правильным. Ответ придёт от настоящего сервера. Резолвер посмотрит на незнакомую печать и скажет:

— Документы не сходятся. Следующий.

DNSSEC решает проблему подлинности, но приносит собственную инженерную западню. Подписи увеличивают ответы, управление ключами требует дисциплины, а одна забытая или просроченная запись способна сделать домен невидимым именно для тех резолверов, которые тщательно проверяют безопасность.

Неподписанный домен может работать. Неправильно подписанный выглядит как подделка.

Тридцатого января 2024 года это правило на себе проверил Рунет. Вечером российские сайты у начали медленно открываться или исчезли совсем. Пользователи ругали операторов, приложения сообщали об отсутствии интернета, хотя связь как таковая продолжала работать. Проблемы возникали даже у пользователей российских сервисов за границей. Причем, что интересно, у части пользователей все работало нормально.

Причиной стал сбой в инфраструктуре DNSSEC доменной зоны .ru. Во время обновления ключей часть резолверов перестала успешно проверять криптографическую цепочку. Адреса существовали, авторитетные серверы отвечали, сайты стояли на месте. Проверяющий резолвер смотрел на документы и говорил:

— У этого ответа подпись не сходится. Поскольку ответа с правильной подписью у меня нет, я верну клиенту пустой ответ.

Координационный центр национального домена позднее объяснил аварию несовершенством программного обеспечения DNSSEC. Обновлённые ключи пришлось отозвать, после чего работоспособность зоны восстановилась.

Особенно странно авария выглядела со стороны пользователей. У одного сайт открывался, у второго нет. Через мобильную сеть не работает, через домашнего провайдера работает. Сервер доступен, маршруты на месте, записи опубликованы. Разница заключалась в том, какой резолвер использует человек и проверяет ли тот DNSSEC. Получался парадокс: менее строгая справочная могла отдать адрес и продолжить работу. Более безопасная добросовестно проверяла подпись, обнаруживала ошибку и отказывалась отвечать. Чем тщательнее резолвер исполнял протокол, тем надёжнее он отключал пользователю интернет.

Россия в этой дисциплине не одинока. В мае 2023 года ошибка при плановой смене ключей зоны .nz сделала новозеландские домены недоступными для части пользователей примерно на тринадцать часов. Среди затронутых оказались правительственные, медицинские, университетские и парламентские адреса. В мае 2026 года неверные подписи немецкой зоны .de заставили проверяющие резолверы отвергать адреса Deutsche Bahn, DHL, банков, провайдеров и крупных медиа. Серверы продолжали работать. Безопасная справочная просто отказывалась сообщать, где они находятся.

DNSSEC решает проблему поддельных ответов ценой жесткого правила: сомнительному адресу лучше не доверять вообще. С точки зрения криптографии решение безупречное. С точки зрения пользователя интернет по всей стране перестал работать из-за чьих то кривых ручек.

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

Окей, справочная наконец научилась доказывать, что её ответ настоящий. Оставалась другая проблема: вопрос пользователя всё ещё произносился вслух. Провайдер, администратор сети или сосед в публичном Wi-Fi мог увидеть, какие имена вы запрашиваете, а иногда и вмешаться в разговор.

Ответ подписали. Теперь предстояло запечатать сам вопрос.

Обычный DNS-запрос долгое время путешествовал по сети открытым текстом. Вы ещё не подключились к сайту, не отправили пароль и не загрузили страницу, а по сети в открытом виде уже бежит вопрос: “с адреса пользователя Васи ищут адрес вот этого домена.” И этот вопрос виден вашему оператору.

Само содержимое будущего разговора может быть защищено HTTPS, но DNS-запрос всё равно позволяет довольно подробно понять, какими сервисами человек пользуется. Возникает естественное желание: зашифровать разговор со справочной.

Один вариант называется **DNS over TLS**, сокращённо DoT. Обычные DNS-запросы заворачивают в защищённое TLS-соединение. Провайдер все еще видит, что вы разговариваете с DNS-сервером, но уже не видит, какой именно домен спрашиваете.

Второй вариант — **DNS over HTTPS**, или DoH. Тот же запрос прячется внутри обычного HTTPS-трафика. Со стороны сети он выглядит как ещё один защищённый разговор с обычным веб-сервисом.

Разница напоминает два способа отправить секретное письмо. DoT использует отдельную бронированную машину с табличкой «секретная почта». Содержание защищено, но всем понятно, что это секретная почта. DoH кладёт конверт в обычный грузовик вместе с тысячами других посылок.

Для пользователя результат похож: провайдер, администратор гостиничного Wi-Fi или случайный наблюдатель между устройством и резолвером больше не может просто прочитать DNS-запрос или незаметно подменить ответ.

Загвоздка переехала в другое место. Шифрование защищает путь от вас до выбранной справочной. Сама справочная всё равно видит вопрос. Кто-то должен открыть конверт, прочитать имя домена и найти ответ.

Раньше пользователь обычно спрашивал резолвер своего интернет-провайдера. С появлением публичных DNS-сервисов выбор расширился. Можно отправлять запросы Google, Cloudflare, Quad9 или другому оператору, а браузер и операционная система способны самостоятельно выбирать зашифрованный резолвер.

С точки зрения приватности это обмен одного наблюдателя на другого. Провайдер больше не видит список доменов. Зато выбранный публичный резолвер получает запросы от огромного числа пользователей.

Справочная стала лучше защищать тайну посетителя от людей в очереди. Одновременно все посетители начали ходить в несколько самых больших отделений.

Здесь возникает конфликт между сетью и приложением. Корпоративный администратор настраивает внутренний DNS, чтобы сотрудники могли обращаться к внутренним служебным серверам. Родительский фильтр блокирует нежелательные домены. Гостиница через DNS направляет нового пользователя на страницу авторизации.

Браузер включает собственный DoH и говорит:

— Спасибо, но я буду пользоваться другой справочной.

В результате внутренний сервис перестает открываться, корпоративные фильтры обходятся, а вайфай в гостинице и вовсе не работает, потому что вы же не залогинились на странице авторизации. Защита приватности одного участника выглядит как потеря контроля для другого.

Российский вариант этого конфликта называется Национальная система доменных имён, или НСДИ. Её создавали как локальную инфраструктуру разрешения имён, которая должна обеспечить работу российских ресурсов при проблемах с глобальным DNS. Если связь с глобальной системой нарушена, российские ресурсы всё равно можно найти через внутреннюю инфраструктуру. Российские операторы обязаны предлагать своим пользователям именно национальные сервера. Само собой, владелец такой справочной, возможно, и не видит отдельные запросы доменных имен каждым конкретным пользователем, но точно контролирует, какой ответ получит пользователь.

Сервер может продолжать работать, а его адрес — оставаться в глобальном DNS. НСДИ при этом способна вернуть другой адрес либо сообщить, что запрошенное имя не найдено. Чтобы сделать сайт недоступным, необязательно выключать его сервер или перерезать кабель. Достаточно, чтобы справочная убедительно говорила, что его не существует..

Зашифрованный DNS меняет расклад. Если браузер самостоятельно отправляет DoH-запрос зарубежному публичному резолверу, локальная справочная больше не видит вопрос и не может вернуть собственный ответ. Для пользователя это способ обойти подмену. Для государства и оператора сети — канал, который проходит мимо национальных правил разрешения имён.

DNS перестаёт быть нейтральной телефонной книгой. Выбор резолвера определяет не только скорость ответа и приватность, но и то, какие имена существуют для пользователя вообще. Летом 2026 года у части абонентов нескольких российских операторов перестали работать защищённые DNS-сервисы Google и Cloudflare. Наблюдаемая картина была похожа на целенаправленную фильтрацию популярных DoH- и DoT-сервисов. Кто именно распорядился закрыть справочную, официально не сообщалось.

В общем, полностью избавиться от доверия не получилось. DNSSEC позволяет резолверу проверить, что ответ подписан владельцем зоны. DoH и DoT не дают посторонним прочитать или переписать разговор с резолвером по дороге. Ни одна из этих технологий не отменяет простой факт: резолвер знает, о чём вы его спросили, и может влиять на ответ.

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

— Вход со двора, звонок не работает, лучше приходите по HTTP третьей версии.

DNS начинался как один текстовый файл. Затем стал распределённым деревом. Потом научился запоминать ответы, подписывать их, искать принтеры и принимать зашифрованные вопросы.

Каждое улучшение закрывало старую проблему и добавляло новую. Централизованный файл заменили распределённой системой. Для приватности распределённой системы пользователи снова выбрали несколько крупных посредников.

Чтобы понять, кому вообще принадлежит имя, нужно вернуться к вершине дерева DNS — доменам верхнего уровня. Это последняя часть адреса: `.com`, `.ru`, `.org`. Именно их серверы корень рекомендует спросить на следующем шаге.

Первые домены верхнего уровня были похожи на отделы большой организации. `.com` предназначался для коммерческих компаний, `.edu` — для учебных заведений, `.gov` — для американских государственных учреждений, `.mil` — для военных. Зона `.org` стала домом для организаций, которым не подошли остальные ящики.

Интернет определял характер деятельности владельца домена по последним буквам его доменного имени. Компания отправлялась в коммерческий отдел, университет — в образовательный. Реальная жизнь довольно быстро показала, что разложить весь мир по шести папкам затруднительно.

Некоторые зоны сохранили строгие правила. Зарегистрировать имя в `.gov` или `.edu` может далеко не любой желающий. Зона `.com`, напротив, давно перестала проверять, ведёте ли вы коммерческую деятельность. Там одинаково хорошо живут магазины, личные страницы, благотворительные проекты и сайт человека, коллекционирующего фотографии автобусных остановок.

Рядом появились национальные домены. Странам и территориям выдавали короткие двухбуквенные обозначения: `.it` для Италии, `.fr` для Франции, `.ru` для России. За каждой такой зоной стоит собственный оператор, правила регистрации и набор авторитетных серверов. Корневая база IANA и сегодня разделяет домены верхнего уровня на общие зоны вроде `.com` и национальные вроде `.uk`.

Название «национальный домен» слегка преувеличивает географическую строгость системы. Маленькое тихоокеанское государство Тувалу получило зону `.tv`, которую полюбили видеосервисы. Колумбийская `.co` стала заменой переполненному `.com`. Национальная зона крошечного карибского острова Ангилья “.ai” в последние пару лет испытывает необъяснимый взрывной рост, так что выручка от регистрационных платежей составляет почти половину ВВП.

DNS сообщает, какой организации делегирована зона. Каким смыслом люди затем наделят две удачные буквы, протоколу безразлично.

Иногда карта мира меняется быстрее корневой зоны. Девятнадцатого сентября 1990 года в DNS появился национальный домен `.su` — от Soviet Union. Его зарегистрировали для Советского Союза. Через год государства не стало, но домен продолжил отвечать. После появления российской зоны `.ru` домен `.su` собирались вывести из эксплуатации, но внутри уже находились тысячи зарегистрированных имён, их владельцы не хотели переезжать, а техническая инфраструктура исправно работала. В итоге закрытие так и не состоялось.

Сегодня `.su` по-прежнему присутствует в корневой зоне. У него есть администратор, авторитетные серверы и новые регистрации. Границы изменились, правительство исчезло, карты перепечатали. Но для DNS есть единственный существенный вопрос:

— Серверы зоны отвечают? — Отвечают. — Тогда продолжаем.

Советский Союз до наших дней не дошел, но домен его живет.

К началу нового тысячелетия несколько общих зон и набор двухбуквенных национальных доменов уже плохо вмещали растущий интернет. Хорошие имена в `.com` закончились примерно за несколько эпох до того, как вы решили зарегистрировать стартап.

В 2010-х корневая зона начала быстро расширяться. Появились сотни новых общих доменов: для профессий, городов, технологий, товаров и отдельных компаний. Теперь адрес может заканчиваться на `.shop`, `.app`, `.moscow` или на название бренда вроде .google или .yandex.

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

Так появились интернационализированные домены верхнего уровня. Например, зона `.дети` написана кириллицей и предназначена для русскоязычных проектов, связанных с детской аудиторией. Естественно, и сами домены стало возможным писать на национальных языках, и это породило очередную проблему с безопасностью. Некоторые буквы разных алфавитов выглядят почти одинаково. Кириллическая «а» и латинская «a» для глаза могут не отличаться, а для DNS это совершенно разные символы.

Мошенник может зарегистрировать имя, визуально похожее на адрес банка и отправить вам имейл со ссылкой. DNS честно найдёт именно его. DNSSEC подтвердит настоящую криптографическую подпись. Браузер установит настоящее защищённое соединение с настоящим владельцем домена, очень похожего на домен банка.

Ни один протокол не соврал. DNS способен доказать, кому делегировано имя и кто подписал ответ. Доказать, что имя означает именно то, что вы в нём увидели, он не может.

Вернёмся на наше собеседование. Вы набрали адрес сайта, нажали Enter, и браузер нарисовал фигвам. Теперь ответ на вопрос «что произошло?» занимает не сорок минут, а примерно всю историю интернета.

Возможно, рекурсивный резолвер не получил ответа. Возможно, он слишком хорошо помнит адрес, с которого сервис уже съехал. Истекла подпись DNSSEC, браузер выбрал другую справочную, чиновники решили, что вам на этот сайт ходить не надо. Сам сервер при этом может спокойно работать и недоумевать, почему сегодня никто не заходит.

DNS начинался с одного текстового файла, который поддерживала небольшая команда. Файл превратился в глобальное дерево, где полномочия спускаются от корня к отдельным доменам. Справочная научилась искать почту и принтеры, запоминать ответы, проверять подписи и принимать вопросы в запечатанных конвертах. Чем совершеннее становилась система, тем сложнее становился ответ на простой вопрос: «Кто знает правильный адрес?»

Так что если браузер сообщит, что не может найти сайт, то возможно, сайт никуда не делся. Кабели целы, сервер отвечает, а пакеты готовы пересечь половину планеты. Просто вы не знаете, как до этого сайта дойти.

Это был подкаст «До нас дошло». Этот выпуск для вас подготовили Иннокентий Солнцев и звукорежиссёр Алексей Попов.