Comments 38
Каждый ns в итоге совершенно самостоятелен и не зависит от какой-то центральной базы.
В распределенных географически инсталляциях (даже на малых расстояниях), может быть так, что связность ns до базы лежит (упал канал), а связь клиентов до ns не лежит (т.е. они хотят ответов).
Поэтому еще раз, каждый ns обладает всем необходимым, чтобы ответить на запрос.
Мониторинг типа запросов и dnstop — вещь, особенно для провайдеров, рассадники вирусов таким образом вычисляли и прибивали.
Первый же день эксплуатации показал, что с репликацией не по пути :(
PS. у нас row-based replication лет 7 работает, десятки RENAME TABLE каждый день, проблемы только если в RENAME указана нереплицируемая таблица (явный запрет в replicate_*) — но это человеческий фактор
Да, была мысль использовать БД и забыть о master/slave и *XFR — но решили пойти более простым классическим путем. Файлы зон лежат в git, не забыть после редактирования исправить сериал и сказать nsd-control reload — не такая уж сверхъестественная задача. Не забыть о git commit можно уже и крону поручить, если самому лень.
Уже некоторое время спустя пришла мысль, что можно было бы использовать powerdns c БД в качестве мастера (а по сути в качестве веб-редактора зон), а несколько экземпляров nsd — в качестве слейвов (и их уже выставили бы наружу). Но не сложилось, а когда еще сложится — может и никогда…
О выборе дистрибутива linux могу сказать одно — удобно, когда майнтейнер nsd ты сам, а с майнтейнером unbound нет никаких разногласий по поводу упаковки :)
Видимо, либо это было давно, либо система у вас был старая, поскольку во FreeBSD Unbound является штатной частью системы вместо выпиленного Bind с 10-RELEASE т.е. с 2014 года.
Связка NSD + Unbound, действительно, хороша и шустра. Но проблема хранения и редактирования зон через доступный пользователю интерфейс есть.
Остаётся свой вариант с хранением данных в SQL + веб-интерфейс и выпихивание результатов в файл. Не слишком удобно, но работает.
Но, вообще PowerDNS в качестве hidden primary и NSD в качестве visible хороший вариант.
А еще ни слова не сказано про механизм supermaster (у меня отлично работает на 2х pdns серверах + poweradmin).
Ну и простая цитата из документации про 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~
В данном случае не понятно, чем плоха репликация БД? Неужели делать полный дамп базы раз в 2 минуты независимо от того, есть в ней изменения или нет, правильнее чем настроить репликацию?
Если пробовать делать это на транзакциях, то есть, делать кучу операций в транзакции, то это атомарно, как и RENAME TABLE, но гораздо более медленно.
Вот то, что надо ли делать это каждые две минуты, а не по наличию изменений — не уверен.
P.S. Правда речь идет о PostgreSQL, с MySQL я давно не работал…
Однако, про ANY на авторитетных серверах вышла смешная история. Одному из наших клиентов перестали доходить письма из Бюро Кредитных Историй. После краткого расследования стало понятно, что там на той стороне qmail как раз какой-то адовой версии, которая шлет нашим авторитетным серверам ANY (авторы qmail где-то в списке рассылки говорили, что это круто и быстро).
В итоге, на авторитетных у нас ANY можно, а на резольверах низя.
— иметь свой собственный DNS можно даже дома. Если нет сервера или подходящего маршрутизатора, то его можно поднять на raspberry Pi. Одно из применений дома — резать рекламу и well know bad domains, например с использованием RPZ;
— держать открытый рекурсивный DNS сервис в интернет — плохо и для большинства случаев это не нужно;
— не упомянуты ACL на уровне DNS. В особенности для bind это важно, когда один сервер является авторитативным и рекурсивным;
— запросы ANY бывают полезны для админов и лучше делать rate limit на них, чем совсем резать;
— rate limit можно настраивать на уровне DNS (в частности в bind).
PS «резольвер» — ужастный термин, хоть и короткий.
Если вы делаете резольвер, перестаньте отвечать на запросы ANY потому, что это вид запроса, который на самом деле толком не стандартизован и используется на 99% всякими замечательными вирусами.
Запрос ANY прекрасно описан в rfc1035:
* 255 A request for all records
Когда мы вырубали его, то руководствовались двумя вещами:
1. Анализ того, что мы видим в запросах (99,9% были нелегитимные запросы)
2. Насколько пострадают от наших действий пользователи (т.е. с повышенным внимание отрабатывали запросы «не работает» от наших абонентов).
Результат оказался вполне нормальным: никто не пострадал, мир стал чище.
Запросы ANY на авторитативных серверах, если они не возвращают больших ответов (нет DNSSEC) в основном безвредны (ибо используют их для Amplification/Reflection).
Запросы ANY для своих клиентов — rate limit. Более одного запроса в секунду обычно не требуется, хотя можно и увеличить интервал.
Для внешних клиентов кэш вообще не должен отвечать (криворукие ISP — можно отнести к разряду клиентов)
1. Я глубоко уверен, что авторитетный и рекурсор на одной машине — это плохо. Я в докладе объясняю, почему.
2. Я не особый сторонник bind, поскольку он по сути больше авторитетный сервер, нежели рекурсор, который предлагает мне хранить БД в текстовом виде. От чего я тоже хочу уйти подальше.
3. Держать открытый рекурсивный DNS в Интернет порой надо, увы. В моем случае, как только мы закрылись от таких запросов снаружи, вылезли две вещи:
— один крупный оператор связи косанул с настройкой абонентских роутеров и ходит резольвить к нам (и его абоненты, разумеется, пострадали в первую очередь)
— один из наших коллег ставил наши резольверы в сетевых настройках некоторых систем, которые он уже давно не администрирует, то есть пострадали бы достаточно крупные, хоть и не очень важные для нас люди.
Поэтому в итоге у нас резольвер смотрит в интернер, увы.
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
Более того, с появлением GTID-репликации, проблем стало гораздо меньше (да, она чуть сложнее, да, есть нюансы, но всё это нивелируется с её преимуществами по сравнению с обычной).
Есть вопрос, в первую очередь, автору (а так же всем остальным, кто его использовал) касательно SO_REUSEPORT. AFAIK, у вас linux. Так вот, как вы увидели, что REUSEPORT у вас действительно используется (снижение нагрузки не в счёт, так как на это может влиять что угодно)? Каким механизмом? Например, во FreeBSD это можно посмотреть через procstat, а в linux'e как (перелопатил много чего, но кроме того, как это пихать в код не нашёл; ещё нашёл как-то патч от 2013 года для netstat'a, но это как-то костыльно)?
Пряморукий DNS: делаем правильно