1 23/05/2026 10 min

PowerDNS su Ubuntu 22.04: cosa installare davvero

Su Ubuntu 22.04, PowerDNS va trattato come due pezzi distinti: il server autorevole che risponde alle query e il backend che conserva i record. Se l’obiettivo è servire zone DNS in modo affidabile, la scelta più comune è PowerDNS Authoritative Server con backend MariaDB/MySQL. È una combinazione pratica perché separa il motore DNS dal dato, rende semplice fare backup e ti evita di infilare i record in file sparsi quando l’ambiente cresce.

Qui non stiamo parlando di resolver ricorsivo, ma di authoritative DNS: il server deve rispondere per le zone che gestisce e basta. Se cerchi caching, forwarding o recursion, il componente giusto è un altro. Questa distinzione conta perché cambia porta, policy, logging e, soprattutto, il tipo di test che devi fare dopo l’installazione.

Scenario atteso e controlli iniziali

Stato atteso: il server Ubuntu 22.04 ha accesso ai repository, una porta UDP/TCP 53 libera, un backend SQL raggiungibile e un dominio di test da pubblicare. Stato osservato prima di toccare nulla: non c’è ancora un servizio DNS attivo, quindi il primo rischio reale è sovrascrivere un demone già presente, oppure pubblicare una zona con serial errato e non accorgersene finché il secondario non sincronizza.

Prima di installare, verifica quali servizi stanno già usando la porta 53 e se il sistema ha componenti che possono entrare in conflitto con PowerDNS.

Verifiche rapide sul nodo

Esegui questi controlli: se trovi un servizio già in ascolto su 53, va gestito prima del cambio.

sudo ss -lntup '( sport = :53 )'
systemctl list-units --type=service | grep -Ei 'bind9|named|pdns|dnsmasq|unbound'
resolvectl status | sed -n '1,120p'

Esito atteso: nessun demone inatteso in ascolto su 53, oppure la consapevolezza che devi fermarlo o spostarlo. Se trovi bind9 o dnsmasq attivi sul server che farà da authoritative DNS, non andare avanti alla cieca: prima definisci il blast radius e il rollback del servizio che dovrai fermare.

Installazione dei pacchetti su Ubuntu 22.04

Per Ubuntu 22.04, il percorso più lineare è installare il server authoritative e il backend SQL. Nel dubbio, usa il repository standard della distribuzione: è meno esotico e più facile da manutenere. Se hai esigenze di versione specifica, puoi valutare il repository ufficiale PowerDNS, ma per una installazione ordinaria non serve complicarsi la vita.

Aggiorna l’indice dei pacchetti e installa il server con il backend MySQL/MariaDB.

sudo apt update
sudo apt install pdns-server pdns-backend-mysql mariadb-server

Se vuoi usare MySQL remoto invece di MariaDB locale, il pacchetto backend è lo stesso: cambia solo il punto di connessione e la gestione degli account. In produzione, MariaDB locale ha il vantaggio di semplificare latenza e troubleshooting; il rovescio della medaglia è che devi proteggere bene il disco e il backup del database.

Dopo l’installazione, controlla che i servizi esistano e non siano partiti in modo anomalo.

systemctl status pdns --no-pager
systemctl status mariadb --no-pager

Se pdns risulta in errore subito dopo il setup, il problema tipico non è il demone in sé ma la configurazione del backend o il conflitto sulla porta 53. In quel caso non correggere “a tentativi”: prima guarda il log del servizio.

journalctl -u pdns -b --no-pager | tail -n 80

Schema database per PowerDNS

PowerDNS con backend SQL richiede uno schema dedicato. È il passaggio che spesso viene sottovalutato, poi ci si ritrova con un servizio attivo ma senza zone leggibili. Il database deve contenere tabelle per domini, record, metadati e, se usi funzionalità più avanzate, anche per il traffico API e le statistiche.

Su Ubuntu, i file di schema si trovano di solito sotto /usr/share/doc/pdns-backend-mysql/ o in un percorso simile, a seconda del pacchetto. Non dare per scontato il nome esatto: verifica il path reale sul nodo.

dpkg -L pdns-backend-mysql | grep -E 'schema|sql'

Se il file schema è presente, crea il database e l’utente con privilegi minimi. Evita di usare account troppo permissivi: PowerDNS deve leggere e scrivere nel proprio schema, non amministrare l’intero server SQL.

sudo mysql
CREATE DATABASE powerdns;
CREATE USER 'pdns'@'localhost' IDENTIFIED BY 'SOSTITUISCI_CON_PASSWORD_FORTE';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER ON powerdns.* TO 'pdns'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Importa poi lo schema. Il comando preciso dipende dal pacchetto installato, quindi prima individua il file e solo dopo applicalo.

sudo mysql powerdns < /usr/share/doc/pdns-backend-mysql/schema.mysql.sql

Se il file non esiste con quel nome, non forzare il path: usa il risultato di dpkg -L e adatta il comando. È un classico gap da chiudere subito, perché uno schema non importato significa un demone che parte ma non trova i dati.

Configurazione del backend in PowerDNS

Il file principale è /etc/powerdns/pdns.conf. Su Ubuntu, conviene tenere la configurazione essenziale e spostare i dettagli del backend in un file separato se vuoi mantenere ordine. Il minimo indispensabile è dire a PowerDNS dove sta il database e su quale interfaccia deve ascoltare.

Prima di modificare, fai un backup del file o lavora con uno snippet versionato. Il rollback deve essere banale.

sudo cp /etc/powerdns/pdns.conf /etc/powerdns/pdns.conf.bak.$(date +%F-%H%M)

Una configurazione base ragionevole può essere questa:

launch=gmysql
local-address=0.0.0.0
local-port=53
setgid=pdns
setuid=pdns
gmysql-host=127.0.0.1
gmysql-dbname=powerdns
gmysql-user=pdns
gmysql-password=SOSTITUISCI_CON_PASSWORD_FORTE

Non lasciare password in chiaro in un ticket, in una wiki pubblica o in un documento condiviso senza controllo accessi. Se devi distribuire il file, usa i permessi corretti e valuta un meccanismo di secret management o almeno un file separato con accesso ristretto. Il punto non è essere eleganti: è evitare di regalare credenziali a chi non deve vederle.

Imposta permessi coerenti sul file di configurazione, poi riavvia il servizio.

sudo chown root:pdns /etc/powerdns/pdns.conf
sudo chmod 640 /etc/powerdns/pdns.conf
sudo systemctl restart pdns
sudo systemctl status pdns --no-pager

Se il riavvio fallisce, il log del servizio ti dice quasi sempre se il problema è il backend SQL, il binding sulla porta 53 o un parametro non riconosciuto.

Pubblicare la prima zona DNS

Installare il demone non basta: una installazione utile deve servire almeno una zona di test. La zona iniziale deve essere semplice, con record A, NS e SOA coerenti. Il serial del SOA va trattato come dato operativo, non come dettaglio ornamentale: se sbagli serial, i secondari non aggiornano come ti aspetti.

Puoi inserire la zona via SQL oppure usare l’API, ma per una prima verifica locale il modo più trasparente è popolare il database direttamente. Ecco un esempio minimale.

INSERT INTO domains (name, type) VALUES ('example.test', 'NATIVE');
INSERT INTO records (domain_id, name, type, content, ttl, prio, disabled, ordername, auth)
VALUES
((SELECT id FROM domains WHERE name='example.test'), 'example.test', 'SOA', 'ns1.example.test hostmaster.example.test 2024052201 3600 600 604800 3600', 3600, NULL, 0, NULL, 1),
((SELECT id FROM domains WHERE name='example.test'), 'example.test', 'NS', 'ns1.example.test', 3600, NULL, 0, NULL, 1),
((SELECT id FROM domains WHERE name='example.test'), 'ns1.example.test', 'A', '192.0.2.10', 3600, NULL, 0, NULL, 1),
((SELECT id FROM domains WHERE name='example.test'), 'www.example.test', 'A', '192.0.2.20', 3600, NULL, 0, NULL, 1);

Il dominio example.test è un placeholder e non va usato come zona pubblica reale. Sostituiscilo con un dominio che controlli davvero. Il range 192.0.2.0/24 è documentativo e serve solo in esempi: anche qui, in produzione, usa gli IP reali.

Una volta inseriti i record, controlla che PowerDNS veda la zona.

dig @127.0.0.1 example.test SOA +short
dig @127.0.0.1 www.example.test A +short

Esito atteso: il SOA restituisce il serial corretto e il record A risponde con l’indirizzo configurato. Se ottieni SERVFAIL, il problema è spesso uno tra schema mancante, backend errato o record incoerenti.

Verifiche di rete, firewall e ascolto

PowerDNS deve essere raggiungibile su TCP e UDP 53. È un dettaglio che salta fuori solo quando i client esterni fanno query e quelle UDP non arrivano. In ambienti con firewall locale, security group o appliance intermedie, devi aprire entrambe le modalità.

Controlla l’ascolto del processo e la connettività locale prima di esporre il servizio verso l’esterno.

sudo ss -lntup | grep ':53'
dig @127.0.0.1 example.test NS

Se usi UFW, apri la porta in modo esplicito. Se sei dietro un firewall di rete, replica la regola anche lì. Il blast radius è limitato al servizio DNS, ma un errore qui rende il server invisibile ai resolver esterni.

sudo ufw allow 53/udp
sudo ufw allow 53/tcp
sudo ufw status verbose

Se il server deve anche pubblicare AXFR verso secondari, ricordati che il trasferimento zona usa TCP. Quindi aprire solo UDP è un errore parziale: la zona può sembrare funzionare al test base ma fallire sul replication path.

API REST e gestione operativa

PowerDNS ha una API utile per automatizzare zone e record, specie quando vuoi integrare provisioning o gestione multi-tenant. In installazioni semplici puoi anche farne a meno, ma se l’ambiente cresce l’API evita aggiornamenti manuali ripetitivi sul database.

Se abiliti l’API, definisci una chiave dedicata e limita l’esposizione alla sola rete amministrativa. Non pubblicarla su interfacce aperte senza controllo: stai dando potere di modifica sul DNS.

api=yes
api-key=SOSTITUISCI_CON_CHIAVE_FORTE
webserver=yes
webserver-address=127.0.0.1
webserver-port=8081

Con questa impostazione, l’interfaccia API resta locale. È una scelta prudente: puoi poi esporla tramite reverse proxy o tunnel amministrativo, ma la superficie d’attacco resta piccola finché non hai una ragione concreta per allargarla.

Test rapido dell’endpoint di controllo:

curl -s http://127.0.0.1:8081/api/v1/servers/localhost | head

Se preferisci la gestione da pannello o da automazione esterna, la logica resta identica: autenticazione robusta, accesso ristretto e log delle modifiche. Il DNS è uno di quei servizi dove un record sbagliato si trasforma in disservizio immediato, quindi ogni canale di modifica va trattato come infrastruttura critica.

Hardening minimo e manutenzione

Un’installazione fatta bene non si ferma a “il servizio parte”. Devi pensare a aggiornamenti, backup del database, monitoraggio e riduzione della superficie esposta. Il minimo sindacale è avere backup del DB, controllo dello stato del servizio e una verifica periodica delle risposte DNS da un host esterno.

Per il backup, salva sia il database sia la configurazione. Senza i due pezzi insieme, il ripristino è incompleto.

mysqldump powerdns > /var/backups/powerdns-$(date +%F).sql
sudo cp /etc/powerdns/pdns.conf /var/backups/pdns.conf-$(date +%F)

Per il monitoraggio, controlla almeno questi indicatori: processo attivo, porte 53 aperte, query rate, error rate e latenza di risposta. Se hai una piattaforma di osservabilità, aggiungi alert su crash del servizio, picchi di SERVFAIL e aumento improvviso di timeout. La metrica obiettivo più sensata qui è il tasso di errore: se sale, gli utenti lo sentono subito.

Un test esterno utile è una query ripetuta da un host fuori dal segmento del server, così distingui un problema locale da uno di rete.

dig @IP_DEL_TUO_DNS www.example.tld A +stats

Se il tempo di risposta cresce senza motivo, guarda prima il backend SQL, poi la saturazione CPU e infine eventuali filtri di rete. Non partire subito a “ottimizzare” il software: spesso il collo di bottiglia è altrove.

Problemi tipici dopo l’installazione

Il primo problema classico è il conflitto sulla porta 53. Il secondo è un backend SQL non raggiungibile. Il terzo è una zona inserita male, con SOA o NS incoerenti. A questi si aggiungono permessi sbagliati sui file, firewall incompleto e serial non aggiornato dopo una modifica.

Se il servizio non parte, parti dal log:

journalctl -u pdns -b --no-pager | tail -n 100

Se il servizio parte ma le query falliscono, guarda il comportamento con dig e confronta l’output locale con quello remoto. Se locale funziona e remoto no, il problema è quasi sempre rete o firewall. Se entrambi falliscono, il problema è configurazione o database.

Assunzione operativa: il server è destinato a produzione o pre-produzione, quindi ogni modifica va fatta con backup della configurazione e possibilità di rollback rapido del demone e dello schema SQL.

In sintesi pratica, l’installazione di PowerDNS su Ubuntu 22.04 non è complessa, ma richiede disciplina: separa il ruolo authoritative da quello del backend, controlla la porta 53, prepara il database con privilegi minimi e valida subito la prima zona con query reali. Se fai bene questi quattro passaggi, il resto diventa manutenzione ordinaria invece che emergenza.