The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

"Выпуск PowerDNS Authoritative Server 4.6"  +/
Сообщение от opennews (?), 28-Янв-22, 17:39 
Увидел свет релиз авторитетного (authoritative) DNS-сервера  PowerDNS Authoritative Server 4.6, предназначенного для организации отдачи DNS-зон.  По данным разработчиков проекта, PowerDNS Authoritative Server обслуживает примерно 30% из общего числа доменов в Европе (если рассматривать только домены с подписями DNSSEC, то 90%). Код проекта распространяется под лицензией  GPLv2...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56601

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

11. Сообщение от Аноним (11), 28-Янв-22, 19:13   –1 +/
> По данным разработчиков проекта, PowerDNS Authoritative Server обслуживает примерно 30% из общего числа доменов в Европе

по моим данным гораздо меньше

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14

14. Сообщение от Аноним (-), 28-Янв-22, 20:28   +/
По-моему у провайдеров глобальных сетей BIND господствует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #16, #38

15. Сообщение от Аноним (15), 28-Янв-22, 21:08   +/
Лучше чем BIND?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #25

16. Сообщение от Онаним (?), 28-Янв-22, 21:31   –3 +/
Ну все эти поделки - они работают только как authority servers. А BIND можно и так и эдак закрутить. Держать два стека на продакшне - да нафиг бы надо. Второй набор софта конечно имеется, но он совсем детально не тестируется и нужен только на случай отказа BIND.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #17

17. Сообщение от Аноним (17), 28-Янв-22, 21:54   +1 +/
PowerDNS тоже когда-то был блоатварью, но потом его распилили пополам.
А вот разрабов bind блоатварность не смущает, они наоборот, стремятся догнать и перегнать systemD.
Когда уже они объединят три своих мега-решета (named, dhcpd, ntpd) в один большой бинарник, чтобы не поддерживать лишние стеки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #20

18. Сообщение от Аноним (17), 28-Янв-22, 21:58   +1 +/
Если зоны хотя бы иногда надо обновлять - определенно лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #21

20. Сообщение от Онаним (?), 28-Янв-22, 22:23   +/
named у меня есть, остального нет.
В качестве абонентского DHCP ныне FreeRADIUS, опять же, чтобы второй стек не держать.
Вместо ntpd - chronyd, он просто в новых центосах из коробки, работает не хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #22

21. Сообщение от Онаним (?), 28-Янв-22, 22:24   +/
Чем? Какие проблемы у бинды с обновлением зон?
5000+ зон, никаких проблем пока не наблюдал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23

22. Сообщение от Ivan_83 (ok), 29-Янв-22, 02:05   +1 +/
chronyd - однозначно вин по сравнению с остальными поделками, хотя его бы тоже пропатчить чтобы он не умничал что часы слишком далеко ушли (более 100 лет) и потому синкать время не будет.

Когда то переводил провайдера в котором работал с VPN на IPoE, FreeRADIUS - это был первый шаг.
Он сам по себе нормально не работал, пришлось добавить логику через перл модуль.
Ещё немного подумав я выкинул FreeRADIUS и написал свой DHCP сервер на перле, который по нужной логике лазал напрямую в базу за адресами.
FreeRADIUS вообще довольно дурацкое поделие, что бы понять его логику - нужно играть в психиатора, потому что оно очень далеко от того что принято в интернет сообществе.

Сам бинд был УГ все годы и только последнее время там выгнали пенсионеров и переписали двигло в нём и в дхцп сервере.
Но поставить unbound в качестве рекурсера с кешем всё равно винрарнее, чем возится с этой тухлятиной.
Зоны не держал, про nsd ничего не скажу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #24, #29

23. Сообщение от Аноним (-), 29-Янв-22, 03:50   +/
гы, а я вообще с 2003 сей bind крутил и так и эдак, и только 1 раз слабая машина просела по CPU под ДДоСом - году эдак в 2006, версии новЕе не проседали. Проблем с тех пор не встречал, не смотря на как минимум 3 горизонта с policy acl'ами везде. Зоны разные, много. Ажиотаж по смежным поводам мне потому не сильно понятен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

24. Сообщение от Ivan_83 (ok), 29-Янв-22, 05:35   +1 +/
http://netlab.dhis.org/wiki/ru:software:perl:dhcp_server
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27

25. Сообщение от Аноним (-), 29-Янв-22, 10:40   +/
Вы не понимаете, это - другое!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

26. Сообщение от Catwoolfii (ok), 29-Янв-22, 11:23   +3 +/
ИМХО, там основная фишка - это API
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

27. Сообщение от PnD (??), 29-Янв-22, 12:34   +/
Олдскульненько. Фрюха, perl.
В моих краях в 200х аналогичный вопрос решали допиской isc-шного. (Потому что там зоопарк хаков под кучу экзотических клиентов. "На коленке" такое без шансов.)
А когда стали пересаживаться на linux (потому что персонал дешевле, ниже требования к квалификации на тех же задачах), дописку вообще заменили внешним скриптом "читаем лог → пишем в psql".

Но да, там было B2B.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #32

28. Сообщение от Аноним (17), 29-Янв-22, 14:05   +/
Ага. Но не само по себе, а в сочетании с возможностью использования реплицируемой БД в качестве бэкенда.

Допустим, во внутренней сети стоит pdns со включенным API, к которому могут подключаться админка (например, powerdns-admin), certbot для DNS01 challenge и прочие средства автоматизации). В качестве бэка у него мастер постгреса, к которому в качестве реплик подключены уже те постгресы, которые на доступных извне серваках стоят (и работают только на чтение). Соответственно
- изменения в зонах расходятся по всем сервакам практически моментально
- можно делать по расписанию снапшоты с базы и фигачить их в архив, или в гит, например, если хочется иметь красивые diff-ы
- а можно использовать постгресовский PITR, позволяющий откатиться на любой выбранный момент времени, если что-то пошло не так
- даже если как-то ломанут внешние серверы - поменять ничего не смогут, потому что реплики работают только на чтение
- DNS01 challenge вообще без ручных костылей.

Селектел уже заценил - у него в DNS-сервисе миллионы доменов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #34

29. Сообщение от Аноним (17), 29-Янв-22, 14:13   +/
>  chronyd - однозначно вин по сравнению с остальными поделками, хотя его бы тоже пропатчить чтобы он не умничал что часы слишком далеко ушли (более 100 лет) и потому синкать время не будет.

Вы бы хоть матчасть изучили, что ли
> Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 232 секунд, с теоретической точностью 2−32 секунды. Поскольку шкала времени в NTP повторяется каждые 232 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет[8]).

Может, вам еще ботинки пропатчить, чтобы гравитацию игнорировать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30, #33

30. Сообщение от Аноним84701 (ok), 29-Янв-22, 14:52   +/
> Вы бы хоть матчасть изучили, что ли
>> Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 232 секунд, с теоретической точностью 2−32 секунды. Поскольку шкала времени в NTP повторяется каждые 232 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет[8]).

Ну да, если сделать по умолчанию "примерное время" = "время сборки", то на комп сотрудника Патруля Времени уже не поставишь, да и у пра-правнуков могут быть проблемы :(
А вот у всех остальных будет нормально работать следущие 67 лет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #31

31. Сообщение от Аноним (17), 29-Янв-22, 17:37   +/
Ну, если у вас встречается погрешность часов более 70 лет, то вы как раз в Патруле Времени и работаете, так что вам это не поможет.

Современные биосы, кстати, обычно так и делают, так что для тех, кому машину времени не дают, проблемы и нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от Ivan_83 (ok), 29-Янв-22, 18:24   +/
Скрипт работает без привязки к фряхе.

Не знаю что у вас за хаки такие были, этот скрипт разошёлся по СНГ и работает у разных провайдеров, полагаю что как минимум 100к клиентов ежесуточно он обеспечивает адресами.
При этом я ни разу не получал жалоб что у кого то отваливается инет или не может получить адрес.
Скрипту уже примерно 10+ лет.

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

В отличии от ISC~шного тут нет никаких лиз на самом деле, никакой времени аренды и прочего, скрипт работает по принципу: спросили адрес - ответил тем что было в базе.
Формально это не по RFC, но в этом аспекте оно и не надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

33. Сообщение от Ivan_83 (ok), 29-Янв-22, 23:45   +/
Мне собственно всё равно, я хочу чтобы оно выставило то время которое получило по сети, плевать что биос думает что сейчас 2238 год.

Если авторам по какой то странной причине мало одного только желания пользователя выраженного ключами ком строки и параметрами из конфиг файла, то они могли бы ещё смотреть на дату компиляции бинарника.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

34. Сообщение от Sw00p aka Jerom (?), 30-Янв-22, 13:37   +1 +/
>Ага. Но не само по себе, а в сочетании с возможностью использования реплицируемой БД в качестве бэкенда.

а зачем репликацию через бд? есть же собственный механизм мастер слейв (праймари секондари), можно хидден мастер делать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #35

35. Сообщение от Аноним (17), 30-Янв-22, 19:01   +/
До появления autoprimary (см. новость) был гемор с новыми зонами.
Да и скорость обновления все равно не та, тот же DNS01 будет очень долго отрабатывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #36, #37

36. Сообщение от Sw00p aka Jerom (?), 30-Янв-22, 21:26   +/
> До появления autoprimary (см. новость) был гемор с новыми зонами.

так autoprimary это и есть supermaster который был всегда, мастер после изменения зоны посылает notify на слейвы и слейв тянет обновления зон, в чем проблема, меньше минуты занимает любые изменения.

> Да и скорость обновления все равно не та, тот же DNS01 будет
> очень долго отрабатывать.

все та же будет, потому-что разницы в апдейте базы нет, реплицируются самой бд или средствами самого днс (трансфером зон). Мастер в любом случае отправит notify слейвам сразу как только увидит изменения зоны.

пс: репликация средствами самого днс как по мне надежнее, чем репликация средствами бд.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

37. Сообщение от Sw00p aka Jerom (?), 31-Янв-22, 00:35   +/
а репликация как я понял синхронная? и как это будет масштабироваться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #40

38. Сообщение от Аноним (38), 31-Янв-22, 11:45   +/
бинд стоит обычно слэйвом к pdns и жопой к интернету
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #39

39. Сообщение от Аноним (-), 31-Янв-22, 12:05   +/
Глупо. Я бы BIND сделал основным DNS-сервером.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

40. Сообщение от Аноним (17), 31-Янв-22, 15:00   +/
Восемь серверов-реплик (четыре VIP, на каждом из которых висит dnsdist, балансирующий между двумя pdns), асинхронная репликация, изменения доставляются в пределах пяти секунд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #41

41. Сообщение от Sw00p aka Jerom (?), 31-Янв-22, 17:38   +/
> Восемь серверов-реплик (четыре VIP, на каждом из которых висит dnsdist, балансирующий между
> двумя pdns), асинхронная репликация, изменения доставляются в пределах пяти секунд.

ясно, ваши слейвы работают в нативном (NATIVE) режиме, когда шариться общая база (в режиме чтения), и каждый pdns независим. Тогда, при включении dnssec, каждый из этих pdns сам будет подписывать записи (online signing) и на каждом из них будут копии ключей (общая база). В моем случае хидден мастер подписывает и механизмом трансфера зон уже подписанные зоны (PRESIGNED) отправляет на слейвы, тем самым избавляя слейвы которые принимают запросы, от операций подписывания, что на мой взгляд более приемлемо с точки зрения использования вычислительных ресурсов. Плюс ключи, которые находятся в одном (надежном) месте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #42

42. Сообщение от Аноним (17), 01-Фев-22, 00:31   +/
Подпись зоны при отправке трансфера - это вообще побочка. Так-то никто не запрещает подписывать нативные зоны внешним инструментов (presigned) даже в режиме native.
Но мы от dnssec отказались, неприемлемо высокие риски для надежности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #43

43. Сообщение от Sw00p aka Jerom (?), 01-Фев-22, 00:56   +/
> Так-то никто не запрещает подписывать нативные зоны внешним инструментов (presigned) даже в режиме native.

можно

> Но мы от dnssec отказались, неприемлемо высокие риски для надежности.

как включения dnssec влияет на риск надежности? от кривых рук только зависит, и всю рутину с dnssec pdns берет на себя.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #44

44. Сообщение от Аноним (17), 01-Фев-22, 12:13   +/
Риска два: регистратор что-нибудь начудит со своими ключами (единичные случаи класса clusterf*ck), и косяки на местах (битая подпись или устаревший trust anchor на резолвере/клиенте, вечные проблемы класса FUBAR).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43


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

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




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру