DNS privato per reti VPS: come funziona e quando serve

Avvii un terzo server, vuoi che le macchine si raggiungano per nome invece che per IP e cerchi "private DNS VPS". Tornano tre risultati e non concordano. Uno è un'impostazione Android che cifra le richieste del telefono. Uno è una guida cPanel per personalizzare i name server di un dominio. Uno è un documento AWS sulle zone ospitate private. Il 20 luglio 2026, Cloudflare ha reso Internal DNS disponibile a tutti e lo ha descritto come "a volte chiamato anche DNS privato", quindi ora la sovrapposizione arriva anche dai fornitori di infrastruttura.

Il termine è sovraccarico. Questo articolo separa i diversi significati, poi si concentra su quello di rete VPS: una zona DNS interna per la comunicazione tra server. Alla fine saprai individuare il sistema che ti serve, decidere se il tuo parco macchine richiede un DNS privato ed evitare i più comuni errori di progettazione.

TL;DR

• "DNS privato" indica almeno tre sistemi senza alcun legame tra loro: una zona DNS interna per una rete di server, la funzione di cifratura DNS-over-TLS di Android e i name server personalizzati di cPanel. Questo articolo usa il termine nel primo senso: una zona DNS interna per una rete VPS.
• Una zona DNS privata di un VPS è uno spazio dei nomi interno limitato alla rete che associa hostname come db.internal.example.com a IP privati. I suoi record non vengono pubblicati nel DNS pubblico.
• Per una manciata di server con IP stabili, /etc/hosts è davvero sufficiente. Un server DNS interno inizia a ripagarsi quando il parco macchine cresce, gli IP cambiano spesso o i servizi richiedono una risoluzione dei nomi affidabile.
• Per la maggior parte delle reti VPS in produzione, usa un sottodominio di tua proprietà, come internal.example.com. Usa lo spazio dei nomi .internal solo per un ambiente isolato in cui siano accettabili le collisioni di nomi tra reti, la gestione dei certificati tramite una CA privata e una gestione particolare di DNSSEC. Evita .local, che mDNS riserva.

Cosa questo articolo non tratta

Questo articolo resta circoscritto al significato di rete VPS del DNS privato. Non tratta usi estranei lato consumer e dei marchi di hosting:

• Configurare l'impostazione DNS privato o DNS-over-TLS di Android su un telefono.
• Configurare name server privati cPanel per un marchio di hosting.
• Una guida completa all'installazione di BIND 9, Unbound, dnsmasq o CoreDNS. Qui l'implementazione resta a livello di riferimento, non di configurazione passo passo.
• I resolver cifrati per consumatori come 1.1.1.1 o NextDNS, oltre alla loro distinzione dal significato di rete.

Che cosa significa davvero "DNS privato"?

"DNS privato" non è un sistema soltanto. Il termine ne indica almeno tre senza alcun legame: una zona DNS limitata alla rete che risolve gli hostname interni dentro una rete VPS o VPC, la funzione di cifratura DNS-over-TLS di Android e i name server autoritativi personalizzati di cPanel. Questo articolo tratta il primo, la zona interna che i tuoi server interrogano per trovarsi a vicenda. Esiste anche un quarto uso più vago: i resolver pubblici cifrati promossi come "privati".

I quattro significati condividono un nome e nient'altro:

L'annuncio della disponibilità generale di Internal DNS di Cloudflare è un esempio gestito e attuale del primo significato, oltre che uno dei motivi per cui la sovrapposizione è diventata visibile: un fornitore di infrastruttura usa ora "DNS privato" come sinonimo di DNS interno nei testi di lancio. Il sistema descritto, un Gateway Resolver insieme a Internal Authoritative DNS per i clienti Enterprise, appartiene alla stessa categoria di quello che costruisci da solo su un parco di VPS, solo in versione gestita.

In sintesi della sezione: i principali sistemi chiamati "DNS privato" condividono un'etichetta, non una funzione. Individua il significato prima di seguire una guida alla configurazione.

Come funziona il DNS privato su una rete VPS?

Una zona DNS privata di un VPS è uno spazio dei nomi limitato alla rete, servito da un resolver che i tuoi server sono configurati per usare. Associa hostname interni come db.internal.example.com a IP privati in un intervallo che controlli tu. I record non vengono pubblicati nel DNS pubblico, anche se le richieste possono passare per un tunnel privato o un control plane DNS gestito prima di arrivare al resolver. Questa separazione è il cuore della distinzione tra DNS privato e DNS pubblico: il protocollo è lo stesso, ma cambiano la visibilità della zona e il suo ambito di accesso.

Il lavoro lo fanno tre parti. Un server autoritativo o una sorgente di zona custodisce la zona interna e i suoi record. Un resolver risponde alle richieste inviate dai tuoi server. E i record A e AAAA della zona associano gli hostname interni a indirizzi privati, così app.internal.example.com punta al livello applicativo e db.internal.example.com punta al database. Altri tipi di record possono fornire alias o informazioni di servizio. Quando la zona e il percorso del resolver sono configurati correttamente, il resolver risponde localmente alla richiesta interna invece di inoltrarla verso la radice del DNS pubblico.

Le piattaforme cloud legano questo alla rete anziché alla macchina, il che è un utile modello di riferimento. Le zone ospitate private di AWS Route 53 funzionano solo quando la VPC ha sia enableDnsHostnames sia enableDnsSupport impostati su true, e il resolver risponde dalla zona privata per ogni VPC che vi associ. Le zone private di Google Cloud sono limitate alle reti VPC autorizzate e, nell' ordine di risoluzione standard di una VPC vengono consultate prima del DNS pubblico, a meno che una policy sui server in uscita non cambi il percorso. Leggili come illustrazioni dello schema, non come tutorial di piattaforma: un server DNS interno autogestito è la stessa idea, eseguita sul tuo VPS.

Tenere la zona fuori dal DNS pubblico è solo metà del lavoro. Vincola il servizio DNS a un'interfaccia privata o limita la porta 53 su UDP e TCP alla tua rete privata o alla VPN. Non esporre il servizio ricorsivo alla rete pubblica; un resolver aperto può essere sfruttato in attacchi di amplificazione DNS.

Le zone private e quelle pubbliche usano lo stesso modello di record DNS e di caching. I record portano un TTL e i resolver con cache riutilizzano di norma una risposta finché quel TTL non scade, anche se impostazioni specifiche del resolver possono cambiare il tempo di cache effettivo. Quel comportamento è trattato nella nostra guida su come puntare un dominio a un VPS, comprese le basi della propagazione DNS e del TTL, quindi qui non viene rispiegato.

Quando la tua rete VPS ha davvero bisogno di un DNS privato?

Per due o tre server statici, /etc/hosts è davvero sufficiente. Un server DNS interno inizia a ripagarsi quando il parco macchine cresce, gli IP cambiano con regolarità o le applicazioni richiedono un service discovery affidabile. Il vero fattore scatenante è la complessità operativa, non un numero fisso di server.

/etc/hosts è una mappa statica da hostname a IP che esiste già su ogni macchina Linux. Non richiede né un daemon né un file di zona, ma copie obsolete o incoerenti sono modalità di guasto reali. Aggiungi al file l'IP privato di ogni server, tieni le copie sincronizzate e le macchine potranno trovarsi per nome. Per un parco piccolo e stabile è la risposta giusta, e ricorrere invece a BIND 9 aggiunge solo un daemon da mantenere senza alcun vantaggio.

Smette di reggere in tre situazioni. Quando aggiungi e rimuovi server di frequente, tenere un file statico coerente su ogni host diventa fatica manuale. Quando gli IP cambiano, per autoscaling, ricostruzioni o riassegnazioni del provider, il file invecchia in silenzio. E quando container o runtime isolati non ereditano le voci dell'host, la corrispondenza smette di essere universale. Ognuna di queste è il vero fattore scatenante. Il solo numero di server è un'approssimazione grossolana, non il segnale reale.

In sintesi della sezione: il fattore scatenante è il ricambio operativo, non il numero di server. Un parco congelato di dieci macchine può tranquillamente vivere con /etc/hosts; un parco di tre macchine ricostruito ogni notte probabilmente no.

Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.

Vedi piani Linux

Quale server DNS conviene usare: BIND 9, Unbound, dnsmasq o CoreDNS?

Scegli in base alla forma del tuo parco macchine. dnsmasq si addice a reti piccole che vogliono un DNS leggero e, dove serve, il DHCP dallo stesso daemon. Unbound è un resolver ricorsivo snello e validante, capace anche di rispondere per una modesta zona locale. BIND 9 offre ampie capacità autoritative e ricorsive con la superficie di configurazione più estesa. CoreDNS si adatta a parchi con container e Kubernetes, dove il DNS fa parte del service discovery.

La logica di scelta è breve. Se ti serve un piccolo resolver basato su un file in stile hosts, o distribuisci già lease DHCP, dnsmasq toglie una parte in movimento. Se ti serve soprattutto un resolver validante che inoltri verso l'esterno e risponda per una modesta zona interna, Unbound offre proprio quell'insieme più ristretto senza un dispiegamento completo di BIND 9. Se ti serve pieno controllo autoritativo, delega e il più ampio corpus di documentazione su cui appoggiarti alle 3 di notte, BIND 9 resta la scelta prudente nonostante la superficie di configurazione più estesa. Se il DNS fa già parte di uno stack di service discovery con container o Kubernetes, CoreDNS lo incontra dov'è. La regola pratica è far girare la cosa più piccola che copra la forma del tuo parco macchine.

In un parco di produzione, non rendere una singola istanza DNS l'unico percorso verso ogni nome interno. Esegui almeno due istanze DNS in grado di rispondere per la zona, collocale su domini di guasto separati dove è possibile e configura i client per raggiungerle entrambe. Altrimenti un solo guasto DNS può far sembrare morti servizi perfettamente sani.

Come chiamare il dominio interno: .internal, .local o un sottodominio?

Per la maggior parte delle reti VPS in produzione, usa un sottodominio di tua proprietà, come internal.example.com. Usa lo spazio dei nomi .internal solo per un ambiente isolato in cui siano accettabili le collisioni di nomi tra reti, la gestione dei certificati tramite una CA privata e una gestione particolare di DNSSEC. Evita .local, che mDNS riserva.

Il problema di .local è concreto. RFC 6762 riserva ai nomi che terminano in .local un trattamento speciale per Multicast DNS, quindi una zona unicast su BIND 9 o Unbound che usa lo stesso suffisso può entrare in conflitto con il comportamento mDNS su dispositivi Apple e altri sistemi con mDNS. Usa uno spazio dei nomi diverso invece di affidarti a rimedi specifici per singoli client.

Consiglio pratico: se hai ereditato una zona interna in .local, trattala come debito tecnico. Alcuni client inviano le richieste .local a mDNS anziché al tuo server DNS unicast, il che può produrre guasti che dipendono dal client o sembrano intermittenti.

Il Consiglio di ICANN ha riservato in modo permanente .internal dalla delega nella radice del DNS pubblico nel luglio 2024, dopo una precedente raccomandazione del SSAC. I nomi sotto di esso, per progetto, non si risolveranno attraverso il DNS globale. Questo comporta dei compromessi: i nomi .internal non sono globalmente univoci, non ci si aspetta che le autorità di certificazione pubbliche emettano certificati per essi, e i resolver che validano DNSSEC affidandosi all'ancora di fiducia globale non riusciranno a risolverli. Se ti serve HTTPS su .internal, metti in conto di gestire una CA privata.

Qui vanno tenute distinte due cose. La riserva di ICANN è definitiva. In modo separato, un Internet-Draft attivo, draft-davies-internal-tld-06, pubblicato il 6 maggio 2026 per documentare lo spazio dei nomi e confrontarlo con l'indirizzamento privato della RFC 1918. Resta un Internet-Draft in lavorazione e non una RFC pubblicata, quindi descrivi .internal come un TLD a uso privato riservato da ICANN, non come uno standard IETF.

Per la maggior parte dei parchi VPS, un sottodominio di un dominio che controlli è la scelta predefinita più sicura. ISC raccomanda una gerarchia di sottodomini, per esempio un sottodominio interno del tuo dominio, invece di mantenere versioni interne e pubbliche separate e incomplete della stessa zona padre. Questa preferenza non è una questione di stile: previene il guasto descritto nella sezione successiva.

In sintesi della sezione: la scelta dello spazio dei nomi dura a lungo. Un sottodominio che controlli è il valore predefinito per la maggior parte degli ambienti di produzione, perché preserva l'unicità globale e funziona con la PKI pubblica. Usa .internal quando uno spazio dei nomi privato e isolato è più adatto e accetti i suoi compromessi su DNSSEC, certificati e collisioni.

DNS split-horizon e gli errori che lo rompono

Il DNS split-horizon restituisce per lo stesso hostname una risposta diversa a seconda di chi chiede: l'IP privato dall'interno, quello pubblico dall'esterno. Si rompe più spesso per la trappola NXDOMAIN nello stesso dominio, per resolver alternativi che aggirano la vista prevista e per percorsi DNS nei container che non raggiungono l'upstream atteso. Farlo bene dipende da tre cose insieme, non da una.

La trappola NXDOMAIN è proprio il guasto su cui ISC mette in guardia direttamente. Se i tuoi server interni sono autoritativi per il dominio padre, ma la loro versione della zona non contiene un record pubblico come l'host www, un client interno che interroga quel nome riceve NXDOMAIN anche se la zona pubblica lo contiene. La zona interna è autoritativa e per il dominio padre non ripiega sul DNS pubblico. È esattamente per questo che l'approccio a gerarchia di sottodomini della sezione sui nomi è il design preferito da ISC.

Consiglio pratico: prima di puntare i tuoi server a una configurazione split-horizon sullo stesso dominio, prova dall'interno della rete a risolvere un nome pubblico noto di quel dominio. Una risposta NXDOMAIN per un nome che dall'esterno si risolve senza problemi è la firma di questa trappola.

Altre tre insidie sfuggono facilmente. Un resolver alternativo configurato su un host o un container può aggirare la separazione; a seconda dell'implementazione del resolver, può essere interrogato dopo un timeout o in parallelo, quindi le risposte possono variare. I container sul bridge predefinito di Docker ricevono all'avvio una copia della configurazione DNS dell'host, mentre quelli su reti personalizzate interrogano il resolver integrato di Docker all'indirizzo 127.0.0.11. Quel resolver inoltra le richieste esterne ai server DNS configurati per l'host o il container, quindi il comportamento dello split-DNS dipende dalla configurazione di Docker e dell'host, non solo dal file del resolver interno al container. Se un servizio interno sta dietro un reverse proxy come Gestore Proxy Nginx, la validazione del certificato può fallire quando il certificato non copre l'hostname richiesto o quando la CA che lo ha emesso non è considerata attendibile dal client. Usare semplicemente un certificato diverso all'interno non è di per sé un errore. Sono lacune di configurazione, non difetti degli strumenti.

I client remoti possono incappare nello stesso guasto quando una VPN self-hosted non spinge né instrada le richieste DNS verso il resolver interno previsto.

C'è anche una dimensione di sicurezza. Se hostname interni e IP privati finiscono nei record DNS pubblici, hai esposto parte del tuo schema interno di nomi e indirizzi a chiunque interroghi la zona. Lo split-horizon esiste anche per tenere quella mappa all'interno, e una zona pubblica configurata male lo vanifica in silenzio.

In sintesi della sezione: i guasti dello split-horizon sono trappole di configurazione, non difetti degli strumenti. La correttezza dipende dalla disciplina nei nomi, dal sapere quale resolver interroga davvero ogni client e dal delimitare bene la zona, non da una singola impostazione.

LEGGI

Come Puntare un Dominio a VPS: Guida Veloce

Conclusione: scegliere il giusto design di DNS privato

Ora sai individuare quale sistema chiamato "DNS privato" intendi davvero. Per le reti VPS è la zona DNS interna, non l'impostazione DNS-over-TLS di Android né i name server autoritativi personalizzati. Se il tuo parco macchine è piccolo e stabile, /etc/hosts è una scelta difendibile. Se non lo è, usa un sottodominio di tua proprietà come spazio dei nomi predefinito, scegli il server DNS più piccolo adatto al parco macchine e tieni espliciti accesso, ridondanza e ambito della zona interna rispetto a quella pubblica. Usa .internal solo quando uno spazio dei nomi isolato è più adatto e accetti i suoi compromessi su certificati, DNSSEC e collisioni.

Domande frequenti