DNSSEC per domini ecommerce: attivazione, verifica e rotazione delle chiavi

DNSSEC protegge l’autenticità del DNS, non la sua riservatezza

DNSSEC aggiunge autenticazione dell’origine e integrità alle risposte DNS firmate. Un resolver validante può quindi riconoscere dati alterati o non coerenti con la firma. Non cifra però le query, non nasconde i nomi richiesti e non sostituisce TLS, protezione dell’account registrar o sicurezza dei nameserver.

La stessa protezione crea un rischio operativo. Quando il dominio padre pubblica un record DS, i resolver validanti si aspettano una catena verificabile fino alle DNSKEY della zona figlia. Se il DS indica una chiave assente, se le firme sono scadute o se vecchi dati restano in cache durante una rotazione, la risposta può essere considerata bogus e tradursi in SERVFAIL. Per questo l’attivazione non è un interruttore, ma una sequenza con prove e tempi espliciti.

Preparare inventario, responsabilità e finestra di cambiamento

Disegnare la catena di fiducia reale

Documenta registrar, registry, operatore DNS autoritativo, titolari degli account, contatti di emergenza e modalità con cui il DS viene inserito o rimosso. Registra nameserver, zone secondarie, sottodeleghe, algoritmi, digest, TTL di DS e DNSKEY, durata delle firme, frequenza di rinnovo e automazioni di rotazione. Se registrar e DNS provider sono soggetti diversi, assegna una persona a ogni passaggio: nessun tool può compensare un’autorizzazione mancante durante un incidente.

Conserva una baseline delle risposte contenenti dati DNSSEC, ottenute da resolver validanti, e delle query dirette ai nameserver autoritativi. Definisci il change owner, chi può decidere lo stop e chi comunica con assistenza, registrar e provider. La guida ICANN insiste su policy, pratica operativa, ruoli e monitoraggio: per un negozio il formato può essere più snello, ma le responsabilità devono essere altrettanto concrete.

Firmare la zona prima di creare il collegamento DS

Fase A: rendere completa la zona figlia

Attiva la firma presso l’operatore autoritativo senza pubblicare ancora il DS nel dominio padre. Verifica che tutti i nameserver servano lo stesso insieme DNSKEY, che le risposte contengano RRSIG valide e che i record di non esistenza siano firmati correttamente. Controlla il tag della chiave, l’algoritmo e il digest che il provider propone per il DS. Una chiave mostrata nel pannello non basta: la prova deve arrivare dalle risposte autoritative pubbliche.

In questa fase il parent non impone ancora la validazione, quindi un difetto può essere corretto prima di vincolare la catena. Lascia stabilizzare la firma su tutti i nameserver e ripeti i test sui nomi critici. Non copiare manualmente un DS da un ambiente precedente e non dedurlo dal solo identificatore della chiave; usa il valore prodotto per quella zona e confrontalo con le DNSKEY effettivamente pubblicate.

Fase B: pubblicare il DS nel parent

Dopo il gate della zona firmata, inserisci il DS attraverso il registrar o il processo previsto dal registry. Interroga il parent autoritativo per verificare che il DS pubblicato coincida con quello atteso, poi osserva la catena completa. L’attivazione è conclusa quando risposte positive e negative vengono validate lungo il percorso parent-child, non quando il pannello mostra una spunta verde.

Verificare da più resolver e da più percorsi

Usa query dirette ai nameserver per separare il contenuto autoritativo dal comportamento delle cache, quindi interroga più resolver validanti indipendenti e i resolver realmente usati da uffici, monitor sintetici o reti operative. Con dig +dnssec osserva DS, DNSKEY e RRSIG; con uno strumento di validazione controlla quale anello fallisce. Confronta le risposte IPv4 e IPv6 e, se esistono più provider autoritativi, controlla ogni nameserver e località disponibile.

• Parent: il DS atteso è presente, senza valori obsoleti o duplicati non pianificati.
• Child: tutte le DNSKEY necessarie sono pubblicate e il relativo insieme è firmato.
• Firme: RRSIG valide coprono record esistenti e risposte negative.
• Resolver: il dominio risolve con validazione attiva e senza SERVFAIL anomali.
• Journey: storefront, login, checkout, API e callback completano test sintetici.

Mantieni il monitoraggio per almeno i TTL e le finestre operative coinvolte, calcolati sui valori reali di parent e child. Non trasformare 24 o 48 ore in una regola universale: la durata dipende dai TTL, dalle cache già popolate e dal processo di registrar e registry.

Ruotare le chiavi con sovrapposizione e gate

Distinguere ZSK, KSK e automazione del provider

La rotazione della chiave che firma i record di zona può restare interna alla zona se la chiave di fiducia non cambia; una rotazione che modifica il riferimento del parent richiede coordinamento del DS. I servizi gestiti possono automatizzare parte del processo, ma il proprietario del dominio deve sapere se il provider gestisce DNSKEY, firme e rollover, oppure se richiede azioni al registrar. Documenta anche come sospendere l’automazione durante una migrazione: due sistemi che ruotano autonomamente possono invalidare una sequenza preparata.

Il modello prudente è pre-pubblicare la nuova chiave, attendere che sia visibile dove necessario, iniziare a usarla, mantenere la vecchia durante la sovrapposizione e rimuoverla soltanto dopo la scadenza delle cache pertinenti. Per una KSK o una variante equivalente, pubblica e verifica il nuovo DS prima di ritirare quello precedente. RFC 6781 descrive metodi diversi perché il calendario dipende da firme, TTL e capacità delle parti; non comprimere i passaggi per rispettare una finestra di manutenzione arbitraria.

Migrare operatore senza spezzare la catena

Una migrazione DNSSEC non coincide con il normale cambio di nameserver. Il nuovo operatore, quello precedente e il registrar devono poter mantenere fiducia verso entrambe le chiavi durante la transizione. La procedura documentata da Google usa DNSKEY incrociate e più DS per far sì che i resolver possano validare risposte provenienti da entrambi gli operatori mentre cambiano le deleghe. Richiede l’importazione delle chiavi, più record DS, lo stesso algoritmo presso entrambi gli operatori e la rotazione sospesa. Non cambiare algoritmo durante la migrazione.

Prima del cambio NS, verifica che entrambe le infrastrutture servano la zona corretta, che il parent esponga entrambi i DS pianificati e che siano trascorsi i TTL indicati dal runbook. Dopo il cutover, mantieni il vecchio operatore finché le vecchie deleghe possono trovarsi in cache. Solo allora rimuovi chiavi e DS precedenti nell’ordine previsto. Se le piattaforme non supportano questo modello, disattivare temporaneamente DNSSEC è una scelta di rischio esplicita, non una scorciatoia equivalente alla continuità della catena.

Rollback: rimuovere il vincolo prima di cambiare i nameserver

Se l’attivazione produce SERVFAIL e la zona firmata non può essere corretta rapidamente, il rollback operativo consiste nel rimuovere il DS dal parent, confermare la rimozione autoritativa e attendere la scadenza del relativo TTL prima di disabilitare la firma o cambiare nameserver. Cloudflare avverte di rimuovere il DS e attendere prima di modificare i nameserver: invertire l’ordine può lasciare resolver con un’aspettativa di validazione che la nuova zona non soddisfa.

Durante l’attesa, resolver diversi possono vedere stati differenti. Mantieni la zona firmata e le chiavi referenziate disponibili, continua i test e comunica uno stato basato su osservazioni, non su una stima generica. Il runbook deve contenere valori DS precedenti, accessi, comandi di verifica, escalation e criteri per correggere in avanti oppure ritirare la catena. Collega questo scenario al piano di disaster recovery, ma non confondere un rollback DNSSEC con il ripristino dell’applicazione o dei dati ecommerce.

Monitorare scadenze, validazione e impatto commerciale

Il cruscotto deve unire stato DNS e journey: giorni alla scadenza delle firme, coerenza DNSKEY tra nameserver, DS osservato al parent, esito di validazione da più resolver, SERVFAIL, latenza DNS, disponibilità di storefront e checkout, successo dei callback e anomalie per rete o area. Allerta prima della scadenza, non quando la firma è già inutilizzabile. Ogni cambio deve lasciare un audit con valori prima e dopo, proprietario, gate superati e decisione finale.

Una gestione affidabile di DNSSEC combina catena documentata, firma anticipata, DS pubblicato per ultimo, verifica distribuita e rotazioni con sovrapposizione. Per allineare registrar, DNS autoritativo, monitoraggio e runbook, consulta i nostri servizi per domini e infrastruttura ecommerce. Se devi pianificare l’attivazione o revisionare una rotazione imminente, contatta AE Digital Agency per una verifica operativa prima del cambiamento.