Защита корневых DNS-серверов

ОГЛАВЛЕНИЕ

ICCAN объявил, что с 2009 года можно будет зарегистрировать  домены верхнего уровня, а это означает, что нагрузка на корневые DNS сервера дополнительно возрастет. Корневые DNS сервера Интернет периодически атакуют, используя бот сети. Бот сети разрастаются до огромных размеров. Практически ни одна из коммерческих организаций не способа противостоять DoS атакам с использованием бот-сетей. Давайте разберемся, что «хорошие парни», ответственные за работоспособность корневых  DNS серверов противопоставляют  «плохим  парням», которые, возможно, будут атаковать эти сервера.

Основы работы DNS

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

            Чтобы разобраться, почему атакуются именно корневые сервера DNS необходимо понимать, как работает эта система. Графически, структуру DNS корректней всего представить в виде дерева.

            В корне дерева расположены так называемые корневые сервера. Их всего 13 штук. Корневые сервера знают о месте положения (IP адреса) так называемых TLD (Top Level Domain) серверов. TLD сервера обслуживают большие зоны первого уровня, такие как com, net, ru, kz, ua, gov….  Группа TLD серверов знает о месте положения серверов обслуживающих домены второго уровня в пределах их зоны ответственности. Например, ответственные за домен  com знают IP адреса серверов второго уровня для зоны первого уровня com, ответственные за зону ru  знают о серверах зоны ru, ну и так далее. Сервера ответственные за зоны второго уровня уже, как правило,   знают конкретные адреса серверов, предоставляющих сервисы интернета, таких как www, mail и т.д. Также сервера второго уровня  могут быть ответственными за домены третьего уровня, ну и так далее.

            Для того, чтобы понять как вся  структура функционирует, рассмотрим как это работает на примере определения  IP адреса сервера www.securityab.ru. Для упрощения,  рассмотрим пример работы рекурсивного DNS без учета механизмов кэширования.

            Все, что первоначально  известно серверу, который предоставляет услуги DNS это 13 IP адресов корневых серверов. В моей любимой ОС FreeBSD они жестко прописаны в файле named.root, в вашей любимой ОС, они, возможно, хранятся в других местах, но, эти   IP адреса однозначно одна из самых постоянных вещей Интернета. 

Допустим, клиент запрашивает IP адрес сервера www.securitylab.ru сервер DNS, который его обслуживает. Тот, в свою очередь, спрашивает об этом корневые сервера, при этом IP адрес корневого сервера выбирается произвольно. Один из корневых серверов ему отвечает, что ничего не знает о www.securitylab.ru, но, спросить об этом можно у  одного из 6-ти (на данный момент) TLD серверов, ответственных за зону ru. Сервер DNS запрашивает один из серверов TLD, который отвечает, что надо бы запросить об этом один из трех серверов ответственных за зону второго уровня securitylab.ru. Сервер DNS дает третий запрос к одному из серверов второго уровня, и, наконец, узнает что www.securitylab.ru живет на IP адресе 217.16.31.134.

            Все это справедливо, если вы не используете при работе с DNS кэширование (запоминаете результаты предыдущих запросов). Кэширование подразумевает, что после первого запроса сервер  уже знает адреса серверов, которые хранят информацию о зоне ru и securitylab.ru и, собственно, где расположен www.securitylab.ru.

            Кэширование выгодно всем. Меньше запросов к корневым и TLD серверам, меньше трафика тратит сервер DNS провайдера, меньше времени клиент ждет ответа от DNS сервера провайдера.

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

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

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

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

            В качестве другого решения противостояния распределенным DoS атакам на текущий момент внедрена крайне масштабируемая система с использованием anycast. Рассмотрим, что это такое.