Comments 38
UFO just landed and posted this here
Я правильно понимаю, что у вас на каждом ДНС сервере с PowerDNS еще и база крутится? Они разве не умеют ходить за данными все в одну базу?
Я так понял, что они могут быть удалены географически. Поэтому каждый раз туда делать запросы будет долго. Из-за этого локальная база у каждого это просто что-то вроде кэша. Каждый ходит регулярно на главный сервер с базой и копирует её к себе. Никаких мастер-слейв, сплит брейн и тому подобного.
Умеют, однако задача была уйти от единой точки отказа.
Каждый ns в итоге совершенно самостоятелен и не зависит от какой-то центральной базы.
В распределенных географически инсталляциях (даже на малых расстояниях), может быть так, что связность ns до базы лежит (упал канал), а связь клиентов до ns не лежит (т.е. они хотят ответов).
Поэтому еще раз, каждый ns обладает всем необходимым, чтобы ответить на запрос.
Каждый ns в итоге совершенно самостоятелен и не зависит от какой-то центральной базы.
В распределенных географически инсталляциях (даже на малых расстояниях), может быть так, что связность ns до базы лежит (упал канал), а связь клиентов до ns не лежит (т.е. они хотят ответов).
Поэтому еще раз, каждый ns обладает всем необходимым, чтобы ответить на запрос.
Отличный доклад, спасибо! Уже отошел немного от этой темы, но понял что в некоторых случаях стоило сделать по-другому.
Мониторинг типа запросов и dnstop — вещь, особенно для провайдеров, рассадники вирусов таким образом вычисляли и прибивали.
Мониторинг типа запросов и dnstop — вещь, особенно для провайдеров, рассадники вирусов таким образом вычисляли и прибивали.
UFO just landed and posted this here
Из-за того, что я делал RENAME TABLE, у меня репликация ломалась просто через раз.
Первый же день эксплуатации показал, что с репликацией не по пути :(
Первый же день эксплуатации показал, что с репликацией не по пути :(
Мы после миграции с feebsd/bind на linux/unbound настолько впечатлились результатами (справедливости ради стоит сказать, что feebsd/bind были виноваты не сами по себе, а способ, которым все это было собрано и запущено), что зоны (больше 100 прямых и раз в десять больше обратных) мигрировали на ПО от того же производителя (nsd) — и результатами остались ничуть не менее довольны.
Да, была мысль использовать БД и забыть о master/slave и *XFR — но решили пойти более простым классическим путем. Файлы зон лежат в git, не забыть после редактирования исправить сериал и сказать nsd-control reload — не такая уж сверхъестественная задача. Не забыть о git commit можно уже и крону поручить, если самому лень.
Уже некоторое время спустя пришла мысль, что можно было бы использовать powerdns c БД в качестве мастера (а по сути в качестве веб-редактора зон), а несколько экземпляров nsd — в качестве слейвов (и их уже выставили бы наружу). Но не сложилось, а когда еще сложится — может и никогда…
О выборе дистрибутива linux могу сказать одно — удобно, когда майнтейнер nsd ты сам, а с майнтейнером unbound нет никаких разногласий по поводу упаковки :)
Да, была мысль использовать БД и забыть о master/slave и *XFR — но решили пойти более простым классическим путем. Файлы зон лежат в git, не забыть после редактирования исправить сериал и сказать nsd-control reload — не такая уж сверхъестественная задача. Не забыть о git commit можно уже и крону поручить, если самому лень.
Уже некоторое время спустя пришла мысль, что можно было бы использовать powerdns c БД в качестве мастера (а по сути в качестве веб-редактора зон), а несколько экземпляров nsd — в качестве слейвов (и их уже выставили бы наружу). Но не сложилось, а когда еще сложится — может и никогда…
О выборе дистрибутива linux могу сказать одно — удобно, когда майнтейнер nsd ты сам, а с майнтейнером unbound нет никаких разногласий по поводу упаковки :)
Видимо, либо это было давно, либо система у вас был старая, поскольку во FreeBSD Unbound является штатной частью системы вместо выпиленного Bind с 10-RELEASE т.е. с 2014 года.
Связка NSD + Unbound, действительно, хороша и шустра. Но проблема хранения и редактирования зон через доступный пользователю интерфейс есть.
Остаётся свой вариант с хранением данных в SQL + веб-интерфейс и выпихивание результатов в файл. Не слишком удобно, но работает.
Резолвер переезжал в 2014-2015, а на какой FreeBSD он был раньше — никто уж и не помнит. Зоны переезжали в 2015-2016, а для варианта с хранением данных в SQL (+ веб-интерфейс) как раз задним умом и подумали о PowerDNS, но даже если б вовремя придумали такой вариант — не факт, что заморочились бы. Текстовые файлы — не такой уж плохой вариант, особенно когда что-нибудь сломается или пойдет не так…
Но, вообще PowerDNS в качестве hidden primary и NSD в качестве visible хороший вариант.
Согласен с вами, текстовые файлы не есть зло, если ими нормально пользоваться. Одно время у нас работала такая схема: есть веб-интерфейс, на котором разрешено было добавлять/изменять зоны, он создавал текстовик для bind, выставлял серию и пр., давал указание bind перечитать конфигурацию, чтобы изменения принялись. Текстовики при через rsync при изменении уходили на slave, там при обнаружении новых/измененных файлов происходило перечитывание конфигурации. В таком виде схема работала несколько лет на обслуживании нескольких сотен доменов. Когда понадобилось api и пр. плюшки, доработали систему: написали демонов, которые работают на каждом дочернем dns и слушают служебный порт, еще один демон (на мастере) принимает данные по api, веб-интерфейсам и пр., и отправляет данные на дочерние. При изменении данных на мастере отправляются изменения на все дочерние, там они находятся все в тех же текстовиках для bind, т.к. система росла, а не писалась с нуля, то решили не менять это. Сейчас эта система держит более 1млн. зон, bind справляется успешно, памяти много не кушает.
Совершенно непонятно, зачем при каждом изменении зоны на мастере делать mysqldump? Ведь PowerDNS автоматом рассылает notify по всем прописанным ns-серверам и обновляет их.
А еще ни слова не сказано про механизм supermaster (у меня отлично работает на 2х pdns серверах + poweradmin).
А еще ни слова не сказано про механизм supermaster (у меня отлично работает на 2х pdns серверах + poweradmin).
Почитайте внимательно, я говорю об отказе от master/slave вообще. Зоны всегда одинаковые везде, поскольку синхронизируется бэкенд.
Ну и простая цитата из документации про supermaster (которая хорошо поясняет, почему это костылик для малого количества постоянных доменов):
То есть, если я убрал зону на мастере, то надо сходить и как-то руками ее убрать на слейве. Минуточку, это же… OH SHI~
Ну и простая цитата из документации про supermaster (которая хорошо поясняет, почему это костылик для малого количества постоянных доменов):
Note: Removal of zones provisioned using the supermaster must be done on the slaves themselves. As there is no way to signal this removal from the master to the slave.
То есть, если я убрал зону на мастере, то надо сходить и как-то руками ее убрать на слейве. Минуточку, это же… OH SHI~
Про отказ от master/slave — упустил.
В данном случае не понятно, чем плоха репликация БД? Неужели делать полный дамп базы раз в 2 минуты независимо от того, есть в ней изменения или нет, правильнее чем настроить репликацию?
В данном случае не понятно, чем плоха репликация БД? Неужели делать полный дамп базы раз в 2 минуты независимо от того, есть в ней изменения или нет, правильнее чем настроить репликацию?
Я об этом тоже говорил, но повторю. Поскольку я использую RENAME TABLE, то это часто ломает репликацию в клочья.
Если пробовать делать это на транзакциях, то есть, делать кучу операций в транзакции, то это атомарно, как и RENAME TABLE, но гораздо более медленно.
Если пробовать делать это на транзакциях, то есть, делать кучу операций в транзакции, то это атомарно, как и RENAME TABLE, но гораздо более медленно.
Репликация плоха хотя бы тем, что её надо поднимать заново при разрыве соединения. А если ns разнесены географически, то вероятность накрытия медным тазом увеличивается настолько, что это будет происходить ежедневно, если не ежечасно.
Вот то, что надо ли делать это каждые две минуты, а не по наличию изменений — не уверен.
Вот то, что надо ли делать это каждые две минуты, а не по наличию изменений — не уверен.
Странная у Вас репликация. У меня годами работает, включая плановые перезагрузки и замены оборудования, и ничего не отваливается и ничего поднимать заново не надо.
P.S. Правда речь идет о PostgreSQL, с MySQL я давно не работал…
P.S. Правда речь идет о PostgreSQL, с MySQL я давно не работал…
В статье — mysql, с которым и работает powerdns. И об её же репликации речь.
Специально сейчас сделал на 2х pdns репликацию на mysql master-slave и перезагрузил master (целиком весь сервер). Произошел разрыв соединения, после перезагрузки и выхода в онлайн — все встало на свои места и работает в штатном режиме.
Это не разрыв, это штатное закрытие соединения. Для тестирования стоит устроить пропадание пакетов между репликами, что на длинных линках вполне себе штатное явление. Мне подобное когда-то устроил ростелеком, отчего сбор данных из филиалов был организован при помощи mysql-proxy и логирования им инсертов…
UFO just landed and posted this here
UFO just landed and posted this here
На нашем проде было видно, что ANY на резольверах используется только ботнетами.
Однако, про ANY на авторитетных серверах вышла смешная история. Одному из наших клиентов перестали доходить письма из Бюро Кредитных Историй. После краткого расследования стало понятно, что там на той стороне qmail как раз какой-то адовой версии, которая шлет нашим авторитетным серверам ANY (авторы qmail где-то в списке рассылки говорили, что это круто и быстро).
В итоге, на авторитетных у нас ANY можно, а на резольверах низя.
Однако, про ANY на авторитетных серверах вышла смешная история. Одному из наших клиентов перестали доходить письма из Бюро Кредитных Историй. После краткого расследования стало понятно, что там на той стороне qmail как раз какой-то адовой версии, которая шлет нашим авторитетным серверам ANY (авторы qmail где-то в списке рассылки говорили, что это круто и быстро).
В итоге, на авторитетных у нас ANY можно, а на резольверах низя.
А вроде powerdns-ы писали, что его можно как ресолвер собрать. Не пробовали?
Статья больше похоже на brain dump — отрывочные сведения по настройке DNS серверов.
— иметь свой собственный DNS можно даже дома. Если нет сервера или подходящего маршрутизатора, то его можно поднять на raspberry Pi. Одно из применений дома — резать рекламу и well know bad domains, например с использованием RPZ;
— держать открытый рекурсивный DNS сервис в интернет — плохо и для большинства случаев это не нужно;
— не упомянуты ACL на уровне DNS. В особенности для bind это важно, когда один сервер является авторитативным и рекурсивным;
— запросы ANY бывают полезны для админов и лучше делать rate limit на них, чем совсем резать;
— rate limit можно настраивать на уровне DNS (в частности в bind).
PS «резольвер» — ужастный термин, хоть и короткий.
— иметь свой собственный DNS можно даже дома. Если нет сервера или подходящего маршрутизатора, то его можно поднять на raspberry Pi. Одно из применений дома — резать рекламу и well know bad domains, например с использованием RPZ;
— держать открытый рекурсивный DNS сервис в интернет — плохо и для большинства случаев это не нужно;
— не упомянуты ACL на уровне DNS. В особенности для bind это важно, когда один сервер является авторитативным и рекурсивным;
— запросы ANY бывают полезны для админов и лучше делать rate limit на них, чем совсем резать;
— rate limit можно настраивать на уровне DNS (в частности в bind).
PS «резольвер» — ужастный термин, хоть и короткий.
+ забыл добавить по этому поводу
Запрос ANY прекрасно описан в rfc1035:
Если вы делаете резольвер, перестаньте отвечать на запросы ANY потому, что это вид запроса, который на самом деле толком не стандартизован и используется на 99% всякими замечательными вирусами.
Запрос ANY прекрасно описан в rfc1035:
* 255 A request for all records
Давайте сначала коротко про ANY. Я придерживаюсь того, что описывает CloudFlare в своем блоге. Там отличная история, как они планомерно отказывались от ANY.
Когда мы вырубали его, то руководствовались двумя вещами:
1. Анализ того, что мы видим в запросах (99,9% были нелегитимные запросы)
2. Насколько пострадают от наших действий пользователи (т.е. с повышенным внимание отрабатывали запросы «не работает» от наших абонентов).
Результат оказался вполне нормальным: никто не пострадал, мир стал чище.
Когда мы вырубали его, то руководствовались двумя вещами:
1. Анализ того, что мы видим в запросах (99,9% были нелегитимные запросы)
2. Насколько пострадают от наших действий пользователи (т.е. с повышенным внимание отрабатывали запросы «не работает» от наших абонентов).
Результат оказался вполне нормальным: никто не пострадал, мир стал чище.
Чтобы мир стал чище, нужно повсеместно применять bcp38 и очень желательно закрывать открытые рекурсивные DNS у обычных пользователей.
Запросы ANY на авторитативных серверах, если они не возвращают больших ответов (нет DNSSEC) в основном безвредны (ибо используют их для Amplification/Reflection).
Запросы ANY для своих клиентов — rate limit. Более одного запроса в секунду обычно не требуется, хотя можно и увеличить интервал.
Для внешних клиентов кэш вообще не должен отвечать (криворукие ISP — можно отнести к разряду клиентов)
Запросы ANY на авторитативных серверах, если они не возвращают больших ответов (нет DNSSEC) в основном безвредны (ибо используют их для Amplification/Reflection).
Запросы ANY для своих клиентов — rate limit. Более одного запроса в секунду обычно не требуется, хотя можно и увеличить интервал.
Для внешних клиентов кэш вообще не должен отвечать (криворукие ISP — можно отнести к разряду клиентов)
Про ACL и rate-limit на уровне bind:
1. Я глубоко уверен, что авторитетный и рекурсор на одной машине — это плохо. Я в докладе объясняю, почему.
2. Я не особый сторонник bind, поскольку он по сути больше авторитетный сервер, нежели рекурсор, который предлагает мне хранить БД в текстовом виде. От чего я тоже хочу уйти подальше.
3. Держать открытый рекурсивный DNS в Интернет порой надо, увы. В моем случае, как только мы закрылись от таких запросов снаружи, вылезли две вещи:
— один крупный оператор связи косанул с настройкой абонентских роутеров и ходит резольвить к нам (и его абоненты, разумеется, пострадали в первую очередь)
— один из наших коллег ставил наши резольверы в сетевых настройках некоторых систем, которые он уже давно не администрирует, то есть пострадали бы достаточно крупные, хоть и не очень важные для нас люди.
Поэтому в итоге у нас резольвер смотрит в интернер, увы.
1. Я глубоко уверен, что авторитетный и рекурсор на одной машине — это плохо. Я в докладе объясняю, почему.
2. Я не особый сторонник bind, поскольку он по сути больше авторитетный сервер, нежели рекурсор, который предлагает мне хранить БД в текстовом виде. От чего я тоже хочу уйти подальше.
3. Держать открытый рекурсивный DNS в Интернет порой надо, увы. В моем случае, как только мы закрылись от таких запросов снаружи, вылезли две вещи:
— один крупный оператор связи косанул с настройкой абонентских роутеров и ходит резольвить к нам (и его абоненты, разумеется, пострадали в первую очередь)
— один из наших коллег ставил наши резольверы в сетевых настройках некоторых систем, которые он уже давно не администрирует, то есть пострадали бы достаточно крупные, хоть и не очень важные для нас люди.
Поэтому в итоге у нас резольвер смотрит в интернер, увы.
1. Это естественно плохо. Но ставить открытый для всех рекурсивный DNS намного хуже.
2. Это generic DNS сервер, который может делать и авторитативку и кэш. При этом на кэше есть хорошие фитчи типа RPZ.
3. В таком случае нужно прикрываться ACL и постепенно переводить данных клиентов на правильные настройки. Как найти клиентов — query.log в помощь.
2. Это generic DNS сервер, который может делать и авторитативку и кэш. При этом на кэше есть хорошие фитчи типа RPZ.
3. В таком случае нужно прикрываться ACL и постепенно переводить данных клиентов на правильные настройки. Как найти клиентов — query.log в помощь.
У нас похожая схема авторитарных серверов, только у нас нормальная репликация Master/Slave. Ипользовали PowerAdmin, но он в край надоел и при очередной переделке наших NS заменили его на оперовский DNS-ui, который оказался очень даже огонь, хотя немного бажный (пришлось даже несколько issues по пути в их гитхабе открыть). В отличии от PowerAdmin, он не работает с БД pdns напрямую, а имеет отдельную базу и общается с pdns по API. Да и вообще, админка оказалась куда более годная и удобная в использовании.
Как только мы пришли к PowerDNS, раз это база данных, мы хотим удобный редактор в вебе. А редакторов нет, кроме PowerAdmin. Это веб-приложение на PHP
Есть прекрасный инструмент PowerDNS-Admin написанный на Flask-е и работает через API PowerDNS
В целом неплохо, но явно в докладе отчётливо прослеживается идея — я делаю именно так. А все остальные методы плохие и почти вся статья посвящается тому, что бы найти проколы в остальных методах. Особенно странно звучит фраза про использование репликации mysql и кучей проблем, которые это в себе таит. У себя использую базы в продакшине, которые связаны master-master репликацией. И это не какие-то там разовые запросы на изменения записей в DNS (ну пускай у вас будет запись в базу с rate — 10 rps/s), а реальный высоконагруженный проект с сотнями rps/s. Может просто у вас не вышло грамотно настроить репликацию и разобраться во всех её тонкостях?
Более того, с появлением GTID-репликации, проблем стало гораздо меньше (да, она чуть сложнее, да, есть нюансы, но всё это нивелируется с её преимуществами по сравнению с обычной).
Есть вопрос, в первую очередь, автору (а так же всем остальным, кто его использовал) касательно SO_REUSEPORT. AFAIK, у вас linux. Так вот, как вы увидели, что REUSEPORT у вас действительно используется (снижение нагрузки не в счёт, так как на это может влиять что угодно)? Каким механизмом? Например, во FreeBSD это можно посмотреть через procstat, а в linux'e как (перелопатил много чего, но кроме того, как это пихать в код не нашёл; ещё нашёл как-то патч от 2013 года для netstat'a, но это как-то костыльно)?
Более того, с появлением GTID-репликации, проблем стало гораздо меньше (да, она чуть сложнее, да, есть нюансы, но всё это нивелируется с её преимуществами по сравнению с обычной).
Есть вопрос, в первую очередь, автору (а так же всем остальным, кто его использовал) касательно SO_REUSEPORT. AFAIK, у вас linux. Так вот, как вы увидели, что REUSEPORT у вас действительно используется (снижение нагрузки не в счёт, так как на это может влиять что угодно)? Каким механизмом? Например, во FreeBSD это можно посмотреть через procstat, а в linux'e как (перелопатил много чего, но кроме того, как это пихать в код не нашёл; ещё нашёл как-то патч от 2013 года для netstat'a, но это как-то костыльно)?
Sign up to leave a comment.
Пряморукий DNS: делаем правильно