Comments 46
хабракат поставьте
Следующим шагом идёт наращивание мощностей самого сервера. Данным методом счастье тоже достигается, но при
стабильном росте абонентской базы оно быстро заканчивается.
Мне даже интересно стало, это сколько же у вас народу пользуется DNS и какой у вас рекурсор используется.
40k пользователей, сейчас стоит штатный bind
rndc status
recursive clients: 268/14900/15000
да, бинд достаточно быстр, работает по алгоритму конечного автомата. У меня 15к обслуживает и проц на 2-3% загружен.
Как мы все прекрасно понимаем, дело не в пользователях а в их запросах, и в отсутствии штатных средств ограничивать аппетиты конечного пользователя.
Дело в том, что например в том же bind есть только одна опция которая может быть полезна — ограничение общего количества рекурсивных запросов, но что произойдет с bind-ом когда все эти запросы сделает один клиент? Правильно. Он просто перестанет обрабатывать валидные запросы других клиентов.
На самом деле это огромная проблема.
Дело в том, что например в том же bind есть только одна опция которая может быть полезна — ограничение общего количества рекурсивных запросов, но что произойдет с bind-ом когда все эти запросы сделает один клиент? Правильно. Он просто перестанет обрабатывать валидные запросы других клиентов.
На самом деле это огромная проблема.
ну, в вашем случае лимит на ip тоже может охреначить большую сетку за NAT-ом или нижестоящий кеш-dns-сервер.
Выкиньте bind и возьмите unbound. Без всякого шаманства 4% загрузки CPU на Core 2 Duo. Правда еще память еще любит щас полгига выжирает. Статистика:
Порядка 20k клиентов.
total.num.queries=703792251
total.num.cachehits=485271820
total.num.cachemiss=218520431
total.num.recursivereplies=217160216
total.requestlist.avg=82.2027
total.requestlist.max=1222
total.requestlist.overwritten=1424
total.requestlist.exceeded=1353691
total.requestlist.current.all=84
total.requestlist.current.user=83
total.recursion.time.avg=15.325532
total.recursion.time.median=0.0985865
Порядка 20k клиентов.
Вы можете ограничить в unbound количество запросов от каждого клиента? Насколько я знаю — нет.
Вы просто отсрочили ту же самую проблему, когда один клиент со скоростью в 100Мбит/s начинает тупо валить ваш DNS вполне валидными DNS запросами.
Вы просто отсрочили ту же самую проблему, когда один клиент со скоростью в 100Мбит/s начинает тупо валить ваш DNS вполне валидными DNS запросами.
ну, тут вам файервол не поможет тоже, если канал забьют.
Вы можете ограничить в unbound количество запросов от каждого клиента? Насколько я знаю — нет.
Я не считаю это нужным.
когда один клиент со скоростью в 100Мбит/s начинает тупо валить ваш DNS вполне валидными DNS запросами.
В случае если такие клиенты есть и они забивают канал ваше решение не поможет. Думаю вы сами можете догадаться почему. А вот использование в качестве рекурсора bind верный путь продолжать вкладывать деньги в конфигурацию машины.
Вы поймите, что абсолютно не Важно какое название у вашего рекурсивного DNS сервера.
Если при максимальном количестве запросов к вашему серверу X, любой из Ваших пользователей может сделать X+1 запрос, то название Вашего DNS сервера меня не интересует :)
Если при максимальном количестве запросов к вашему серверу X, любой из Ваших пользователей может сделать X+1 запрос, то название Вашего DNS сервера меня не интересует :)
А вас при этом не интересует, что ваш метод спасает только от тупняка сервера при такой атаке? И то тупняк возникает из-за использования bind? Ну и собственно что если пакет запроса от клиента пришел и был отброшен на сервере, то проблему DOS атаки по забиванию канала это не решает.
вам правильно говорят. зачем делать сложные штуки с менеджментом запросов, когда можно сделать простой и реактивный резолвер на почти _любом_ относительно современном железе?
вы озадачиваетесь странными вещами, ресурс днс-сервера копеечен. в случае с анбаундом и правильно приложенным напильником вообще можно сказать бесплатен.
не понятно зачем что-то ограничивать, если это не мешает и ресурс настолько дешев. ну и конечно как рассказывать абонентам про кончившийся их ресурс днс-запросов и не открывающийся vkontakte.ru. Ж)
коли уж сами не можете приготовить годный рекурсер, отдайте абонентам на растерзание какие публичные, например, гугловские.
ps: на месте ваших абонентов я бы поднял свой собственный рекурсер с блэкджеком и шл… :)
вы озадачиваетесь странными вещами, ресурс днс-сервера копеечен. в случае с анбаундом и правильно приложенным напильником вообще можно сказать бесплатен.
не понятно зачем что-то ограничивать, если это не мешает и ресурс настолько дешев. ну и конечно как рассказывать абонентам про кончившийся их ресурс днс-запросов и не открывающийся vkontakte.ru. Ж)
коли уж сами не можете приготовить годный рекурсер, отдайте абонентам на растерзание какие публичные, например, гугловские.
ps: на месте ваших абонентов я бы поднял свой собственный рекурсер с блэкджеком и шл… :)
Классно, вот как раз супер реактивного ресолвера мне то и не хватает для DNS туннелей.
Причем денег я вам платить не буду, а буду сидеть вечно в отключенном состоянии и гонять трафик поверх вашего реактивнейшего DNS ресолвера — побольше бы таких администраторов.
С чего Вы взяли, что режутся валидные DNS запросы? Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.
Причем денег я вам платить не буду, а буду сидеть вечно в отключенном состоянии и гонять трафик поверх вашего реактивнейшего DNS ресолвера — побольше бы таких администраторов.
С чего Вы взяли, что режутся валидные DNS запросы? Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.
я вас умаляю, днс-туннеленг был актуалет наверно годы назад, когда интернет еще был медленным, дорогим и помегобайтным… но в те славные времена только особо отмороженные делали трафик до днс-сервера бесплатным. :)
а нынче цены вопроса 8 мегабит даже в моей деревне гроши, пускай и не гарантированных 8 мегабит. кому оно надо то возиться с днс-туннелингом?
>С чего Вы взяли, что режутся валидные DNS запросы?
а как вы отличаете валидные/невалидные? в статье вы всего лишь по оффсету определяете _тип_ запроса.
>Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.
100 запросов за 10 секунд? т.е. 10 запросов в секунду? ) ну может быть. однако, днс-туннелинг слабый аргумент в пользу этих танцев :) может лучше вообще каждому клиенту ставить свой рекурсер, рас уж такая параноя о днс-туннелях пошла Ж)
а нынче цены вопроса 8 мегабит даже в моей деревне гроши, пускай и не гарантированных 8 мегабит. кому оно надо то возиться с днс-туннелингом?
>С чего Вы взяли, что режутся валидные DNS запросы?
а как вы отличаете валидные/невалидные? в статье вы всего лишь по оффсету определяете _тип_ запроса.
>Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.
100 запросов за 10 секунд? т.е. 10 запросов в секунду? ) ну может быть. однако, днс-туннелинг слабый аргумент в пользу этих танцев :) может лучше вообще каждому клиенту ставить свой рекурсер, рас уж такая параноя о днс-туннелях пошла Ж)
>> Пока IPv6 распространён не сильно, можно оставить данный тип запросов к нашему DNS серверу, ограничив двумя запросами в 10 секунд от каждого из клиентов, чтобы пустые запросы типа AAAA localhost. не влияли на работу DNS сервера.
Вот от таких решений и задерживается введение IPv6.
«Пока» у горе-админов это = «пока петух в жопу не клюнет».
Начитаются и забудут же, а потом будут кричать что IPv6 плохой и глючный.
Вот от таких решений и задерживается введение IPv6.
«Пока» у горе-админов это = «пока петух в жопу не клюнет».
Начитаются и забудут же, а потом будут кричать что IPv6 плохой и глючный.
Я не говорю что IPv6 это плохо, IPv6 это хорошо, можно и красиво, но десятки клиентов которые «ложат» Ваш DNS сервер запросами типа AAAA? localhost. это действительно плохо.
Я не предлагаю убивать IPv6 я предлагаю вводить адекватные ограничения на использование DNS запросов определенных типов.
P.S. спасибо, что дочитали статью хотя бы до этого момента.
Я не предлагаю убивать IPv6 я предлагаю вводить адекватные ограничения на использование DNS запросов определенных типов.
P.S. спасибо, что дочитали статью хотя бы до этого момента.
Трафик то все равно будет идти, ответ на такой запрос у нормального рекурсора использует меньше ресурсов чем правило iptables.
P.S. Статью я прочитал полностью. Местами по делу, но местами очень спорно.
P.S. Статью я прочитал полностью. Местами по делу, но местами очень спорно.
> Запись SRV (server selection) указывает на серверы для сервисов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.
Вообще-то данные запросы направляют Jabber-клиенты.
Вообще-то данные запросы направляют Jabber-клиенты.
В статье с громким названием «Производительный рекурсивный DNS сервер» сначала рассказывается, что такое A и MX запись, а потом даются советы как дропать запросы для того что бы «производительный сервер» на упал.
Мне одному кажется, что здесь что то неправильно? =)
Мне одному кажется, что здесь что то неправильно? =)
Вам одному.
Проблема в том, что введение адекватных ограничений это единственный метод борьбы с DNS флудом.
В большинстве случаев даже завирусованный вусмерть клиент этих ограничений не заметит, а вот спам бот который будет пытаться ресолвить MX, не сможет это делать так быстро, как он этого хочет.
Проблема в том, что введение адекватных ограничений это единственный метод борьбы с DNS флудом.
В большинстве случаев даже завирусованный вусмерть клиент этих ограничений не заметит, а вот спам бот который будет пытаться ресолвить MX, не сможет это делать так быстро, как он этого хочет.
Вы netflow собираете? думаю, что да. Так почему бы просто не длочить сразу DNS флудеров? За одно будете держать в разумный пределах количество спам ботов (заблоченные подсетки итд).
А статью надо было назвать «Как блокировать нежелательный DNS трафик».
А статью надо было назвать «Как блокировать нежелательный DNS трафик».
По поводу названия погорячился :)
Netflow безусловно собирается. Поясните мысль по поводу блокировки на основании netflow.
Netflow безусловно собирается. Поясните мысль по поводу блокировки на основании netflow.
Смысл в том, что бы на основе netflow генерировать список аккаунтов для блокировки. Можно обращать внимание как на количество DNS запросов, так и на трафик в сторону MX серверов. На основе этих данных разбираться с флудерами (банить, ограничивать, помогать избавиться от ботов).
Более конкретно к сожалению не могу, через час на поезд, да и остальное надо смотреть на конкретных реализациях сети.
Более конкретно к сожалению не могу, через час на поезд, да и остальное надо смотреть на конкретных реализациях сети.
«Запись SRV (server selection) указывает на серверы для сервисов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.»
Гм… VoIP софтфоны и шлюзы, например, делают SRV запросы далеко не только в целях отладки. Но ограничение вполне достаточно для клиента, да.
Гм… VoIP софтфоны и шлюзы, например, делают SRV запросы далеко не только в целях отладки. Но ограничение вполне достаточно для клиента, да.
Зачем запрещать dns запросы? клиенты-же всёравно переспросят, и только будут ругаться что интернет медленно работает, нагрузку на сервер ваш способ никак не уменьшает, а даже увеличивает, добавляя нагрузку на работу netfilter и нагрузку на канал(за счёт повторных пакетов)
UFO just landed and posted this here
Все очень просто. Представьте себе клиента компьютер которого рассылает спам, и спам бот постояно обращается к DNS серверу провайдера «долбя» его вопросами типа
Где почтовик mail.ru?
Где почтовик gmail.ru?
Где почтовик yahoo.com?
DNS сервер мало того что принимает данные запросы, так он еще и тратит ценные ресурсы отвечая на них. В конечном итоге DNS сервером тратится огромное количество ресурсов на запросы которые генерируются вредноносным ПО.
В статье описан метод снижения нагрузки на DNS сервер, неважно какое ПО на нем работает, причем данный метод никак не отражается на работе валидных клиентов.
Где почтовик mail.ru?
Где почтовик gmail.ru?
Где почтовик yahoo.com?
DNS сервер мало того что принимает данные запросы, так он еще и тратит ценные ресурсы отвечая на них. В конечном итоге DNS сервером тратится огромное количество ресурсов на запросы которые генерируются вредноносным ПО.
В статье описан метод снижения нагрузки на DNS сервер, неважно какое ПО на нем работает, причем данный метод никак не отражается на работе валидных клиентов.
Перечитайте статью. Где Вы все увидили ограничение валидных запросов. Ограничение будет только если от клиента идет непрерывный DOS DNS сервера, вот для того чтобы все ресурсы сервера не были исчерпаны одним пользователей и вводятся ограничения. Для j,sxyjuj gjkmpjdfntkz никакой разницы не будет
Я бы добавил еще TXT-запросы — без них SPF не сильно будет работать — а это достаточно действенный способ борьбы со спамом (мы ведь не забываем про своих корпоративных клиентов, да? :)
PS 100k клиентов:
16:25:34 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
16:25:34 all 25,48 0,18 7,99 0,10 0,58 1,35 0,00 64,32 166,34
на
deb40:~# cat /proc/cpuinfo | grep 'model name'
model name: Intel® Xeon(TM) CPU 3.00GHz
model name: Intel® Xeon(TM) CPU 3.00GHz
model name: Intel® Xeon(TM) CPU 3.00GHz
model name: Intel® Xeon(TM) CPU 3.00GHz
deb40:~# free -m
total used free shared buffers cached
Mem: 3043 2590 453 0 19 552
-/+ buffers/cache: 2017 1025
Swap: 1529 154 1374
+ на этом же сервере крутится корпоративная почта на 500 человек
PS 100k клиентов:
16:25:34 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
16:25:34 all 25,48 0,18 7,99 0,10 0,58 1,35 0,00 64,32 166,34
на
deb40:~# cat /proc/cpuinfo | grep 'model name'
model name: Intel® Xeon(TM) CPU 3.00GHz
model name: Intel® Xeon(TM) CPU 3.00GHz
model name: Intel® Xeon(TM) CPU 3.00GHz
model name: Intel® Xeon(TM) CPU 3.00GHz
deb40:~# free -m
total used free shared buffers cached
Mem: 3043 2590 453 0 19 552
-/+ buffers/cache: 2017 1025
Swap: 1529 154 1374
+ на этом же сервере крутится корпоративная почта на 500 человек
а что, если: запустить два днс-сервера на одном компьютере, один с высоким приоритетом, другой — с низким. клиентов, которые не перегружают сервер запросами, обслуживать на первом, а кто флудит — на втором? в результате хорошие клиенты будут обслуживаться заведомо хорошо, плохие — настолько хорошо, насколько это возможно не в ущерб первой группе
Т.е. если у клиента вирус, то вы его фактически отрубаете от ДНС?
Его легитимные запросы не доходят до вашего ДНС и поэтому для него Интернет не работает?
По-моему таким ограничением вы довольным клиента не сделаете.
Его легитимные запросы не доходят до вашего ДНС и поэтому для него Интернет не работает?
По-моему таким ограничением вы довольным клиента не сделаете.
Мне кажется, что сыр бор идет отчасти из-за того, что эффект не отражен должны образом. Я сторонник методов, что плохой админ тот, кто заморачивается из-за 5% производительности.
Мы видим, что «количество одновременных рекурсивных DNS запросов к нашим DNS серверам более чем в 20 раз (c 10000 до 400), без жалоб на работу DNS со стороны наших пользователей. »
Но не видим какие ресурсы стали экономиться на DNS сервере — процессор, память, нагрузка на канал и проч. и на какие величины. Т.е. до и после. Так же не видна насколько нагрузка возросла — из-за дополнительных правил фильтрации. Запросов стало меньше, но правил больше :).
Т.е. просто дайте наглядную картину по загрузке сервера до и после и уверен, негативных комментариев станет меньше.
Мы видим, что «количество одновременных рекурсивных DNS запросов к нашим DNS серверам более чем в 20 раз (c 10000 до 400), без жалоб на работу DNS со стороны наших пользователей. »
Но не видим какие ресурсы стали экономиться на DNS сервере — процессор, память, нагрузка на канал и проч. и на какие величины. Т.е. до и после. Так же не видна насколько нагрузка возросла — из-за дополнительных правил фильтрации. Запросов стало меньше, но правил больше :).
Т.е. просто дайте наглядную картину по загрузке сервера до и после и уверен, негативных комментариев станет меньше.
Sign up to leave a comment.
Блокировка нежелательного DNS трафика