PDNS Manager

Multi-Server-Verwaltung

Eines der Kernfeatures, mit dem sich der PDNS Manager von der typischen „Ein Panel, ein Server"-Lösung abhebt: du kannst beliebig viele PowerDNS-Authoritative-Server aus dem gleichen Panel pflegen. Egal, ob die zu derselben DB sprechen, ob das ein Master/Slave-Pair ist oder völlig getrennte Setups in verschiedenen Rechenzentren.

Wie es im Panel aussieht

Unter Einstellungen → DNS-Server liegt die Liste der eingetragenen Server. Pro Eintrag:

  • Name – freier Anzeigename, taucht überall in der UI als Badge auf.
  • URL – HTTP-API-Endpoint (typisch http://<host>:8081).
  • API-Key – derselbe Wert wie in pdns.conf, wird verschlüsselt in der DB abgelegt.
  • Schreibend? Wenn aus, wird der Server als reine Read-Replica behandelt.
Hier ist noch kein Bild hinterlegt. Lege es unter src/assets/screenshots/<dateiname> ab und trage es in der Galerie-Liste ein.

Wie der Manager mit mehreren Servern umgeht

Auf Lese-Seite: zusammengeführte Sicht

Die Zonenliste, die globale Suche und das Dashboard fragen alle eingetragenen Server parallel ab. Identische Zonen werden zu einer einzigen Zeile zusammengefasst. Welche Server die Zone führen, siehst du als kleine Badges hinter dem Zonen-Namen: 

example.com.         master-fra1   master-ams1   replica-fra2
internal.lan.        master-fra1
secret.example.com.  master-ams1

Beim Klick auf eine Zone navigiert das Panel automatisch zum schreibbaren Server – falls vorhanden. Wenn alle Server für diese Zone read-only sind, kommst du in die Read-only-Ansicht.

Auf Schreib-Seite: Fan-out

Seit v2.3.7 werden Schreib-Operationen auf Records (POST, PUT, DELETE, Bulk) automatisch auf alle Server angewendet, die beide Bedingungen erfüllen:

  1. allow_writes = true (also: dieser Server ist als „schreibend" markiert).
  2. Die Zone existiert auf dem Server.

Read-only-Server werden hart abgelehnt (HTTP 403) statt heimlich übersprungen. So merkst du sofort, wenn dein Server-Eintrag versehentlich falsch konfiguriert ist.

Typische Topologien

1 · Mehrere Authoritative auf eine geteilte DB

Klassische Hochverfügbarkeits-Variante: zwei oder mehr PowerDNS-Container/-VMs sprechen via gmysql-Backend dieselbe MariaDB-Cluster-Adresse an. Genau einen davon im Panel als schreibend markieren – die anderen sind reine Replicas. Damit verhinderst du, dass derselbe Schreibvorgang doppelt durch das gmysql-Backend rauscht.

2 · Master + AXFR-Slaves

Klassik. Im Panel ist nur der Master eingetragen, oder zusätzlich die Slaves als Read-only, damit du sie über das Dashboard mitsehen kannst. NOTIFY läuft sowieso nativ über PowerDNS.

3 · Mehrere voneinander unabhängige Setups

Beispielsweise „internes DNS" und „externes DNS" auf unterschiedlichen Server-Paaren. Beide eintragen, beide schreibend – aber sie haben halt jeweils eigene Zonen, die nicht überlappen. Der Manager fasst die Sichten am Dashboard trotzdem zusammen.

Verbindungstest pro Server

In der Server-Liste hat jeder Eintrag einen Verbindungstest-Button. Der schickt einen GET auf /api/v1/servers der PowerDNS-API und meldet:

  • Reachable (HTTP 200) → grün, Statistik wird angezeigt.
  • HTTP 401 → API-Key falsch.
  • HTTP 5xx → PowerDNS hat geantwortet, ist aber kaputt – Detail im Backend-Log.
  • Timeout / Connection refused → Netzwerk- oder Webserver-Konfig in pdns.conf.

API-Key einsehen

Der eingetragene API-Key liegt verschlüsselt in der DB. Wer ihn (z. B. für ein externes Skript) braucht, kann ihn als Admin einmalig abrufen: 

curl -X GET "https://pdns.example.com/api/v1/settings/servers/3/api-key" \
     -H "Authorization: Bearer dnsmgr_usr_..."

Diese Aktion wird mit action=REVEAL_API_KEY ins Audit-Log geschrieben – der Vorgang ist also nachvollziehbar.