Guida all'installazione DNSSEC per DNScale — Passo-passo

Questa guida ti accompagna nell'attivazione di DNSSEC su una zona DNScale, nella pubblicazione del record DS presso il tuo registrar, nella verifica della catena di fiducia e nella gestione dei modi di fallimento più comuni. Se vuoi prima il contesto concettuale, leggi Cos'è DNSSEC? e Come funziona DNSSEC.

Prima di iniziare

Conferma tre cose:

1. La tua zona è delegata a DNScale. I record NS presso il tuo registrar puntano ai server di nomi DNScale, e dig NS tuodominio @1.1.1.1 restituisce il set DNScale. Se non hai ancora migrato, fallo prima — vedi Delegazione DNS per regioni DNScale.
2. Il tuo TLD supporta DNSSEC. Tutti i gTLD (.com, .net, .org, ecc.) e la maggior parte dei ccTLD (.de, .fr, .nl, .eu, .uk, .it) supportano DNSSEC da anni. Una manciata di TLD più vecchi o piccoli non — controlla il report TLD IANA in caso di dubbio.
3. Il tuo registrar supporta la pubblicazione DS. La maggior parte dei registrar principali sì. Se il tuo no, dovrai trasferire il dominio a un registrar capace di DNSSEC o accettare che DNSSEC non sia disponibile per quel dominio.

Passo 1 — Attivare DNSSEC in DNScale

Dalla dashboard

1. Apri la tua zona nella dashboard DNScale.
2. Clicca sulla scheda Sicurezza (o DNSSEC a seconda della versione).
3. Clicca su Attiva DNSSEC. DNScale genera una nuova CSK usando ECDSA P-256 e inizia a firmare la zona. Questo richiede pochi secondi.
4. La dashboard mostra il record DS da pubblicare presso il tuo registrar:

example.com.   86400   IN   DS   12345 13 2 7c89aa1f3e7b4d8b...

Nota i quattro campi: Tag chiave (12345), Algoritmo (13 = ECDSA P-256), Tipo digest (2 = SHA-256), Digest (la stringa hex). Le UI di registrar diversi chiedono questi in combinazioni diverse — la maggior parte chiede tutti e quattro; alcuni chiedono la stringa completa del record DS; alcuni calcolano da soli il digest e chiedono solo la chiave pubblica DNSKEY.

Usando l'API DNScale

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/dnssec/enable" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"

La risposta include i campi del record DS che ti serviranno presso il registrar:

{
  "enabled": true,
  "ds_records": [
    {
      "key_tag": 12345,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "7c89aa1f3e7b4d8b..."
    }
  ]
}

Usando Terraform

resource "dnscale_zone_dnssec" "example" {
  zone_id   = dnscale_zone.example.id
  enabled   = true
}

Dopo terraform apply, la risorsa espone i campi del record DS come output che puoi passare a un provider di registrar (se il tuo registrar è gestito da Terraform) o catturare per inserimento manuale.

Usando DNSControl

D("example.com", DNSCALE,
  AUTODNSSEC_ON,
  // ... i tuoi record
);

La direttiva AUTODNSSEC_ON di DNSControl attiva la firma sul lato provider DNScale. Il record DS diventa disponibile nell'output di dnscontrol get-zones.

Passo 2 — Pubblicare il record DS presso il tuo registrar

Questo è l'unico passaggio manuale che il fornitore DNS non può (ancora) fare per te — vedi automazione CDS/CDNSKEY più avanti. La UI esatta varia a seconda del registrar; ecco i più comuni.

Schema generico

La maggior parte delle dashboard registrar ha una sezione DNSSEC o DNS avanzato per dominio. Tipicamente:

1. Clicca su Aggiungi record DS.
2. Inserisci i quattro campi: Tag chiave, Algoritmo, Tipo digest, Digest.
3. Salva.

Alcuni registrar chiedono la stringa completa del record DS (es. 12345 13 2 7c89aa1f...) — incolla l'intera riga. Altri ti permettono di incollare la chiave pubblica DNSKEY e calcolano il DS da soli — entrambi funzionano; usa quello che il registrar preferisce.

Cloudflare Registrar

Domain → DNS → DNSSEC → Attiva → Aggiungi record DS. Incolla i quattro campi. Cloudflare pubblica il DS al TLD in pochi minuti.

Gandi

Domains → tuo dominio → DNSSEC → Aggiungi una chiave. Incolla i campi; Gandi pubblica tipicamente entro 30 minuti.

Namecheap

Domain List → Manage → Advanced DNS → DNSSEC → Add Key. Incolla i campi e salva.

OVH

Dominio → DNSSEC → Aggiungi → Attiva DNSSEC. Incolla i campi. OVH propaga entro 30 minuti per la maggior parte dei TLD.

IONOS / 1&1

Dominio → SSL & DNSSEC → DNSSEC → Attiva → Aggiungi un record. Incolla i campi. IONOS pubblica tipicamente entro un'ora.

GoDaddy

Dominio → DNS → DNSSEC. Aggiungi chiave. Incolla i campi. Il tempo di pubblicazione varia; preventiva 24–48 ore.

Dominio presso un registry diretto

Alcune registry ccTLD accettano i record DS direttamente tramite interfaccia web o EPP. Il registrar normalmente li passerebbe — se non lo fa, contatta il supporto del registry.

Passo 3 — Verificare la catena end-to-end

Una volta pubblicato il DS, verifica che la catena funzioni a ogni anello. Il singolo comando più affidabile:

dig +dnssec example.com @1.1.1.1

Cerca due cose nella risposta:

1. Il flag AD nell'intestazione — ;; flags: qr rd ra ad; — conferma che il resolver ha validato con successo la catena.
2. Record RRSIG nella sezione risposta, abbinati a ciascun record di dati.

Se il flag AD manca ma sono presenti record RRSIG, il resolver non sta validando (prova 8.8.8.8 o 9.9.9.9). Se i record RRSIG mancano, la firma non ha avuto effetto — riverifica il Passo 1.

Verificare il DS presso la zona padre

dig DS example.com @a.gtld-servers.net.

Per .com, interroga direttamente i server gTLD. Per altri TLD, trova i NS del padre tramite dig NS .com @a.root-servers.net. o usa dig +trace. Risposta attesa: il tuo record DS, esattamente come inviato.

Se il DS non appare presso il padre entro 48 ore, contatta il tuo registrar — la pubblicazione è probabilmente fallita.

Usare un visualizzatore

Per un quadro completo, il visualizzatore DNSViz disegna l'intera catena dalla radice alla tua zona ed evidenzia eventuali rotture. Il Verisign DNSSEC Debugger fa lo stesso in una presentazione diversa.

Passo 4 — Testare da più resolver

Resolver diversi memorizzano nella cache in modo diverso e distribuiscono gli aggiornamenti a ritmi diversi. Dopo la verifica iniziale, interroga da almeno tre:

dig +dnssec example.com @1.1.1.1     # Cloudflare
dig +dnssec example.com @8.8.8.8     # Google
dig +dnssec example.com @9.9.9.9     # Quad9

Se tutti e tre mostrano il flag AD, il tuo deployment DNSSEC sta raggiungendo la flotta dei resolver pubblici.

Modi di fallimento comuni e come recuperare

Il DS presso il registrar non corrisponde al DNSKEY

Sintomo: dig +dnssec tuodominio restituisce SERVFAIL. DNSViz mostra un collegamento rosso tra il DS del padre e il tuo DNSKEY.

Causa: Digest sbagliato, algoritmo sbagliato o tag chiave sbagliato inserito presso il registrar.

Correzione: Recuperare il DS corretto dalla dashboard DNScale. Aggiornare presso il registrar. Attendere la propagazione TLD. Se la UI del registrar non accetta la tua modifica, rimuovi prima il DS errato e riaggiungi.

Più DS obsoleti presso il registrar

Sintomo: La validazione funziona in modo intermittente — alcuni resolver segnano AD la risposta, altri SERVFAIL.

Causa: Una precedente attivazione DNSSEC ha lasciato vecchi record DS che non corrispondono più a nessun DNSKEY attuale.

Correzione: Presso il registrar, rimuovi ogni DS che non appare nell'elenco DS DNScale attuale. Mantieni solo il DS della KSK attualmente attiva.

Il TLD non accetta il DS

Sintomo: La UI del registrar rifiuta il DS o lo mostra come "in attesa" indefinitamente.

Causa: Il TLD non supporta ancora DNSSEC (molto raro nel 2026), o c'è un ritardo lato registry.

Correzione: Controlla il report TLD IANA per lo stato DNSSEC. Se non supportato, non puoi attivare DNSSEC per quel dominio; considera il trasferimento a un TLD che lo supporti. Se supportato ma bloccato, contatta il supporto del registrar.

La firma è stata disattivata prima che il DS fosse rimosso

Sintomo: Il dominio restituisce SERVFAIL dai resolver validanti; i resolver non validanti continuano a risolvere normalmente.

Causa: L'ordine delle operazioni era sbagliato — il record DS presso il padre ora punta a una chiave che non esiste più nella tua zona.

Correzione: Riattivare DNSSEC in DNScale (che ripristina la firma con gli stessi tag chiave se possibile), o rimuovere il DS presso il registrar. L'ordine corretto per la disattivazione permanente è: rimuovere DS → attendere 48h → disattivare la firma.

Risposte negative pre-cachate persistono

Sintomo: Dopo aver corretto una configurazione errata DNSSEC, alcuni utenti continuano a vedere SERVFAIL per qualche tempo.

Causa: I resolver validanti memorizzano nella cache i fallimenti di validazione (tipicamente fino a 5 minuti). I resolver pubblici che eseguono il serving stale-data RFC 8767 possono mantenere i fallimenti obsoleti più a lungo.

Correzione: Attendi. I fallimenti memorizzati nella cache scadono; nulla dal tuo lato cambia i tempi. Verificare da un nuovo resolver ricorsivo (dig +dnssec tuodominio @1.0.0.1 invece di @1.1.1.1) conferma se lo stato sottostante è ora corretto.

Opzionale: Automatizzare il DS tramite CDS/CDNSKEY

RFC 7344 e RFC 8078 definiscono i record CDS e CDNSKEY — record lato figlio che dicono al padre quali record DS pubblicare. Un registrar che supporta lo scanning CDS/CDNSKEY può raccogliere automaticamente i cambiamenti DS senza inserimento manuale.

Il supporto è disomogeneo:

• ✅ Cloudflare Registrar — automazione CDS completa
• ✅ Gandi — supporta CDS per alcuni TLD
• ⚠️ La maggior parte degli altri — gestione DS manuale ancora
• ❌ Alcuni registrar legacy — nessun supporto DNSSEC

DNScale pubblica automaticamente i record CDS e CDNSKEY quando DNSSEC è attivato. Se il tuo registrar supporta lo scanning CDS, non è necessario alcun inserimento DS manuale — le rotazioni DS durante il rollover delle chiavi avvengono senza il tuo coinvolgimento.

Cosa succede dopo — Operazioni automatiche

Una volta che DNSSEC è attivato su una zona DNScale:

• Le firme si aggiornano continuamente. I record RRSIG vengono re-firmati prima della scadenza; i resolver vedono firme fresche su ogni query.
• La rotazione delle chiavi avviene secondo un programma. La ZSK ruota più spesso (quando separata dalla KSK); la KSK ruota raramente (ogni qualche anno). Con CSK (il default), le rotazioni coinvolgono il registrar — DNScale ti notifica quando è necessaria un'azione del registrar.
• Gli aggiornamenti dell'algoritmo sono roll coordinati. Se l'industria cambia (es. a Ed25519), DNScale esegue una rotazione di algoritmo senza downtime dei dati di zona.
• Aggiornamenti del record DS durante la rotazione: con automazione CDS, il DS del padre si aggiorna senza il tuo coinvolgimento; senza di essa, DNScale ti notifica che un nuovo DS deve essere pubblicato.

Non dovresti dover ripensare a DNSSEC dopo la configurazione iniziale — finché non decidi di migrare o la UX del registrar cambia.

Riferimenti

• RFC 4033/4034/4035 — specifica core DNSSEC
• RFC 7344 — Automating DNSSEC delegation trust maintenance (CDS/CDNSKEY)
• RFC 8078 — Managing DS records from the parent via CDS/CDNSKEY
• RFC 8901 — Modelli DNSSEC multi-firmatario (per deployment multi-provider)
• Ancore di fiducia radice IANA
• Visualizzatore DNSViz
• Verisign DNSSEC Debugger

Letture correlate

• Cos'è DNSSEC? — introduzione top-of-funnel
• Come funziona DNSSEC — meccanica KSK/ZSK/DS/DNSKEY
• Gestione delle chiavi DNSSEC — procedure operative di rotazione
• Deployment DNS multi-provider — aggiungere un secondo fornitore DNS in sicurezza con DNSSEC
• Delegazione DNS per regioni DNScale — puntare la tua zona a DNScale prima di attivare DNSSEC
• Avvelenamento della cache DNS — l'attacco che DNSSEC sconfigge
• NIS2 e conformità DNS — DNSSEC come controllo normativo