Как работает DNS и почему он может сломаться? [Спецвыпуск]

Либо-либо. Всем привет. Меня зовут Самат Галимов, и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионалов, с которым можно поговорить простым человеческим языком. Дорогие друзья, это специальный эпизод нашего подкаста. Вообще-то мы закончили сезон и ушли на небольшие каникулы, но 30 января сломался Рунет. Было несколько часов, когда перестали открываться сайты и работать мобильные приложения. Почему это произошло? Все дело в технологии, которой мы все пользуемся каждый день по много раз в день, но большинство людей о ней даже не слышали. Это протокол DNS. Вообще-то это дико интересная история, потому что DNS один из старейших протоколов интернета и активно используется до сих пор. Это такая базовая технология, которая, как и обычно, пока работает, не замечаешь. Сегодня мы познакомимся с этим протоколом поближе, а поможет нам в этом эксперт, человек, который работает с ДНС больше 10 лет.

Привет, меня зовут Михаил Анисимов, я старший менеджер корпорации по присвоению доменных имен и IP-адресов ICANN по работе с заинтересованными сторонами в странах Восточной Европы, Центральной Азии и странах Кавказа. Вообще я занимаюсь доменами доменной отрасли уже где-то с 2010 года. Сначала работал в разных коммерческих компаниях, регистраторах и хостинг-провайдерах, российских, мелких, крупных и так далее. Потом я почти 6 лет поработал как раз в Координационном Центре, доменами .RU и .РФ. И с 2020 года я работаю в ICANN и отвечаю за связи с нашим регионом – Восточная Европа, страны Кавказа и Центральная Азия.

Миш, что случилось с интернетом 30 января в России? Давай сначала с обычных людей. Как это для нормальных людей выглядело? Вот я набираю yandex.ru, что у меня происходит на экране?

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

То есть я набираю яндекс.ру, он не открывается?

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

Сайты— это одна большая штука, вторая— это приложения. Мобильные приложения продолжали работать или тоже сломались?

Мобильные приложения по-разному. Не все устроены одинаково, но значительная часть приложений устроена по-прежнему так, что она работает на базе системы доменных имен. То есть мы просто заменили процесс ввода доменного имени в строку браузера на клик по приложению. Но механика, которая стоит под капотом, примерно похожа. Сначала работает система DNS, которая возвращает тебе IP-адрес, а потом уже этот IP-адрес позволяет тебе прийти к серверу и получить оттуда все необходимые данные. Соответственно, та же самая система с электронной почтой, потому что тебе нужен адрес почтового сервера, чтобы отправить письмо и так далее.

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

DNS— это одна из самых старых, одна из самых фундаментальных систем интернета, которые, в общем, держат вообще его, что называется, up and running. И история его появления достаточно, конечно, интересна. Джон Постел (Jon Postel) очень-очень давно, который вообще все это придумал и очень долго был единственным, кто вообще хоть что-то понимает в этом и разбирается. И на заре интернета, когда его еще интернетом даже не называли, потому что это была сеть ученых американских, связывающая между собой институты и несколько серверов электронной почты, это были такие абсолютно вегетарианские времена, полные энтузиастов, хиппи, которые вообще не думали о безопасности. он вёл её в своём блокнотике. То есть он писал ручкой в своей тетрадке в соответствии вот этих вот сочетаний букв и их IP-адресов. И вот этот вот блокнотик Джона Постела, который сейчас, по-моему, хранится где-то в музее, это, в общем-то, первая критическая инфраструктура интернета. которая лежала на столе у него. Потом понятно стало, что так больше нельзя, потому что их количество умножилось, расширялось, появлялись другие зоны и так далее. Все автоматизировали, и она потихоньку пришла к тому виду, который мы видим сейчас.

Погоди, был блокнотик. Какой следующий шаг? Вообще из блокнотика он на компьютер как-то попадал? Или это только между людьми распространялась эта информация? Какое имя какому IP-адресу соответствует?

Но, скажем так, на самых-самых первых парах это даже не было автоматизировано. То есть, приходилось вручную сопоставлять какие-то такие вещи. Фактически, это работа телефонистки, которой ты звонишь и говоришь, барышня, Смольный, вот здесь то же самое. Мне, пожалуйста, сервер Колумбийского университета. Окей, вот вам IP-адрес. Идите, заходите. А потом, естественно, это стало автоматизировано, а блокнот, он был скорее неким бэкапом, что если вдруг что-то сломается, мы знаем, откуда его потом забрать еще раз. Примерно аналог справочника «Желтые страницы». Вообще DNS так же и называют. Телефонная книга интернета.

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

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

А вот как это работает? Можешь немножко рассказать?

Тут, наверное, надо сначала начать вообще про то, как система ДНС устроена. Потому что это уникальная достаточно вещь, и, наверное, очень мало каких-то других систем интернета, похожих на ее устройство. Она, с одной стороны, похожа на лоскутное одеяло, которое состоит из каких-то разных частей. С другой стороны, они так друг к другу шиты, что образуют, ну, очень по-гиковски красивую, на мой взгляд, картину. Просто вообще Микеланджело. Так вот, дело в том, что она иерархична. Как очень часто говорят по системе DNS, она состоит из нескольких уровней. На самом-самом верхнем уровне— это так называемые корневые серверы интернет. Вообще, когда мы говорим о DNS и DNSSEC, там очень много каких-то, знаешь, толкинистических аналогий, потому что это вот семь колец, чтобы миром править, ну вот что-то подобное. Есть 13 корневых серверов, которые управляются Чёртовы дюжины, скажем так. Управляются 12 разными организациями, независимыми друг от друга. Одна просто управляет сразу двумя. Изначально это было 13 физических машин, которые стояли где-то в университетах или в каких-то правительственных и неправительственных организациях. Сейчас понятно, что это 13 облаков, скорее. Каждая из которых состоит из сотен, а иногда даже тысяч физических машин, разбросанных по всему миру. И вот там хранится Это самая-самая первая точка, куда приходит DNS-запрос после того, как мы вбили адрес в свой браузер или отправили письмо по электронной почте. И вот оттуда начинается Бильбо Бэггинса, вот это разрешение доменного имени. То есть, корневые серверы характерны тем, что они хранят информацию обо всех доменах верхнего уровня. Как страновых, таких как .ru, .de, .cn, так и так называемых generic, общих доменах верхнего уровня, таких как .com, .net, .org и так далее. Просто само по себе слово «домен» означает просто «область» и всё, да, в переводе. Ну, собственно, там, если ты наверняка изучал физику, есть там магнитный домен, это просто область в металле, которая магничена. Здесь то же самое. Мы всё-таки для того, чтобы быть понятыми, да, и чтобы быть более точными, мы обычно всегда говорим «домен какого-то уровня». Соответственно, есть домен. верхнего уровня, .ru, .de и так далее. Есть домен второго уровня, это как раз yandex.ru третьего и так далее. Всего их, по-моему, может быть до 64 уровней вложенности.

То есть на корневых серверах хранятся адреса доменов верхнего уровня, где надо узнать дальше информацию про .ru или про .com?

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

Слушай, это прям как в сказках, когда герой идёт от одного персонажа к другому, и каждый говорит, сходи к этому спроси, сходи к этому спроси, и в конце концов он находит.

Абсолютно. Это классическая сказка путешествия, которая, собственно, пробегает наш DNS-запрос. Весь этот процесс называется разрешение доменного имени. То есть получение информации о том, что с ним ассоциировано. Разрешение или резолвинг, соответственно. Так вот, процесс резолвинга чем интересен? Тем, что ты можешь делать его сам. Ты можешь сам настроить свой iPhone, свой ноутбук, чтобы он это делал сам для тебя. Но чаще всего его для тебя делает некий посредник. Чаще всего таким посредником является твой провайдер, то есть тот, кто дает тебе интернет мобильный, твой Wi-Fi офисный и так далее, и так далее. Либо ты можешь выбирать стороннего такого посредника, который будет это делать. Самые популярные, самые знаменитые такие сторонники— это Google 4.8-ки, которые ты у себя прописываешь, либо Cloudflare, либо 4.9-ки, ну и там некоторое количество их сейчас довольно много по всему миру. Ну и, собственно, в зависимости от того, каковы их настройки, какова их политика разрешения, какие у них блок-листы и так далее, фактически, глядя через разные эти окошки, ты будешь видеть разные интернеты, которые для тебя, соответственно, разрешает какой-то твой посредник по твоему выбору.

А теперь минутка рекламы. Мы говорили с Мишей почти 2 часа. Часть этого разговора о том, кто управляет корневыми записями интернета. Кто эти люди, что это за организации и почему мы им доверяем ключи от интернета. Все это вы услышите в бонусном эпизоде нашего подкаста «Продолжение разговора с Мишей». Подписаться можно на Apple подкастах и в Телеграме. Помимо бонусных эпизодов нашего подкаста, там доступны еще бонусные эпизоды других подкастов студии Либо-Либо. А еще эксклюзивный подкаст «Студия. О жизни студии Либо-Либо». Все ссылки в описании. Слушай, я немножко понял, как работает DNS. Думаю, слушатели тоже. Теперь давай вернемся к аварии, когда типа что-то в этой системе сломалось. Вообще то, что ты рассказал, выглядит как очень такая простая и элегантная система. Что в ней вообще может сломаться?

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

То есть то, что сломалось в России, но продолжало работать в соседних странах, это на самом деле фича, это как бы система сработала так, как надо.

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

Что произошло в январе?

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

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

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

Вот это запоминание называется кэш, и когда ты туда пихаешь говно, называется отравление кэша, так?

Да, да, да, cache poisoning (кэш-пойзонинг). И вот, собственно, Каминский сделал такое один раз с DNS, он провел несколько презентаций, несколько примеров, как это можно было сделать, привел всю эту вот благодушную общественность в ужас, и решили, что надо с этим что-то сделать. Предложили такой протокол, который называется DNSSEC. Это тот же самый DNS, это надстройка на нем, который просто позволяет вот эту информацию, которая лежит на сервере, всю атрибутику домена, все то, что с ним связано, подписывать цифровой подписью, и таким образом, когда она к нам приходит, у нас выполняются две задачи. Во-первых, цифровая подпись позволяет понять, откуда она пришла, и быть уверенным, что нам ее отдал именно тот, кто должен, что не какой-то левый человек это сделал. Во-вторых, в том, что она по дороге не была изменена. Дело в том, что когда ты подписываешь что-то электронной подписью, тут, наверное, нужно сказать пару слов, потому что, может быть, не все об этом знают. Общий принцип довольно простой. Дело в том, что электронная подпись, для того, чтобы ее посмотреть, нужны два ключа. Публичный и приватный. Это вообще механизм асимметричного шифрования, безумно интересная вещь, но, наверное, требует отдельного какого-то выпуска.

Отдельный эпизод у нас про это есть, ссылка в описании.

Ну, тем более, тогда, может быть, кто-то услышал, я рекомендую, чтобы к этому вернуться. И приватный ключ по своему названию, да, неизвестен никому. Это самый вообще большой секрет и самый главный секрет электронной подписью, потому что, если вдруг она стала доступна, все скомпрометировано, все, закрывайте лавочку. Публичный ключ, соответственно, доступен всем. Соответственно, что происходит? Мы берем какую-то информацию, мы подписываем ее приватным ключом и публикуем. Вместе с этим публикуем и открытый публичный ключ. Мы прямо его рядом кладем. И, соответственно, если вдруг кто-то берет публичный ключ, открывает эту подпись, открывает этот сундучок и видит его содержимое, он может быть уверен, что он был закрыт именно приватным ключом и никаким другим, иначе бы они друг к другу не подошли. Это уникальная пара, которую невозможно, ну или теоретически невозможно, подобрать случайным образом. То есть это как раз способ удостоверения, что информацию в этот сундучок положил только тот, кто владеет приватным ключом. И, соответственно, когда мы вот этот вот сундучок закрыли и поставили на всеобщее обозрение, чтобы все забирали оттуда все, что хотят, мы должны рядом положить и новый публичный ключ, например, если мы меняем эту подпись. Вот DNSSEC работает именно так. Мы подписываем на каждом из этих вот этапов, то есть на втором уровне, на первом уровне, на корневом уровне, подписываем содержание ключом. Все эти ключи разные. И он позволяет нам быть уверенным, что мы получаем все как надо.

у владельцев серверов, DNS-серверов, которые источники информации о том, типа, какие IP-адреса каким серверам принадлежат, у них есть свои цифровые подписи, и они каждую запись подписывают, типа, все верно увиденному верить. Окей, мой компьютер, когда получает ответ, он может проверить, что, типа, да, ту информацию, которую я получил, она верная, да? Это мой компьютер сам проверяет.

Это зависит от настроек. Чаще всего проверка лежит на посреднике. То есть наш провайдер или наш Google, Cloudflare, кого бы мы ни выбрали, они работают как раз, они делают для нас так называемую валидацию этого файла зоны. То есть вся атрибутика домена называется файлом зоны. То есть все, что там написано, IP-адрес, почтовые отсылки, какие-то служебные информации и так далее, это называется файлом зоны. Соответственно, они делают валидацию файла зоны, они дают нам, удостоверить для нас, что всё работает правильно.

Окей. Звучит очень классно, клёвый протокол, пользуемся все.

Да, да, да, всё прекрасно.

Что пошло не так?

Что пошло не так? Дело в том, что DNSSEC действительно технология довольно сложная, и многие специалисты говорят о так называемой родовой травме DNS, поскольку он требует большого внимания на детали, очень хорошего тайм-менеджмента, все должно быть сделано вовремя, в определенной последовательности. И в том случае, если у нас вдруг что-то сделано не так процедурно, мы что-то перепутали, что-то забыли, сделали что-то не вовремя, поставили или старые ключи, или что-то пошло не так при их генерации, при сотворении этой пары, то, соответственно, этот сундучок не откроется.

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

Абсолютно, абсолютно. Ну там не 10, там сильно больше, там довольно большие ключи, чтобы их нельзя было подобрать. Почему вообще такое происходит? Дело в том, что все ключи, как и любые какие-то атрибуты вот такого типа безопасности, их нужно время от времени менять, как пароли, как и все остальное. Соответственно, есть процедура ротации ключей, она в каждой доменной зоне происходит по своим правилам, где-то она происходит раз в 3 месяца, раз в 6 месяцев и так далее. Ну и, соответственно, как это выглядит, генерится новая пара ключей, подписывается доменная зона новым приватным ключом, публикуется, соответственно, вместе с новой цифровой подписью и вместе с новым публичным ключом, чтобы можно было проверить, сделать эту самую валидацию автоматическую, которую для тебя делает этот посредник.

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

Конечно. Это обязательная пара, которая делается одновременно. Вот тут на самом деле и кроются всякие чисто технические, чисто операционные сложности. То есть теоретически всё понятно, всё пошагово, написаны тысячи документов. Но на практике бывает такое, что опубликовали новую подпись, старый ключ, старую подпись, новый ключ. Сделали это не одновременно. Еще есть удивительная такая история. Дело в том, что этот кэш, память, которую хранит наш посредник для того, чтобы отвечать, у него есть определенное время, которое он может там хранить, так называемый time to live (TTL), так называемый параметр. И этот параметр TTL обычно прописывается самим владельцем доменной зоны. То есть он указывает провайдеру, как часто нужно ходить ко мне, чтобы это обновлять. И по идее все свои операции, все свое дальнейшее планирование он делает, исходя из того, что он прописал именно этот TTL. Прописали час, значит час это мое время на разгон. Как только он закончился, по идее я должен быть уверен, что у всех остальных кэши обновились и он уже за новым запросом будет обращаться в свои закрома, а он придет ко мне за новой актуальной информацией. Соответственно, так я строю свою операционную деятельность. Такое случается, что иногда провайдеры, получив эту информацию, сами его меняют в своих настройках.

То есть владелец говорит, обновляем информацию обо мне не реже, чем раз в 5 минут или там в час?

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

Вот ты сказал, что я заменил на новые ключи, подписал новыми. Старые в этот момент перестают работать, что ли?

Ну, по идее, их нужно вообще удалить.

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

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

О-о-о, то есть может разъехаться информация и ключ.

Да-да-да.

Из разных версий. Блин, я думаю, что это атомарно, что у тебя типа ключ и этот одновременно как бы в одном пакете хранятся.

Нет, они одновременно, они одновременно и по идее у тебя хранится это все в паре. Но дело в том, что эти процессы могут быть несколько асимметричны, да, там получение и проверки и так далее могут немного расходиться по времени. Ну то есть там есть свои тонкости. Вот. Такое случается. И такой случай, например, был на моей памяти с доменной зоной .kz казахстанской. В начале 23-го года там как раз история была тоже. Переподписание ключей и про то, что с несколькими крупнейшими провайдерами не договорились о синхронизации и какой-то обновлении своевременном, о соблюдении правил TTL.

Что они должны сбросить кэши.

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

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

Абсолютно. Ну вот теперь, когда мы знаем чуть-чуть о том, что такое ДНС, а так и самым общим принципах того, как это все работает, можно вернуться к случаю 30 января. И случилось ровно это. Ну, скажем так, я не знаю, что именно там случилось достоверно. Мы это все можем оценивать только по официальным заявлениям, которые были сделаны соответственно регистраторой или кем-то еще. Но суть была следующая. Было очередное плановое стандартное переподписание таменной зоны, что нужно делать обязательно, и это нормальная стандартная процедура, которая работала много лет без сбоев и должна так работать. Тут я на самом деле целиком адвокатирую точку.ру, потому что я очень хорошо знаю этих людей, они крайне технически грамотные, там все работает как часы и так далее, и так далее. Вот дальше заявление, которое было выпущено, оно не позволяет очень широко это понять, там ссылались на проблему с программным обеспечением, который генерирует эти ключи. Возможно, это я сейчас предполагаю сразу, чтобы исключить спекуляции, что каким-то образом эти ключи были перепутаны и состоялось подписание чего-то не тем, либо публикация чего-то не того, например, подписано старым публикован новый, наоборот, подписанный новым, публикован старый ключ. И, соответственно, вот эта валидация перестала работать. То есть, у нас провайдеры считают эту информацию скомпрометированной. Соответственно, естественно, происходит в автоматическом режиме, и провайдеры, начав получать массово вот эту вот доменную зону с каким-то косяком, да, с каким-то багом в ключах, стали массово говорить всем, что нет, у меня нет ответа на ваш запрос, соответственно, я не могу разрешить домены из точки RU. А поскольку этот баг с ключами произошел на верхнем уровне, то есть он касался всей доменной зоны точку.ru, ни один из доменов, который в точке.ru, ни один из доменов второго уровня из всей доменной зоны не смог превратиться в нужную нам информацию. То есть ты даже не дойдешь до Яндекс.ру, чтобы понять, что-то о нем, у него все валидно или протухло и так далее, потому что уже на верхнем уровне тебе приходит ответ, что все, дальше мы не идем, нету этой информации, не могу вам ответить.

Миша, у меня один из друзей работает в крупном российском провайдере, и ТЦИ, технический центр интернет, разослал им письмо с постмортемом, то есть с описанием того, что произошло. Я прочитал постмортем, и там пишут, что на самом деле произошла коллизия хэша ключей, который используется как идентификатор ключа, keytag. Хэш— это как маленький отпечаток. Так вот, они сделали новый ключ, и хэш нового ключа совпал с хэшем старого. у него был такой же человекочитаемый идентификатор, как и у первого. Типа просто не повезло. Он 16-битный, это значит их сколько? 2 в 16-й их может быть на свете 65 тысяч. И вот как бы случилось такое, что одна 65-тысячная вероятность как бы сработала. и поэтому типа софт сломался.

Я не знал этого, у меня не было таких данных. Я могу предположить, что что-то подобное случилось, но, конечно, это какое-то... Это такое фантастическое невезение, которое даже сложно комментировать. Ну, то есть, это просто вот пойти и наступить в одну маленькую лужу размером с монетку на всей площади, да, вот прям в нее и наступить. Удивительно, конечно, и тогда, конечно, Моё как бы безграничное сочувствие ребятам из точки RU, потому что вот так вот взять и сесть в эту маленькую лужу— это, конечно, надо удивиться. Но как бы это на самом деле вот такое объяснение, оно даёт нам понимание, что это даже не человеческая ошибка. То есть, что это как раз тот случай, от которого, наверное, никто не может быть застрахован. Но вероятность его, конечно, даже, наверное, мало кем рассматривается всерьёз, тем более удивительно, что оно случилось.

Когда я читал вначале объяснение, которое официально опубликовали, что это какие-то, как они там это сформулировали, недостатки в программном обеспечении, которые повлекли, бла-бла-бла. Мне это показалось таким корпоративным, знаешь, способом прикрыть, извините, задницу, сказать типа, это программы плохие, это не мы ошиблись. Сейчас, прочитав постмортом и понимая, что дело в коллизии хэша-ключей 1 к 65 тысячам, я понимаю, что это на самом деле недостаток в программном обеспечении. В этом случае это суперкорректная формировка.

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

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

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

Да-да-да, типа, сейчас попробую привести аналогию. Условно, тебе приходят два человека, они называются одинаково. Иван Петров и второй тоже Иван Петров. И только потом, в конечном счете, выясняется, что у них даты рождения немножко отличаются. Типа день рождения другой. Типа у одного 8 февраля, у другого 7 февраля.

Ну да, да. И ты понимаешь, что важный конверт отдал не тому Ивану Петрову, например.

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

Ну, скажем так, я бы тут обобщил, назвал это все-таки неким общим явлением. Не сработала проверка подписи.

Да, DNSSEC начал говорить, что подписи невалидные.

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

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

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

То есть выключить DNS Security на стороне посредников?

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

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

Абсолютно. То есть мы так или иначе протащим этот час или сколько-нибудь на пробитой шине, на вздымающемся двигателе, потому что на кону что-то большее стоит. Но вообще, конечно, это такая практика, если у нас болит палец, мы его отрубаем, чтобы он не болел, например, такого типа решения. Но, повторюсь, я признаю, необходимость и безальтернативность этого шага тогда нельзя было сделать по-другому. Соответственно, когда это сделали, у ребят, тех, которые ответственны за вот эти вот авторитативные так называемые DNS-сервера, то есть те, из которых происходят ответы, те, которые дают ответы, У них появилось какое-то время для того, чтобы все поправить, и как раз из второго заявления, которое было сделано регистраторой, стало понятно, что они откатились к старым ключам. То есть они взяли уже старую проверенную пару, которая совершенно точно работает, и чтобы уже потом это все оттестировать, может быть, где-то в отдельной лаборатории. и опубликовали её заново, переподписали зону заново. Соответственно, это всё откатилось, и следующей рекомендацией как раз Роскомнадзора, которая опять же распространялась по всем провайдерам, было такое сообщение, что всё хорошо, да, сейчас всё начало работать, если вы вдруг отключали на время проверку DNSSEC, валидацию DNSSEC, пожалуйста, включите её обратно. То есть это как раз свидетельствует о том, что все-все откатили обратно, убедились в работоспособности, оттестировали, и сейчас готовы пускать это в бой.

Класс.

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

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

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

Теоретически такое могло произойти, но вот на практике я пытаюсь себе это представить. Для этого нужно не просто ДНС-записи подменить, нужно еще каким-то образом перехватить запросы этой посреднической системы. Ну то есть какое-то время нужно условно сидеть на трубе, через которую идет сигнал и даже... переключить эту трубу. Есть пример, когда это происходило. Пакистан в одно время сломал для всего мира YouTube, когда сказал, что типа давайте через меня пропускайте YouTube, известный случай. Но насколько я понимаю, именно от этого типа атак, когда маршруты на себя переписывают, и вот через себя начинают пропускать много трафика, это заметно, мы уже от этого вполне умеем защищаться, то есть это все риски, они довольно теоретические были, да, мне кажется?

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

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

Эти проблемы происходят время от времени, ровно потому что... Ну вот, видишь, я до сегодняшнего эфира был склонен говорить о том, что это протокол просто сам по себе непростой и нужно быть очень внимательным и технически подкованным для того, чтобы не делать ошибок. Но сейчас ты, вот видишь, мне открыл глаза, что, оказывается, есть еще и совершенно Удивительные обстоятельства, вероятность которых мало кто может просчитать, когда даже самые крутые технически подготовленные специалисты могут сесть в лужу, потому что, надо же, совпали хэши. Вероятность 1 на 65 тысяч. Но кто, как это вообще возможно? Даже тут мы не можем быть в этом уверены. И это, к сожалению, что-то, что находится в ДНК. Хотя, опять же, повторюсь, вероятность этого очень мала. Просто чтобы наши слушатели потом не подумали, ну и зачем это все, если столько проблем. Нет, мы все-таки считаем, и большинство специалистов считают, что бенефиты, которые мы получаем, перевешивают риски, с которыми нам приходится иметь дело. это, к сожалению, не так редко, как может показаться. Помимо России и Казахстана было несколько официальных сообщений, в том числе, кстати, есть примеры и в заявлениях, и описывали кейс .RU. Например, это случалось с островом Фиджи, который тоже на несколько часов просто исчез весь из интернета. Частично это происходило с доменами Австралии и Новой Зеландии, Время от времени это действительно случается, и этот случай совершенно не уникальный. Он не первый и, к моему большому сожалению, наверняка не последний.

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

Ну, смотри, тут же вопрос в том, какую проблему мы решаем, и в том, какие вообще существуют пути решения именно этой самой проблемы. У нас проблема, которую решает ДНС сек, декларируется очень-очень четко. Нам нужно сделать так, чтобы информация, которая идет от сервера, чтобы ее, например, никто не подменил. Нам нужно удостоверенность в ее целостности, быть уверенным в этом. И нам нужно быть уверенным, что она пришла из того источника, из которого должна, что никто не встал и не притворился этим авторитативным источником. Делать это из доступных вообще нам, техническому сообществу способов можно, наверное, только одним способом— это цифровая электронная подпись. Но, к сожалению, больше особо нет каких-то вещей, которые позволяли бы нам сделать такой функционал. Сама по себе подпись— это некая процедура, которая требует определенных правил ее соблюдения. В том случае, если ты ее нарушаешь, то ты, естественно, получаешь риск несрабатывания. Я такую аналогию приведу абсолютно человеческую. Если вдруг ты озаботился о своей безопасности, например, своего офисного здания, и у тебя правда стоит этот вопрос, и внедрил систему пропусков, то возникает риск того, что кто-то забыл пропуск дома и не может попасть в здание. Такая проблема есть. неотъемлемая часть пропускной системы. Ты не можешь как бы отменить пропуска, потому что люди их забывают. И вот вопрос к тебе я возвращаю. Можно ли что-то сделать такое, чтобы изменить пропускную систему, чтобы люди перестали забывать пропуска? Наверное, можно перейти на биометрию или что-то еще.

Да-да-да, я как раз подумал, что отпечатки пальцев, типа, не забудешь.

Но я не думаю, что мы когда-нибудь перейдем в ДНС на отпечатки пальцев, да? И так далее. Это как бы та часть... Тот момент,

когда аналогия ломается, я так понимаю.

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

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

Да, конечно. Но тут зависит от... Поскольку это система многогранная, там очень много всяких аспектов, да, и технических, и юридических, и административных, всяких разных. Тут очень сильно зависит от того, что именно хотите узнать. Например, если хотите узнать больше о том, как работает DNS технически, есть самая, наверное, замечательная и знаменитая книжка в этой области— это DNS and BIND. А если не хочется погружаться совсем в детали на таком уровне для того, чтобы, например, иметь что-то делать руками, а просто хочется узнать на понятийном уровне, Я очень рекомендую блоги больших технических компаний, потому что никто не умеет так подробно и понятно рассказывать об этом, как они. В частности, я очень рекомендую блог компании Cloudflare, которая вообще рассказывает много разных технических вещей, и у них совершенно потрясающая, очень понятная статья, там устроен DNS-сек, о всей этой цепочке доверия и всяких разных других аспектах работы DNS. Очень-очень рекомендую. Ну и, собственно, в самом ICANN на нашем сайте есть отдельный большой раздел, который называется ICANN Learn. Причем он выполнен на нескольких языках. Там не все есть курсы на русском, но есть, в том числе, курсы на русском. О том, как все устроено, уже больше административно. Кто за что отвечает, что такое регистратуры, как происходит публикация файлов зоны. Это все открыто, бесплатно. Welcome! Будем очень рады. Ну и кроме того, у нас есть своя программа Fellowship, кстати, да, которую уже очень многие, на самом деле, посетили люди из нашего региона, и сам я когда-то посетил, это было мое первое знакомство с ICANN как организацией еще в 2018 году. У нас проходят большие конференции ICANN-овские три раза в год в разных местах мира. И, собственно, Fellowship— это когда вы проходите курсы ICANN Learn, вы получаете наставника, который с вами работает, вы приезжаете на эту конференцию, вам помогают с билетами со всем остальным, присутствуете на всех секциях, заседаниях, смотрите, о чем разговаривают, подходите, знакомитесь, задаете вопросы и, соответственно, уезжаете оттуда преусполненные новыми знаниями и пониманиями того, как все работает. Вот это, наверное, самые главные пути знакомства с нашей экосистемой.

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

Да, которые могут жить в соседнем подъезде, да.

Мне кажется, это очень классно. Редактор субтитров Т.Горелова Корректор А.Егорова