Рекурсия dns сервера как настроить

Настройка рекурсивной службы DNS

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

После того как вы установите Plesk, встроенный DNS-сервер будет принимать рекурсивные запросы только от вашего собственного сервера и других серверов в вашей сети. Это оптимальные настройки. Если вы обновили Plesk с более ранней версии, вы можете настроить свой DNS-сервер на обслуживание рекурсивных запросов с любого хоста.

Если вы хотите изменить настройки рекурсивной службы доменных имен:

Перейдите на страницу Инструменты и настройки > Шаблон DNS > Настройки рекурсии DNS.
Выберите нужную опцию:
- Чтобы разрешить обслуживание рекурсивных запросов со всех хостов, выберите Any host.
- Чтобы разрешить обслуживание рекурсивных запросов с вашего сервера и хостов из вашей сети, выберите Localnets.
- Чтобы разрешить обслуживание рекурсивных запросов только с вашего сервера, выберите Localhost.
Нажмите OK.

Источник

Понятие DNS рекурсии

Посетителей: 22994 | Просмотров: 29788 (сегодня 4) Шрифт:

Основная концепция преобразования DNS названий достаточно проста. Каждому веб сайту присваивается уникальный IP адрес. Для доступа к веб сайту клиенту необходимо знать этот IP адрес сайта. Конечно, пользователь обычно не вводит IP адрес в своем браузере Web browser, а вместо этого вводит название домена сайта (domain name). Для доступа к запрашиваемому веб сайту браузер (Web browser) должен уметь преобразовывать название домена сайта (domain name) в соответствующий ему IP адрес. В этом месте в игру вступает DNS. На клиентском компьютере настроен адрес предпочтительного сервера DNS (preferred DNS server). Запрашиваемый URL передается на сервер DNS, а сервер DNS возвращает IP адрес для запрашиваемого веб сайта. После этого клиент может обратиться к запрашиваемому сайту.

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

Предпочтительный метод преобразования имени в адрес называется рекурсией (recursion). Если говорить в общем, то рекурсия это процесс, при котором сам сервер DNS отправляет запросы на другие сервера DNS, для того чтобы затем по обратной цепочке передать ответ клиенту, который совершил запрос. В общем, DNS сервер становится DNS клиентом. Некоторые администраторы предпочитают отключить рекурсию в целях увеличения производительности. Если рекурсия отключена, то сервер DNS использует процесс, называемый итерация (iteration), для обработки запроса.

Root Hints

Если сервер DNS не знает адрес запрашиваемого сайта, то он передает запрос другому серверу DNS. Для этого сервер DNS server должен знать IP адрес другого сервера DNS, которому он может передать запрос. Это задача корневых подсказок (root hints). Корневые подсказки предоставляют список IP адресов DNS серверов, которые находятся на корневом уровне (root level) иерархии DNS.

Хорошая новость заключается в том, что корневые подсказки (root hints) заранее настроены на DNS серверах, работающих под управлением операционной системы Windows Server 2003. Корневые подсказки (root hints) хранятся в файл под названием CACHE.DNS, который находится в папке \Windows\System32\Dns. Если вы хотите узнать, как выглядят корневые подсказки, то вы можете открыть этот файл в блокноте (Notepad). Как вы можете увидеть на рисунке A, файл с корневыми подсказками представляет собой ничто иное, чем обыкновенный текстовый файл, в котором попарно расположены DNS сервера и их IP адреса.

Рисунок A : Корневые подсказки соответствуют DNS серверам корневого уровня и их IP адресам

Теперь давайте поговорим о том, что такое корневые подсказки, что они делают, а также рассмотрим процесс рекурсии (recursion process) в действии. Диаграмма, изображенная на рисунке B иллюстрирует пример, о котором я хочу вам рассказать.

Рисунок B : Так работает DNS рекурсия (recursion)

Процесс начинается с того, что пользователь вводит URL в своем браузере (Web browser). В нашем примере давайте предположим, что пользователь ввел в качестве URL следующий адрес www.contoso.com. После этого запрос на преобразование названия домена Contoso.com в IP адрес передается на предпочтительный сервер DNS (preferred DNS server), который задан на рабочей станции. Очень часто в КЭШе предпочтительного сервера DNS (preferred DNS server) уже содержится запрашиваемая запись, но в этом примере давайте предположим, что на нашем предпочтительно сервере DNS нет информации относительно сайта CONTOSO.COM.

Если предположить также, что включена DNS рекурсия, то сервер DNS server начинает работать в роли DNS клиента и отправляет серию итерационных запросов на другие сервера DNS. Я объясню разницу между итеративным (iterative) и рекурсивным (recursive) запросом позднее, а сейчас просто представьте, что в целом процесс считается рекурсивным потому, что клиент отправляет лишь один запрос на предпочтительный сервер DNS (preferred DNS server).

В любом случае, предпочтительный сервер DNS на рабочей станции не знает IP адреса веб сайта www.contoso.com, и не знает IP адрес сервера DNS, которые отвечает за домен Contoso.com (а поэтому знает IP адрес сайта www.contoso.com). Все что знает DNS сервер, лишь IP адрес DNS сервера корневого уровня (благодаря файлу с корневыми подсказками). Поэтому предпочтительный сервер DNS (preferred DNS server) передает запрос корневому серверу DNS (root DNS server).

Корневой сервер DNS (root DNS server) также не знает IP адрес веб сервера www.contoso.com. Он лишь знает IP адрес сервера DNS server, который отвечает за домен .COM domain. Корневой сервер root DNS server передает IP адрес сервера DNS, который отвечает за домен .COM domain предпочтительному серверу DNS. Предпочтительный сервер DNS после этого передает клиентский запрос на сервер DNS домена .COM. Сервер DNS домена .COM не знает IP адрес сайта www.contoso.com, но он знает IP адрес сервера DNS, который отвечает за домен Contoso.com. Сервер домена .com возвращает IP адрес сервера DNS, который отвечает за домен Contoso.com предпочтительному серверу DNS. Предпочтительный сервер DNS клиента, затем посылает запрос DNS серверу домена Contoso.com, который в свою очередь возвращает IP адрес запрашиваемого веб сайта. Этот адрес затем передается клиенту, который его запросил.

В этом примере необходимо обратить внимание на две вещи. Во-первых, как я уже объяснял ранее, клиент совершает лишь один запрос DNS. Он абсолютно ничего не знает об итеративных запросах сервер DNS. Во-вторых, сервер DNS, который отвечает за домен CONTOSO.COM вовсе не обязательно принадлежит Contoso. Обычно, этот сервер DNS принадлежит компании, занимающейся веб хостингом (Web hosting company) и отвечает за все сайты, принадлежащие этой компании. Именно поэтому предпочтительный сервер DNS (preferred DNS server) не может пропустить один шаг и сразу передать клиенту адрес DNS сервера, который отвечает за домен, по крайней мере не в нашем случае.

Если сервер DNS не поддерживает рекурсивные очереди (recursive queries), то клиент по умолчанию будет выполнять итеративные запросы (iterative queries).

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

Заключение

В этой статье я рассказал о том, как работает рекурсивная очередь DNS (recursive DNS query). Большинство серверов DNS поддерживают, как рекурсивные (recursive), так и итеративные запросы от клиентов. Если вы настроите ваш сервер DNS на поддержку рекурсивных очередей (recursive queries), то в общем сможете добиться лучшей производительности, т.к. благодаря этому можно добиться снижению количества запросов, которые должен совершить сетевой клиент.

Источник

Отключение рекурсии на DNS-сервере

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

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

Минимальным требованием для выполнения этой процедуры является членство в группе Администраторы или наличие эквивалентных прав. Подробные сведения об использовании соответствующих учетных записей и членства в группах см. на странице https://go.microsoft.com/fwlink/?LinkId=83477 .

Отключение рекурсии на DNS-сервере

Чтобы отключить рекурсию на DNS-сервере с помощью интерфейса Windows

Откройте диспетчер DNS.

В дереве консоли щелкните правой кнопкой мыши необходимый DNS-сервер и выберите Свойства.

Перейдите на вкладку Дополнительно.

В группе Параметры сервера установите флажок Отключить рекурсию и нажмите кнопку ОК.

Дополнительные сведения

Чтобы открыть диспетчер DNS, нажмите кнопку Пуск, выберите Администрирование, затем щелкнете DNS.

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

Чтобы отключить рекурсию на DNS-сервере с помощью командной строки

Откройте окно командной строки.

Введите указанную ниже команду и нажмите клавишу ВВОД.

Имя средства командной строки, предназначенного для управления DNS-серверами.

Обязательный компонент. DNS-имя узла, на котором содержится DNS-сервер. Также можно ввести IP-адрес DNS-сервера. Чтобы указать DNS-сервер на локальном компьютере, можно ввести точку (.).

Обязательный компонент. Настройка указанного сервера с помощью этой команды.

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

Обязательный компонент. Чтобы отключить рекурсию, введите 1 (отключено). Чтобы включить рекурсию, введите 0 (включено). По умолчанию рекурсия включена.

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

Дополнительная информация

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

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

Источник

Открытый рекурсивный DNS-сервер. Часть 2

Практически 4 месяца назад я открыл свой рекурсивный DNS-сервер для всех пользователей интернет (см. предыдущую статью). Накопленный объем данных на первом этапе теста был достаточно большим, для его визуализации я загнал данные в БД и построил динамические изменяющиеся графики и карту. Записанное видео можно посмотреть под катом. Результат получился достаточно интересным, поэтому полностью закрывать DNS-сервер я не стал, а ограничился включением зон (используемых для атак) в списки RPZ (что такое RPZ можно прочитать в этой статье). «Расслабившись» на «небольших» атаках (не более 100 запросов в секунду), я не заблокировал ответы по двум DNS-зонам и получил первый abuse-репорт. Abuse-репорт был отправлен в дата-центр моего провайдера от «робота». Нагрузка на его сеть с моего сервера была небольшой и периодически доходила до 100 запросов в секунду. С учетом того, что могли использоваться миллионы открытых ресолверов, то максимальная нагрузка на его сеть могла быть значительной. Abuse-репорт и замотивировал меня перейти к второй части теста. Отключив открытый рекурсивный DNS и продолжил наблюдать за поведением атакующих.

Визуализация атаки описанной в первой статье:

Описание тестовой среды

При написании прошлой статьи все данные собирались и обрабатывались практически в ручном режиме. Это было долго, нудно и результаты иногда приходилось перепроверять. Так как я достаточно ленив, мне нравится автоматизировать процессы и анализировать данные, то самим собой напросился вывод создать небольшую систему отчетности и анализа поступающих логов с DNS-сервера в режиме близкому к real time (если это интересно, то могу описать в отдельной статье). Все графики и таблицы, использованные в данной статье, были сгенерированы с использованием jqPlot, jqGrid и сервиса Google Maps. В качестве DNS-сервера я использую виртуальное устройство Infoblox, но формат syslog-сообщений у него аналогичен bind.

Атаки

За время проведения тестирования мой сервер использовался для проведения DrDoS атак (Amplification + Reflection), а так же были произведены попытки осуществить отравление кэша. По некоторым запросам было видно, что используется механизм DGA (Domain Generation Algorithm) возможно для отравления кэша, возможно для связи с управляющими центрами (так как эти домены использовались только для атак) или при атаке с фантомными доменами.

После отключения рекурсивного сервера паразитная нагрузка снизилась, но не исчезла совсем.

Пиковая нагрузка на «открытом» сервере доходила до 3 тысяч запросов в секунду и в среднем держалась около 100 запросов в секунду, на закрытом сервере максимальная нагрузка снизилась до 20 запросов в секунду с редкими пиками до 100 запросов (rate limit настроен до 300 запросов в минуту с возможностью роста до 1000).

Как видно на графике ниже, от действий злоумышленников больше всего пострадали компании в США.

Анализ количества отправленных запросов в сеть каждой компании может косвенно помочь определить жертвы и возможные зараженные сети. Например, сеть China Telecom скорее всего заражена, а клиент Ростелекома был атакован. В таблице ниже приведена информация организациям, количеству IP-адресов и количеству обработанных запросов. Данные о компаниях были получены с помощью сервиса whois.

Параметр	Описание

Страна	Компания	Кол-во запросов	Кол-во IP
United States	SoftLayer Technologies Inc.	3965202	36
United States	SingleHop, Inc.	2617987	27
United States	PSINet, Inc.	1994461	22
France	OVH SAS	1051080	304
United Kingdom	Hosting Services Inc	938367	4
Germany	1&1 Internet AG	761020	12
United States	PrivateSystems Networks	748641	4
Russian Federation	OJSC Rostelecom Ticket 09-39331, RISS 15440, UrF	687028	1
United States	Time Warner Cable Internet LLC	671211	1568
Canada	OVH Hosting, Inc.	592920	213
United States	Akamai Technologies, Inc.	176327	4410
China	China Telecom	51565	207
United States	AT&T Internet Services	27502	854

Атака DrDOS

Для атаки были использованы домены приведенные в таблице ниже. Домен freeinfosys.com появился уже после «закрытия» рекурсивного сервера. Что может означать, что кто-то использует устаревшие базы, которые редко проверяются.
Чтобы определить, что ваш сервер атакуется или используется для проведения атак достаточно проанализировать к каким доменам и как часто обращались с запросом «ANY +E».

Домен	Запрос	Флаг	Кол-во запросов
webpanel.sk	ANY	+E	14962032
oggr.ru	ANY	+E	8300693
energystar.gov	ANY	+E	6676350
doleta.gov	ANY	+E	6326853
067.cz	ANY	+E	2463053
sema.cz	ANY	+E	1251206
GUESSINFOSYS.COM	ANY	+E	690320
jerusalem.netfirms.com	ANY	+E	587534
paypal.de	ANY	+E	454756
nlhosting.nl	ANY	+E	414113
freeinfosys.com	ANY	+E	352233
krasti.us	ANY	+E	333806
doc.gov	ANY	+E	259248
svist21.cz	ANY	+E	231946
wradish.com	ANY	+E	117294

При использовании «ANY +E» запрашивается вся информация по зоне и активируется функционал EDNS, чтобы получить максимально возможный размер UDP пакета. Список 10 наиболее частых запросов и их флагов приведен в таблице ниже.

Запрос	Флаги	Кол-во запросов
ANY	+E	43500439
A	-ED	17339
ANY	+	11932
A	—	9853
A	-EDC	8956
AAAA	-EDC	4749
AAAA	-ED	4467
ANY	—	2289
A	+E	1899
RRSIG	+E	1124

Cache Poisoning, Random domain attack и DGA

В процессе работы DNS сервера были выявлено небольшое количество атак на отравление кэша. В статистике работы DNS-сервер Infoblox было указано, что были получены ответы с неправильными портами и query ID, но, к сожалению, log-файлы для анализа не сохранились.

Помимо этого были обнаружены подозрительные запросы вида:

ndnaplaaaaeml0000dgaaabbaaabgnli.energystar.gov;
mmokojaaaaeml0000dgaaabbaaabgclm.doleta.gov;
oaanjeaaaaesc0000deaaabbaaabicoc.webpanel.sk;
cnklipaaaaesh0000claaabbaaabfgoa;
2d852aba-7d5f-11e4-b763-d89d67232680.ipvm.biz.

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

Источник