Una migrazione dei nameserver può risultare completata correttamente in tutti i pannelli di controllo e lasciare comunque un sito irraggiungibile. Il dominio è attivo, i nuovi server DNS autorevoli restituiscono l’indirizzo previsto e il server web non è stato modificato. Eppure i resolver DNS che effettuano la validazione DNSSEC rispondono SERVFAIL. Spesso manca un passaggio: la delega DNSSEC continua a considerare attendibile la chiave di firma del precedente gestore DNS.
Nell’incidente esaminato, le normali interrogazioni DNS fallivano, mentre le stesse richieste andavano a buon fine quando si aggirava la validazione DNSSEC. La zona padre pubblicava ancora un vecchio record DS, ma inizialmente la nuova zona autorevole non era firmata. La pubblicazione di una chiave corrispondente e la firma della nuova zona hanno ripristinato le risposte validate sui resolver esaminati. La lezione non è che si debba disattivare DNSSEC: cambiare nameserver e trasferire la catena di fiducia DNSSEC sono due operazioni distinte.
Perché record A corretti possono comunque causare SERVFAIL
Il DNS risponde a due domande diverse. Un record A indica quale indirizzo IPv4 corrisponde a un nome. DNSSEC permette a un resolver che esegue la validazione di stabilire se la risposta sia attendibile. Avere dati di indirizzamento corretti non significa automaticamente disporre di una catena di fiducia DNSSEC valida.
Per un dominio firmato, la catena parte da una zona padre attendibile, attraversa un record DS (Delegation Signer) e arriva a una DNSKEY nella zona figlia. Quest’ultima pubblica firme (record RRSIG) sui propri dati DNS. Il record DS contiene un digest che identifica una DNSKEY autorizzata: non è un record A, né una copia della chiave privata, né un’impostazione di un normale editor dei file di zona.
Dopo un cambio dei nameserver autorevoli, la zona padre può continuare a pubblicare un record DS associato al precedente firmatario. Se la nuova zona non dispone della DNSKEY corrispondente e delle relative firme, un resolver che valida DNSSEC non riesce a completare la catena di fiducia. Normalmente considera la risposta non valida e restituisce SERVFAIL anziché un indirizzo non verificato.
Non è la stessa cosa di un’interruzione del servizio HTTP: la richiesta potrebbe non raggiungere mai il server web. È anche diverso da un certificato TLS scaduto: DNSSEC valida i dati DNS, mentre HTTPS protegge la connessione successiva tra browser e server.
Il test che distingue un problema DNSSEC da un record mancante
Il test più indicativo consiste nell’interrogare due volte lo stesso nome usando lo stesso resolver. Per prima cosa esegui una query ordinaria e controlla lo stato, non soltanto la risposta:
dig example.com A +noall +comments +answerPoi ripeti la query impostando il bit CD (Checking Disabled, controllo DNSSEC disabilitato):
dig example.com A +cdflag +noall +comments +answerNel caso osservato, la query ordinaria restituiva SERVFAIL, mentre quella con CD restituiva il record A previsto. Questa differenza indicava con forza un problema di validazione DNSSEC, piuttosto che un record DNS mancante o un’applicazione che non rispondeva. L’opzione +cdflag chiede a un resolver ricorsivo che la supporta di non eseguire la normale validazione DNSSEC per quella richiesta. È uno strumento diagnostico, non una correzione nel browser né un modo per disattivare DNSSEC per i visitatori.
Non trarre troppe conclusioni da un risultato vuoto con +short. Sia l’assenza di una risposta sia un errore SERVFAIL possono apparire come output vuoto con quel formato. Durante la diagnosi mantieni +comments, così da poter vedere status: SERVFAIL e status: NOERROR.
Il solo confronto con CD non identifica quale componente di DNSSEC abbia fallito: suggerisce dove proseguire l’indagine. Un resolver potrebbe anche avere un problema transitorio a monte; se necessario, ripeti il test e controlla la delega nella zona padre.
Controllare il record DS della zona padre, non soltanto l’editor DNS
Cerca i record DS del dominio:
dig example.com DS +noall +comments +answerPer una vista più completa del percorso di delega, interroga direttamente la gerarchia DNS:
dig +trace example.com DSIl nameserver autorevole della zona padre dipende dal dominio di primo livello. Ciò che conta è l’insieme dei record DS (RRset) pubblicato dalla zona padre, non soltanto il riepilogo mostrato nel pannello del provider DNS. Un trasferimento del dominio a un altro registrar può lasciare invariati i nameserver, e un cambio di nameserver può avvenire senza cambiare registrar. In entrambi i casi, i DS della zona padre devono rimanere coerenti con la zona autorevole effettivamente attiva.
Un record DS contiene quattro campi significativi: identificativo della chiave (key tag), algoritmo, tipo di digest e digest. Il key tag è un riferimento comodo per la diagnosi, ma da solo non dimostra che una DNSKEY corrisponda. Anche il digest e le informazioni sull’algoritmo devono corrispondere a una chiave realmente pubblicata dalla zona autorevole.
Nel caso in esame, la situazione decisiva era semplice: la zona padre continuava a pubblicare le vecchie informazioni di fiducia DNSSEC, mentre la zona autorevole sostitutiva segnalava che la firma non era attiva. I record A erano presenti e potevano essere recuperati aggirando la validazione. Modificare la configurazione dell’applicazione o ritoccare ripetutamente lo stesso record A non avrebbe risolto questa incoerenza.
Due modi per ripristinare una delega DNSSEC non valida
Esistono due strategie di ripristino legittime. Risolvono la stessa incoerenza nella catena di fiducia, ma hanno conseguenze operative differenti. Scegline una consapevolmente, evitando di alternarle a caso.
Opzione 1: rimuovere il vecchio DS e mantenere temporaneamente la zona non firmata
Chiedi al registrar attuale di eliminare il record DS obsoleto dalla zona padre, oppure utilizza l’interfaccia di gestione DNSSEC che mette a disposizione. Quando la zona padre non indica più che la delega è sicura, i resolver che validano DNSSEC possono trattare una zona figlia non firmata come non protetta, anziché come non valida. Il DNS continua a funzionare, ma per quel dominio l’autenticazione DNSSEC è temporaneamente assente.
Questa è spesso l’opzione di emergenza più semplice, purché esista un modo affidabile per modificare l’insieme dei record DS nella zona padre. Mantieni stabile la configurazione di firma esistente finché i vecchi DS non saranno scaduti nelle cache dei resolver ricorsivi. La rimozione di un DS dal pannello di controllo non è, da sola, una prova sufficiente: verifica dall’esterno il record pubblicato dalla zona padre e tieni conto del suo TTL. HTTPS rimane indipendente dalla configurazione DNSSEC. Anche la RFC 8078 descrive il passaggio temporaneo a una zona non firmata.
Opzione 2: firmare la nuova zona e pubblicare un DS corrispondente
L’alternativa consiste nell’attivare DNSSEC presso il nuovo operatore DNS autorevole, generare il materiale delle chiavi DNSKEY, firmare la zona e pubblicare il record DS corrispondente nella zona padre. Un resolver che valida DNSSEC può così costruire una catena di fiducia fino alla nuova DNSKEY e verificare il record A.
È questa la procedura di ripristino effettivamente osservata. L’interfaccia di gestione DNS indicava di aver generato le chiavi, firmato la zona e pubblicato un nuovo DS. Una successiva interrogazione della zona padre mostrava il nuovo DS accanto al precedente. Le query ricorsive con validazione hanno ricominciato a restituire il record A previsto; un test successivo ha inoltre restituito NOERROR con il flag ad, che indica dati autenticati da quel resolver.
L’ordine delle operazioni è importante: un DS pubblicato serve soltanto se la DNSKEY corrispondente e firme valide sono già disponibili presso il servizio DNS autorevole. La dicitura «pubblicato» in un pannello di controllo non sostituisce una verifica esterna. Record DS, DNSKEY, RRSIG e NS presenti nelle cache possono far sì che i diversi resolver tornino a funzionare in momenti differenti.
Perché la presenza di due record DS non impediva necessariamente il funzionamento del sito
Un risultato sorprendente è stato che la zona padre conteneva temporaneamente sia un DS obsoleto sia uno nuovo e valido, eppure la validazione DNSSEC riusciva. Non c’è contraddizione. Un insieme di record DS può contenere più voci, come accade spesso durante le transizioni tra chiavi. Un validatore non richiede che ogni DS identifichi una chiave ancora utilizzabile; gli basta un percorso di autenticazione valido attraverso un DS applicabile, una DNSKEY e firme valide. La RFC 6840 chiarisce che i validatori dovrebbero accettare un solo percorso valido.
Questo non significa che sia opportuno conservare per sempre record DS obsoleti. Un vecchio DS aumenta l’ambiguità operativa e dovrebbe essere rimosso una volta verificata la nuova catena. Ma questa pulizia è un’attività di manutenzione, non un motivo per eseguire un’altra rischiosa reimpostazione di DNSSEC quando le interrogazioni validate funzionano già.
Qui c’è una trappola particolarmente pericolosa nei pannelli di controllo: un’azione chiamata «emergency unpublish DS» può significare rimuovere tutti i record DS, compreso quello nuovo e funzionante. Analogamente, disattivare la firma della zona mentre un DS è ancora pubblicato può riprodurre immediatamente il disservizio. Nessuna delle due azioni equivale a eliminare uno specifico DS obsoleto. Se l’interfaccia non consente di selezionare un singolo record, richiedi una modifica selettiva supportata dal registrar anziché un azzeramento generale.
Come cambiare i nameserver autorevoli in sicurezza
La sequenza più sicura dipende dalla possibilità che il vecchio e il nuovo operatore DNS coordinino le chiavi. Per una migrazione tradizionale che prevede un intervallo temporaneo senza firma, quest’ordine evita l’incoerenza riscontrata nell’incidente:
- Prepara prima la zona di destinazione. Copia i record A, AAAA, CNAME, MX, TXT e gli altri record pertinenti. Interroga direttamente i nuovi nameserver autorevoli per testarli prima di modificare la delega.
- Controlla DNSSEC nella zona padre. Verifica la presenza di record DS e identifica chi può aggiornarli. Fallo anche se non hai mai attivato DNSSEC manualmente: alcuni servizi DNS firmano le zone in modo automatico.
- Rimuovi il vecchio DS mentre la vecchia zona firmata è ancora operativa. Conferma la modifica presso la zona padre autorevole, poi attendi il tempo necessario perché scadano i record DS già memorizzati nelle cache. L’attesa dipende dai TTL osservati, non da un numero fisso di minuti valido in ogni situazione.
- Cambia la delega dei nameserver. Mantieni disponibile il precedente servizio autorevole finché le deleghe NS nelle cache potrebbero ancora indirizzarvi le richieste. Considera i TTL dei record NS nella zona padre e verifica quali server vengono effettivamente usati dai diversi resolver.
- Decidi se riattivare DNSSEC. Se il nuovo servizio deve rimanere non firmato, non pubblicare un DS. Se deve essere firmato, verifica che la nuova DNSKEY e le firme siano distribuite correttamente prima di pubblicare il DS corrispondente. Coordina questa operazione tenendo conto delle cache che puntano ancora ai vecchi NS, per evitare un nuovo problema di validazione.
- Verifica in modo indipendente. Controlla i DS della zona padre, la DNSKEY autorevole, la normale risoluzione ricorsiva e l’esito dell’autenticazione sui resolver che effettuano la validazione.
Se è indispensabile mantenere la protezione DNSSEC senza interruzioni, è preferibile una rotazione delle chiavi coordinata esplicitamente o una transizione con più firmatari, anziché un intervallo senza firma. Entrambi gli operatori DNS devono supportare la necessaria gestione delle chiavi e delle firme: copiare semplicemente il digest del vecchio DS presso il nuovo provider non equivale a effettuare una rotazione delle chiavi.
Breve lista di controllo dopo la migrazione
Dopo ogni modifica relativa a DNSSEC, controlla sia i record DNS sia la prova che i resolver li accettino:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerPer controllare una risposta autenticata, usa un resolver ricorsivo che esegua la validazione. Nella sua risposta, NOERROR insieme al record A previsto indica che la risoluzione è riuscita; la presenza del flag ad segnala inoltre che quel resolver ha autenticato la risposta secondo la propria politica DNSSEC. L’assenza del flag ad non prova, da sola, un errore: capacità, politiche e flag delle query cambiano da un resolver all’altro. Se durante un’interruzione le query DNSKEY falliscono tramite un resolver che valida DNSSEC, interroga anche direttamente il servizio DNS autorevole attivo nell’ambito della diagnosi.
Non fermarti dopo una singola risposta positiva da parte di un resolver. Cache diverse possono conservare temporaneamente deleghe e chiavi differenti. Aggiorna anche le eventuali richieste di assistenza operativa ancora aperte: una precedente istruzione di eliminare tutti i record DS diventa pericolosa dopo la pubblicazione di un nuovo DS funzionante. La comunicazione successiva deve chiedere esplicitamente di preservare la chiave attiva e, se necessario, rimuovere soltanto il record obsoleto.
Il guasto non dipendeva da un indirizzo errato del server web. Era dovuto al cambiamento dei server da cui venivano fornite le risposte DNS senza prima allineare le informazioni di fiducia che indicavano ai resolver quali risposte considerare valide. Prima di ogni passaggio a nuovi nameserver, quindi, la domanda pratica è: quali record DS pubblica la zona padre, e la DNSKEY e le firme della destinazione sono in grado di soddisfarli?