↓ До тексту
  1. Статті/

PowerDNS-Admin проти Poweradmin: дві веб-панелі, дві філософії

cat /etc/passwd
Автор
cat /etc/passwd
Технічний блог про Linux, DevOps та Open Source технології.
Зміст
Відмовостійкий DNS - частина серії статей.
Частина 7: ця стаття (ти тут)

У попередніх частинах ми керували DNS із терміналу - pdnsutil і curl до API. Але більшість хоче мишкою. Для PowerDNS є дві популярні веб-панелі з до плутанини схожими назвами: PowerDNS-Admin і Poweradmin. Їх постійно плутають - а вони архітектурно протилежні:

  • PowerDNS-Admin керує сервером через REST API (той, що ми ввімкнули в частині 1);
  • Poweradmin пише прямо в базу MariaDB (таблиці domains/records).

Поставимо обидві в ту саму мережу, що й наш master-slave + DNSSEC стенд, і подивимось наживо, чим вони різняться.

Що потрібно зробити?
#

Розгорнути обидві панелі поряд, підключити до того самого PowerDNS і порівняти: як підключаються, як виглядають, як керують записами й DNSSEC. І головне - зрозуміти, кому яка підходить.

З чим працюю?
#

Той самий стенд: ns1 (майстер, API + БД), ns2 (репліка), зона example.com з DNSSEC. Панелі ставлю на окремий контейнер panels - і одразу спливає ключова різниця:

1
2
3
4
5
6
7
8
9
                         ┌─────────────── panels ───────────────┐
   публічна мережа       │  PowerDNS-Admin  ─── HTTP API ───────────┐
   (DNS, 10.10.60.x) ────┤  :9191 (Docker)                       │  │
                         │                                       │  │
   приватна мережа       │  Poweradmin      ─── пряма БД ──────────┐│  │
   (БД, 10.20.0.x)  ─────┤  :80 (LAMP)                           ││  │
                         └───────────────────────────────────────┘│  │
                                                                  ▼  ▼
                                   ns1:  MariaDB (:3306, приватна)   pdns API (:8081, публічна)

PowerDNS-Admin достукався до ns1 по HTTP API через публічну мережу - йому більше нічого не треба. А Poweradmin потребує саму базу, а вона в нас на приватній мережі - довелося дати контейнеру ще й приватний інтерфейс. Це вже перша відмінність: одна панель чіпляється одним HTTP-портом, друга лізе в БД.

Весь процес встановлення обох панелей - у записі:

Далі те саме по кроках, уже з поясненнями.

Встановлення: PowerDNS-Admin (через API)
#

PowerDNS-Admin найпростіше запустити в Docker. Йому потрібна лише своя база (для користувачів/налаштувань - бери SQLite) і адреса нашого API:

1
2
3
4
5
6
apt install -y docker.io
docker run -d --name pda --restart unless-stopped -p 9191:80 \
  -e SECRET_KEY="$(openssl rand -base64 24)" \
  -e SQLALCHEMY_DATABASE_URI="sqlite:////data/powerdns-admin.db" \
  -v pda-data:/data \
  powerdnsadmin/pda-legacy:latest

Без SQLALCHEMY_DATABASE_URI образ одразу падає - це його обовʼязкова змінна.

Далі відкриваємо http://<панелі>:9191, реєструємо першого користувача (він стає адміністратором) і в Settings → PowerDNS вказуємо API: URL http://<ns1>:8081, ключ і версію. Усе - панель підтягує зони. Вона нічого не знає про базу pdns; спілкується винятково по API.

Встановлення: Poweradmin (пряма БД)
#

Poweradmin - класичний PHP-застосунок. Свої таблиці (користувачі, права, шаблони) він тримає в окремій базі, а записи PowerDNS читає з бази pdns. Тож на майстрі заводимо для нього базу й користувача (панель під’єднуватиметься з приватної адреси контейнера):

1
2
3
4
5
# на ns1 (майстрі)
mysql -e "CREATE DATABASE poweradmin CHARACTER SET utf8mb4;
          CREATE USER 'padmin'@'10.20.0.3' IDENTIFIED BY 'надійний-пароль';
          GRANT ALL ON poweradmin.* TO 'padmin'@'10.20.0.3';
          GRANT ALL ON pdns.* TO 'padmin'@'10.20.0.3';"

Потім на контейнері - LAMP (разом із mariadb-client) і сам Poweradmin:

1
2
apt install -y apache2 php php-mysql php-intl php-gmp php-curl php-mbstring mariadb-client git
git clone https://github.com/poweradmin/poweradmin /var/www/poweradmin

Налаштування - у config/settings.php: name - своя база Poweradmin, а pdns_db_name - база із записами PowerDNS (обидві на тому самому сервері):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<?php
return [
    'database' => [
        'host' => '10.20.0.1',       // приватна адреса MariaDB майстра
        'user' => 'padmin',
        'password' => 'надійний-пароль',
        'name' => 'poweradmin',      // своя база панелі
        'type' => 'mysql',
        'pdns_db_name' => 'pdns',     // база із записами PowerDNS
    ],
    'security' => ['session_key' => 'випадковий-рядок'],
];

Далі - веб-інсталятор (http://<панелі>/install/): він створює таблиці Poweradmin, заводить адміна й дописує конфіг. (У записі я роблю те саме з терміналу: вантажу схему sql/poweradmin-mysql-db-structure.sql і додаю адміна - кому як зручніше.) Після інсталяції:

1
rm -rf /var/www/poweradmin/install

⚠️ Каталог install/ обовʼязково видалити - інакше Poweradmin відмовляється працювати й замість логіну показує «The install/ directory exists, you must remove it first». Класичний крок, який легко забути.

Окрема база для панелі (а не вкидання її таблиць у pdns) тримає базу PowerDNS чистою - і її не засмічують реплікації на ns2. Але сам факт лишається: Poweradmin потребує прямого мережевого доступу до БД, тоді як PowerDNS-Admin обходиться HTTP-портом API.

Візуальне порівняння
#

Обидві панелі підключені до того самого PowerDNS і бачать нашу example.com. Але виглядають і поводяться по-різному.

Головна
#

PowerDNS-Admin - сучасний інтерфейс: бічне меню, таблиця зон, і він одразу показує зелений замок DNSSEC (прочитав наш підпис через API):

PowerDNS-Admin - дашборд

Poweradmin - класичний «пульт» з іконок, помітно хостинг-орієнтований: окремо Master/Slave/Supermaster зони, Bulk Registration, PTR Records, шаблони, групи:

Poweradmin - головна

Керування записами
#

PowerDNS-Admin редагує записи акуратно, по одному, ховає службовий SOA, має кнопки Changelog і Zone Settings:

PowerDNS-Admin - записи зони

Poweradmin показує всі записи (разом із SOA) в одній великій редагованій таблиці, плюс хостингові речі: Ownership, Metadata, Generate PTR, Export, Save as Template, Bulk add:

Poweradmin - редагування зони

Уже з цих двох екранів видно різницю підходів: PowerDNS-Admin - про акуратне керування й сучасний UX; Poweradmin - про щільний хостинг-функціонал в одному вікні.

DNSSEC
#

А ось тут ховається найцікавіша відмінність. У частині 6 ми підписали example.com однією командою pdnsutil secure-zone. Подивимось, як кожна панель показує цей підпис.

PowerDNS-Admin бачить DNSSEC одразу - це той самий зелений замок, що й на головній. Клік по ньому відкриває ключ: DNSKEY і готові DS-записи для реєстратора (ті самі, що ми в частині 6 діставали через pdnsutil export-zone-ds), плюс кнопку ввімкнути/вимкнути:

PowerDNS-Admin - DNSSEC

Нічого налаштовувати не довелось: PowerDNS-Admin працює через API, а DNSSEC - це частина того самого API. Отримав безкоштовно.

Poweradmin спершу DNSSEC не показує взагалі. І це принципово: ключі DNSSEC не можна читати чи створювати простим SELECT/INSERT у базу - потрібні криптооперації, які вміє лише сам PowerDNS. Тому Poweradmin v4 керує DNSSEC винятково через API - а якщо API не налаштований, він просто вдає, що DNSSEC немає. Щоб його побачити, довелось у config/settings.php доповісти API - ту саму залежність, якої Poweradmin зі своїм прямим доступом до бази дозволяв уникнути:

1
2
3
4
5
6
'dnssec'   => ['enabled' => true],
'pdns_api' => [
    'url' => 'http://10.10.60.103:8081',   // той самий API ns1
    'key' => '...',
    'server_name' => 'localhost',
],

Зате після цього сторінка DNSSEC у Poweradmin навіть докладніша за модалку PDA: таблиця ключів (тип CSK, тег 56910, алгоритм ECDSAP256SHA256), кнопки Add new key, Show DS and DNSKEY, Unsign zone, а кожен ключ можна активувати, експортувати чи імпортувати:

Poweradmin - DNSSEC

Зверніть увагу на тег ключа - 56910 в обох панелях. Це той самий CSK із нашого стенду: обидві панелі говорять з одним сервером через один API. Висновок трохи несподіваний: для DNSSEC обидві панелі однаково залежать від API. У PowerDNS-Admin він вбудований від початку, а Poweradmin заради DNSSEC мусить його докрутити - прямого доступу до бази для криптографії не вистачає.

Таблиця відмінностей
#

PowerDNS-AdminPoweradmin
СтекPython/Flask, зазвичай DockerPHP, класичний LAMP
Керує pdnsчерез REST APIпрямо в базі
Де може стоятибудь-де (лише HTTP до API)лише з доступом до БД
Зміни застосовуютьсяодразу (через pdns)потрібен pdns_control rediscover (пише повз pdns)
DNSSECз коробки (API вбудований): замок, DS, DNSKEY, вмик/вимкє, але тільки через API - треба окремо ввімкнути й дати ключ API
Автентифікаціялокальна + LDAP/OAuth/SAML, аудит дійлокальна/LDAP, шаблони прав
Хостинг-функціїбазовіsupermaster, bulk-реєстрація, PTR, шаблони зон, власники
Інтерфейссучасний (sidebar)класичний (icon-grid)
Історія змінActivity + Changelogлоги

Що вибрати
#

  • PowerDNS-Admin - якщо цінуєте сучасний UX і API-підхід: панель не потребує доступу до БД (безпечніше), зміни застосовуються одразу через pdns, є зручне керування DNSSEC і корпоративна автентифікація (SSO/LDAP/SAML) з аудитом. Логічний вибір для команд та інфраструктури - і, до речі, ідеально лягає на наш реплікований стенд: пише через API на майстрі, репліка підхоплює сама.
  • Poweradmin - якщо у вас хостинговий сценарій: багато зон і клієнтів, потрібні supermaster, масова реєстрація, генерація PTR, шаблони зон і тонкі права. Легкий LAMP, перевірений роками. Але він вимагає прямого доступу до БД (у нашому випадку - ще й окремого мережевого шляху до приватної мережі) і пише повз pdns, тож памʼятайте про rediscover.

Коротко: PowerDNS-Admin - через API, Poweradmin - через базу. Перша - для чистого керування й безпеки звʼязності; друга - для щільного хостинг-функціоналу.

Що далі
#

Керувати записами мишкою - зручно, але відмовостійкості на рівні самих записів панель не додасть. Наступний крок - health-check прямо в DNS: PowerDNS через LUA-записи сам опитує бекенди й віддає лише живі, тож www ніколи не вказує на мертвий сервер.

Підсумок
#

Схожі назви приховують протилежні рішення. PowerDNS-Admin тримається осторонь бази й говорить із сервером мовою API - акуратно, безпечно, з DNSSEC і SSO. Poweradmin занурюється прямо в базу й дає щільний хостинг-арсенал - ціною тіснішої звʼязності та rediscover. На нашому стенді обидві керують однією зоною; вибір - між філософіями, а не між «кращою» і «гіршою».

Відмовостійкий DNS - частина серії статей.
Частина 7: ця стаття (ти тут)

Related

PowerDNS: DNSSEC за одну команду

DNSSEC підтверджує, що відповідь DNS справжня, а не підмінена. У PowerDNS увімкнути його - одна команда: secure-zone генерує ключ і сервер підписує відповіді онлайн. Ключі лежать у MariaDB, тож їдуть реплікацією - репліка віддає зону підписаною сама. Показуємо RRSIG, DS для реєстратора і перевіряємо на обох нодах. Частина серії про відмовостійкий authoritative DNS.

dnsdist: захист від флуду TCP-зʼєднань

·5 хвилин
У частині 4 ми різали UDP-флуд запитами. Але атака буває по TCP-зʼєднаннях: мало запитів, багато конектів - і TCP-потоки сервера забиті. Ставимо в dnsdist ліміти зʼєднань: скільки одночасних з одного IP, скільки запитів на конект, скільки конект живе. Наживо відкриваємо 60 зʼєднань з однієї машини й бачимо, як їх ріже до 5, а чесний клієнт не помічає.

dnsdist проти флуду: rate-limit і динамічні блоки

Резолвери заливають authoritative-сервер запитами, і pdns захлинається. Ставимо захист у dnsdist: ліміт на IP з форсуванням TCP проти спуфленого UDP і динамічні блоки, що тимчасово банять абʼюзера. Заливаємо сервер наживо з сусідньої машини - потік падає з 800 до ~100 запитів/с, а чесний клієнт не помічає. Частина серії про відмовостійкий authoritative DNS.