Vai al contenuto principale

SERVFAIL dopo l'attivazione di DNSSEC: diagnosi e correzione

Di CaptainDNS
Pubblicato il 25 febbraio 2026

Diagnosi SERVFAIL DNSSEC: albero decisionale per identificare e correggere la causa di un SERVFAIL dopo l'attivazione di DNSSEC
TL;DR
  • Un SERVFAIL legato a DNSSEC significa che il resolver ha rifiutato la risposta DNS perché un anello della catena di fiducia non è valido
  • Cinque cause coprono la quasi totalità dei casi: DS mancante, DS errato, RRSIG scaduta, algoritmo incompatibile, cache non aggiornata
  • Tre comandi dig sono sufficienti per isolare il problema (vedi l'albero decisionale a fine articolo)
  • Verifica che la tua catena sia intatta con il nostro DNSSEC Checker (vedi piano d'azione a fine articolo)

Hai appena attivato DNSSEC presso il tuo registrar. I primi test vanno a buon fine. Poi, qualche ora dopo, i tuoi utenti segnalano che il sito è irraggiungibile. La diagnosi: SERVFAIL.

Il SERVFAIL non è un problema del server. È il resolver DNS che rifiuta di restituire la risposta perché la validazione DNSSEC è fallita. Il tuo server funziona, ma il resolver lo blocca.

Questa guida copre i cinque scenari di SERVFAIL legati a DNSSEC, con il comando di diagnosi e la correzione esatta per ciascuno.

SERVFAIL e DNSSEC: il meccanismo

Quando un resolver validante (1.1.1.1, 8.8.8.8, 9.9.9.9) riceve una risposta DNS per un dominio firmato con DNSSEC, verifica l'intera catena di fiducia: trust anchor, DS record, DNSKEY, RRSIG.

Se una verifica fallisce, il resolver contrassegna la risposta come BOGUS e restituisce SERVFAIL al client. Il sito diventa irraggiungibile per tutti gli utenti il cui resolver valida DNSSEC (circa il 38% delle query DNS globali secondo l'APNIC).

La difficoltà: un SERVFAIL non indica perché la validazione è fallita. Bisogna diagnosticare manualmente.

Diagnosi rapida: tre comandi

Prima di analizzare ogni scenario, ecco i tre comandi sufficienti nella maggior parte dei casi.

Comando 1: verificare il DS record

dig DS captaindns.com +short

Se il comando non restituisce nulla, non c'è un DS record al TLD. La catena non è stata stabilita.

Comando 2: confrontare DS e DNSKEY

dig DNSKEY captaindns.com +short

Il DS record contiene un hash della KSK (flag 257). Se l'hash non corrisponde a nessuna DNSKEY pubblicata, il DS è errato.

Comando 3: verificare le firme

dig A captaindns.com +dnssec +cd

Il flag +cd (Checking Disabled) chiede al resolver di restituire la risposta senza validare DNSSEC. Se la risposta arriva con +cd ma non senza, il problema è legato a DNSSEC.

Le cinque cause di SERVFAIL dopo DNSSEC

Causa 1: DS record mancante

Sintomo: dig DS captaindns.com +short non restituisce nulla.

Spiegazione: hai firmato la tua zona (DNSKEY e RRSIG esistono) ma il DS record non è stato pubblicato al TLD. Il resolver non può collegare la tua zona alla zona padre.

Stato DNSSEC: INSECURE (non BOGUS). Il resolver non valida, ma non blocca nemmeno. Questo caso provoca un SERVFAIL solo se il resolver ha un DS nella cache da una configurazione precedente.

Correzione:

  1. Recupera il DS record dal tuo provider DNS (Cloudflare, Route 53, OVHcloud)
  2. Aggiungilo nell'interfaccia del tuo registrar (sezione DNSSEC)
  3. Attendi la propagazione (TTL del DS al TLD, spesso 24-48h)

Verifica:

dig DS captaindns.com +short
# Deve restituire il DS record con Key Tag, Algorithm, Digest Type, Digest

Causa 2: DS record errato

Sintomo: il DS record esiste ma l'hash non corrisponde a nessuna KSK pubblicata.

Spiegazione: il DS al TLD contiene un hash che non corrisponde alla KSK della tua zona. Cause frequenti:

  • Errore di copia-incolla durante l'inserimento manuale
  • Rotazione della KSK senza aggiornamento del DS
  • DS generato con un algoritmo di hash sbagliato (SHA-1 invece di SHA-256)

Stato DNSSEC: BOGUS. Il resolver restituisce SERVFAIL.

Diagnosi:

# Recuperare il DS al TLD
dig DS captaindns.com +short
# Esempio : 12345 13 2 ABC123...

# Recuperare le DNSKEY
dig DNSKEY captaindns.com +short
# Cercare la KSK (flag 257)
# Verificare che il Key Tag (12345) corrisponda

Correzione:

  1. Dal tuo provider DNS, genera il DS record corretto
  2. Nell'interfaccia del registrar, elimina il vecchio DS e aggiungi il nuovo
  3. Se il tuo registrar supporta CDS/CDNSKEY (RFC 7344), l'aggiornamento può essere automatico

Verifica:

dig captaindns.com +dnssec | grep flags
# Il flag "ad" deve essere presente

Causa 3: firme RRSIG scadute

Sintomo: la risposta DNS contiene RRSIG la cui data di scadenza è superata.

Spiegazione: ogni firma RRSIG ha una durata di validità (tipicamente da 7 a 30 giorni). Se il tuo provider DNS non rinnova le firme prima della scadenza, i resolver le rifiutano.

Stato DNSSEC: BOGUS. SERVFAIL su tutti i record la cui firma è scaduta.

Diagnosi:

dig A captaindns.com +dnssec +cd
# Esaminare il campo RRSIG : inception ed expiration
# Format : RRSIG A 13 2 300 20260315120000 20260301120000 12345 captaindns.com. ABC...
#                                ^^^^^^^^^^^^^^^^ expiration
#                                                 ^^^^^^^^^^^^^^^^ inception

Cause frequenti:

  • BIND o PowerDNS autogestito senza rinnovo automatico configurato
  • Errore nel cron di re-firma
  • Migrazione DNS senza trasferimento delle chiavi di firma

Correzione:

  1. Se DNS gestito: contatta il supporto del provider
  2. Se BIND autogestito: rilancia la firma con rndc sign captaindns.com
  3. Se PowerDNS: esegui pdnsutil rectify-zone captaindns.com

Causa 4: algoritmo incompatibile

Sintomo: il DS record specifica un algoritmo diverso da quello usato dalla DNSKEY.

Spiegazione: il DS record indica ad esempio l'algoritmo 8 (RSA/SHA-256) mentre la DNSKEY usa l'algoritmo 13 (ECDSA P-256). Il resolver non può verificare la corrispondenza.

Stato DNSSEC: BOGUS. SERVFAIL.

Diagnosi:

# Verificare l'algoritmo del DS
dig DS captaindns.com +short
# Format : KeyTag Algorithm DigestType Digest
# Esempio : 12345 8 2 ABC...  (algoritmo 8 = RSA/SHA-256)

# Verificare l'algoritmo della DNSKEY
dig DNSKEY captaindns.com +short
# Format : Flags Protocol Algorithm PublicKey
# Esempio : 257 3 13 ABC...  (algoritmo 13 = ECDSA P-256)

Se i numeri di algoritmo differiscono tra DS e DNSKEY (flag 257), questa è la causa.

Correzione:

  1. Rigenera il DS record dal tuo provider DNS (userà l'algoritmo corretto)
  2. Aggiorna il DS al registrar
  3. Attendi la propagazione

Causa 5: cache del resolver (falso SERVFAIL)

Sintomo: SERVFAIL intermittente. Alcuni resolver restituiscono SERVFAIL, altri no.

Spiegazione: il resolver ha memorizzato nella cache una vecchia risposta o un vecchio DS record. Dopo una modifica DNSSEC (attivazione, rotazione di chiave, cambio di provider DNS), la cache del resolver può contenere dati incoerenti.

Diagnosi:

# Testare con un resolver diverso
dig A captaindns.com @1.1.1.1 +dnssec
dig A captaindns.com @8.8.8.8 +dnssec
dig A captaindns.com @9.9.9.9 +dnssec

Se alcuni resolver funzionano e altri no, è un problema di cache.

Correzione:

  1. Attendi la scadenza del TTL (verifica il TTL del DS record al TLD)
  2. Svuota la cache se possibile:

Prevenzione: prima di qualsiasi modifica DNSSEC, abbassa il TTL del DS record 24h in anticipo (se il tuo registrar lo consente).

Albero decisionale SERVFAIL DNSSEC: identificare la causa con tre comandi dig

Prevenire i SERVFAIL DNSSEC

Tre pratiche riducono il rischio di rottura:

DNS gestito invece che autogestito

I provider DNS gestiti (Cloudflare, Route 53, OVHcloud, Google Cloud DNS) gestiscono la firma automaticamente: rotazione delle chiavi, rinnovo delle RRSIG, pubblicazione del DS tramite CDS/CDNSKEY. Il rischio di SERVFAIL è quasi nullo con un DNS gestito.

Doppio DS durante le transizioni

Durante una rotazione della KSK, pubblica entrambi i DS record (vecchio + nuovo) al registrar. Attendi la propagazione completa del nuovo DS prima di eliminare il vecchio. Non eliminare mai il vecchio DS prima di aver verificato che il nuovo sia propagato.

Monitoraggio continuo

Verifica regolarmente la propagazione DNS della tua configurazione DNSSEC. Un DS errato o una firma scaduta possono verificarsi silenziosamente. Un avviso automatico sullo stato DNSSEC del tuo dominio permette di rilevare un problema prima che i tuoi utenti lo segnalino.

Processo di correzione SERVFAIL DNSSEC: dalla rilevazione alla verifica post-correzione

Piano d'azione in caso di SERVFAIL

  1. Confermare che DNSSEC è la causa: esegui dig captaindns.com +cd; se la risposta arriva con +cd ma non senza, DNSSEC è la causa
  2. Identificare l'anello rotto: verifica DS, DNSKEY e RRSIG con i tre comandi di diagnosi
  3. Applicare la correzione: segui lo scenario corrispondente (DS mancante, DS errato, RRSIG scaduta, algoritmo, cache)
  4. Verificare la riparazione: attendi il TTL poi verifica che il flag ad sia presente con dig captaindns.com +dnssec
  5. Documentare l'incidente: annota la causa, la correzione e il tempo di risoluzione per velocizzare la diagnosi futura

Lancia una diagnosi DNSSEC completa del tuo dominio per verificare che ogni anello sia al suo posto.

Guide DNSSEC correlate

FAQ

Cos'è un SERVFAIL DNS?

SERVFAIL (Server Failure) è un codice di risposta DNS (RCODE 2) che indica che il resolver non è riuscito a ottenere una risposta valida. Nel contesto DNSSEC, un SERVFAIL significa che la validazione crittografica è fallita: il resolver ha rifiutato la risposta perché un anello della catena di fiducia non è valido.

Qual è la differenza tra SERVFAIL e NXDOMAIN?

NXDOMAIN significa che il dominio non esiste. SERVFAIL significa che il dominio probabilmente esiste, ma il resolver non è riuscito a validare la risposta. Con DNSSEC, un SERVFAIL indica un problema di validazione (DS errato, firma scaduta), non un dominio inesistente.

Come capire se un SERVFAIL è causato da DNSSEC?

Usa il flag +cd (Checking Disabled) nel tuo comando dig: dig captaindns.com +cd. Se la risposta arriva con +cd ma non senza, DNSSEC è la causa del SERVFAIL. Senza +cd, il resolver valida DNSSEC e blocca la risposta.

Quanto tempo serve per correggere un SERVFAIL DNSSEC?

La correzione in sé richiede pochi minuti (aggiunta o modifica del DS record). La propagazione può richiedere da 1 a 48 ore a seconda del TTL del DS record al TLD. Nel frattempo, i resolver che hanno il vecchio valore nella cache continueranno a restituire SERVFAIL.

Bisogna disattivare DNSSEC d'urgenza in caso di SERVFAIL?

No. Disattivare DNSSEC in emergenza (eliminare il DS record senza disattivare la firma della zona) può peggiorare il problema. Identifica prima la causa esatta. Se il DS record è errato, correggilo. Disattiva DNSSEC solo se non riesci a identificare la causa e il sito è critico.

Perché il SERVFAIL non colpisce tutti gli utenti?

Solo i resolver validanti (che verificano DNSSEC) restituiscono SERVFAIL. I resolver non validanti ignorano le firme e restituiscono la risposta normalmente. Inoltre, i resolver che hanno ancora la vecchia risposta nella cache possono continuare a funzionare fino alla scadenza del TTL.

Come verificare che la correzione DNSSEC abbia funzionato?

Esegui dig captaindns.com +dnssec | grep flags. Se il flag ad (Authenticated Data) è presente, la catena di fiducia è validata. Testa con più resolver (1.1.1.1, 8.8.8.8, 9.9.9.9) per confermare che la propagazione sia completa.

Il DNS gestito elimina il rischio di SERVFAIL DNSSEC?

Quasi completamente. I provider DNS gestiti (Cloudflare, Route 53, OVHcloud) gestiscono automaticamente la firma, la rotazione delle chiavi e il rinnovo delle RRSIG. L'unico rischio residuo è un DS record errato al registrar, cosa che può succedere durante la configurazione iniziale o un trasferimento di dominio.

Glossario

  • SERVFAIL: codice di risposta DNS (RCODE 2) che indica che il resolver non è riuscito a completare la query. Nel contesto DNSSEC, segnala un fallimento della validazione.
  • BOGUS: stato interno del resolver quando la validazione DNSSEC fallisce. Il resolver restituisce SERVFAIL al client.
  • INSECURE: stato di un dominio la cui zona è firmata ma senza DS record al TLD. Il resolver non valida ma non blocca.
  • DS record: record al TLD contenente un hash della KSK. Anello di collegamento tra la zona e la zona padre.
  • RRSIG: firma crittografica di un record DNS con una durata di validità definita.
  • +cd (Checking Disabled): flag dig che chiede al resolver di non validare DNSSEC, utile per diagnosticare se DNSSEC causa un SERVFAIL.

Fonti

Articoli simili