DNSSEC e SERVFAIL: controllare DS, RRSIG e resolver

Se un dominio firmato restituisce SERVFAIL, verifica nell’ordine le RRSIG e le DNSKEY servite dai nameserver autoritativi, il DS pubblicato dalla zona padre e la risposta di un resolver validante. Le indicazioni tecniche di Cloudflare mostrano che una firma presente nella zona non basta: dopo un cambio di provider, un DS rimasto associato alle vecchie chiavi può interrompere la risoluzione.

Interroga poi lo stesso resolver per lo stesso nome con e senza il flag CD. Se la richiesta ordinaria fallisce e quella con CD restituisce i dati, la validazione DNSSEC è il principale indizio da approfondire; se falliscono entrambe, controlla anche delega, nameserver e raggiungibilità. Una risposta riuscita con il flag AD indica invece che quel resolver considera autenticati i dati restituiti.

Preparare richieste confrontabili

Nei comandi sostituisci dominio.tld con il dominio, nome.dominio.tld con un nome che abbia un record A, NS_AUTORITATIVO con un nameserver delegato e IP_RESOLVER con l’indirizzo del resolver che serve gli utenti interessati. Mantieni identici nome e tipo di record durante il confronto: una richiesta per un nome inesistente risponderebbe a una domanda diversa da quella che produce il guasto.

Per vedere il percorso della delega esegui dig dominio.tld NS +trace e individua i nameserver indicati dalla zona padre. Confrontali con quelli del registrar, soprattutto durante una migrazione: interrogare un server del vecchio provider può mostrare firme valide per una zona che non è più quella delegata. Evita +short nelle verifiche diagnostiche, perché nasconde lo stato della risposta e i flag dell’intestazione.

Distinguere le firme dalla risposta autenticata

Interroga direttamente un nameserver delegato con dig @NS_AUTORITATIVO nome.dominio.tld A +dnssec +norecurse. Se quel record A appartiene a una zona firmata, cerca la RRSIG che lo accompagna nella sezione della risposta. Ripeti la richiesta verso gli altri nameserver delegati: differenze nei record o nelle firme indicano che i server non stanno offrendo dati coerenti.

La RRSIG dimostra la presenza di una firma, non che il resolver possa verificarla fino a una chiave fidata. Esegui dig @IP_RESOLVER nome.dominio.tld A +dnssec e osserva sia lo stato sia la riga dei flag. AD su una risposta riuscita indica che il resolver dichiara autenticati i dati; l’assenza di AD, presa da sola, non prova che la firma sia errata. Una delega priva di DS, un resolver che non valida o il suo comportamento nella restituzione dei flag richiedono controlli distinti.

Confrontare le DNSKEY della zona con il DS del padre

Leggi le chiavi pubblicate dalla zona attualmente delegata con dig @NS_AUTORITATIVO dominio.tld DNSKEY +dnssec +norecurse. Cerca poi il DS con dig dominio.tld DS +trace: nella traccia, verifica che la risposta provenga dalla zona padre. Il registrar gestisce normalmente i dati inviati al registro per questa delega; aggiungere un DS nella zona figlia non sostituisce quello pubblicato dal padre.

Confronta il DS visibile nella delega con i dati DNSSEC del provider autoritativo attuale. La verifica riguarda identificativo della chiave, algoritmo, tipo di digest e digest: un identificativo uguale non dimostra, da solo, che il DS corrisponda alla DNSKEY pubblicata. Se esistono più DS, valuta se almeno uno consente un percorso di validazione; la semplice presenza di un valore diverso non basta a diagnosticare il guasto.

Se il padre punta soltanto a chiavi del vecchio provider, il punto da correggere è la delega gestita tramite il registrar, coordinandola con le chiavi già pubblicate dal nuovo provider. Se invece il DS è coerente ma un nameserver non serve le DNSKEY o le firme attese, controlla la configurazione della zona presso il provider DNS. Una zona può esporre RRSIG e DNSKEY anche senza DS: in quel caso manca il collegamento di fiducia dalla zona padre.

Usare CD per isolare un errore di validazione

Esegui in successione dig @IP_RESOLVER nome.dominio.tld A +dnssec e dig @IP_RESOLVER nome.dominio.tld A +dnssec +cd. Il flag CD, descritto nella specifica RFC 4035, chiede al resolver ricorsivo di restituire, se disponibili, anche dati che la sua verifica locale respingerebbe. Una risposta ottenuta grazie a CD serve alla diagnosi e non va considerata autenticata.

SERVFAIL senza CD e una risposta utile con CD indirizzano l’indagine verso DS, DNSKEY, RRSIG e validità delle firme. SERVFAIL in entrambi i casi non localizza invece la causa nelle firme: controlla che i nameserver delegati rispondano e che il nome richiesto esista nella zona prevista. Conserva l’indirizzo del resolver usato nel confronto; cambiare resolver fra le due richieste introdurrebbe una seconda configurazione.

Verificare il resolver e il suo trust anchor

Esegui dig @IP_RESOLVER dnssec-failed.org A +dnssec. Nel test indicato da ICANN, questo dominio deliberatamente non valido produce SERVFAIL quando il resolver esegue la validazione; NOERROR indica che non la applica a quel test. Un mancato contatto con il resolver o un errore di rete richiede invece una verifica separata.

Se il resolver restituisce SERVFAIL per il dominio di test, sai che sta validando, ma non hai ancora individuato la rottura del tuo dominio: torna al DS e ai dati serviti dai nameserver delegati. Se lo stesso resolver fallisce anche per altri domini firmati che risultano raggiungibili tramite resolver validanti diversi, chi lo amministra deve esaminare configurazione DNSSEC, trust anchor e orologio di sistema. Un trust anchor non aggiornato o un orologio errato può compromettere la verifica senza alcuna modifica alla zona del dominio.

Correggere il componente indicato dai risultati

Un DS del padre incoerente con le chiavi del provider attuale indirizza l’intervento al registrar. DNSKEY o RRSIG mancanti su uno dei nameserver delegati indirizzano invece al provider DNS autoritativo. Se la zona e la delega risultano coerenti ma il problema compare solo con un resolver, l’indagine riguarda quel resolver e la sua catena di fiducia.

Dopo la correzione, ripeti le richieste al padre, a ciascun nameserver delegato e al resolver usato dagli utenti. Durante la scadenza dei dati già memorizzati, un resolver può ancora mostrare una risposta precedente: confrontare questi punti permette di distinguere la cache da una configurazione tuttora incoerente prima di modificare nuovamente DS o chiavi.