Il DNS (Domain Name System) è il sistema distribuito che permette di associare nomi leggibili, come www.esempio.it, alle informazioni necessarie per raggiungere servizi su Internet. Nel caso di un sito web, una delle operazioni più comuni consiste nel trovare l’indirizzo IP associato a un nome, ma lo stesso sistema gestisce anche posta elettronica, deleghe dei nameserver, verifiche di dominio e molti altri tipi di dati.
La definizione della “rubrica telefonica di Internet” è utile per capire il concetto, ma racconta solo una parte del meccanismo. Non esiste infatti un unico elenco globale nome → IP: l’infrastruttura è gerarchica, distribuita e basata su resolver, server autorevoli, zone e record differenti.
Capire questa distinzione è importante soprattutto quando devi configurare un dominio o diagnosticare un problema. “Cambiare i DNS” può voler dire modificare il resolver utilizzato dal computer, cambiare un record della zona oppure spostare la delega verso altri nameserver. Sono tre operazioni molto diverse, anche se nel linguaggio comune vengono spesso chiamate nello stesso modo.
Cos’è il DNS e a cosa serve
DNS significa Domain Name System, cioè sistema dei nomi di dominio. Le specifiche fondamentali sono descritte nelle RFC 1034 e RFC 1035, che definiscono il modello gerarchico, il funzionamento di resolver e nameserver e il formato dei principali resource record.
Il problema che risolve è semplice: per una persona è molto più pratico ricordare un nome come esempio.it che un indirizzo numerico.
Quando vuoi raggiungere un servizio, però, il nome da solo non basta. Il client deve recuperare le informazioni necessarie per contattare la destinazione corretta. È questo il compito della risoluzione dei nomi.
Nome di dominio e indirizzo IP
Un nome di dominio e un indirizzo IP non sono la stessa cosa.
Il dominio è un nome inserito nello spazio gerarchico del sistema. L’indirizzo IP, invece, viene utilizzato a livello di rete per identificare e raggiungere una destinazione.
Per esempio:
www.esempio.it ↓ record ↓ 192.0.2.10
Questa rappresentazione è volutamente semplificata. Lo stesso nome può essere associato a più indirizzi IP e lo stesso indirizzo può essere utilizzato da più servizi o domini.
Il sistema, inoltre, non gestisce soltanto associazioni con indirizzi. Attraverso differenti record può indicare, per esempio, quali server ricevono la posta di un dominio, quali nameserver ne gestiscono la zona o quali informazioni devono essere utilizzate per verificare un servizio.
Un dominio non corrisponde necessariamente a un solo IP
Uno degli equivoci più comuni è pensare che la relazione sia sempre:
un dominio = un indirizzo IP
Non è così.
Uno stesso hostname può avere più record A e quindi più indirizzi IPv4. Lo stesso principio vale per IPv6 tramite record AAAA. Configurazioni di questo tipo possono essere utilizzate, per esempio, per distribuire o rendere ridondante un servizio.
Allo stesso tempo, un singolo indirizzo IP può servire numerosi siti web.
È quindi più corretto pensare a questa infrastruttura come a un database distribuito di informazioni associate ai nomi, non come a una semplice tabella che assegna un unico numero a ogni dominio.
Come funziona il DNS: la risoluzione passo per passo
Quando inserisci un indirizzo nel browser, la risoluzione può sembrare immediata perché gran parte del lavoro avviene automaticamente e molte risposte sono già disponibili in cache.
Quando invece la risposta richiesta non è disponibile, entrano in gioco diversi componenti della gerarchia.
Un percorso semplificato è questo:
Dispositivo
↓
Resolver ricorsivo
↓
Root nameserver
↓
Nameserver del TLD
↓
Nameserver autorevole
↓
Record richiesto
↓
Resolver
↓
Dispositivo
Non ogni richiesta attraversa necessariamente l’intera catena. La cache esiste proprio per evitare interrogazioni inutili.
Prima del resolver: cache locale e file hosts
Prima di arrivare a un resolver esterno, il sistema operativo e le applicazioni possono utilizzare informazioni già disponibili localmente.
Uno degli elementi che può influire sulla risoluzione è il file hosts, che permette di associare manualmente un nome a un indirizzo senza interrogare il normale sistema di risoluzione. Se stai facendo test, migrazioni o troubleshooting, sapere dove si trova e come modificare il file hosts può essere utile proprio perché una sua voce può cambiare il risultato ottenuto dal computer.
Se non esiste una risposta locale utilizzabile, il client si rivolge normalmente al resolver configurato.
Il resolver ricorsivo
Il resolver ricorsivo è il componente al quale il dispositivo chiede di trovare una risposta.
Può essere fornito dal provider Internet, dall’organizzazione a cui appartiene la rete oppure da un servizio pubblico.
La prima cosa che conviene fare al resolver è verificare la propria cache. Se possiede ancora una risposta valida per il nome e il tipo di record richiesti, può restituirla senza interrogare nuovamente la gerarchia autorevole.
Se la risposta non è disponibile, deve cercarla.
Il root nameserver
La radice si trova al vertice dello spazio dei nomi.
Un root nameserver normalmente non risponde dicendo direttamente “questo sito si trova a questo IP”. Fornisce invece al resolver le informazioni necessarie per continuare la ricerca verso i nameserver responsabili del Top-Level Domain, come .it, .com o .org.
È quindi un punto di partenza della catena di delega, non un gigantesco database contenente tutti i record di Internet.
Il nameserver del TLD
Il livello successivo riguarda il TLD, cioè la parte più a destra del nome.
Prendendo:
www.esempio.it
il TLD è .it.
Il resolver può chiedere ai server responsabili di quel TLD dove trovare le informazioni autorevoli per esempio.it.
La risposta contiene normalmente una delega verso i nameserver responsabili del dominio.
Il nameserver autorevole
Il nameserver autorevole fornisce i dati della zona per la quale è autorevole.
Se il resolver sta cercando, per esempio, il record A di www.esempio.it, è a questo livello che può ottenere il resource record richiesto, se presente.
La risposta viene poi restituita al client e può essere memorizzata temporaneamente nella cache.
La distinzione fondamentale è che nameserver autorevole e resolver non svolgono lo stesso lavoro: il primo pubblica i dati di una zona; il secondo cerca le risposte per conto del client.
Query ricorsive, iterative e cache
Dal punto di vista del dispositivo, la richiesta al resolver è normalmente ricorsiva: il client chiede una risposta e lascia al resolver il compito di ottenerla.
Durante la ricerca nella gerarchia, invece, il resolver può procedere tramite interrogazioni che gli indicano progressivamente dove continuare.
Questo sistema sarebbe molto inefficiente se ogni visita richiedesse sempre un passaggio completo root → TLD → autorevole. La cache riduce drasticamente il numero di query necessarie.
Ed è proprio qui che entra in gioco il TTL.
Server DNS, resolver e nameserver: qual è la differenza
“Server DNS” è un’espressione molto generica. Può indicare componenti che svolgono ruoli differenti, e questa ambiguità è alla base di molta confusione.
Le due categorie da distinguere subito sono:
- resolver ricorsivo: cerca le risposte per conto del dispositivo;
- nameserver autorevole: pubblica le informazioni di una determinata zona.
Quando nelle impostazioni di rete di Windows, macOS, Android, iOS o del router trovi campi come “DNS preferito” e “DNS alternativo”, stai generalmente scegliendo resolver ricorsivi, non i nameserver autorevoli del tuo dominio.
Quando invece entri nel pannello del registrar e sostituisci ns1.provider.example e ns2.provider.example, stai modificando la delega del dominio.
Sono due operazioni completamente diverse.
Il server configurato sul dispositivo
Il dispositivo deve sapere a chi inviare le richieste di risoluzione.
Questo resolver può essere configurato automaticamente dalla rete oppure scelto manualmente. È quello a cui si riferiscono normalmente espressioni come:
- DNS primario;
- DNS secondario;
- DNS preferito;
- DNS alternativo.
In questo contesto “primario” e “secondario” non significano necessariamente server autorevole primario e secondario di una zona.
I nameserver autorevoli del dominio
I nameserver associati a un dominio indicano invece dove è servita autorevolmente la relativa zona.
Se vuoi sapere quali sono quelli effettivamente delegati, puoi verificare i nameserver del dominio e confrontare il risultato con la configurazione prevista.
Questa verifica è particolarmente utile dopo una migrazione, un cambio di provider o quando i record presenti nel pannello che stai modificando sembrano non avere alcun effetto.
Potresti infatti stare lavorando su una zona che non è quella effettivamente delegata.
Cosa significa davvero “DNS primario e secondario”
L’espressione può quindi avere almeno due significati.
Nel pannello di rete del computer può indicare due resolver da utilizzare. Nell’amministrazione di una zona, invece, termini come server primario e secondario possono riferirsi alla distribuzione autorevole dei dati.
Il contesto viene prima dell’etichetta.
Se qualcuno ti dice semplicemente “cambia il DNS”, la prima domanda da fare dovrebbe essere:
quale DNS? Il resolver del dispositivo, un record della zona o i nameserver del dominio?
Record DNS: quali sono e cosa fanno
Una zona contiene resource record, ognuno con un tipo e una funzione.
Il registro mantenuto da IANA elenca i tipi e i parametri DNS assegnati. Nella gestione quotidiana di siti web e domini, alcuni record ricorrono molto più spesso di altri.
| Record | Funzione principale | Esempio di utilizzo |
|---|---|---|
| A | Associa un nome a un indirizzo IPv4 | sito web su IPv4 |
| AAAA | Associa un nome a un indirizzo IPv6 | sito web su IPv6 |
| CNAME | Crea un alias verso un altro nome canonico | www come alias di un hostname |
| MX | Indica i mail exchanger del dominio | ricezione della posta |
| TXT | Pubblica informazioni testuali utilizzabili da servizi | SPF, verifiche, policy |
| NS | Identifica nameserver autorevoli | delega e gestione della zona |
| SOA | Contiene informazioni amministrative della zona | parametri della zona autorevole |
| CAA | Indica quali Certificate Authority possono emettere certificati per il dominio | controllo emissione certificati |
| SRV | Indica host, porta e parametri di uno specifico servizio | service discovery |
| PTR | Associa un indirizzo a un nome nel reverse DNS | reverse lookup |
La tabella aiuta a scegliere il record corretto, ma non significa che ogni dominio debba avere tutti questi tipi.
Record A e AAAA
Un record A associa un nome a un indirizzo IPv4.
Esempio:
www.esempio.it. A 192.0.2.10
Un record AAAA svolge una funzione analoga per IPv6:
www.esempio.it. AAAA 2001:db8::10
Uno stesso nome può avere più record A o AAAA. La specifica contempla esplicitamente host con più indirizzi: non esiste una regola generale secondo cui un dominio debba avere un solo record A.
Quando cambi hosting, uno degli interventi possibili consiste proprio nell’aggiornare i record che indicano la nuova destinazione. Questo, però, non implica necessariamente cambiare anche i nameserver.
Se invece la destinazione deve essere aggiornata perché l’indirizzo IP cambia nel tempo, modificare manualmente il record a ogni variazione diventa poco pratico. Il DNS dinamico (DDNS) automatizza questo processo: un router o un client può rilevare il nuovo indirizzo e aggiornare il record A o AAAA mantenendo stabile l’hostname utilizzato per raggiungere il servizio.
CNAME: un alias, non un redirect
Il record CNAME, abbreviazione di Canonical Name, fa di un nome un alias di un altro nome.
Per esempio:
www.esempio.it. CNAME sito.provider.example.
Quando un resolver incontra il CNAME, deve continuare la risoluzione utilizzando il nome canonico indicato.
La distinzione fondamentale è questa:
CNAME non equivale a un redirect HTTP.
Con un redirect 301 o 302, il server web comunica al browser di richiedere un altro URL e il cambiamento può essere visibile anche nella barra degli indirizzi.
Con un CNAME siamo invece ancora nel livello di risoluzione dei nomi: stiamo dicendo che un nome è alias di un altro. Non stiamo ordinando al browser di cambiare URL.
È una differenza particolarmente importante quando si configurano CDN, piattaforme SaaS e sottodomini.
MX e TXT: posta elettronica, autenticazione e verifiche
I record MX indicano i server che devono ricevere la posta destinata a un dominio.
Possono essere presenti più MX con differenti valori di preferenza: in generale, un numero più basso indica una priorità maggiore.
I record TXT sono più flessibili. Vengono spesso utilizzati per pubblicare informazioni richieste da altri sistemi, per esempio verifiche di proprietà del dominio e dati relativi all’autenticazione della posta.
SPF viene normalmente pubblicato tramite TXT. DKIM usa invece il DNS per rendere disponibile la chiave pubblica associata alla firma: a seconda dell’implementazione del provider puoi incontrare direttamente un record TXT oppure una configurazione basata su CNAME. DMARC utilizza a sua volta un TXT sotto uno specifico nome.
Questo spiega perché modificare “un TXT” senza sapere a quale servizio appartenga può avere conseguenze molto diverse.
Se devi verificare quali record sono effettivamente pubblicati per un dominio, MxToolbox permette di interrogare DNS, MX, SPF, DKIM e DMARC attraverso lookup dedicati. Il risultato va però interpretato nel contesto del record che stai controllando.
NS, SOA, CAA, SRV e PTR
I record NS identificano i nameserver autorevoli relativi a una zona o delegazione.
Il record SOA (Start of Authority) contiene informazioni amministrative e parametri importanti della zona.
CAA viene utilizzato per indicare quali autorità di certificazione sono autorizzate a emettere certificati per un dominio.
SRV permette invece di descrivere la posizione di determinati servizi includendo informazioni come destinazione e porta.
Il PTR viene utilizzato nel percorso inverso: invece di cercare l’indirizzo associato a un nome, permette di risalire a un nome partendo da un indirizzo. Se ti serve questo caso specifico, nella guida dedicata trovi come funziona il record PTR e il reverse DNS lookup.
Zona DNS, delega e nameserver: dove vengono gestiti i record
Per gestire correttamente un dominio bisogna separare tre ruoli che possono appartenere alla stessa azienda, ma non necessariamente:
- registrar;
- provider autorevole;
- hosting o servizio di destinazione.
Il registrar è l’operatore attraverso cui viene amministrata la registrazione del dominio.
Il provider autorevole ospita e serve la zona.
L’hosting ospita invece il sito, l’applicazione o altre risorse.
Un unico fornitore può offrire tutti e tre i servizi, ma l’architettura non richiede che coincidano.
Registrar, hosting e provider DNS non sono la stessa cosa
Immagina di registrare esempio.it presso il provider A, utilizzare i nameserver del provider B e ospitare il sito sul provider C.
La situazione potrebbe essere:
Registrar
↓ delega
Provider autorevole
↓ record A/AAAA/CNAME
Hosting
Se sposti il sito dal provider C al provider D ma mantieni il provider B, probabilmente dovrai modificare uno o più record, non la delega.
Se invece vuoi trasferire la gestione autorevole della zona dal provider B a un altro servizio, dovrai intervenire sui nameserver delegati.
È la differenza che evita molti errori durante una migrazione.
Cambiare nameserver e modificare un record non sono la stessa operazione
Prendiamo alcuni casi pratici.
| Cosa vuoi ottenere | Intervento probabile |
|---|---|
| Spostare il sito verso un nuovo server | modificare A/AAAA o il record richiesto dalla piattaforma |
Collegare www a un hostname esterno | configurare un CNAME, se compatibile con il caso |
| Cambiare servizio email | modificare MX e gli eventuali record di autenticazione |
| Verificare un dominio presso un servizio | aggiungere il TXT/CNAME richiesto |
| Spostare l’intera gestione della zona a un altro provider | cambiare la delega/nameserver |
| Usare un resolver diverso sul PC | modificare le impostazioni del dispositivo o della rete |
Prima di modificare qualcosa, identifica quindi il livello sul quale vuoi intervenire.
Cambiare i nameserver quando bastava aggiornare un record può creare lavoro inutile e, se la nuova zona non contiene tutti i dati precedenti, può interrompere sito, email o altri servizi.
Propagazione DNS, cache e TTL: cosa succede davvero dopo una modifica
“Propagazione DNS” è un’espressione molto diffusa, ma può dare un’immagine sbagliata del funzionamento del sistema.
Non esiste un singolo processo centrale che prende la modifica e la copia progressivamente su tutti i resolver e nameserver di Internet.
Quando cambi un record sul nameserver autorevole, il nuovo valore può essere disponibile lì quasi immediatamente. Il problema è che resolver e altre cache possono conservare ancora la risposta precedente fino alla sua scadenza.
È questo uno dei motivi per cui due utenti possono ottenere temporaneamente risultati differenti.
Perché la “propagazione globale” è una semplificazione
Supponiamo che il record fosse:
www.esempio.it → 192.0.2.10
e venga modificato in:
www.esempio.it → 192.0.2.20
Un resolver che non possiede il vecchio valore in cache può recuperare subito la nuova risposta.
Un altro che conserva ancora una risposta valida può continuare a restituire 192.0.2.10 fino alla sua scadenza.
Non è quindi necessario immaginare migliaia di server che devono ricevere uno dopo l’altro una copia del nuovo valore. Stiamo soprattutto osservando cache con tempi di vita differenti e, nel caso dei nameserver, eventuali effetti relativi alla delega.
Come funziona il TTL
TTL significa Time To Live.
La RFC 1035 lo definisce come l’intervallo di tempo, espresso in secondi, durante il quale un resource record può essere mantenuto in cache prima che la sorgente debba essere consultata nuovamente.
Se un record ha:
TTL = 3600
la configurazione autorevole sta consentendo di conservarlo in cache per un’ora.
Non esiste però un unico TTL “standard” valido per tutti i domini e tutti i provider.
Valori più lunghi riducono il numero di interrogazioni all’infrastruttura autorevole e mantengono più a lungo le risposte in cache. Valori più brevi permettono alle modifiche di diventare osservabili più rapidamente una volta scadute le cache precedenti.
C’è un dettaglio operativo da non sottovalutare: abbassare il TTL dopo aver modificato un record non cancella retroattivamente le vecchie cache.
Se stai pianificando una migrazione e vuoi ridurre la durata delle risposte precedenti, il TTL va abbassato con sufficiente anticipo perché i vecchi valori abbiano il tempo di scadere.
Anche le risposte negative possono essere memorizzate
La cache non riguarda soltanto record esistenti.
Il sistema prevede anche il negative caching: un resolver può memorizzare temporaneamente informazioni come l’inesistenza di un nome o l’assenza del record richiesto.
Questo spiega perché, dopo aver creato un hostname che poco prima non esisteva, in alcune situazioni puoi continuare a ricevere temporaneamente una risposta negativa.
Per questo motivo un errore apparentemente persistente non dimostra automaticamente che la configurazione autorevole sia ancora sbagliata.
DNSSEC, DoH e DoT: sicurezza e privacy sono problemi diversi
DNSSEC, DNS over HTTPS e DNS over TLS vengono spesso raggruppati sotto l’etichetta “DNS sicuro”, ma proteggono aspetti differenti.
La distinzione più utile è:
- DNSSEC → autenticità e integrità dei dati;
- DoH/DoT → protezione del trasporto tra client e resolver compatibile.
Confondere le due categorie porta facilmente a sovrastimare ciò che ciascuna tecnologia può fare.
Cosa protegge DNSSEC e cosa non protegge
DNSSEC aggiunge firme crittografiche che permettono a un resolver validante di verificare l’autenticità dei dati firmati e che questi non siano stati modificati lungo la catena di fiducia.
La RFC 4033 è esplicita su questo punto: DNSSEC aggiunge autenticazione dell’origine e integrità dei dati.
Non aggiunge però confidenzialità.
In altre parole, non nasce per nascondere a un osservatore il nome che stai cercando. Serve a permettere la validazione della risposta.
Per funzionare correttamente richiede inoltre una catena di fiducia valida tra la zona e il livello superiore. Una configurazione errata può rendere il dominio non risolvibile per i resolver che effettuano la validazione, quindi non è una funzione da attivare senza verificare delega, record DS e configurazione del provider autorevole.
DNS over HTTPS e DNS over TLS
DoH e DoT affrontano un altro problema: la protezione del traffico fra client e resolver.
DNS over HTTPS è standardizzato nella RFC 8484 e trasporta le query attraverso HTTPS. DNS over TLS è definito nella RFC 7858 e utilizza invece TLS come trasporto dedicato.
Entrambi possono impedire che le query viaggino in chiaro sul tratto protetto.
Non significa però diventare anonimi su Internet e non significa che ogni risposta sia automaticamente autenticata tramite DNSSEC.
Un resolver DoH può cifrare la comunicazione con il client ma resta comunque il soggetto a cui stai affidando le richieste. La scelta del resolver e le sue policy continuano quindi ad avere importanza.
Quando il DNS non funziona: capire dove si trova il problema
Un errore di risoluzione non significa automaticamente che “il DNS è rotto”.
Prima di cambiare configurazioni a caso conviene capire quale livello sta fallendo.
I casi più comuni possono essere ricondotti a tre famiglie:
| Livello | Possibile problema | Primo controllo |
|---|---|---|
| Dispositivo/rete | cache locale, resolver non raggiungibile, hosts errato | prova altro resolver o verifica configurazione locale |
| Infrastruttura autorevole | record errato, record mancante, delega sbagliata, DNSSEC non valido | controlla zona e nameserver effettivi |
| Servizio finale | risoluzione corretta ma web/mail/server non risponde | verifica applicazione, hosting e rete di destinazione |
Questa separazione evita uno degli errori più frequenti: modificare record autorevoli quando il problema è soltanto sul computer, oppure svuotare la cache locale quando la zona pubblica è configurata male.
Un controllo rapido può aiutarti a separare la connettività IP dalla risoluzione dei nomi: se riesci a raggiungere un indirizzo IP esterno ma lo stesso test fallisce usando un nome di dominio, DNS e name resolution diventano candidati concreti. In questi casi può essere utile confrontare il ping verso un indirizzo IP e verso un hostname prima di modificare record o nameserver.
Problema del resolver o della cache locale
Se il dominio funziona su altri dispositivi o altre reti ma non sul tuo computer, il primo sospetto può cadere sulla risoluzione locale.
In questi casi possono essere utili:
- controllo del resolver configurato;
- verifica del file hosts;
- test su un’altra rete;
- svuotamento della cache.
Se devi eliminare risposte memorizzate sul dispositivo, trovi le procedure per eseguire un DNS flush su Windows, macOS e Linux.
Il flush locale, però, non modifica i record pubblici e non obbliga i resolver esterni a eliminare le proprie cache.
Quando il server DNS non risponde
Se il resolver configurato non è raggiungibile o non riesce a completare correttamente le richieste, la navigazione può fallire anche se il sito e la sua zona autorevole sono perfettamente funzionanti.
Prima di modificare il dominio conviene quindi capire se il problema riguarda la rete locale, il router o il servizio ricorsivo. Nella guida dedicata trovi una diagnostica specifica per l’errore server DNS non risponde.
Questo è un troubleshooting diverso dalla gestione dei record della zona.
Problema della zona o della delega
Se invece più resolver indipendenti restituiscono lo stesso risultato errato, bisogna guardare con maggiore attenzione alla configurazione autorevole.
Fra i controlli più utili:
- nameserver effettivamente delegati;
- presenza del record richiesto;
- valore del record;
- TTL;
- eventuale CNAME;
- correttezza dei record MX se il problema riguarda la posta;
- configurazione DNSSEC, se attiva.
Dopo una migrazione è particolarmente importante verificare dove è realmente ospitata la zona. Avere record corretti in un pannello che non corrisponde ai nameserver delegati non produce alcun effetto sul sistema pubblico.
NXDOMAIN non significa “Internet non funziona”
NXDOMAIN indica che, secondo la risposta ricevuta, il nome richiesto non esiste.
Può essere una risposta corretta — perché il nome effettivamente non esiste — oppure il sintomo di una configurazione sbagliata, di un hostname digitato male o di una situazione transitoria influenzata dalla cache negativa.
È quindi più utile interpretare il codice di risposta che applicare immediatamente una soluzione generica.
Il problema diventa molto più semplice da diagnosticare quando smetti di pensare a un unico “server DNS” e inizi a chiederti chi ha prodotto quella risposta, se è autorevole o in cache e quale tipo di record stavi cercando.
Conclusione
Il DNS è molto più di un meccanismo che “trasforma un dominio in un IP”. È un sistema gerarchico e distribuito attraverso il quale nomi, deleghe e differenti tipi di record permettono ai servizi Internet di essere trovati e utilizzati.
La distinzione più utile da portarsi dietro è questa:
resolver, record, nameserver e cache appartengono allo stesso ecosistema, ma risolvono problemi differenti.
Se vuoi cambiare il server utilizzato dal tuo computer per la risoluzione dei nomi, stai intervenendo sul resolver.
Se vuoi spostare il sito o configurare la posta, probabilmente devi modificare uno o più record.
Se vuoi trasferire a un altro provider la gestione autorevole dell’intera zona, devi intervenire sui nameserver e sulla delega.
Se continui a vedere una risposta precedente dopo una modifica, devi invece valutare TTL e cache prima di concludere che la nuova configurazione non abbia funzionato.
Capire a quale di questi livelli appartiene il problema è il modo più rapido per evitare modifiche inutili e diagnosticare il DNS con criterio.