dnsbalancer — демон балансировки UDP-трафика рекурсивного DNS

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

https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing :

• поддержка IPv4 и IPv6;
• поддержка множества фронтендов и бекендов одновременно;
• слежение за доступностью бекендов, игнорирование недоступных бекендов;
• работа в многопоточном режиме;

Тем более если это интернет-провайдер и динамическая маршрутизация там уже используется в полный рост.

Оправданием для этого шедевра могли бы быть два оставшихся пункта:

• поддержка правил обработки DNS-запросов с использованием регулярных выражений и выполнением различных действий над клиентскими запросами;
• ведение статистики по фронтендам, бекендам, типам запросов и задержкам ответов.

только вот никак не могу придумать, зачем бы это было нужно...

Круто. А есть бечмарки в сравнении с nginx ? :)

А смысл сравнивать DNS-балансер и HTTP-сервер?

Не-а. В nginx запилили поддержку UDP уже после того, как мы своё поделие внедрили в продакшн. А сейчас руки не доходят, но и правда, самому интересно. Может, как-то сделаю.

Зачем оно??...

Один инстанс Unbound жуёт на 6 ядрах более 600kpps(!) при правильной настройке, сами юзаем. А они 10kpps балансируют.. странные люди.

Там тоже есть UDP балансер, и его тоже можно использовать для балансировки UDP трафика (в т.ч. DNS).

А смысл? И так понятно что многотредовая игрушка нормальному инструменту не конкурент.

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

А код, видимо, на Си написан. Кто-то может объяснить, где у этого демона тесты? Или у Си-программистов ничего тестировать не принято? Как-то страшно должно быть такое прям в открытый мир выставлять лицом

Это делается гораздо проще - обычным VRRP с плавающим виртуальным адресом (или несколькими). И не надо заморачиваться с анонсами.

Anycast это скорее не отказоустойчивость, а выбор наиболее близкого хоста (пусть и в попугаях BGP).

Это делается гораздо проще - обычным VRRP

При обычном VRRP нет защиты от отказа того рутера, который обслуживает оба сервера.

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

Всмысле? Что значит «обычном»? Шлюз должен быть отказоустойчивым - как это реализовано (VSS, VRRP/HSRP/GLBP или ещё как) - не важно.

Затем сам сервис через VRRP (keepalived), либо какой-нибудь Pacemaker делается отказоустойчивым.

В итоге не имеем единой точки отказа.

Это для тех, кто не осилил anycast? А как оно работает, когда запрос или ответ в UDP не помещается и DNS переключается на TCP? Бессмысленный код.

средствами Iptables эту же задачу нельзя было решить?

средствами Iptables эту же задачу нельзя было решить?

Во, я тоже хотел про это спросить!

когда запрос или ответ в UDP не помещается и DNS переключается на TCP?

меня тоже интересует данный вопрос.

Нет. Эта задача не решается ни iptables, ни этим вот поделием.

И всё это ради того, чтобы DNS не падал? Anycast делает всё то же самое, только проще, быстрее, надёжнее и на уже имеющейся инфраструктуре.

inb4: рекурсивные и авторитативные DNS-серверы на всех континентах кроме Южной Америки. ~2000 r/s/s в среднем. Anycast. Брат жив.

Нет, iptables не умеет DPI в том смысле, в котором он нам нужен.

А мы вот просто берём и не даём клиентам DNS по TCP.

То есть IPv6 и DNSSec у вас в пролёте?

Ага.

Печально. Небось ещё и пользователей за NATом держите и отдельные деньги за «белый айпи-адрес» берёте?

Нет. Белые без доп. платы.

Стало быть доброе начало в вас есть! Ну что же, не стоит себя сдерживать, вперёд к массовым деплоям IPv6 и отказу от наколенных решений по DNS-балансировке ;)

кастую баттл этого поделия против http://dnsdist.org/

Можешь сравнить. С того времени, как мы внедрили своё, это поделие так и не научилось много потоков и больше 2^16 одновременных запросов. Хотя да, это более фичастый и перспективный конкурент, но когда-то потом, а не сейчас.

Вот поэтому люди и не пользуются провайдерским DNS :)

Заббиксовые графики с тобой категорически не согласны.

Конечно, если запретить весь трафик на udp/53 tcp/53 во внешний мир ;)

Где TODO, Roadmap? Я бы поучаствовал.

Пока в планах две вещи — хранение конфига в мускуле с релоадом на лету и оптимизация ACL, т.к. я уверен, что он будет тормозить, если правил будет много.

Что городить? Пару строк в конфиге VRRP? А для эникаста нужно роутинговые демоны пущать на каждом сервере чтобы анонсы отваливались вместе с сервером.

Пока эникаст-анонсы перестроятся у тебя отвалится по таймауту куча запросов, VRRPv3 же сработает за доли секунды.

Ещё раз - эникаст это, в основном, способ сократить количество хопов до сервера, а уже во вторую - отказоустойчивость. Никто не мешает юзать и то и то.

Вы так и не рассказали - какую задачу решает этот софт? Фильтрация запросов (ACL)? Другого применения я пока не вижу, ибо всё остальное решается уже имеющимся софтом.

Нам изначально нужно было решить несколько задач, в т. ч. балансировку и фильтрацию.

Таки зачем балансировать если с любым адекватным потоком справится практически любой DNS-рекурсор? Не пойму вот никак.

только вот никак не могу придумать, зачем бы это было нужно...

Великий фильтр неугодных по DNS, это же очевидно.

VRRP это протокол для резервирования конечного шлюза. И кому он будет резервировать и балансировать DNS? Машрутизатору в своем сегменте?

А по поводу роутинг демонов на серверах это вообще о чем? Машрутизатор может за сервер проанонсировать его anycast.

High availability, например.

Вы так и не сказали: как вы собираетесь с помощью vrrp решать задачу балансировки нагрузки?

Из-за нестабильности ланетовского DNS, я накостылил баш-скриптец, который проверяет доступность интернета, и если есть проблемы, переключает из ланетовского DNS на DNS от Google/OpenDNS

Лучше опиши, в чём проявляется нестабильность.

VRRP это протокол для резервирования конечного шлюза.

К шлюзу он имеет отношение постольку-поскольку. Это универсальный протокол резервирования IP-адресов. man keepalived etc. У меня два DNS-сервера сейчас крест-накрест зарезервированы через keepalived/VRRPv3, на каждом приличная нагрузка по ~12k запросов в секунду. Любой из них могу отключить для обслуживания и клиенты ничего не заметят - IP переедет ко второму за ~0.2сек.

А по поводу роутинг демонов на серверах это вообще о чем? Машрутизатор может за сервер проанонсировать его anycast.

Про то что маршрутизатор не знает жив ли сервер. Либо нужно городить какие-то хартбиты/health check и убирать анонс когда сервер дохнет, либо анонсировать с самих серверов чтобы анонс отваливался когда истечёт dead time в роутинговом протоколе.

А отказоустойчивость вашего балансировщика кто будет обеспечивать? Получается его тоже резервировать надо, иначе будет SPOF. Проще резервировать сразу DNS-сервера через виртуальные IP-адреса чем дополнительно городить ещё один слой, который тоже надо резервировать.

Зачем её решать в контексте DNS? Я уже выше писал, что Unbound в одно рыло покроет *любые реальные* требования по производительности.

Для справки - у Google Public DNS (8.8...) по статистике за 2012 год было около 850к запросов в секунду, это лишь чуть больше чем может всего один unbound (>600к)

Балансировщики резервируются через VRRP.

Зачем резервировать балансировщики через VRRP если можно через него же зарезервировать сами DNS сервера?

Персонал провайдеров очень любят кодить ибо тупо админить им скучно. В 99% случаев изобретают велосипеды, на за то свои!

Чтобы равномерно размазать нагрузку.