Тест №1 - документ

Что делает DNSSEC

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

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

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

Защита от атак

Domain Name System Security Extensions

Для обеспечения безопасности DNS планируется развертывание Domain Name System Security Extensions (DNSSEC). Однако DNSSEC не может оказать противодействие DDoS-атакам и сам по себе может быть причиной amplification-атак.

Атаки на DNS приобрели высокую популярность, поскольку они предоставляют злоумышленникам множество преимуществ:

Ведется атака на критически важную инфраструктуру – DNS-сервер является важным элементом инфраструктуры. Это означает, что если нарушается работа DNS-сервиса организации, отключается весь ее интернет-трафик. На более высоком уровне, если вывести из строя корневые DNS-серверы – весь интернет перестанет функционировать (что попыталась осуществить группа Anonymous в «Операции Blackout»).
Асимметричный характер атаки – асимметричное усиление позволяет атакам на DNS вызвать отказ в обслуживании, пользуясь ограниченными ресурсами и небольшим трафиком.
Сохранение анонимности – не использующий информацию о состоянии протокол DNS позволяет злоумышленникам изменить их IP-адрес источника и легко замаскироваться. Используя метод отражения, злоумышленник даже не посылает трафик непосредственно на объект атаки. В сегодняшних условиях, после большого количества арестов хакеров и членов группы Anonymous, сохранение анонимности является важным преимуществом.

Разгромный отзыв от Минэкономразвития

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

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

В то же время, даже при отсутствии внешней угрозы, в случае сбоя в работе оборудования Технического центра интернета (операторам реестров доменных зон .RU, .РФ и .SU), разрешение доменных имен в данных зонах станет невозможным. В связи с этим в Минэкономразвития считают целесообразным разработать требования к операторам реестров доменных зон и определить порядок их взаимодействия с операторами реестра корневой зоны интернета.

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

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

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

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

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

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

Примеры настройки dnsmasq

Переходим к основной части инструкции. Приведем примеры использования и соответствующей настройки dnsmasq.

1. Перевод запросов на другой DNS-сервер для определенного домена

Предположим, у нас есть задача — переводить все запросы для имен с доменом consul на другой DNS-сервер, который находится в нашей сети. Также, данный сервер слушает не на стандартном для NS-сервера порту (53), а на порту 8600. Кстати, это реальный пример работы при настройке кластера consul.

Создаем конфигурационный файл:

vi /etc/dnsmasq.d/consul

В него добавим одну строку:

server=/consul/127.0.0.1#8600

* в данном примере мы будем переводить все запросы для домена consul на сервер 127.0.0.1 (в этом примере локальный сервер, но может быть любой) и порт 8600.

Чтобы настройки вступили в силу, перезапускаем dnsmasq:

systemctl restart dnsmasq

2. Настройка кэширования

По умолчанию, dnsmasq работает как кэширующий сервер. Мы же подредактируем настройки.

Создаем конфигурационный файл:

vi /etc/dnsmasq.d/cache

cache-size=10000
all-servers
no-negcache

* где:

cache-size — размер кэша (количество хостов).
all-servers — задает поведение, при котором наш сервер будет отправлять запрос всем доступным ему серверам DNS и принимать ответ от того, кто первый ему ответит.
no-negcache — не кэшировать негативные ответы.

Чтобы настройки вступили в силу, перезапускаем dnsmasq:

systemctl restart dnsmasq

3. Подмена IP-адресов

Есть несколько вариантов подмены IP-адресов в dnsmasq. Для настройки создадим файл:

vi /etc/dnsmasq.d/replacement

В зависимости от ситуации, применяем один из вариантов, описанных ниже.

а) Подмена одного адреса:

alias=1.1.1.1,2.2.2.2

* в данном примере если наш сервер получит ответ 1.1.1.1, он его заменит на 2.2.2.2.

б) Подмена адресов в подсети:

alias=1.1.1.0,2.2.2.0,255.255.255.0

* в данном примере все адреса из подсети 1.1.1.0/24 будут заменены на соответствующие адреса подсети 2.2.2.2/24.

в) Диапазоны:

alias=1.1.1.100-1.1.1.200,192.168.0.0,255.255.255.0

* в данном примере адреса в диапазоне от 1.1.1.100 до 1.1.1.200 будут переопределены в адреса в диапазоне от 192.168.0.100 до 192.168.0.200.

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

Выполняем команду:

systemctl restart dnsmasq

Это, далеко, не все возможности dnsmasq. По мере необходимости, они будут дополняться в данной инструкции.

DNSSEC и логика кэширования

начала понимания DNSSEC нужно зафиксировать один важный момент. Состоит он в том, что эта технология изначально адаптировалась под то, чтобы не быть сильно нагружающей как каналы связи, так и конечные узлы в плане вычислительных возможностей.
Вот смотрите. Наша цель в плане DNSSEC – это подтверждение подлинности и неизменности DNS-данных. Многие считают, что DNSSEC – это “подписанные DNS-зоны”. Но по сути это:

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

Т.е. нам надо, чтобы ответ сервера вида “Запись X разрешилась в адрес Y”, равно как и “Запись X не существует” мог существовать как отдельный объект, кэшироваться, проверяться на подлинность и отсутствие модификаций. Вот всё это DNSSEC будет нам предоставлять.

Теперь время изучить специфичную терминологию.

Как отключить кэширование на стороне клиента

Чтобы отключить кэширование DNS, выполните одну из следующих команд:

чтобы полностью отключить кэш DNS в Windows, используйте средство контроллера служб или средство «службы», чтобы задать для параметра «тип запуска службы DNS-клиента значение» отключено»

обратите внимание, что имя Windows службы DNS-клиента также может отображаться как «днскаче»

Примечание

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

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

когда сопоставитель Windows получает ответ (положительный или отрицательный) на запрос, он добавляет этот ответ в свой кэш и тем самым создает запись ресурса DNS. Сопоставитель всегда проверяет кэш перед запросом DNS-сервера. Если запись ресурса DNS находится в кэше, сопоставитель использует запись из кэша вместо запроса к серверу. Такое поведение ускоряет запросы и уменьшает сетевой трафик для запросов DNS.

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

Эта команда отображает содержимое кэша сопоставителя DNS, включая записи ресурсов DNS, предварительно загруженные из файла Hosts, и все недавно запрошенные имена, разрешенные системой. Через некоторое время сопоставитель отклоняет запись из кэша. Период времени указывается значением срока жизни (TTL) , связанным с записью ресурса DNS. Кэш также можно очистить вручную. После очистки кэша компьютер должен снова запрашивать DNS-серверы для любых записей ресурсов DNS, которые ранее были разрешены компьютером. Чтобы удалить записи в кэше сопоставителя DNS, выполните команду из командной строки.

Упаковка

Сервер	Создатель	Стоимость ( долл. США )	Открытый исходный код	Лицензия на программное обеспечение
СВЯЗЫВАТЬ	Консорциум Интернет-систем	Бесплатно	да	BSD , MPL 2.0 для 9.11+
Microsoft DNS	Microsoft	Входит в состав Windows Server	Нет	Лицензия Clickwrap
djbdns	Дэниел Дж. Бернштейн	Бесплатно	да	Всеобщее достояние
Dnsmasq	Саймон Келли	Бесплатно	да	GPL
Простой DNS Plus	Программное обеспечение JH	79–379 долларов	Нет	Лицензия Clickwrap
НРД	NLnet Labs	Бесплатно	да	Вариант BSD
Узел DNS	CZ.NIC	Бесплатно	да	GPL
Узел резольвер	CZ.NIC	Бесплатно	да	GPL
PowerDNS	PowerDNS.COM BV / Берт Хьюберт	Бесплатно	да	GPL
MaraDNS	Сэм Тренхолм	Бесплатно	да	Вариант BSD
pdnsd	Томас Мёстль и Пол Ромбоутс	Бесплатно	да	GPL
Посадис	Мейлоф Вининген	Бесплатно	да	GPL
Несвязанный	NLnet Labs	Бесплатно	да	BSD
ЯДИФА	EURid	Бесплатно	да	BSD
Secure64 DNS Authority	Secure64	Неопубликованная цена	Нет	Лицензия Clickwrap
Secure64 DNS-кеш	Secure64	Неопубликованная цена	Нет	Лицензия Clickwrap
DNS-сервер Technitium	Технитум	Бесплатно	да	GPL

Как работает DNS

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня — org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.
Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторизированным сервером DNS, на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Рассмотрим на примере работу всей системы.
Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер знает только IP-адрес сервера DNS, обычно это один из серверов интернет-провайдера. Он спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org?». Сервер DNS обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 поддерживает доменную зону org.» Браузер направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 поддерживает доменную зону wikipedia.org.» Наконец, браузер отправляет свой запрос к третьему DNS-серверу (который является авторизированным сервером для домена wikipedia.org), и получает ответ — IP-адрес. Этот процесс называется рекурсивным поиском.

Имя хоста и IP-адрес не тождественны — хост с одним IP может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество хостов: это позволяет создавать балансировку нагрузки.
Запрос на определение имени обычно не идёт дальше кэша DNS, который помнит (ограниченное время) ответы на запросы, проходившие через него ранее. Организации или провайдеры могут по своему усмотрению организовывать кэш DNS. Обычно вместе с ответом приходит информация о том, сколько времени следует хранить эту запись в кэше.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию. Существует 13 корневых серверов, расположенных по всему миру и привязанных к своему региону, их адреса никогда не меняются, а информация о них есть в любой операционной системе.
Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса.

Windows серверов 2000 и Windows Server 2003, не в составе

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

Типы ресурсов

Тип ресурса задается в поле <Type> записи
ресурса. Типов ресурсов множество. Полный
их список можно узнать в соответствующих RFC
(см. «Дополнительную информацию»). Ниже
приводятся наиболее используемые типы.

· SOA Начало полномочий (управления)
сервера имен.
· NS Сервер имен.
· A Адрес хоста.
· CNAME Каноническое имя. Используется для
задания псевдонимов.
· HINFO Информация о хосте.
· MX Почтовый шлюз.
· PTR Указатель.

Рассмотрим каждый из этих типов.

SOA (начало полномочий)

Запись с ресурсом типа SOA обозначает
начало зоны управления сервера имен. Зона
управления действует до следующей записи SOA.

ПРИМЕР ЗАПИСИ SOA

<Name>SOA<Origin><Person>(<Serial><Refresh><Retry><Expire><Minimum>)

komtek.dp.ua.INSOAsrv.komtek.dp.ua.root.srv.komtek.dp.ua. (9703083600600360000086400)

Здесь поле <Data> является составным и
включает поля <Origin>, <Person>, <Serial> и т.
д.

<Name> Обозначает имя домена зоны
управления.

<Origin> Имя первичного сервера имен зоны.

<Person> Почтовый ящик лица,
ответственного за зону. Данное поле
формируется аналогично электронному
адресу, но вместо символа «@» ставится
точка (т. е. alex@komtek.dp.ua заменяется на
alex.komtek.dp.ua).

<Serial> Номер версии зоны. Когда
производятся изменения в зоне, то это число
необходимо увеличить. Именно по данному
полю ориентируется вторичный сервер имен,
определяя необходимость обновления
информации по зоне.

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

<Retry> Время в секундах для повторного
обращения вторичного сервера зоны, если
ранее попытка обращения к первичному
серверу была неудачной.

<Expire> Предел времени в секундах. Если
вторичный сервер не может получить доступ к
первичному в течение этого времени, то он
будет считать информацию по зоне
устаревшей.

<Minimum> Значение TTL в записях ресурсов
данной зоны по умолчанию, т. е. когда поле <TTL>
пустое.

NS (сервер имен)

Запись с ресурсом типа NS обозначает имя
хоста, являющегося первичным сервером имен
для домена.

ПРИМЕР ЗАПИСИ NS

NS<Server>

komtek.dp.ua.NSsrv1.komtek.dp.ua.NSsrv2.komtek.dp.ua.

<Domain> обозначает домен, а <Server> — имя
сервера имен. В примере показывается, что
серверы srv1.komtek.dp.ua и srv2.komtek.dp.ua представляют
собой серверы имен домена komtek.dp.ua.

A (адрес)

Запись с ресурсом типа A служит для
задания сетевого адреса хоста. Здесь <Host>
— доменное имя хоста, а <Address>- его IP-адрес.

ПРИМЕР ЗАПИСИ A

A<Adress>
sri-nic.arpa.A10.0.0.51

CNAME (каноническое имя)

Запись с ресурсом типа CNAME применяется для
указания псевдонима хоста. <Nickname>
обозначает псевдоним, а <Host> —
официальное (каноническое) имя хоста.

ПРИМЕР ЗАПИСИ CNAME

CNAME<Host>

rs1CNAMEsrv1.komtek.dp.ua.
wwwCNAMEsrv2.komtek.dp.ua
ftpCNAMEsrv2.komtek.dp.ua

Чем опасны DNS-атаки

Атаки на DNS можно условно разделить на две категории.

Первая категория – это атаки на уязвимости в DNS-серверах. С этим подвидом атак связаны следующие опасности:

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

Вторая категория – это DDoS-атаки, приводящие к неработоспособности DNS-сервера. При недоступности DNS-сервера пользователь не сможет попасть на нужную ему страницу, так как его браузер не сможет найти IP-адрес, соответствующий введённому адресу сайта. DDoS-атаки на DNS-сервера могут осуществляться как за счёт невысокой производительности DNS-сервера, так и за счёт недостаточной ширины канала связи. Потенциально DDoS-атаки второго вида могут иметь мощность до 70 Гбит/с при использовании техник наподобие DNS Amplification и пр.

Причина

Копия Active Directory в некоторых контроллерах домена содержит ссылки на другие контроллеры домена в лесу. Эти контроллеры домена пытаются реплицировать все локальные разделы каталогов во время Windows запуска, в рамках начальной синхронизации или синхронизации init.

В попытке загрузки с последним контентом зоны DNS серверы Microsoft DNS, на которые встроены AD-копии зон DNS, задерживают запуск службы DNS на несколько минут после Windows запуска. Задержка не произойдет, если Active Directory выполнил первую синхронизацию во время Windows запуска. Тем временем Active Directory задерживается из-за входящие разделы репликации каталогов. Репликация отложена до тех пор, пока она не сможет разрешить GUID CNAME своего контроллера исходных доменов на IP-адрес на DNS-серверах, используемых контроллером домена назначения для разрешения имен. Длительность зависания при подготовке сетевых подключений зависит от количества локальных разделов каталогов, проживающих в копии Active Directory контроллера домена. Большинство контроллеров домена имеют по крайней мере следующие пять разделов:

схема
configuration
domain
раздел приложения DNS в лесу
раздел приложения DNS для всей области домена

И эти контроллеры домена могут испытывать задержку запуска на 15-20 минут. Наличие дополнительных разделов увеличивает задержку запуска.

DNS Event ID 4013 в журнале событий DNS указывает на задержку запуска службы DNS. Это происходит из-за того, что входящие репликации разделов Active Directory не происходили.

Несколько условий могут усугубить следующие проблемы:

медленное Windows запуска
ведение журнала событий DNS 4013 на DNS-серверах, настроенных для зоны, интегрированной с AD, которые неявно находятся на компьютерах, действующих в качестве контроллеров домена.

К этим условиям относятся следующие условия:

Настройка DNS-сервера, на который размещены зоны DNS, интегрированные с AD. Его копия Active Directory содержит знания других контроллеров домена в лесу, чтобы указать на себя исключительно для разрешения имен DNS.
Настройка DNS-сервера, на который размещены зоны DNS, интегрированные с AD. Его копия Active Directory содержит знания о других контроллерах домена в лесу, чтобы указать DNS-серверы, которые либо не существуют, в настоящее время находятся в автономном режиме, не доступны в сети, либо не содержат необходимые зоны и записи, необходимые для входящие репликации Active Directory. Примеры включают запись GUID контроллера домена CNAME и соответствующую запись A или AAAA потенциальных контроллеров домена источника.
Загрузка контроллера домена и DNS-сервера с зонами DNS, интегрированными с AD. Его копия Active Directory содержит знания других контроллеров домена о том, что является эффективной изолированной сетью, так как:
- Сетевой адаптер или сетевой стек на вызываемом или целевом компьютере отключен или нефункционарен.
- Контроллер домена загружается в изолированную сеть.
- Копия Active Directory локального контроллера домена содержит ссылки на устаревшие контроллеры домена, которые больше не существуют в сети.
- Копия Active Directory локального контроллера домена содержит ссылки на другие контроллеры домена, которые в настоящее время отключены.
- Существует проблема в контроллере домена источника, контроллере домена назначения или DNS или сетевой инфраструктуре. Таким образом, копия Active Directory контроллера домена локального домена содержит ссылки на другие контроллеры домена, которые находятся в Интернете и доступны, но не могут быть успешно реплицированы из.

В Windows Server 2003 и Windows 2000 Server SP3 или более поздней модели контроллеры домена, принимающие главные роли операций, также должны успешно реплицировать входящие изменения в раздел каталога, который поддерживает состояние роли магистрали операций. Перед выполнением операций, зависящих от FSMO, необходимо выполнить успешную репликацию. Такие начальные синхронизации были добавлены, чтобы убедиться, что контроллеры домена были в согласии с владением ролью FSMO и состоянием ролей. Начальные требования к синхронизации, необходимые для работы ролей FSMO, отличаются от начальной синхронизации, о которой говорится в этой статье, когда Active Directory должен входящие репликации, чтобы немедленно запустить службу DNS Server.

Атаки на DNS

подмена DNS или «отравление» кэша: использование уязвимости системы для управления кэшем DNS с целью перенаправления пользователей в другое место
DNS-туннелирование: в основном используется для обхода средств защиты от удаленных подключений
перехват DNS: перенаправление обычного трафика DNS на другой целевой DNS-сервер путем изменения регистратора домена
атака NXDOMAIN: проведение DDoS-атаки на авторитетный сервер DNS путем отправки неправомерных доменных запросов для получения принудительного ответа
фантомный домен: заставляет DNS-преобразователь (DNS resolver) ждать ответа от несуществующих доменов, что приводит к снижению производительности
атака на случайный субдомен: взломанные хосты и ботнеты проводят DDoS-атаку на действующий домен, но сосредотачивают огонь на ложных субдоменах, чтобы принудить DNS-сервер выполнять поиск записей и захватить управление над службой
блокировка домена: представляет собой отправку множества спам-откликов для блокировки ресурсов DNS-сервера
ботнет-атака с абонентского оборудования: совокупность компьютеров, модемов, роутеров и других устройств, концентрирующих вычислительную мощность на определенном веб-сайте для его перегрузки запросами трафика

Включаем EDNS0 на Windows Server

Включение механизма EDNS0 не так очевидно, как кажется. Первое, что надо отметить – Ваш сервер, если это Windows Server 2003 и выше, умеет принимать и обрабатывать EDNS0-ответы – т.е. не пугается ни бОльшего размера датаграммы, ни наличия специфичной OPT-записи. А начиная с Windows Server 2008 R2, механизм EDNS включен по умолчанию. Включать же мы будем, фактически, добавление в запросы другим DNS-серверам дополнительной “тестовой” OPT-записи. Цель – чтобы по их ответу на этот запрос было понятно, поддерживают они EDNS0 или нет.

Для включения этого механизма, EDNS Probes, да и вообще работы с EDNS, у нас будет специальный субконтекст – edns:

Работа с EDNS0 через ATcmd(кликните для увеличения до 677 px на 343 px)Учебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/

Включим механизм командой :

Включаем EDNS probes в Windows Server(кликните для увеличения до 677 px на 343 px)Учебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/

Совет по части этого параметра будет простым – включайте его со стороны своего сервера только убедившись, что “большие” EDNS-ответы технически могут добраться до него снаружи. Ключевое – разница между “наш сервер поддерживает и декларирует остальным серверам, что умеет” и “технически возможно прохождение датаграммы бОльшего размера, чем 576 байт”. Плохо, если Ваш сервер будет всем показывать, что может, но отправляемые ему датаграммы будут теряться, не доходя до него.

Тестим EDNS0, используя автоматизированную утилиту ATcmd

Для упрощения тестирования в ATcmd есть диагностический контекст – test, в котором поддерживается несколько типовых сценариев опроса DNS-серверов на предмет поддержки EDNS0:

Режимы тестирования EDNS в ATcmd(кликните для увеличения до 859 px на 454 px)Учебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/

Это режим local, когда утилита автоматически тестирует все DNS-сервера данного хоста, режим прямого указания одиночного IP-адреса сервера и режим, когда указывается FQDN домена Active Directory – и утилита последовательно подключается к NS-серверам и тестирует их. Данный режим очень удобен для больших предприятий, и позволяет увидеть работоспособность EDNS-обмена с различными серверами с точки зрения конкретного хоста.

В общем, думаю, Вы оценили количество потенциальных проблем, которые будут, если оставить данный вопрос на самотёк – поэтому пора приступать к настройкам работы EDNS0 в сети предприятия.

Что такое и зачем нужен EDNS0

Что же добавляет EDNS0? В принципе, основным нововведением в нём является добавление нового типа псевдо-записи – OPT. Это специфичный тип RR-записи, которая не несёт DNS-данные (поэтому и “псевдо”), а нужна исключительно для стандартизации обмена служебной информацией. В подавляющем большинстве случаев использования в ней передаётся один блок информации – запись о максимальном обрабатываемом размере DNS-датаграммы.

Данный пункт действительно является важнейшим по простой причине – так как на момент разработки DNS сети были ещё очень медленные, а также в них было множество устаревших на данный момент протоколов канального уровня (сильно различавшихся технически и логически), то датаграмма DNS, в целях повышения её выживаемости в ходе путешествия по Интернету, ограничена размером в 512 байт (чтобы вместе с заголовками транспортного и сетевого уровня не первышать 576 байт). По сути, всё сделано для того, чтобы датаграмма выжила в среде с самым мелким MTU и без поддержки фрагментации. Понятное дело, что в современной ситуации, когда в DNS-ответ может быть добавлена пачка адресов (одно имя теперь часто, для отказоустойчивости, разрешается в несколько адресов сетевого уровня), притом крупных в плане занимаемого места – например, IPv6, ну и всякие дополнительные данные, например DNSSEC’овские RRSIG и DSKEY, да или просто TXT, такое ограничение (“не более 512 байт DNS-данных а то вдруг не дойдёт”) крайне неудобным.

Неприятностей добавляет простая проблема, исходящая из природы UDP – дело в том, что в случае отправки запроса или ответа отправитель, в случае тишины после, никак не сможет понять, что произошло – был ли пакет потерян по случайной причине, или отброшен промежуточным узлом по причине несоответствия максимальному размеру MTU, или потерялся по причине необходимости фрагментации на каком-то отрезке пути, а фрагментация DNS-пакета не получилась, или какой-либо другой. Плюс не надо забывать, что датаграммы от клиента к серверу, а после – в обратном направлении, совершенно необязательно будут идти по одной и той же трассе. В результате возможно множество различных неприятных ситуаций, вида “клиент отправил запрос серверу – сервер отработал, отправив ответ – ответ не дошёл, потому что великоват в части MTU, а клиент ошибочно думает, что сервер технически недоступен”, или “сервер отправил запрос другому серверу – запрос не дошёл, потому что тот сервер не поддерживает EDNS0 – клиент, изначально отправивший запрос, предполагает, что ближайший к нему сервер не работает, т.к. прошёл тайм-аут ожидания ответа”, и многих других. Поэтому понимание и представление о том, как всё это работает, резко помогает понять множество “странных багов DNS”.

Давайте попробуем протестировать работу EDNS0.