После статьи ValdikSS о блокировке сайтов по тухлым доменам РКН мне не давала покоя мысль о том, что произойдёт, если реестр начнёт резолвится в очень большое число IPv4-адресов. Проводить полноценные "учения" мне кажется сомнительным делом, т.к. они могут случайно обернуться умышленным нарушением связности рунета. Поэтому я ограничился поиском ответов на два вопроса: Я нагрепал и зарегистрировал несколько свободных доменов из списка, поднял DNS сервер и поставил писаться трафик в pcap... Домены для регистрации были выбраны следующим образом: два домена присутствующие в выгрузке с https-ссылками, два домена с http ссылками и два "голых" домена без ссылок. Сделано это для проверки гипотезы о равенстве всех доменов перед фильтром. IPv4 адреса, на которые указывают эти домены, были выбраны из существующих в реестре, чтоб не повышать нагрузку на фильтры. Адреса отсутствующие в реестре выделены в настоящий момент моим виртуальным машинам, поэтому DoS-атаки в данном эксперименте не содержится. Можно пойти по открытым спискам Looking Glass разных провайдеров и посмотреть, какие из крупных около-российских провайдеров имеют на своих маршрутизаторах маршруты с маской /32 на адреса из реестра, т.к. эти провайдеры имеют риск пострадать от атаки на переполнение таблицы маршрутизации. Таких провайдеров находится не так уж мало: Эквант aka GIN aka Orange Business Services, Beeline, Ростелеком, Транстелеком, Obit и, что немного забавно, Федеральная университетская компьютерная сеть России (шутка про академическую свободу и независимость университетов). Проверим, что IP-адрес, который мы планируем внести "под блок" не присутствуют в таблицах маршрутизации на этих же LG: 1, 2, 3, 4, 5, 6. Если кто-то будет воспроизводить этот эксперимент предельно чисто, то стоит также проверить все IPv4 и IP адреса, которые планируется добавить в таблицу. Я предполагаю, что с ними ситуация аналогичная. 14 июня в 15:00 по Москве я добавил адреса некоторых из своих серверов в файлы DNS-зон и стал наблюдать, что происходит в pcap-файлах, пока резолверы обновляли записи. Всего в логи за 16 часов попали запросы резолверов из полутора тысяч автономных систем. В них наблюдается довольно большое разнообразие вариантов поведения с точки зрения резолва доменов. Из сети с abuse-контактом на netup.ru резолвятся только те домены, которые в списке указаны с URLом, при этом домен с 2048 записями получает запросов примерно в 5 раз больше. AS ФГУП Электросвязь с тем же контактом исправно ходит в DNS для всех "маленьких" доменов раз в 8 минут, но почему-то не присылает ни одного запроса на "большие" домены, ровно как и ижевский РадиоЛинк. Tele2 резолвит https и "безурловый" dns, но не резолвит http, предположительно весь http там завёрнут на proxy. Железногорский Сигнал и екатеринбургский Miralogic наоборот — резолвят только http. SPNet из Сергиевого Посада — URLы не резолвит вообще, только "голые" домены. Московский citytelecom — наоборот, только https и, как ФГУП Электросвязь, даже не пытается порезолвить "большие" домены, что позволяет предположить наличие альтернативного способа распространения чёрных списков с пред-резолвленными адресами. Полное содержание статистики числа запросов за первые 16 часов можно увидеть в gist, обращаю внимание, что не все ASN принадлежат российским провайдерам. В pcap-ах практически не обнаружено запросов с опцией EDNS Client Subnet, таких запросов меньше 1%. Это не очень удивительно, т.к. google (практически единственный "поставщик" подобных запросов) раскрывает адреса клиентов только тем DNS-серверам, которые явно анонсируют поддержку данной опции, а мой DNS-сервер этого не делал. Указанный небольшой процент запросов — это, полагаю, и есть те попытки автоматического определения поддержки EDNS Client Subnet: каждый четвёртый запрос из AS гугла приходил с этой опцией. Помимо гугла с Client Subnet пришло 4 запроса из Бразилии с резолвера, использующего "хак" с bit 0x20: Хак с битом 0x20 относительно популярен – с ним приходит порядка 5% запросов от 2.5% резолверов (если считать уникальные резолверы по ASN). Другой интересной опцией EDNS является EDNS UDP payload size, анонсирующая максимальный размер DNS-пакета, который клиент готов принять. Помимо четверти запросов, которые не анонсируют поддержку EDNS и 55% запросов установивших эту опцию в 4096 байта, есть несколько других интересных значений. 2% запросов говорят, что UDP-пакеты увеличенного размера им ни к чему и используют минимальное допустимое значение 512. Примером такого резолвера может служить irc.kristel.ru из Минусинска, который изменяет эту опцию после первого "большого" ответа, который пришлось получать по TCP. Аналогичное поведение наблюдается и на некоторых других резолверах, включая сброс размера обратно в 512 байт через некоторое время. Также в логи попали пара сканеров, которые могли искать DNS amplification, т.к. выставили клиентский размер в 65527 байта, что является максимальным значением. Интересно, что "большие" ответы powerdns отправляет без каких-либо ответных resource records, ставя флаг truncated в заголовке, что вынуждает резолвер перейти на TCP. Так powerdns избегает DNS amplification при работе с большими ответами по UDP. Я был немного удивлён, что ни одного DNS-запроса по TCP не пришло с использованием TCP Fast Open. Конечно, отсутствие этой фичи можно объяснить тем, что если беспокоиться о скорости, то прежде всего не следует отдавать большие DNS ответы, вынуждающие резолвер переходить на TCP. За 10 часов на вышеперечисленных looking glass не появилось /32 маршрута ни на один из "добавленных" в DNS IPv4 адресов, но через 20 часов как минимум на LG ТТК и университетской сети эти маршруты появились. Если провести измерения с помощью RIPE Atlas, то можно найти некоторое количество транзитных провайдеров, которые, вероятно, выполняют резолвинг и заносят маршруты на фильтр, получив 2049 A записей в ответ: Список неполный, т.к. был составлен методом пристального всматривания. Наличие крупных провайдеров в списке говорит о том, что вопрос о потенциальной уязвимости критической инфраструктуры к данной атаке не закрыт. Также остаются открытыми вопросы: Если кто-то хочет посмотреть на данные самостоятельно, то в RIPE Atlas это измерения 8844224, 8844225, 8844226, 8844227, 8844228, 8844229, 8844230, 8844231, 8844232, 8844233, 8844234, 8844235. Запросы за первые 16 часов эксперимента доступны в виде дампа postgres:9.6. Гигабайты pcap-ов могу отгрузить по отдельному запросу.