Approfondimento: Zone DNS

Approfondimento: Zone DNS

Perché il DNS è il punto più critico della piattaforma

Fra tutti i servizi di DS001 le zone DNS hanno il rapporto peggiore fra facilità di modifica e gravità delle conseguenze. Cambiare un record richiede tre clic e non produce nemmeno una notifica di conferma; sbagliarlo rende irraggiungibile un sito o interrompe la ricezione della posta per l'intera organizzazione, con un ritardo che dipende dalle cache dei resolver e non da chi ha fatto la modifica. Non esiste annullamento: la sola rete di sicurezza è un'esportazione CSV fatta prima.

Questo approfondimento è organizzato in due livelli. La prima parte spiega il modello: come si arriva dalla richiesta di un utente al record della zona, e perché la piattaforma da sola non basta a far risolvere un nome. La seconda parte è operativa: strategie di TTL, playbook per le situazioni ricorrenti e un albero diagnostico.

Parte 1 — Il modello

La catena di delega

Quando un browser cerca www.esempio.it, la risoluzione non parte dalla zona in DS001. Parte dai root server, che indicano chi è autoritativo per .it; il registry di .it indica quali nameserver sono autoritativi per esempio.it; solo allora la richiesta arriva ai nameserver Deepstone, che leggono la zona e restituiscono il record.

Ogni anello della catena è indipendente dagli altri. Ne derivano tre situazioni che in piattaforma appaiono identiche ma hanno cause diverse:

La piattaforma è responsabile solo del terzo caso, e questo spiega il riquadro rosso di stato sulla pagina di dettaglio della zona: non è un errore di configurazione della zona, è la segnalazione che la delega a monte non punta ancora a Deepstone. Finché resta, i record possono essere perfetti e il nome non risolverà comunque. La propagazione richiede tipicamente dalle ventiquattro alle quarantotto ore, e Verifica ora forza un nuovo controllo.

Un punto che genera confusione ricorrente: collegare la zona al dominio con Collega zona DNS non modifica i nameserver. Sono due operazioni distinte, e la seconda va eseguita dal dettaglio del dominio se è interno, oppure presso il registrar se è esterno.

I due tipi di record NS

Nella zona esistono record NS, e presso il registry esistono i nameserver del dominio. Portano la stessa informazione ma vivono in luoghi diversi, e la piattaforma offre due comandi distinti per agire su ciascuno:

• Resetta i record NS, nel menu Azioni della zona, riscrive i record NS dentro la zona con i nameserver Deepstone predefiniti. È irreversibile.
• Modifica nameserver, nel dettaglio del dominio, aggiorna la delega presso il registry. Richiede almeno due nameserver e sostituisce l'elenco esistente, quindi vanno indicati tutti, non solo quelli nuovi.

Il primo non fa risolvere una zona che non risolve. Il secondo sì.

La zona come centro operativo

La pagina di dettaglio della zona non gestisce solo record. È l'unico punto da cui nascono due funzioni che hanno una sezione propria per la consultazione ma non per la creazione:

• I pool di endpoint si creano dal riquadro Gestione Pool della zona. Un record di tipo POOL può poi puntare al pool anziché a un indirizzo fisso.
• I monitor si attivano dalla tabella record della zona, su un singolo record. La sezione Monitor consente di consultarli, modificarli, sospenderli ed eliminarli, ma non di crearne.

La conseguenza pratica: un monitor eliminato per errore va ricostruito dalla zona, non da dove è stato eliminato. E l'eliminazione di una zona porta con sé pool e monitor associati.

Le operazioni sull'intera zona

Parte 2 — Operatività

Strategia di TTL

Il TTL non è a testo libero: si sceglie fra quindici valori predefiniti, da 20 secondi a un giorno, con 300 secondi come predefinito. La scelta è un compromesso fra velocità di propagazione delle modifiche future e volume di traffico di risoluzione.

Il TTL dei record POOL merita attenzione particolare: un TTL alto vanifica in parte il failover, perché i resolver continuano a servire l'endpoint precedente per tutta la durata residua della cache, anche dopo che il pool ha già escluso quell'endpoint.

Va inoltre segnalata una particolarità dell'elenco: il valore 700 secondi è etichettato «12 min», mentre corrisponde a 11 minuti e 40 secondi. Se serve un TTL esatto di 12 minuti, l'elenco non lo offre.

Playbook 1 — Go-live di una nuova zona

1. Consultare i template disponibili in Zone Templates con l'icona a forma di occhio e scegliere quello adeguato: la zona nasce con i record già corretti.
2. Creare la zona da Zones → Aggiungi zona applicando il template. Se il pulsante è disabilitato, il piano non prevede ulteriori zone e l'aumento va richiesto.
3. Completare i record specifici del progetto, verificando le regole di validazione: nessuno spazio nel campo Nome, nessun CNAME su @, nome in minuscolo per gli SRV, nessuna virgoletta ai bordi dei TXT.
4. Abbassare a 5 minuti il TTL dei record che punteranno a servizi non ancora definitivi.
5. Esportare un CSV: è la fotografia della configurazione approvata.
6. Aggiornare i nameserver del dominio con i quattro indicati nel riquadro rosso di stato.
7. Attendere e usare Verifica ora a intervalli di qualche ora, non di minuti.
8. Una volta che il riquadro rosso è scomparso, attivare i monitor sui record che rappresentano servizi critici.
9. Riportare i TTL ai valori di regime.

Playbook 2 — Migrazione di un servizio a un nuovo indirizzo

L'ordine delle operazioni è ciò che determina la durata del disservizio.

1. Tre o quattro giorni prima: abbassare il TTL dei record coinvolti a 5 minuti, con la modifica in linea. Il cambio è efficace solo dopo che il TTL precedente è scaduto nelle cache: se era di un'ora, l'abbassamento diventa effettivo entro un'ora.
2. Esportare un CSV di backup.
3. Predisporre e collaudare il servizio sul nuovo indirizzo, raggiungibile per IP.
4. Al momento del cambio: aggiornare il valore del record. Con TTL a 5 minuti la sostituzione completa avviene entro pochi minuti.
5. Verificare, e tenere attivo il vecchio servizio per almeno un'ora: i resolver che non rispettano il TTL esistono.
6. Aggiornare i monitor se puntavano all'indirizzo precedente.
7. Riportare il TTL al valore di regime.

Se il record da migrare è un CNAME che va spostato sul dominio radice, va ricreato come A o AAAA: sulla radice il CNAME non è ammesso, e il tipo di un record non è modificabile.

Playbook 3 — Intervento su una zona in produzione

Da usare per qualunque modifica non banale su una zona che serve traffico reale.

1. Esportare il CSV prima di aprire qualsiasi form.
2. Isolare il record con la ricerca testuale o i filtri Tipo e Stato monitor, per non agire sulla riga sbagliata: in una zona con molti record il rischio è concreto.
3. Applicare la modifica.
4. Rileggere il valore in tabella. La modifica di un record non produce notifica, quindi l'assenza di messaggio non dice nulla sull'esito.
5. Se esiste un monitor sul record, verificarne lo stato dopo qualche minuto.

Albero diagnostico — «il dominio non risolve»

1. Il riquadro rosso di stato è presente sulla pagina della zona? Se sì, il problema è la delega: i nameserver del dominio non puntano a Deepstone. Aggiornarli e attendere la propagazione. Fine.
2. Lo stato della zona nell'elenco è «Non raggiungibile» senza riquadro rosso? Verificare che la zona non sia stata sospesa dal menu Azioni.
3. Il record esiste in tabella? Se non c'è, verificare se è stato eliminato: l'eliminazione è immediata e irreversibile. Ricostruirlo dal CSV di backup.
4. Il record esiste ma il valore è errato? Correggerlo e ricordare che l'assenza di notifica non indica un fallimento: rileggere il valore.
5. Il valore è corretto ma alcuni utenti vedono ancora il vecchio? È propagazione: il tempo di attesa residuo è al massimo pari al TTL precedente.
6. Il nome è un sottodominio con CNAME? Verificare che il target esista e risolva a sua volta: un CNAME verso un nome inesistente non produce errore in piattaforma.
7. Il record è di tipo POOL? Il problema può essere negli endpoint, non nel DNS: controllare la colonna Monitor nell'elenco dei pool e la configurazione del controllo.
8. Tutto corretto in piattaforma? Esportare il CSV, aprire un ticket in DOMINI & DNS citando il nome della zona e il nome del record, e allegare l'export.

La posta: un caso a sé

Due tipi di record hanno conseguenze che si manifestano in silenzio. Eliminare o sbagliare i record MX interrompe la ricezione della posta senza che nessuno riceva un errore visibile: i mittenti ottengono un rifiuto, i destinatari semplicemente non ricevono nulla. Sbagliare i TXT di SPF o DKIM non blocca la posta ma la fa classificare come spam, con un effetto che emerge giorni dopo e viene raramente ricondotto a una modifica DNS.

Su questi record vale la regola più stretta: commento descrittivo obbligatorio all'inserimento — non è modificabile dopo — e CSV di backup prima di ogni intervento.

Limitazioni note che riguardano le zone

Tutte sono già state segnalate al team di sviluppo.

Vedi anche

• Zone DNS · Record DNS · Pool DNS e bilanciamento · Zone Templates · Monitoraggio · Domini