Доступен релиз кэшируюшего DNS-сервера PowerDNS Recursor 4.6, отвечающего за рекурсивное преобразование имён. PowerDNS Recursor построен на одной кодовой базе с PowerDNS Authoritative Server, но рекурсивный и авторитетный DNS-серверы PowerDNS развиваются в рамках разных циклов разработки и выпускаются в форме отдельных продуктов. Код проекта распространяется под лицензией GPLv2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56380
> авторитетный DNS-серверА в какой DNS-зоне он имеет авторитет? И имеет ли он его среди TOR-ов в законе?
> А в какой DNS-зоне он имеет авторитет?90% DNSSEC и 30% CET-рал, ветер серверный.
Авторитет имеет во всех зонах, кроме авторитарных. Там его не уважают и даже боятся.
Не, прекурсор гораздо интереснее!))
Угу, товарищу майору прекурсоры тоже больше нравятся.
> Угу, товарищу майору прекурсоры тоже больше нравятся.Нет. Товарищу майору вообще пофигу. Возьмёт черенок от лопаты и скажет, что это прекурсор. Что самое смешное -- так оно и будет.
Достали его частые "Failed to update . records, got an exception: Too much time waiting for .|NS", лучше взять dnsdist или dnsmask c нескольким публичными и/или провайдерским dns, гораздо надежней и быстрей!
Не встречал. dnsdist рук этих же ребят кстати.
dnsdist интересная поделка, только жрущий +30мб каждый newServer немного огорчает!
на конфиг взлянуть можно? и желательно какая версия
Дело не в конфиге, а количестве бэкэндов (newServer) в нем, просто добавление каждого сразу занимает около 30 мегабайт, версия 1.6.1. Из-за этого на небольших vds, сильно не разгуляешься с балансировкой.
> Дело не в конфиге, а количестве бэкэндов (newServer) в нем, просто добавление
> каждого сразу занимает около 30 мегабайт, версия 1.6.1. Из-за этого на
> небольших vds, сильно не разгуляешься с балансировкой.https://github.com/PowerDNS/pdns/issues/9372
вот такой багрепорт был, похоже на вашу ситуацию
https://dnsdist.org/advanced/tuning.html#memory-usageраздел Memory usage, можно посчитать
Подтверждаю наблюдения пользователя Гость, жрет память оно как не в себя.setMaxUDPOutstanding(10240) -- default 65535
setMaxTCPQueuedConnections(1000) -- default 10000
setMaxTCPClientThreads(4) -- default 10
setMaxCachedTCPConnectionsPerDownstream(4) -- default 10
setRingBuffersSize(256, 4) -- default 10000, 10Вообще никак не повлияло на потребление (ну, может, ±1 Мб, на фоне 200 незаметно).
судя по ченджлогу в бета версии 1.7.0 куча фиксов с течкой памяти и расходами
Протестировали мы 1.7.0. В определенных конфигурациях, если апстримный сервер был up, а потом стал down, то dnsdist прекращает healthcheck-и и считает этот сервер вечно down, даже если он поднялся.
Остались на 1.6.1.
> если апстримный сервер был up, а потом стал down, то dnsdist прекращает healthcheck-и и считает этот сервер вечно down, даже если он поднялся.странная ситуация, нужны подробности, ибо можно сказать, что хилзчек в этой версии перестал работать. Ну и собственно зарепортить багрепорт.
1.6 не замечена значительными утечками, может связано с внедрением DoT и DoH на бэкенде
> 1.6 не замечена значительными утечками, может связано с внедрением DoT и DoH
> на бэкендетам не обязательно из-за утечек, судя по ченджлогам там всякие импрувы reduce memory usage встречаются.
В современном странном мире эффективность кэширования DNS очень сильно упала из-за безумно низких значений TTL в несколько секунд. Всё настолько плохо, что даже APNIC жалуется — https://blog.apnic.net/2019/11/12/stop-using-ridiculously-lo.../
Несколько минут - час простоя это не плохо, зато эффективность кэширования будет хорошая?
Откуда час простоя? Простоя чего? Зачем вы постоянно перенастраиваете DNS? Для балансировки такой низкий TTL точно не нужен.
Все просто: разные независимые каналы с разными ip, проверяем их каждую минуту, если проблемы, убираем отдачу записи, восстанавливается - возвращаем!
Вы простите, но я ничего не понял из вашего тезиса.
Возможно, речь идёт о ЦОДе, подключённом к нескольким провайдерам. При падении линка приходится переключаться на другого провайдера, соответственно, надо менять DNS-записи на IP-адреса этого провайдера.
Если уж есть свои серваки и деньги на аренду стоек, то арендовать автономку вообще не проблема (20 к/мес).Это как купить машину и заливать в бачок омывателя воду из канавы, потому что на нормальную жидкость денег жалко.
Экий ты резвый чужими деньгами распоряжаться...
А если это веб-сервер, почтовик и VPN для "road warriors" на одном хосте в админской каморке? Просто админ предусмотрительный, а начальство разумное, раскошелилось на второй линк от другого провайдера. При падении одного линка использующие его сервисы переводятся другой, автоматом меняются IPшники в DNS (админ же предусмотрительный, выбрал регистратора, у которого можно клеевую запись поменять через API, если DNS тоже придётся перебросить на другой IP), отправка почты приостанавливается (чтобы дальний SMTP не отбил из-за инвалидного DKIM), и так далее. Несколько минут недоступности для тех, кому не повезло запросить DNS незадолго до сбоя - вполне приемлемый компромисс.
Да, это кустарщина в чистом виде. Но такой подход скорее можно сравнить с заливкой в бачок омывателя самогонки собственного приготовления.
> А если это веб-сервер, почтовик и VPN для "road warriors" на одном хосте в админской каморке?Суровый ЦОД, однако.
> отправка почты приостанавливается (чтобы дальний SMTP не отбил из-за инвалидного DKIM)
Какое отношение IP-адрес отправителя имеет к DKIM? Открытые ключи публикуются в отдельных TXT-записях.
Ничто не мешает локальному релею отправлять хоть с пяти адресов по очереди, лишь бы они в SPF были разрешены.Да и вообще, мало-мальски ответственный админ сделает сайт и почтовик (который будет smarthost для локального релея) на нормальном хостинге, где есть резервирование каналов и прочие плюшки ЦОД, типа резерва питания, нормального охлаждения, отсутствия пыли и т.д.
Более-менее оправдано размещать в офисе разве что VPN-гейт, но и то, современные VPN-клиенты (например, OpenVPN) умеют последовательно пробовать несколько серверов.
Перепутал, да, SPF, конечно. Шклерож, чо...
Сайт, на котором всё и так общедоступное - может быть. А вот почтовик - извините, только в моём помещении.
Совет дня: в SPF можно указывать несколько адресов!
Чтобы при заражении офисного компа спам валился с гейта с валидным SPF?
>Возможно, речь идёт о ЦОДе, подключённом к нескольким провайдерам.Ну то есть ты хочешь поговорить о том чего ни разу и близко не видел? %-D
Hy Ok!
Начнём с того что если сдохнет любой из провайдеров обеспечивающих __Ц__од - то НИ ОДНОЙ днс-записи менять не придётся! Прикинь!!!! :-D
А если это не так - не называйте этот сарайчик ЦОД-ом :)
Опеннетные Ыгсрерды - ****** и беспощадные :) (C)
> Все просто: разные независимые каналы с разными ip, проверяем их каждую минуту, если проблемы, убираем отдачу записи, восстанавливается - возвращаем!Более того, в PowerDNS Authoritative (не сабж, а его родственник) поддерживаются LUA-записи с функциями ifurlup и ifportup, которые используют фоновые проверки доступности каждые 5 секунд.
Чтобы, если хост упадёт, в А или иной записи поменять IP-адрес быстро
Поддерживаю, с ttl в минуту записи в кэше долго не живут. Заметил что при обращение на прямую к корневому днс очень долго отвечает, а тот же гугл отдаёт быстро, у cf такая же проблема. Гугл кладёт на все эти TTL?
Есть как минимум две фичи, позволяющие не тупить даже на малых TTL
- prefetch: периодически просматривать кэш, и для часто запрашиваемых записей с истекающим TTL выполнять фоновое обновление раньше, чем истечет TTL.
- serve-stale: если RR в данный момент не резолвится, отдавать из кэша, даже если TTL уже истек.Ну и да, можно просто задать минимальный TTL, "кладя" на все TTL ниже этого значения.
Российским сс (службам) труднее взламывать сервер если он кеширующий ? А то мне уже явно ломали. Я в москвабаде.
А мне в Беларуси уже и blitz.ahadns.com лукашистские СС заблокировали…
Делать prefetch, как в Unbound, видимо, не собираются.> Добавлена функция "Zone to Cache", позволяющая периодически извлекать DNS-зону и подставлять её содержимое в кэш, для того, чтобы кэш всегда был в "горячем" состоянии и содержал связанные с зоной данные.
Работает только для "своих" зон. Какой-нибудь гугл AXFR кому попало не отдаст.
А вот prefetch на все зоны работает одинаково.
Пидро-зум-евается, что эта херня будет стоять *перед* авторитативным сервером и заниматься кэшированием его ответов, а авторитативный сервер для всего, что ломится на 127.0.0.1 разрешает axfr.Вобщем, учитывая, то, насколько криво в своё время работал кэш этих всех powerdns-поделок при наличии ACL, лучше наверно использовать unbound.
Во всяком случае unbound работает согласно стандартам и прозрачно. Да и кэш у него как-то поприятнее устроен. И префетч есть, и DoH, с валидацией ssl и подписей dnssec и свои зоны из bind-like файлов он умеет раздавать и чужие зоны частично переписывать и дополнять своими записями тоже могёт.
Единственное, чем может похвастать recursor - не самым дурным lua-апи. Оно и быстрое и кое-чего может. Луа, как язык, конечно, максимально убог своими средствами и синтаксисом, но зато быстрый, пока за него не берутся питонисты и яваскрипткиддисы.
rec перед auth это просто вариант (не лучший и не всегда удобный) перехода когда auth перестал пропускать рекурсивные запросы, auth вполне самостоятелен и имеет свой кэш.
> rec перед auth это просто вариант (не лучший и не всегда удобный) перехода когда auth перестал пропускать рекурсивные запросыСкорее, когда есть корпоративные резолверы, которым нужно быстро отдавать записи для корпоративного домена (возможно, даже внутреннего).
Но у нас с этим и Unbound прекрасно справляется, и костыли типа Zone to Cache только помешали бы, потому что на auth некоторые особо ответственные записи генерируются на лету Lua-скриптами, которые делают health check (о чем уже писали выше по обсуждению).> auth вполне самостоятелен и имеет свой кэш.
Ага, обычно даже два (query и packet).
Ставить перед ним рекурсор "просто так" - вообще бессмысленно.
Если не хватает производительности - сделать больше потоков, не хватает железа - сделать балансировку через dnsdist.
>сделать балансировку через dnsdist.так и надо, ставится dnsdist который разделяет рекурсивные запросы во внешний мир и рекурсивные запросы на внутренний нейм сервер. Но можно и тем же unbound-дом понасоздавать всяких local-zone
Да можно и не через local-zone.В Unbound есть stub-zone, когда он идет за зоной сразу на заданные серваки, минуя рекурсивный процесс для вышестоящих зон (и, в отличие от forward-zone, запрашивает их без флага RD, так что даже самый придирчивый auth сервер не будет ругаться).
local-zone под нагрузкой 300-400 запросов в секунду дают серьезную деградацию производительности. Споткнулись на 1.13.0. Применение stub-zone ситуацию выплавило, на чем и продолжаем жить.
> Пидро-зум-евается, что эта херня будет стоять *перед* авторитативным сервером и заниматься кэшированием его ответов, а авторитативный сервер для всего, что ломится на 127.0.0.1 разрешает axfr.Типа того. Многие до сих пор не могут смириться, что из auth убрали поддержку рекурсии.
https://doc.powerdns.com/authoritative/guides/recursion.html
В таких сценариях зайдет нормально.> Во всяком случае unbound работает согласно стандартам и прозрачно. Да и кэш у него как-то поприятнее устроен. И префетч есть, и DoH, с валидацией ssl и подписей dnssec и свои зоны из bind-like файлов он умеет раздавать и чужие зоны частично переписывать и дополнять своими записями тоже могёт.
Все так. PDNS recursor на его фоне смотрится как игрушка.
> Делать prefetch, как в Unbound, видимо, не собираются.Попутал, все-таки сделали (refresh-on-ttl-perc) в 4.5.0. А вот serve stale (AKA serve expired) - нет.