DNSSEC record DS errato può causare SERVFAIL per i resolver che convalidano la catena. Il registrar pubblica il DS nel dominio padre, mentre il provider DNS mantiene le chiavi nella zona: i due lati devono corrispondere.
Questa guida approfondisce DNSSEC record DS errato con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.
Che cosa significa
Se i nameserver vengono cambiati senza aggiornare o rimuovere prima il DS, il nuovo provider può firmare con chiavi differenti o non firmare affatto. I resolver considerano allora la risposta non autentica.
Disabilitare DNSSEC soltanto nel pannello DNS lasciando il DS al registrar è una delle cause più comuni di dominio apparentemente offline.
Come riconoscere il problema
- Il dominio funziona con resolver non validanti ma riceve SERVFAIL con altri.
- DNSViz o dig mostrano bogus.
- Il problema nasce dopo cambio nameserver.
- Il DS al registrar non corrisponde alla KSK.
- Rimuovendo temporaneamente la validazione locale la risposta appare.
Cause più frequenti
1. DS vecchio
Il registrar conserva la chiave del provider precedente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
2. DNSSEC disabilitato solo nella zona
Il parent continua a dichiarare la firma. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
3. Algoritmo o digest errato
I valori copiati non corrispondono. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
4. Rotazione KSK incompleta
La nuova chiave non è stata pubblicata correttamente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
5. Zona non firmata o firma scaduta
RRSIG non è valida. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
6. Migrazione non coordinata
Nameserver e DS cambiano nell’ordine sbagliato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
Diagnosi passo per passo
- Interroga DS dal parent. Usa dig sul dominio. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Recupera DNSKEY autoritative. Confronta key tag, algoritmo e digest. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Usa un validatore DNSSEC. Individua il punto di rottura. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla nameserver attuali. Assicurati che la zona corretta sia autoritativa. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Verifica lo stato nel provider DNS. Firma attiva e chiavi disponibili. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla il registrar. DS presenti e valori esatti. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Considera TTL. Le vecchie deleghe possono restare in cache. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
Metodo sicuro di diagnosi
Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.
Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.
Verifica prolungata dopo la correzione
Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.
Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.
Procedura di risoluzione
- Rimuovi il DS vecchio in modo coordinato. Quando il nuovo provider non è ancora firmato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Pubblica il DS corretto. Copia esattamente i valori della KSK attiva. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Attiva DNSSEC nel provider. Prima di dichiararlo nel parent. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Completa la rotazione. Mantieni sovrapposizione secondo la procedura del provider. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi firme e orario. Il provider deve generare RRSIG valide. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Attendi TTL e verifica. Controlla resolver pubblici validanti. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Pianifica le migrazioni. Definisci l’ordine di rimozione e riattivazione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Come raccogliere prove utili
Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.
Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.
Controlli finali
- Nessun SERVFAIL.
- Catena secure.
- DS e DNSKEY coerenti.
- Nameserver corretti.
- Resolver pubblici concordi.
Prevenzione
- Migrazioni pianificate.
- Valori DS documentati.
- Monitoraggio DNSSEC.
- Rotazioni gestite.
- TTL considerati.
Errori da evitare
- Non disabilitare solo un lato.
- Non copiare DS da vecchie zone.
- Non cambiare nameserver e DS insieme senza piano.
- Non ignorare SERVFAIL.
- Non usare resolver non validanti come unica prova.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- dominio
- nameserver
- record DS
- output DNSKEY
- data della migrazione
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Domande frequenti su DNSSEC record DS errato
Che differenza c’è tra DS e DNSKEY?
Il DS è nel parent e riferisce una chiave pubblicata nella zona figlia.
Perché vedo SERVFAIL?
Il resolver non riesce a convalidare la catena DNSSEC.
Posso rimuovere il DS?
Sì, in una procedura coordinata quando devi disattivare o migrare DNSSEC.
Il cambio nameserver richiede attenzione a DNSSEC?
Sì, il vecchio DS può rendere invalida la nuova zona.
Quanto dura la correzione?
Dipende dai TTL di delega, DS e record DNS.