Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск кэшируюшего DNS-сервера PowerDNS Recursor 4.6.0"	+/–
Сообщение от opennews (??), 20-Дек-21, 12:52
Доступен релиз кэшируюшего DNS-сервера PowerDNS Recursor 4.6, отвечающего за рекурсивное преобразование имён. PowerDNS Recursor построен на одной кодовой базе с PowerDNS Authoritative Server, но рекурсивный и авторитетный DNS-серверы  PowerDNS развиваются  в рамках разных циклов разработки и выпускаются в форме отдельных продуктов. Код проекта распространяется под лицензией GPLv2... Подробнее: https://www.opennet.me/opennews/art.shtml?num=56380
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 20-Дек-21, 12:52	+/–
> авторитетный DNS-сервер А в какой DNS-зоне он имеет авторитет? И имеет ли он его среди TOR-ов в законе?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3

2. Сообщение от УГловник (?), 20-Дек-21, 13:11	+/–
> А в какой DNS-зоне он имеет авторитет? 90% DNSSEC и 30% CET-рал, ветер серверный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Анон_ли (?), 20-Дек-21, 13:12	–3 +/–
Авторитет имеет во всех зонах, кроме авторитарных. Там его не уважают и даже боятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от Брат Анон (ok), 20-Дек-21, 15:44	–3 +/–
Не, прекурсор гораздо интереснее!))
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22

6. Сообщение от Гость (??), 20-Дек-21, 16:51	+/–
Достали его частые "Failed to update . records, got an exception: Too much time waiting for .|NS", лучше взять dnsdist или dnsmask c нескольким публичными и/или провайдерским dns, гораздо надежней и быстрей!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18

7. Сообщение от timur.davletshin (ok), 20-Дек-21, 16:51	–1 +/–
В современном странном мире эффективность кэширования DNS очень сильно упала из-за безумно низких значений TTL в несколько секунд. Всё настолько плохо, что даже APNIC жалуется — https://blog.apnic.net/2019/11/12/stop-using-ridiculously-lo.../
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #28

8. Сообщение от Аноним (8), 20-Дек-21, 16:55	–3 +/–
Российским сс (службам) труднее взламывать сервер если он кеширующий ? А то мне уже явно ломали. Я в москвабаде.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

9. Сообщение от Гость (??), 20-Дек-21, 17:19	+/–
Несколько минут - час простоя это не плохо, зато эффективность кэширования будет хорошая?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #10

10. Сообщение от timur.davletshin (ok), 20-Дек-21, 17:26	–1 +/–
Откуда час простоя? Простоя чего? Зачем вы постоянно перенастраиваете DNS? Для балансировки такой низкий TTL точно не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11, #36

11. Сообщение от Гость (??), 20-Дек-21, 17:33	–1 +/–
Все просто: разные независимые каналы с разными ip, проверяем их каждую минуту, если проблемы, убираем отдачу записи, восстанавливается - возвращаем!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #12, #14

12. Сообщение от timur.davletshin (ok), 20-Дек-21, 17:44	+/–
Вы простите, но я ничего не понял из вашего тезиса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #19

13. Сообщение от Аноним (43), 20-Дек-21, 17:54	+/–
Делать prefetch, как в Unbound, видимо, не собираются. > Добавлена функция "Zone to Cache", позволяющая периодически извлекать DNS-зону и подставлять её содержимое в кэш, для того, чтобы кэш всегда был в "горячем" состоянии и содержал связанные с зоной данные. Работает только для "своих" зон. Какой-нибудь гугл AXFR кому попало не отдаст. А вот prefetch на все зоны работает одинаково.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #44

14. Сообщение от Аноним (43), 20-Дек-21, 17:56	+/–
>  Все просто: разные независимые каналы с разными ip, проверяем их каждую минуту, если проблемы, убираем отдачу записи, восстанавливается - возвращаем! Более того, в PowerDNS Authoritative (не сабж, а его родственник) поддерживаются LUA-записи с функциями ifurlup и ifportup, которые используют фоновые проверки доступности каждые 5 секунд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

15. Сообщение от Аноним (15), 20-Дек-21, 18:41	–2 +/–
А мне в Беларуси уже и blitz.ahadns.com лукашистские СС заблокировали…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

16. Сообщение от Аноним (16), 20-Дек-21, 18:53	+1 +/–
Пидро-зум-евается, что эта херня будет стоять *перед* авторитативным сервером и заниматься кэшированием его ответов, а авторитативный сервер для всего, что ломится на 127.0.0.1 разрешает axfr. Вобщем, учитывая, то, насколько криво в своё время работал кэш этих всех powerdns-поделок при наличии ACL, лучше наверно использовать unbound. Во всяком случае unbound работает согласно стандартам и прозрачно. Да и кэш у него как-то поприятнее устроен. И префетч есть, и DoH, с валидацией ssl и подписей dnssec и свои зоны из bind-like файлов он умеет раздавать и чужие зоны частично переписывать и дополнять своими записями тоже могёт. Единственное, чем может похвастать recursor - не самым дурным lua-апи. Оно и быстрое и кое-чего может. Луа, как язык, конечно, максимально убог своими средствами и синтаксисом, но зато быстрый, пока за него не берутся питонисты и яваскрипткиддисы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #21, #26

18. Сообщение от Аноним (18), 20-Дек-21, 21:48	+/–
Не встречал. dnsdist рук этих же ребят кстати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #20

19. Сообщение от YetAnotherOnanym (ok), 20-Дек-21, 22:16	+/–
Возможно, речь идёт о ЦОДе, подключённом к нескольким провайдерам. При падении линка приходится переключаться на другого провайдера, соответственно, надо менять DNS-записи на IP-адреса этого провайдера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #24

20. Сообщение от Гость (??), 20-Дек-21, 22:27	+1 +/–
dnsdist интересная поделка, только жрущий +30мб каждый newServer немного огорчает!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #30, #31

21. Сообщение от Гость (??), 21-Дек-21, 00:17	+1 +/–
rec перед auth это просто вариант (не лучший и не всегда удобный) перехода когда auth перестал пропускать рекурсивные запросы, auth вполне самостоятелен и имеет свой кэш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #25

22. Сообщение от Аноним (22), 21-Дек-21, 04:26	–1 +/–
Угу, товарищу майору прекурсоры тоже больше нравятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #23

23. Сообщение от Брат Анон (ok), 21-Дек-21, 11:23	–1 +/–
> Угу, товарищу майору прекурсоры тоже больше нравятся. Нет. Товарищу майору вообще пофигу. Возьмёт черенок от лопаты и скажет, что это прекурсор. Что самое смешное -- так оно и будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

24. Сообщение от Аноним (33), 21-Дек-21, 11:49	+/–
Если уж есть свои серваки и деньги на аренду стоек, то арендовать автономку вообще не проблема (20 к/мес). Это как купить машину и заливать в бачок омывателя воду из канавы, потому что на нормальную жидкость денег жалко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #27, #29

25. Сообщение от Аноним (33), 21-Дек-21, 11:55	+/–
>  rec перед auth это просто вариант (не лучший и не всегда удобный) перехода когда auth перестал пропускать рекурсивные запросы Скорее, когда есть корпоративные резолверы, которым нужно быстро отдавать записи для корпоративного домена (возможно, даже внутреннего). Но у нас с этим и Unbound прекрасно справляется, и костыли типа Zone to Cache только помешали бы, потому что на auth некоторые особо ответственные записи генерируются на лету Lua-скриптами, которые делают health check (о чем уже писали выше по обсуждению). > auth вполне самостоятелен и имеет свой кэш. Ага, обычно даже два (query и packet). Ставить перед ним рекурсор "просто так" - вообще бессмысленно. Если не хватает производительности - сделать больше потоков, не хватает железа - сделать балансировку через dnsdist.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #32

26. Сообщение от Аноним (33), 21-Дек-21, 12:01	+/–
>  Пидро-зум-евается, что эта херня будет стоять *перед* авторитативным сервером и заниматься кэшированием его ответов, а авторитативный сервер для всего, что ломится на 127.0.0.1 разрешает axfr. Типа того. Многие до сих пор не могут смириться, что из auth убрали поддержку рекурсии. https://doc.powerdns.com/authoritative/guides/recursion.html В таких сценариях зайдет нормально. > Во всяком случае unbound работает согласно стандартам и прозрачно. Да и кэш у него как-то поприятнее устроен. И префетч есть, и DoH, с валидацией ssl и подписей dnssec и свои зоны из bind-like файлов он умеет раздавать и чужие зоны частично переписывать и дополнять своими записями тоже могёт. Все так. PDNS recursor на его фоне смотрится как игрушка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

27. Сообщение от YetAnotherOnanym (ok), 21-Дек-21, 13:35	+/–
Экий ты резвый чужими деньгами распоряжаться... А если это веб-сервер, почтовик и VPN для "road warriors" на одном хосте в админской каморке? Просто админ предусмотрительный, а начальство разумное, раскошелилось на второй линк от другого провайдера. При падении одного линка использующие его сервисы переводятся другой, автоматом меняются IPшники в DNS (админ же предусмотрительный, выбрал регистратора, у которого можно клеевую запись поменять через API, если DNS тоже придётся перебросить на другой IP), отправка почты приостанавливается (чтобы дальний SMTP не отбил из-за инвалидного DKIM), и так далее. Несколько минут недоступности для тех, кому не повезло запросить DNS незадолго до сбоя - вполне приемлемый компромисс. Да, это кустарщина в чистом виде. Но такой подход скорее можно сравнить с заливкой в бачок омывателя самогонки собственного приготовления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #34

28. Сообщение от Аноним (28), 21-Дек-21, 23:21	+/–
Поддерживаю, с ttl в минуту записи в кэше долго не живут. Заметил что при обращение на прямую к корневому днс очень долго отвечает, а тот же гугл отдаёт быстро, у cf такая же проблема. Гугл кладёт на все эти TTL?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #37

29. Сообщение от _ (??), 21-Дек-21, 23:22	+/–
>Возможно, речь идёт о ЦОДе, подключённом к нескольким провайдерам. Ну то есть ты хочешь поговорить о том чего ни разу и близко не видел? %-D Hy Ok! Начнём с того что если сдохнет любой из провайдеров обеспечивающих __Ц__од - то НИ ОДНОЙ днс-записи менять не придётся! Прикинь!!!! :-D А если это не так - не называйте этот сарайчик ЦОД-ом :) Опеннетные Ыгсрерды - ****** и беспощадные :)  (C)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

30. Сообщение от Sw00p aka Jerom (?), 21-Дек-21, 23:57	+/–
на конфиг взлянуть можно? и желательно какая версия
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #39

31. Сообщение от Sw00p aka Jerom (?), 21-Дек-21, 23:59	+/–
https://dnsdist.org/advanced/tuning.html#memory-usage раздел Memory usage, можно посчитать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #33

32. Сообщение от Sw00p aka Jerom (?), 22-Дек-21, 00:11	+/–
>сделать балансировку через dnsdist. так и надо, ставится dnsdist который разделяет рекурсивные запросы во внешний мир и рекурсивные запросы на внутренний нейм сервер. Но можно и тем же unbound-дом понасоздавать всяких local-zone
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #35, #49

33. Сообщение от Аноним (33), 22-Дек-21, 01:05	+/–
Подтверждаю наблюдения пользователя Гость, жрет память оно как не в себя. setMaxUDPOutstanding(10240) -- default 65535 setMaxTCPQueuedConnections(1000) -- default 10000 setMaxTCPClientThreads(4) -- default 10 setMaxCachedTCPConnectionsPerDownstream(4) -- default 10 setRingBuffersSize(256, 4) -- default 10000, 10 Вообще никак не повлияло на потребление (ну, может, ±1 Мб, на фоне 200 незаметно).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #38

34. Сообщение от Аноним (33), 22-Дек-21, 01:14	+/–
> А если это веб-сервер, почтовик и VPN для "road warriors" на одном хосте в админской каморке? Суровый ЦОД, однако. > отправка почты приостанавливается (чтобы дальний SMTP не отбил из-за инвалидного DKIM) Какое отношение IP-адрес отправителя имеет к DKIM? Открытые ключи публикуются в отдельных TXT-записях. Ничто не мешает локальному релею отправлять хоть с пяти адресов по очереди, лишь бы они в SPF были разрешены. Да и вообще, мало-мальски ответственный админ сделает сайт и почтовик (который будет smarthost для локального релея) на нормальном хостинге, где есть резервирование каналов и прочие плюшки ЦОД, типа резерва питания, нормального охлаждения, отсутствия пыли и т.д. Более-менее оправдано размещать в офисе разве что VPN-гейт, но и то, современные VPN-клиенты (например, OpenVPN) умеют последовательно пробовать несколько серверов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #42

35. Сообщение от Аноним (33), 22-Дек-21, 01:18	+/–
Да можно и не через local-zone. В Unbound есть stub-zone, когда он идет за зоной сразу на заданные серваки, минуя рекурсивный процесс для вышестоящих зон (и, в отличие от forward-zone, запрашивает их без флага RD, так что даже самый придирчивый auth сервер не будет ругаться).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от mikhailnov (ok), 22-Дек-21, 01:18	–1 +/–
Чтобы, если хост упадёт, в А или иной записи поменять IP-адрес быстро
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

37. Сообщение от Аноним (33), 22-Дек-21, 01:27	+/–
Есть как минимум две фичи, позволяющие не тупить даже на малых TTL - prefetch: периодически просматривать кэш, и для часто запрашиваемых записей с истекающим TTL выполнять фоновое обновление раньше, чем истечет TTL. - serve-stale: если RR в данный момент не резолвится, отдавать из кэша, даже если TTL уже истек. Ну и да, можно просто задать минимальный TTL, "кладя" на все TTL ниже этого значения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

38. Сообщение от Sw00p aka Jerom (?), 22-Дек-21, 08:28	+/–
судя по ченджлогу в бета версии 1.7.0 куча фиксов с течкой памяти и расходами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #40, #41

39. Сообщение от Гость (??), 22-Дек-21, 12:13	+/–
Дело не в конфиге, а количестве бэкэндов (newServer) в нем, просто добавление каждого сразу занимает около 30 мегабайт, версия 1.6.1. Из-за этого на небольших vds, сильно не разгуляешься с балансировкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #48

40. Сообщение от Аноним (33), 22-Дек-21, 12:18	+/–
Протестировали мы 1.7.0. В определенных конфигурациях, если апстримный сервер был up, а потом стал down, то dnsdist прекращает healthcheck-и и считает этот сервер вечно down, даже если он поднялся. Остались на 1.6.1.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #47

41. Сообщение от Гость (??), 22-Дек-21, 12:19	+/–
1.6 не замечена значительными утечками, может связано с внедрением DoT и DoH на бэкенде
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #45

42. Сообщение от YetAnotherOnanym (ok), 22-Дек-21, 12:28	+/–
Перепутал, да, SPF, конечно. Шклерож, чо... Сайт, на котором всё и так общедоступное - может быть. А вот почтовик - извините, только в моём помещении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #43

43. Сообщение от Аноним (43), 22-Дек-21, 14:54	+/–
Совет дня: в SPF можно указывать несколько адресов!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #46

44. Сообщение от Аноним (43), 22-Дек-21, 14:57	+/–
>  Делать prefetch, как в Unbound, видимо, не собираются. Попутал, все-таки сделали (refresh-on-ttl-perc) в 4.5.0. А вот serve stale (AKA serve expired) - нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

45. Сообщение от Sw00p aka Jerom (?), 22-Дек-21, 15:47	+/–
> 1.6 не замечена значительными утечками, может связано с внедрением DoT и DoH > на бэкенде там не обязательно из-за утечек, судя по ченджлогам там всякие импрувы reduce memory usage встречаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

46. Сообщение от YetAnotherOnanym (ok), 22-Дек-21, 15:51	+/–
Чтобы при заражении офисного компа спам валился с гейта с валидным SPF?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

47. Сообщение от Sw00p aka Jerom (?), 22-Дек-21, 15:53	+/–
> если апстримный сервер был up, а потом стал down, то dnsdist прекращает healthcheck-и и считает этот сервер вечно down, даже если он поднялся. странная ситуация, нужны подробности, ибо можно сказать, что хилзчек в этой версии перестал работать. Ну и собственно зарепортить багрепорт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

48. Сообщение от Sw00p aka Jerom (?), 22-Дек-21, 16:04	+/–
> Дело не в конфиге, а количестве бэкэндов (newServer) в нем, просто добавление > каждого сразу занимает около 30 мегабайт, версия 1.6.1. Из-за этого на > небольших vds, сильно не разгуляешься с балансировкой. https://github.com/PowerDNS/pdns/issues/9372 вот такой багрепорт был, похоже на вашу ситуацию
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

49. Сообщение от Аноним (49), 23-Дек-21, 12:46	+/–
local-zone под нагрузкой 300-400 запросов в секунду дают серьезную деградацию производительности. Споткнулись на 1.13.0. Применение stub-zone ситуацию выплавило, на чем и продолжаем жить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема