Увидел свет релиз авторитетного (authoritative) DNS-сервера PowerDNS Authoritative Server 4.6, предназначенного для организации отдачи DNS-зон. По данным разработчиков проекта, PowerDNS Authoritative Server обслуживает примерно 30% из общего числа доменов в Европе (если рассматривать только домены с подписями DNSSEC, то 90%). Код проекта распространяется под лицензией GPLv2...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56601
> По данным разработчиков проекта, PowerDNS Authoritative Server обслуживает примерно 30% из общего числа доменов в Европепо моим данным гораздо меньше
По-моему у провайдеров глобальных сетей BIND господствует.
Ну все эти поделки - они работают только как authority servers. А BIND можно и так и эдак закрутить. Держать два стека на продакшне - да нафиг бы надо. Второй набор софта конечно имеется, но он совсем детально не тестируется и нужен только на случай отказа BIND.
PowerDNS тоже когда-то был блоатварью, но потом его распилили пополам.
А вот разрабов bind блоатварность не смущает, они наоборот, стремятся догнать и перегнать systemD.
Когда уже они объединят три своих мега-решета (named, dhcpd, ntpd) в один большой бинарник, чтобы не поддерживать лишние стеки?
named у меня есть, остального нет.
В качестве абонентского DHCP ныне FreeRADIUS, опять же, чтобы второй стек не держать.
Вместо ntpd - chronyd, он просто в новых центосах из коробки, работает не хуже.
chronyd - однозначно вин по сравнению с остальными поделками, хотя его бы тоже пропатчить чтобы он не умничал что часы слишком далеко ушли (более 100 лет) и потому синкать время не будет.Когда то переводил провайдера в котором работал с VPN на IPoE, FreeRADIUS - это был первый шаг.
Он сам по себе нормально не работал, пришлось добавить логику через перл модуль.
Ещё немного подумав я выкинул FreeRADIUS и написал свой DHCP сервер на перле, который по нужной логике лазал напрямую в базу за адресами.
FreeRADIUS вообще довольно дурацкое поделие, что бы понять его логику - нужно играть в психиатора, потому что оно очень далеко от того что принято в интернет сообществе.Сам бинд был УГ все годы и только последнее время там выгнали пенсионеров и переписали двигло в нём и в дхцп сервере.
Но поставить unbound в качестве рекурсера с кешем всё равно винрарнее, чем возится с этой тухлятиной.
Зоны не держал, про nsd ничего не скажу.
http://netlab.dhis.org/wiki/ru:software:perl:dhcp_server
Олдскульненько. Фрюха, perl.
В моих краях в 200х аналогичный вопрос решали допиской isc-шного. (Потому что там зоопарк хаков под кучу экзотических клиентов. "На коленке" такое без шансов.)
А когда стали пересаживаться на linux (потому что персонал дешевле, ниже требования к квалификации на тех же задачах), дописку вообще заменили внешним скриптом "читаем лог → пишем в psql".Но да, там было B2B.
Скрипт работает без привязки к фряхе.Не знаю что у вас за хаки такие были, этот скрипт разошёлся по СНГ и работает у разных провайдеров, полагаю что как минимум 100к клиентов ежесуточно он обеспечивает адресами.
При этом я ни разу не получал жалоб что у кого то отваливается инет или не может получить адрес.
Скрипту уже примерно 10+ лет.Там есть несколько захардкоженных аспектов, но они просто чтобы лишнее отбрасывать, и не тратить время на обработку ненужного.
В отличии от ISC~шного тут нет никаких лиз на самом деле, никакой времени аренды и прочего, скрипт работает по принципу: спросили адрес - ответил тем что было в базе.
Формально это не по RFC, но в этом аспекте оно и не надо.
> chronyd - однозначно вин по сравнению с остальными поделками, хотя его бы тоже пропатчить чтобы он не умничал что часы слишком далеко ушли (более 100 лет) и потому синкать время не будет.Вы бы хоть матчасть изучили, что ли
> Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 232 секунд, с теоретической точностью 2−32 секунды. Поскольку шкала времени в NTP повторяется каждые 232 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет[8]).Может, вам еще ботинки пропатчить, чтобы гравитацию игнорировать?
> Вы бы хоть матчасть изучили, что ли
>> Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 232 секунд, с теоретической точностью 2−32 секунды. Поскольку шкала времени в NTP повторяется каждые 232 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет[8]).Ну да, если сделать по умолчанию "примерное время" = "время сборки", то на комп сотрудника Патруля Времени уже не поставишь, да и у пра-правнуков могут быть проблемы :(
А вот у всех остальных будет нормально работать следущие 67 лет.
Ну, если у вас встречается погрешность часов более 70 лет, то вы как раз в Патруле Времени и работаете, так что вам это не поможет.Современные биосы, кстати, обычно так и делают, так что для тех, кому машину времени не дают, проблемы и нет.
Мне собственно всё равно, я хочу чтобы оно выставило то время которое получило по сети, плевать что биос думает что сейчас 2238 год.Если авторам по какой то странной причине мало одного только желания пользователя выраженного ключами ком строки и параметрами из конфиг файла, то они могли бы ещё смотреть на дату компиляции бинарника.
бинд стоит обычно слэйвом к pdns и жопой к интернету
Глупо. Я бы BIND сделал основным DNS-сервером.
Лучше чем BIND?
Если зоны хотя бы иногда надо обновлять - определенно лучше.
Чем? Какие проблемы у бинды с обновлением зон?
5000+ зон, никаких проблем пока не наблюдал.
гы, а я вообще с 2003 сей bind крутил и так и эдак, и только 1 раз слабая машина просела по CPU под ДДоСом - году эдак в 2006, версии новЕе не проседали. Проблем с тех пор не встречал, не смотря на как минимум 3 горизонта с policy acl'ами везде. Зоны разные, много. Ажиотаж по смежным поводам мне потому не сильно понятен.
Вы не понимаете, это - другое!
ИМХО, там основная фишка - это API
Ага. Но не само по себе, а в сочетании с возможностью использования реплицируемой БД в качестве бэкенда.Допустим, во внутренней сети стоит pdns со включенным API, к которому могут подключаться админка (например, powerdns-admin), certbot для DNS01 challenge и прочие средства автоматизации). В качестве бэка у него мастер постгреса, к которому в качестве реплик подключены уже те постгресы, которые на доступных извне серваках стоят (и работают только на чтение). Соответственно
- изменения в зонах расходятся по всем сервакам практически моментально
- можно делать по расписанию снапшоты с базы и фигачить их в архив, или в гит, например, если хочется иметь красивые diff-ы
- а можно использовать постгресовский PITR, позволяющий откатиться на любой выбранный момент времени, если что-то пошло не так
- даже если как-то ломанут внешние серверы - поменять ничего не смогут, потому что реплики работают только на чтение
- DNS01 challenge вообще без ручных костылей.Селектел уже заценил - у него в DNS-сервисе миллионы доменов.
>Ага. Но не само по себе, а в сочетании с возможностью использования реплицируемой БД в качестве бэкенда.а зачем репликацию через бд? есть же собственный механизм мастер слейв (праймари секондари), можно хидден мастер делать.
До появления autoprimary (см. новость) был гемор с новыми зонами.
Да и скорость обновления все равно не та, тот же DNS01 будет очень долго отрабатывать.
> До появления autoprimary (см. новость) был гемор с новыми зонами.так autoprimary это и есть supermaster который был всегда, мастер после изменения зоны посылает notify на слейвы и слейв тянет обновления зон, в чем проблема, меньше минуты занимает любые изменения.
> Да и скорость обновления все равно не та, тот же DNS01 будет
> очень долго отрабатывать.все та же будет, потому-что разницы в апдейте базы нет, реплицируются самой бд или средствами самого днс (трансфером зон). Мастер в любом случае отправит notify слейвам сразу как только увидит изменения зоны.
пс: репликация средствами самого днс как по мне надежнее, чем репликация средствами бд.
а репликация как я понял синхронная? и как это будет масштабироваться?
Восемь серверов-реплик (четыре VIP, на каждом из которых висит dnsdist, балансирующий между двумя pdns), асинхронная репликация, изменения доставляются в пределах пяти секунд.
> Восемь серверов-реплик (четыре VIP, на каждом из которых висит dnsdist, балансирующий между
> двумя pdns), асинхронная репликация, изменения доставляются в пределах пяти секунд.ясно, ваши слейвы работают в нативном (NATIVE) режиме, когда шариться общая база (в режиме чтения), и каждый pdns независим. Тогда, при включении dnssec, каждый из этих pdns сам будет подписывать записи (online signing) и на каждом из них будут копии ключей (общая база). В моем случае хидден мастер подписывает и механизмом трансфера зон уже подписанные зоны (PRESIGNED) отправляет на слейвы, тем самым избавляя слейвы которые принимают запросы, от операций подписывания, что на мой взгляд более приемлемо с точки зрения использования вычислительных ресурсов. Плюс ключи, которые находятся в одном (надежном) месте.
Подпись зоны при отправке трансфера - это вообще побочка. Так-то никто не запрещает подписывать нативные зоны внешним инструментов (presigned) даже в режиме native.
Но мы от dnssec отказались, неприемлемо высокие риски для надежности.
> Так-то никто не запрещает подписывать нативные зоны внешним инструментов (presigned) даже в режиме native.можно
> Но мы от dnssec отказались, неприемлемо высокие риски для надежности.
как включения dnssec влияет на риск надежности? от кривых рук только зависит, и всю рутину с dnssec pdns берет на себя.
Риска два: регистратор что-нибудь начудит со своими ключами (единичные случаи класса clusterf*ck), и косяки на местах (битая подпись или устаревший trust anchor на резолвере/клиенте, вечные проблемы класса FUBAR).