The OpenNET Project / Index page

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

Выпуск PowerDNS Authoritative Server 4.6

28.01.2022 17:35

Увидел свет релиз авторитетного (authoritative) DNS-сервера PowerDNS Authoritative Server 4.6, предназначенного для организации отдачи DNS-зон. По данным разработчиков проекта, PowerDNS Authoritative Server обслуживает примерно 30% из общего числа доменов в Европе (если рассматривать только домены с подписями DNSSEC, то 90%). Код проекта распространяется под лицензией GPLv2.

PowerDNS Authoritative Server предоставляет возможность хранения информации о доменах в различных базах данных, включая MySQL, PostgreSQL, SQLite3, Oracle, и Microsoft SQL Server, а также в LDAP и обычных текстовых файлах в формате BIND. Отдача ответа может быть дополнительно отфильтрована (например, для отсеивания спама) или перенаправлена при помощи подключения собственных обработчиков на языках Lua, Java, Perl, Python, Ruby, C и C++. Из особенностей также выделяются средства для удалённого сбора статистики, в том числе по SNMP или через Web API (для статистики и управления встроен http-сервер), мгновенный перезапуск, встроенный движок для подключения обработчиков на языке Lua, возможность балансировки нагрузки с учётом географического местоположения клиента.

Основные новшества:

  • Реализована поддержка заголовков протокола PROXY во входящих запросах, что позволяет запустить балансировщик нагрузки перед сервером PowerDNS, сохранив при этом передачу сведений об IP-адресах клиентов, подключающихся к балансировщику, такому как dnsdist.
  • Добавлена поддержка механизма ЕDNS Cookies (RFC 7873), позволяющего идентифицировать корректность IP-адреса через обмен Сookie между DNS-сервером и клиентом c целью защиты от спуфинга IP-адресов, DoS-атак, использования DNS в качестве усилителя трафика и попыток отравления кэша.
  • В утилиту pdnsutil и API добавлен новый интерфейс для управления серверами autoprimary, используемыми для автоматизации развёртывания и обновления зон на вторичных DNS-серверах без ручной конфигурации вторичных зон. Достаточно определить для нового домена первичную зону на autoprimary-сервере и новый домен автоматически подхватят вторичные серверы и сконфигурируют для него вторичную зону.


  1. Главная ссылка к новости (https://blog.powerdns.com/2022...)
  2. OpenNews: Выпуск кэшируюшего DNS-сервера PowerDNS Recursor 4.6.0
  3. OpenNews: Выпуск PowerDNS Authoritative Server 4.5
  4. OpenNews: Новый вариант атаки SAD DNS для подстановки фиктивных данных в кэш DNS
  5. OpenNews: Quad9 проиграл апелляцию в деле о принуждении DNS-сервисов к блокировке пиратского контента
  6. OpenNews: Выпуск DNS-сервера BIND 9.18.0 с поддержкой DNS-over-TLS и DNS-over-HTTPS
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/56601-powerdns
Ключевые слова: powerdns, dns
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.11, Аноним (11), 19:13, 28/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > По данным разработчиков проекта, PowerDNS Authoritative Server обслуживает примерно 30% из общего числа доменов в Европе

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

     
     
  • 2.14, Аноним (-), 20:28, 28/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему у провайдеров глобальных сетей BIND господствует.
     
     
  • 3.16, Онаним (?), 21:31, 28/01/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ну все эти поделки - они работают только как authority servers. А BIND можно и так и эдак закрутить. Держать два стека на продакшне - да нафиг бы надо. Второй набор софта конечно имеется, но он совсем детально не тестируется и нужен только на случай отказа BIND.
     
     
  • 4.17, Аноним (17), 21:54, 28/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    PowerDNS тоже когда-то был блоатварью, но потом его распилили пополам.
    А вот разрабов bind блоатварность не смущает, они наоборот, стремятся догнать и перегнать systemD.
    Когда уже они объединят три своих мега-решета (named, dhcpd, ntpd) в один большой бинарник, чтобы не поддерживать лишние стеки?
     
     
  • 5.20, Онаним (?), 22:23, 28/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    named у меня есть, остального нет.
    В качестве абонентского DHCP ныне FreeRADIUS, опять же, чтобы второй стек не держать.
    Вместо ntpd - chronyd, он просто в новых центосах из коробки, работает не хуже.
     
     
  • 6.22, Ivan_83 (ok), 02:05, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    chronyd - однозначно вин по сравнению с остальными поделками, хотя его бы тоже пропатчить чтобы он не умничал что часы слишком далеко ушли (более 100 лет) и потому синкать время не будет.

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

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

     
     
  • 7.24, Ivan_83 (ok), 05:35, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    http://netlab.dhis.org/wiki/ru:software:perl:dhcp_server
     
     
  • 8.27, PnD (??), 12:34, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Олдскульненько Фрюха, perl В моих краях в 200х аналогичный вопрос решали допис... текст свёрнут, показать
     
     
  • 9.32, Ivan_83 (ok), 18:24, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Скрипт работает без привязки к фряхе Не знаю что у вас за хаки такие были, этот... текст свёрнут, показать
     
  • 7.29, Аноним (17), 14:13, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >  chronyd - однозначно вин по сравнению с остальными поделками, хотя его бы тоже пропатчить чтобы он не умничал что часы слишком далеко ушли (более 100 лет) и потому синкать время не будет.

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

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

     
     
  • 8.30, Аноним84701 (ok), 14:52, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, если сделать по умолчанию примерное время время сборки , то на комп ... текст свёрнут, показать
     
     
  • 9.31, Аноним (17), 17:37, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, если у вас встречается погрешность часов более 70 лет, то вы как раз в Патру... текст свёрнут, показать
     
  • 8.33, Ivan_83 (ok), 23:45, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Мне собственно всё равно, я хочу чтобы оно выставило то время которое получило п... текст свёрнут, показать
     
  • 3.38, Аноним (38), 11:45, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    бинд стоит обычно слэйвом к pdns и жопой к интернету
     
     
  • 4.39, Аноним (-), 12:05, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Глупо. Я бы BIND сделал основным DNS-сервером.
     

  • 1.15, Аноним (15), 21:08, 28/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше чем BIND?
     
     
  • 2.18, Аноним (17), 21:58, 28/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если зоны хотя бы иногда надо обновлять - определенно лучше.
     
     
  • 3.21, Онаним (?), 22:24, 28/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чем? Какие проблемы у бинды с обновлением зон?
    5000+ зон, никаких проблем пока не наблюдал.
     
     
  • 4.23, Аноним (-), 03:50, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    гы, а я вообще с 2003 сей bind крутил и так и эдак, и только 1 раз слабая машина просела по CPU под ДДоСом - году эдак в 2006, версии новЕе не проседали. Проблем с тех пор не встречал, не смотря на как минимум 3 горизонта с policy acl'ами везде. Зоны разные, много. Ажиотаж по смежным поводам мне потому не сильно понятен.
     
  • 2.25, Аноним (-), 10:40, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не понимаете, это - другое!
     

  • 1.26, Catwoolfii (ok), 11:23, 29/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    ИМХО, там основная фишка - это API
     
     
  • 2.28, Аноним (17), 14:05, 29/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ага. Но не само по себе, а в сочетании с возможностью использования реплицируемой БД в качестве бэкенда.

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

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

     
     
  • 3.34, Sw00p aka Jerom (?), 13:37, 30/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Ага. Но не само по себе, а в сочетании с возможностью использования реплицируемой БД в качестве бэкенда.

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

     
     
  • 4.35, Аноним (17), 19:01, 30/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    До появления autoprimary (см. новость) был гемор с новыми зонами.
    Да и скорость обновления все равно не та, тот же DNS01 будет очень долго отрабатывать.
     
     
  • 5.36, Sw00p aka Jerom (?), 21:26, 30/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > До появления autoprimary (см. новость) был гемор с новыми зонами.

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

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

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

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


     
  • 5.37, Sw00p aka Jerom (?), 00:35, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    а репликация как я понял синхронная? и как это будет масштабироваться?
     
     
  • 6.40, Аноним (17), 15:00, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Восемь серверов-реплик (четыре VIP, на каждом из которых висит dnsdist, балансирующий между двумя pdns), асинхронная репликация, изменения доставляются в пределах пяти секунд.
     
     
  • 7.41, Sw00p aka Jerom (?), 17:38, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Восемь серверов-реплик (четыре VIP, на каждом из которых висит dnsdist, балансирующий между
    > двумя pdns), асинхронная репликация, изменения доставляются в пределах пяти секунд.

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

     
     
  • 8.42, Аноним (17), 00:31, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Подпись зоны при отправке трансфера - это вообще побочка Так-то никто не запрещ... текст свёрнут, показать
     
     
  • 9.43, Sw00p aka Jerom (?), 00:56, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    можно как включения dnssec влияет на риск надежности от кривых рук только завис... текст свёрнут, показать
     
     
  • 10.44, Аноним (17), 12:13, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Риска два регистратор что-нибудь начудит со своими ключами единичные случаи кл... текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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