DynDNS, DDNS e DNS dinamico descrivono lo stesso problema di fondo: come continuare a raggiungere una connessione o un dispositivo quando il suo indirizzo IP pubblico può cambiare.
La soluzione consiste nell’associare un hostname, per esempio casa.example.net, all’indirizzo IP corrente e nell’aggiornare automaticamente il record DNS ogni volta che quell’indirizzo cambia. DynDNS permette quindi di continuare a usare lo stesso nome anche quando il provider assegna un nuovo IP.
C’è però una distinzione decisiva che spesso viene saltata: DynDNS può mantenere corretto il nome, ma non rende automaticamente raggiungibile la tua rete. Se sei dietro CGNAT, se un firewall blocca la connessione o se il servizio non è esposto correttamente, l’hostname può risolvere verso l’indirizzo previsto e continuare a non funzionare dall’esterno.
Per configurare bene un DDNS conviene quindi seguire questo ordine: capire come funziona, verificare quale indirizzo riceve realmente la connessione, scegliere il sistema di aggiornamento e solo alla fine decidere come consentire l’accesso remoto.
Che cos’è DynDNS e che differenza c’è tra DDNS e DNS
DynDNS viene spesso utilizzato come sinonimo di DNS dinamico, ma vale la pena separare i termini. Il DNS è l’infrastruttura generale che associa nomi e informazioni di rete; il DDNS aggiunge un meccanismo per modificare automaticamente uno o più record quando cambia l’indirizzo della destinazione.
Se vuoi partire dalle fondamenta — resolver, nameserver, zone e record — trovi il modello completo nella guida su cos’è il DNS e come funziona. Qui ci interessa invece un problema più specifico: mantenere aggiornata l’associazione tra hostname e indirizzo.
DynDNS, DDNS e DNS dinamico: perché indicano quasi lo stesso problema
DDNS significa Dynamic Domain Name System, in italiano DNS dinamico. È il termine tecnico più generale.
DynDNS è invece anche il nome storicamente associato al noto servizio Dynamic DNS oggi appartenente all’ecosistema Oracle Dyn. La sua diffusione è stata tale che molti router, manuali e guide continuano a utilizzare “DynDNS” come etichetta generica per la funzione DDNS.
La differenza è simile a quella che si incontra quando il nome di un prodotto molto noto finisce per essere usato informalmente per descrivere un’intera categoria. Dal punto di vista tecnico, quando nel pannello del router trovi una sezione chiamata DDNS, Dynamic DNS o DynDNS, il problema da risolvere è normalmente lo stesso: comunicare a un provider DNS l’indirizzo corrente della connessione.
Il servizio Dyn, peraltro, non va trattato come una tecnologia scomparsa: la documentazione ufficiale mantiene Dyn Updater e le relative modalità di aggiornamento degli hostname.
Cosa cambia rispetto al DNS tradizionale
Nel DNS normale puoi creare, per esempio, un record:
casa.example.net → 203.0.113.24
Se 203.0.113.24 rimane sempre assegnato alla tua connessione, non serve fare nulla finché la configurazione non cambia.
Con un IP dinamico potresti invece ritrovarti dopo qualche tempo con:
198.51.100.72
Il vecchio record continuerebbe a indicare l’indirizzo precedente. Chi prova a collegarsi a casa.example.net raggiungerebbe quindi la destinazione sbagliata o nessuna destinazione.
Il DNS dinamico introduce l’aggiornamento automatico:
IP precedente
↓
il provider assegna un nuovo IP
↓
router/client DDNS rileva il cambiamento
↓
record DNS aggiornato
↓
hostname → nuovo IP
Il valore del DDNS non consiste quindi nel “rendere statico” l’indirizzo. L’IP continua a essere dinamico; è il nome a seguirne automaticamente i cambiamenti.
DynDNS è anche un servizio? La distinzione tra tecnologia e provider
Sì. È proprio qui che nasce molta confusione.
Puoi parlare di DynDNS riferendoti al servizio storico Dyn, oppure usare informalmente il termine per indicare un sistema DDNS in generale. Altri provider possono offrire lo stesso meccanismo senza avere alcun rapporto con Dyn.
Di conseguenza, quando un router mostra un menu DynDNS non significa necessariamente che tu debba utilizzare il provider Dyn. Alcuni firmware permettono di scegliere tra più servizi, altri supportano soltanto provider predefiniti, altri ancora accettano URL di aggiornamento personalizzati.
La prima verifica da fare non è quindi “qual è il miglior DynDNS?”, ma:
quali protocolli e provider supportano il mio router o dispositivo?
Come funziona il DNS dinamico
Per capire il DDNS bisogna separare due operazioni che avvengono in momenti diversi: aggiornare il record e risolvere il nome.
La prima parte viene gestita dal router, da un client o da un altro dispositivo autorizzato. La seconda è il normale processo DNS utilizzato da chi prova a raggiungere l’hostname.
Dall’indirizzo IP che cambia al nome host che resta uguale
Immagina di aver creato:
mionas.example.net
e di averlo associato inizialmente a:
203.0.113.24
Quando il provider Internet assegna un nuovo indirizzo, il client DDNS rileva il cambiamento e comunica al provider del DNS dinamico qualcosa che, concettualmente, equivale a:
mionas.example.net ora deve puntare a 198.51.100.72
Il provider aggiorna il record autorevole. Da quel momento, i resolver che recuperano il nuovo valore potranno restituire il nuovo indirizzo.
Questo passaggio è ciò che permette di continuare a utilizzare lo stesso hostname senza dover controllare e sostituire manualmente l’indirizzo ogni volta che cambia.
Router, client DDNS e provider: chi aggiorna l’indirizzo
L’aggiornamento può essere eseguito in diversi punti della rete.
Il caso più comodo è il router: è acceso insieme alla connessione, conosce lo stato WAN e può comunicare direttamente con il provider DDNS. Molti modem/router integrano infatti una sezione dedicata.
Quando il router non supporta il provider scelto, puoi utilizzare un client DDNS su un NAS, un server, un Raspberry Pi o un altro dispositivo che rimane normalmente acceso. Alcuni provider mettono a disposizione applicazioni proprie; altri espongono API o protocolli compatibili con strumenti come ddclient.
Conta soprattutto una cosa: deve esistere almeno un componente affidabile che rilevi il cambiamento e aggiorni il record.
Installare più updater indipendenti per lo stesso hostname, senza una ragione precisa, può invece complicare la diagnosi. Se utilizzano metodi diversi per determinare l’indirizzo o configurazioni non coerenti, rischi di avere aggiornamenti concorrenti.
Record A e AAAA: cosa cambia tra IPv4 e IPv6
Con IPv4, l’hostname viene normalmente associato tramite un record A.
Con IPv6 viene utilizzato invece un record AAAA.
Se vuoi approfondire le differenze di indirizzamento, NAT e funzionamento dei due protocolli puoi leggere il confronto tra IPv4 e IPv6.
Per un DDNS moderno la distinzione è importante perché una rete può essere dual stack: lo stesso hostname può avere sia un record A sia un AAAA, e i due indirizzi possono cambiare secondo logiche differenti.
Non dare quindi per scontato che “aggiornare il DDNS” significhi sempre aggiornare soltanto IPv4. Controlla quali record gestisce il provider, quale connettività offre l’ISP e che cosa supporta il client utilizzato.
Con IPv6 c’è inoltre una conseguenza pratica: l’assenza del NAT IPv4 tradizionale non significa che il dispositivo debba essere lasciato esposto. Il firewall continua a essere essenziale, e una raggiungibilità globale dell’indirizzo non equivale a un’autorizzazione ad accedere ai servizi.
TTL e aggiornamento DNS: perché il cambio non è necessariamente istantaneo
Quando il provider DDNS modifica il record autorevole, il nuovo valore può essere disponibile molto rapidamente sul nameserver. Questo non implica però che ogni resolver su Internet smetta immediatamente di utilizzare il valore precedente.
Il motivo è il TTL, Time To Live.
Un resolver può conservare un record nella propria cache fino alla scadenza prevista. Se possiede ancora il vecchio indirizzo, per un certo intervallo può continuare a restituirlo anche se il record autorevole è già stato aggiornato.
È utile distinguere quindi:
tempo di rilevazione dell'IP + tempo di aggiornamento presso il provider + eventuale cache DNS residua
Se un hostname continua temporaneamente a risolvere verso il vecchio valore, non significa automaticamente che l’updater abbia fallito. Prima controlla il record autorevole e il TTL.
Quando serve davvero DynDNS
DynDNS è utile quando devi raggiungere una destinazione identificata da un indirizzo che può cambiare nel tempo. Questo avviene soprattutto in reti domestiche, piccoli uffici e installazioni remote che non dispongono di un IPv4 statico.
In questi scenari DynDNS elimina soprattutto il problema di dover conoscere manualmente il nuovo indirizzo dopo ogni variazione della connessione.
Non è però un requisito universale. Molti servizi moderni utilizzano cloud, relay o connessioni in uscita e non richiedono alcun hostname DDNS gestito dall’utente.
NAS, server domestici, telecamere e domotica
Un NAS è un esempio classico. Se vuoi raggiungerlo dall’esterno tramite un servizio che risiede realmente nella tua rete, conoscere l’indirizzo corrente della connessione diventa necessario.
Lo stesso vale per scenari come:
- server domestico;
- pannello di domotica;
- videosorveglianza;
- server di gioco;
- servizio web self-hosted;
- accesso a un dispositivo industriale remoto.
Il DDNS evita di dover scoprire e sostituire manualmente l’indirizzo ogni volta che cambia.
Questo non significa però che sia corretto esporre direttamente qualsiasi servizio. Un hostname stabile rende più semplice raggiungere la rete, non rende sicuro ciò che trovi dietro quell’hostname.
Accesso remoto e server VPN
Un altro scenario è l’endpoint di una VPN self-hosted.
Se il server VPN si trova a casa o in ufficio e l’IP pubblico cambia, il client remoto ha bisogno di sapere dove collegarsi. Un hostname DDNS può diventare l’endpoint stabile:
vpn.example.net
invece di un indirizzo numerico soggetto a variazioni.
Se vuoi capire prima cosa protegge una VPN e cosa invece non risolve, trovi una spiegazione dedicata nella guida su cos’è e come funziona una VPN.
C’è però una distinzione importante: una VPN tradizionale ospitata nella tua rete necessita comunque di raggiungibilità in ingresso. Le reti overlay e alcuni sistemi basati su tunnel in uscita funzionano invece con un’architettura differente e possono essere adatti anche quando il DDNS da solo non basta.
Quando un IP dinamico non è un problema
Se utilizzi Internet soltanto per iniziare connessioni verso l’esterno — navigazione, streaming, posta, servizi cloud — il cambiamento dell’IP pubblico normalmente non richiede un DDNS.
Il browser non ha bisogno di conoscere preventivamente il tuo indirizzo pubblico per visitare un sito. È la tua connessione a iniziare la comunicazione verso il servizio remoto e l’infrastruttura di rete gestisce il traffico di ritorno.
Lo stesso vale per molte videocamere, applicazioni IoT e servizi consumer che si collegano a una piattaforma cloud del produttore. In questi casi l’app potrebbe trovare il dispositivo attraverso l’infrastruttura del vendor senza che tu debba configurare un hostname pubblico.
Quando il DDNS non serve
Non serve necessariamente un DDNS se:
- hai già un IP statico e puoi utilizzare direttamente un nome associato a quell’indirizzo;
- il servizio viene raggiunto esclusivamente attraverso una piattaforma cloud o un relay;
- utilizzi una rete overlay che gestisce autonomamente discovery e raggiungibilità;
- non devi ricevere connessioni dall’esterno;
- il dispositivo che vuoi raggiungere non dovrebbe essere esposto pubblicamente.
Questo ultimo punto è importante. Non trasformare il DDNS in una ragione per pubblicare un servizio che sarebbe più sicuro lasciare privato.
Prima di configurare DDNS: controlla IP pubblico, NAT e CGNAT
Questo è il controllo che farei prima di creare account, hostname e regole sul router. Per configurare DDNS correttamente, devi prima sapere se la tua connessione può realmente ricevere traffico dall’esterno.
Un DDNS può funzionare perfettamente a livello DNS e risultare comunque inutile per una connessione IPv4 in ingresso se il provider non ti assegna una destinazione pubblicamente raggiungibile.
Per orientarti tra indirizzo pubblico, privato, statico e dinamico puoi partire dalla guida dedicata all’indirizzo IP.
IP pubblico e IP privato: il requisito che cambia tutto
In una normale rete domestica i dispositivi utilizzano indirizzi privati, per esempio:
192.168.1.50
Il router si trova fra la LAN e Internet e gestisce il traffico attraverso NAT.
Quando vuoi ricevere una connessione IPv4 dall’esterno, non basta conoscere l’indirizzo privato del NAS o del PC. Devi prima capire quale indirizzo possiede l’interfaccia WAN del router e se quella destinazione è effettivamente raggiungibile da Internet.
Un controllo utile consiste nel confrontare:
IPv4 WAN mostrato dal router
con:
IPv4 pubblico osservato da un servizio esterno
Se coincidono, hai un’indicazione favorevole — non ancora la prova che firewall e porte siano configurati correttamente, ma almeno non stai osservando un’evidente doppia traduzione a monte.
Se non coincidono, devi capire perché.
Perché DynDNS non aggira il CGNAT
Con Carrier-Grade NAT, la traduzione IPv4 non avviene soltanto sul tuo router: esiste un ulteriore livello NAT nella rete del provider.
Questo significa che il tuo router non controlla direttamente l’IPv4 pubblico condiviso attraverso il quale esce il traffico.
La RFC 6598 riserva l’intervallo:
100.64.0.0/10
per lo Shared Address Space utilizzato nei deployment CGN.
Se il router riceve, per esempio, un indirizzo 100.72.x.x mentre un servizio esterno vede un altro IPv4, hai un forte segnale di CGNAT.
Il problema per il DDNS è semplice:
hostname → IP pubblico del provider
può essere perfettamente corretto, ma la connessione in ingresso deve ancora attraversare il NAT controllato dal provider.
La tua regola di port forwarding sul router domestico non può configurare quel dispositivo a monte.
Per questo DDNS ≠ soluzione al CGNAT.
Le possibilità dipendono dal provider e dal caso concreto: richiedere un IPv4 pubblico, acquistare un servizio con IP statico, usare IPv6 quando effettivamente raggiungibile oppure adottare una VPN overlay o un tunnel che stabilisca la connessione dall’interno verso l’esterno.
Un esempio concreto del problema è Starlink, dove il tipo di indirizzamento disponibile incide direttamente sulla possibilità di ricevere connessioni IPv4 dall’esterno.
Double NAT: quando il problema è dentro la rete
Non tutte le doppie traduzioni dipendono dal provider.
Puoi creare un double NAT anche in casa, per esempio con:
Internet ↓ modem/router ISP ↓ router personale ↓ NAS
Se entrambi i router eseguono NAT, una regola di port forwarding configurata soltanto sul secondo può non bastare. La connessione deve attraversare entrambi i livelli.
In questo scenario hai diverse possibilità: mettere uno dei dispositivi in modalità bridge quando supportato, utilizzare correttamente la cascata, oppure configurare consapevolmente entrambe le traduzioni.
La diagnosi è diversa dal CGNAT perché i due router sono sotto il tuo controllo. Nel CGNAT il livello aggiuntivo appartiene invece al provider.
Cosa cambia con IPv6
IPv6 modifica in modo importante il quadro perché un dispositivo può disporre di un indirizzo globalmente instradabile senza richiedere NAT per conservare lo spazio degli indirizzi.
Questo non significa però “IPv6 = tutto accessibile”.
Devi verificare almeno:
- che il provider assegni IPv6 utilizzabile;
- che il dispositivo abbia un indirizzo appropriato;
- che il DNS dinamico aggiorni il record AAAA;
- che il firewall IPv6 permetta esclusivamente il traffico desiderato;
- che il client remoto disponga a sua volta della connettività necessaria.
Inoltre una linea può trovarsi contemporaneamente dietro CGNAT IPv4 e avere connettività IPv6 pubblica. La domanda corretta non è quindi semplicemente “sono sotto CGNAT?”, ma attraverso quale protocollo voglio rendere raggiungibile il servizio?
Come configurare DDNS su router o dispositivo
La posizione dei menu cambia da un produttore all’altro, ma il flusso logico rimane sorprendentemente simile.
Prima di iniziare prepara tre informazioni: provider DDNS, hostname e dispositivo che effettuerà gli aggiornamenti.
1. Scegli un provider e crea l’hostname
Puoi utilizzare un hostname fornito dal servizio:
mionome.provider.example
oppure, con alcuni provider, un tuo dominio o sottodominio:
casa.example.it
La seconda soluzione ti lascia maggiore controllo sul nome, ma richiede che il provider DDNS possa aggiornare la zona DNS interessata.
Durante la scelta verifica soprattutto:
- supporto IPv4 e/o IPv6;
- compatibilità con il router;
- disponibilità di API o protocollo custom;
- numero di hostname;
- eventuali conferme periodiche;
- possibilità di utilizzare un dominio personale;
- autenticazione e gestione delle credenziali.
Se stai cercando un DDNS gratuito, non fermarti alla parola “free”: controlla cosa accade se dimentichi una conferma, quanto dura l’hostname e quali funzioni sono escluse.
2. Configura l’aggiornamento sul router o sul client DDNS
Nel router cerca voci come:
DDNS Dynamic DNS DynDNS DNS dinamico
Normalmente dovrai inserire provider, hostname e credenziali o token.
I passaggi concreti dipendono dal firmware. La guida TP-Link alla configurazione DDNS mostra un esempio tipico: selezione del provider, inserimento dell’hostname, autenticazione e salvataggio.
Se il router non supporta il servizio desiderato, puoi spostare l’updater su un altro dispositivo sempre acceso.
Su Linux, per esempio, ddclient supporta diversi provider e può essere eseguito periodicamente. Altri servizi forniscono script, API REST o propri Dynamic Update Client.
La regola pratica è: un solo updater affidabile è meglio di diversi updater configurati senza sapere quale stia realmente modificando il record.
3. Verifica che il nome risolva verso l’IP corretto
Non considerare completata la configurazione soltanto perché il pannello mostra “Connected”.
Verifica il risultato DNS.
Da Windows puoi usare:
nslookup mionome.example.net
Su macOS e Linux puoi utilizzare anche:
dig +short mionome.example.net A
e, se utilizzi IPv6:
dig +short mionome.example.net AAAA
Confronta il risultato con l’indirizzo che ti aspetti.
Se hai appena effettuato un aggiornamento e ottieni ancora il valore precedente, controlla anche il TTL e prova resolver differenti prima di modificare nuovamente la configurazione.
4. Configura firewall e accesso al servizio solo se necessario
A questo punto il DNS dovrebbe essere separato dal problema dell’accesso.
Per IPv4 dietro NAT, un servizio direttamente esposto può richiedere port forwarding. Ma non aprire porte “per vedere se funziona” senza sapere che cosa stai pubblicando.
Definisci:
porta esterna → dispositivo interno → porta del servizio
e consenti soltanto ciò che serve.
Evita in particolare di pubblicare direttamente servizi amministrativi o protocolli progettati per la rete locale quando esiste un’alternativa più sicura. Per un NAS, un pannello di gestione o una rete domestica, spesso è preferibile entrare attraverso una VPN o una soluzione di accesso remoto autenticata piuttosto che esporre numerose porte.
Il DDNS deve rendere stabile la destinazione, non ampliare inutilmente la superficie di attacco.
5. Prova la connessione da una rete esterna
Il test finale va eseguito davvero dall’esterno.
Provare l’hostname mentre sei collegato alla stessa rete Wi-Fi può produrre risultati fuorvianti: il router potrebbe supportare NAT loopback, risolvere internamente il nome in modo particolare o comportarsi diversamente dalle connessioni provenienti da Internet.
Disattiva quindi il Wi-Fi dello smartphone e prova tramite rete mobile, oppure utilizza un’altra connessione esterna.
Il percorso che vuoi verificare è:
client remoto ↓ risoluzione DDNS ↓ IP pubblico ↓ firewall/NAT ↓ servizio interno
Se il nome risolve ma il servizio non risponde, smetti di modificare il DNS: il problema si trova probabilmente in uno dei livelli successivi.
DDNS gratuito o a pagamento: come scegliere un servizio
Il mercato DDNS è ancora attivo, ma non esiste una singola soluzione corretta per tutti.
Un DDNS gratuito può essere più che sufficiente per un laboratorio domestico, mentre un servizio che deve restare disponibile senza interventi manuali richiede criteri diversi.
La variabile più importante è spesso la compatibilità: un provider eccellente sulla carta serve a poco se il router non può aggiornarlo e non vuoi mantenere un client separato.
Compatibilità con router e dispositivi
Partirei dal dispositivo che dovrà eseguire l’update.
Se il router offre soltanto tre provider preconfigurati, scegliere uno di questi può essere più semplice. Se supporta provider personalizzati, ddclient o API, le possibilità aumentano.
NAS Synology, QNAP, router evoluti, firewall software e sistemi Linux possono offrire più flessibilità di un modem fornito dall’ISP.
È utile verificare anche la modalità di autenticazione. Credenziali separate o token limitati all’aggiornamento DDNS sono preferibili all’utilizzo indiscriminato della password principale dell’account quando il provider offre questa possibilità.
IPv4, IPv6, dominio personale e modalità di aggiornamento
Il confronto dovrebbe considerare almeno quattro aspetti.
IPv4 e IPv6: non tutti i servizi o client gestiscono entrambi nello stesso modo.
Hostname del provider o dominio personale: un indirizzo sotto un dominio del servizio è semplice; un tuo dominio offre più controllo e portabilità.
Updater: router integrato, applicazione, script, API o protocollo dyndns2.
Policy dell’account: numero di hostname, scadenze, conferme periodiche e limiti del piano gratuito.
Non confondere quindi “supporta DDNS” con “supporta esattamente l’architettura che voglio utilizzare”.
Account gratuiti: conferme periodiche, limiti e condizioni
Il costo zero può richiedere manutenzione.
Per esempio, No-IP richiede attualmente la conferma periodica degli hostname gratuiti. Questo significa che l’updater può continuare a inviare correttamente il tuo IP, ma l’account gratuito richiede comunque l’intervento previsto dalla relativa policy.
dynDNS.it propone a sua volta un’opzione gratuita con condizioni specifiche oltre ai servizi commerciali.
Il punto non è stabilire quale dei due sia “migliore” in assoluto. È capire se una policy accettabile per un laboratorio domestico lo è anche per un servizio che deve rimanere raggiungibile senza interventi manuali.
Servizi DDNS ancora attivi e soluzioni legacy da evitare
Alcune opzioni attualmente rilevanti sono:
| Soluzione | Modello | Quando ha senso |
|---|---|---|
| Oracle Dyn | servizio Dynamic DNS + updater | se utilizzi già l’ecosistema Dyn o hardware configurato per quel provider |
| No-IP | hostname DDNS gratuiti e piani superiori | ampia compatibilità e caso d’uso DDNS classico |
| dynDNS.it | servizio italiano gratuito/commerciale | router e installazioni che richiedono un provider con supporto italiano |
| Infomaniak DynDNS | aggiornamento dinamico della propria zona DNS | se il dominio usa la zona DNS Infomaniak |
| DuckDNS | DDNS gratuito | laboratori domestici e dispositivi supportati dai numerosi metodi di update |
| dynv6 | DDNS gratuito con IPv4/IPv6 | particolarmente interessante per configurazioni IPv6 e domini propri |
| Cloudflare | aggiornamento dinamico via API/ddclient | se gestisci già il tuo dominio su Cloudflare e vuoi automatizzare A/AAAA |
Cloudflare, per esempio, documenta esplicitamente l’aggiornamento dinamico dei record tramite API o ddclient. Non è quindi necessario che una soluzione si presenti come classico “servizio DynDNS” per svolgere la stessa funzione.
Bisogna invece fare attenzione alle guide datate. Il Dynamic DNS di Google Domains è stato ritirato: la documentazione di Google Cloud indica che gli aggiornamenti Dynamic DNS non funzionano più dopo il ritiro della relativa funzione. Se trovi una vecchia procedura che suggerisce Google Domains come provider DDNS, verifica la data prima di seguirla.
Perché non esiste un provider migliore per tutti
Per una rete domestica sperimentale potresti privilegiare gratuità e semplicità.
Per una sede remota potresti considerare più importanti continuità del servizio, gestione delle credenziali, assistenza e assenza di conferme periodiche.
Per un dominio personale potresti preferire un provider che aggiorni direttamente i tuoi record A e AAAA, evitando di dipendere da un hostname di terzo livello appartenente a un altro servizio.
Per un dispositivo industriale, infine, la decisione può essere determinata quasi interamente dai protocolli supportati dal firmware.
Il criterio corretto è quindi:
scenario → compatibilità → affidabilità necessaria → modalità di update → policy → costo
non:
lista dei servizi → scegli il primo gratuito.
DynDNS, IP statico o VPN: quale soluzione serve davvero
DDNS, IP statico e VPN vengono spesso presentati come alternative dirette, ma risolvono problemi differenti.
La domanda migliore è: quale problema sto cercando di eliminare?
| Soluzione | Problema che risolve | Cosa non risolve da sola |
|---|---|---|
| DDNS | mantiene un nome associato a un IP che cambia | CGNAT, firewall, autenticazione, sicurezza del servizio |
| IP statico | elimina il cambiamento dell’indirizzo | firewall, esposizione sicura, controllo accessi |
| VPN self-hosted | crea accesso protetto alla rete remota | richiede comunque un endpoint raggiungibile |
| VPN overlay/tunnel | crea connettività attraverso connessioni stabilite dall’interno | dipendenza dal sistema/tunnel utilizzato e relative policy |
Quando scegliere il DNS dinamico
Sceglierei DDNS quando hai già una connessione raggiungibile e l’unico problema strutturale è che l’indirizzo cambia.
Esempio:
IPv4 pubblico dinamico + router configurabile + server VPN domestico = DDNS molto utile
L’hostname diventa un riferimento stabile per il client VPN.
Lo stesso vale per un servizio self-hosted correttamente protetto o per un dispositivo che deve essere contattato direttamente dall’esterno.
Quando ha più senso un IP statico
Un IP statico elimina completamente il passaggio di aggiornamento.
Può avere senso quando il provider lo offre a condizioni ragionevoli e il servizio deve essere raggiungibile in modo prevedibile, oppure quando devi applicare allowlist basate sull’indirizzo.
Non confondere però stabilità con sicurezza. Un IP immutabile non autentica gli utenti, non cifra le connessioni e non sostituisce firewall o controllo accessi.
Dal punto di vista DNS puoi comunque associare un hostname a quell’indirizzo. Semplicemente non hai più bisogno dell’automazione necessaria a inseguire le variazioni.
Quando una VPN o un tunnel è preferibile
Se il tuo vero obiettivo è “voglio accedere in sicurezza ai dispositivi di casa”, esporre ogni singolo servizio tramite port forwarding può essere una soluzione peggiore del necessario.
Una VPN può creare un punto d’ingresso controllato attraverso il quale raggiungere poi le risorse private.
Attenzione però alla parola VPN: un server WireGuard o OpenVPN ospitato direttamente nella tua rete deve normalmente essere raggiungibile. Se sei dietro CGNAT, il DDNS non risolve questo limite.
Le reti overlay e alcuni tunnel gestiti funzionano diversamente: i nodi stabiliscono connessioni in uscita o utilizzano infrastrutture di coordinamento/relay. In questi scenari possono funzionare anche dove una normale connessione IPv4 in ingresso non è disponibile.
Per questo la scelta non è sempre:
DDNS oppure VPN
Può essere:
DDNS + VPN self-hosted
oppure:
overlay/tunnel al posto dell'esposizione diretta
DDNS e port forwarding: perché risolvono problemi diversi
Il DDNS risponde alla domanda:
Qual è l’indirizzo attuale della mia connessione?
Il port forwarding risponde invece:
A quale dispositivo e servizio interno devo consegnare una connessione arrivata al router?
Sono due livelli differenti.
Puoi avere DDNS perfettamente configurato e nessun port forwarding.
Puoi avere port forwarding funzionante e nessun DDNS se conosci l’IP o ne possiedi uno statico.
Puoi avere entrambi corretti e continuare a non ricevere connessioni perché sei dietro CGNAT.
Pensare a questi componenti come una catena rende il troubleshooting molto più semplice:
DNS ↓ raggiungibilità pubblica ↓ NAT/firewall ↓ servizio ↓ autenticazione/sicurezza
Perché DynDNS non funziona: i controlli da fare
Quando un DDNS “non funziona”, il modo peggiore di procedere è modificare contemporaneamente record, router, firewall e applicazione.
Isola invece il livello che fallisce.
L’hostname punta ancora al vecchio indirizzo IP
Prima domanda:
il nome risolve verso l'IP corretto?
Controlla con nslookup o dig.
Se ottieni il vecchio indirizzo, verifica:
- stato dell’updater;
- credenziali;
- log del client;
- hostname configurato;
- record A/AAAA corretto;
- eventuale TTL/cache.
Se il nameserver autorevole contiene il nuovo valore ma un resolver continua a mostrare quello precedente, aspetta la scadenza della cache prevista invece di inviare aggiornamenti casuali.
L’IP WAN del router non coincide con l’IP pubblico
Se il router mostra un IPv4 e un servizio esterno ne mostra un altro, indaga la presenza di un livello NAT aggiuntivo.
Controlla se l’indirizzo WAN appartiene a:
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 100.64.0.0/10
I primi tre sono spazi privati; l’ultimo è Shared Address Space destinato al CGN.
La presenza di uno di questi intervalli sull’interfaccia WAN, insieme a un diverso indirizzo osservato da Internet, è un forte segnale che il router non possiede direttamente l’IPv4 pubblico utilizzato all’esterno.
Il record DNS è corretto ma il servizio non è raggiungibile
Se:
hostname → IP corretto
il DDNS ha già svolto il proprio lavoro. Se DynDNS aggiorna correttamente l’hostname, continuare a intervenire sul record non risolverà un problema di NAT, firewall o servizio.
Sposta la diagnosi.
Verifica se il servizio è in ascolto, se la destinazione interna è corretta, se la porta prevista risponde e se il percorso attraverso router e firewall è configurato.
È un principio utile anche fuori dal DDNS: risoluzione corretta non significa servizio funzionante.
Firewall o porta bloccata
Controlla il firewall del router e quello del dispositivo.
Una regola di port forwarding può puntare correttamente al server, ma il sistema operativo può comunque rifiutare la connessione.
Verifica inoltre che il servizio utilizzi davvero la porta prevista. Non basarti soltanto sul numero “standard” se l’applicazione è stata configurata diversamente.
Se devi esporre un pannello amministrativo, un NAS o un altro servizio sensibile, chiediti anche se l’accesso diretto sia realmente la soluzione migliore. Far funzionare una porta non significa che sia prudente pubblicarla.
Il router non aggiorna correttamente il provider DDNS
Un firmware vecchio può contenere endpoint non più validi, supportare protocolli legacy o avere problemi di autenticazione con un provider che ha cambiato il proprio sistema.
Se il router dichiara errore:
- verifica le credenziali DDNS;
- verifica che il provider sia ancora supportato;
- controlla la documentazione del modello e del firmware;
- prova, se possibile, un updater ufficiale o un client separato;
- verifica il risultato direttamente sul record DNS.
Questo è particolarmente importante per hardware datato che mostra ancora provider o servizi non più operativi.
Il problema è CGNAT, non il DNS dinamico
Se l’hostname viene aggiornato correttamente ma non possiedi una destinazione IPv4 raggiungibile, continuare a riconfigurare il DDNS non cambia la situazione.
A quel punto devi cambiare architettura, non record.
Le opzioni tipiche sono:
- ottenere un IP pubblico dal provider;
- richiedere un IP statico quando disponibile;
- utilizzare IPv6 con configurazione e firewall appropriati;
- utilizzare una soluzione overlay;
- utilizzare un tunnel basato su connessioni in uscita.
Questa distinzione è probabilmente il controllo più importante dell’intera configurazione.
Conclusione
DynDNS è utile perché separa il nome che utilizzi per raggiungere una rete dall’indirizzo IP che il provider può cambiare nel tempo.
Il meccanismo, però, risolve un problema preciso: mantenere aggiornato il mapping DNS.
Non sostituisce un IP pubblico, non attraversa automaticamente il CGNAT, non configura il firewall e non protegge un servizio esposto.
Per questo l’ordine corretto è:
1. verifica come sei connesso a Internet 2. controlla IP pubblico, NAT, CGNAT e IPv6 3. stabilisci quale servizio deve essere raggiunto 4. scegli DDNS, IP statico o un'architettura VPN/tunnel 5. configura l'updater 6. verifica A/AAAA e hostname 7. abilita soltanto l'accesso strettamente necessario 8. testa realmente da una rete esterna
Se possiedi un IP pubblico dinamico e devi raggiungere direttamente la tua rete, il DDNS rimane una soluzione semplice ed efficace. Se invece il vero ostacolo è il CGNAT o vuoi evitare di pubblicare servizi interni, la soluzione va cercata a un livello diverso.
La domanda utile, quindi, non è soltanto “come configuro DynDNS?”, ma prima ancora “quale problema di raggiungibilità devo davvero risolvere?”.