DNS e SSL: record DNS, DNSSEC, TLS, certificati e checklist completa

Esempi:

• un certificato valido non aiuta se il record A punta a un vecchio server,
• un record A corretto non basta se AAAA indirizza il traffico IPv6 verso una macchina non funzionante,
• il rinnovo automatico del certificato non funziona se il record _acme-challenge non può essere creato oppure la porta 80 è bloccata,
• DNSSEC può aumentare la fiducia nelle risposte DNS, ma un record DS errato può provocare un SERVFAIL per l'intero dominio,
• un TTL breve non ripara una delega errata dei name server,
• un certificato wildcard non copre il dominio principale né i sottodomini multilivello, se non sono stati inseriti separatamente.

Nel 2026 la gestione dei certificati dovrebbe essere completamente automatica. Dal 15 marzo 2026 i certificati TLS pubblici di tipo Subscriber Certificate possono avere una validità massima di 200 giorni. Il limite scenderà a 100 giorni nel marzo 2027 e a 47 giorni nel marzo 2029. Let's Encrypt continua a emettere per impostazione predefinita certificati di 90 giorni, ma mette a disposizione anche profili più brevi e, da maggio 2026, il profilo tlsserver emette certificati di 45 giorni per gli utenti che lo scelgono consapevolmente.

TL;DR: mantieni almeno due server DNS autoritativi raggiungibili in modo indipendente, controlla i record A e AAAA, implementa DNSSEC solo con un processo sicuro di gestione dei DS, limita le autorità di certificazione tramite CAA, usa TLS 1.3 con TLS 1.2 come minimo compatibile, automatizza l'emissione e il rinnovo dei certificati tramite ACME e monitora la data di scadenza, la catena dei certificati, SNI, HSTS e gli errori di validazione da più località.

Informazioni e requisiti verificati il 23 luglio 2026.

DNS, SSL e TLS in una sola tabella

Livello	Responsabile di	Elementi principali	Guasti tipici
Registrar del dominio	proprietà del dominio e delega	name server, blocco del trasferimento, DS	compromissione dell'account, delega errata, DS obsoleto
DNS autoritativo	record reali della zona	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	indirizzo errato, record mancante, split-brain, firma errata
Resolver ricorsivo	trovare e memorizzare in cache la risposta	TTL, cache, validazione DNSSEC, DoH/DoT	dati obsoleti in cache, validazione errata
TCP/QUIC e TLS	canale sicuro verso il server	TLS 1.2/1.3, SNI, ALPN, certificato	protocollo debole, chain errata, hostname mismatch
Certificato	conferma dell'identità del nome	SAN, issuer, validità, chiave, firma	scadenza, nome mancante, intermediate errato
HTTP	reindirizzamento e policy HTTPS	301/308, HSTS, header di sicurezza	redirect loop, mixed content, assenza di HSTS

Come funziona davvero la risoluzione di un dominio?

Il DNS è un sistema di nomi gerarchico e distribuito. Il resolver non riceve l'intera risposta da un unico server centrale. In modo semplificato:

1. il browser e il sistema controllano la cache locale,
2. il resolver ricorsivo interroga i server root,
3. i root indicano i server del dominio di primo livello pertinente, per esempio .pl,
4. il server TLD indica i server autoritativi del dominio,
5. il server autoritativo restituisce il record, per esempio A, AAAA oppure CNAME,
6. la risposta viene memorizzata in base al TTL.

użytkownik
   ↓
lokalny cache
   ↓
rekurencyjny resolver
   ↓
root → TLD → autorytatywny DNS
   ↓
A / AAAA / CNAME / HTTPS
   ↓
połączenie TLS z serwerem

Il DNS non garantisce che il server indicato sia integro né che la risposta HTTP sia corretta. Restituisce i dati registrati nella zona. Il monitoraggio DNS dovrebbe quindi essere combinato con test TCP, TLS e HTTP.

1. I record DNS più importanti

A e AAAA

example.com.      300 IN A     192.0.2.10
example.com.      300 IN AAAA  2001:db8::10

• A indica un indirizzo IPv4,
• AAAA indica un indirizzo IPv6.

Il record AAAA non è un'aggiunta senza conseguenze. Se esiste, i client che supportano IPv6 possono provare a connettersi proprio a quello. Non pubblicare AAAA finché firewall, routing, server web, certificato e challenge ACME non funzionano correttamente su IPv6.

Durante la validazione http-01, Let's Encrypt preferisce IPv6 quando il dominio ha un record AAAA. Un IPv6 errato può causare il fallimento dell'emissione o del rinnovo del certificato anche quando IPv4 è corretto.

CNAME

www.example.com.  300 IN CNAME app.hosting.example.

Un CNAME crea un alias verso un altro nome DNS. Un nome con un CNAME non dovrebbe avere contemporaneamente altri dati normali, come A, AAAA o MX, perché il CNAME indica che i dati effettivi si trovano sotto un altro nome.

Sull'apex della zona, ossia example.com, un CNAME classico entra in conflitto con i record obbligatori SOA e NS. I provider aggirano il problema con meccanismi propri come ALIAS, ANAME oppure il flattening, ma non si tratta di normali record CNAME trasmessi nella zona.

NS e SOA

example.com.  86400 IN NS ns1.dns-provider.example.
example.com.  86400 IN NS ns2.dns-provider.example.

NS definisce i name server autoritativi. La delega presso il registrar e i record NS all'interno della zona devono essere coerenti.

SOA contiene i dati amministrativi della zona, tra cui il numero di serie e i parametri usati dai server secondari. Con la gestione manuale della zona, il numero di serie deve aumentare dopo ogni modifica.

Una buona pratica operativa prevede almeno due server autoritativi che operano in reti o località distinte. ICANN raccomanda server autoritativi multipli e distinti, preferibilmente separati sul piano geografico e topologico.

MX

example.com.  3600 IN MX 10 mail1.example.net.
example.com.  3600 IN MX 20 mail2.example.net.

Un numero più basso indica una priorità più alta. La destinazione di un record MX dovrebbe essere un nome host, non un indirizzo IP né un CNAME.

Il cambio dell'hosting web non dovrebbe modificare automaticamente la posta. Prima della migrazione DNS, annota i record MX, SPF, DKIM e DMARC.

TXT

TXT è un contenitore di testo usato, tra l'altro, da:

• SPF,
• DKIM,
• DMARC,
• la validazione della proprietà del dominio,
• ACME dns-01,
• le integrazioni SaaS.

example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"

Più record TXT sotto uno stesso nome possono essere corretti, ma più record SPF concorrenti che iniziano con v=spf1 costituiscono un errore di progettazione.

CAA

CAA permette al proprietario del dominio di indicare quali autorità di certificazione possono emettere certificati per il dominio.

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

• issue riguarda i certificati normali,
• issuewild riguarda i wildcard,
• iodef indica il canale per segnalare le violazioni della policy.

CAA non sostituisce il controllo dell'account presso il registrar, DNSSEC né il monitoraggio della Certificate Transparency. È un vincolo aggiuntivo per le CA pubbliche. L'assenza di CAA significa di solito che qualsiasi CA pubblicamente attendibile può emettere un certificato dopo una corretta validazione del dominio.

PTR

PTR realizza il reverse DNS, ossia la mappatura di un indirizzo IP su un nome. Il record viene impostato dal proprietario del range di IP, di solito il provider VPS o di hosting. È particolarmente importante per i server di posta.

192.0.2.10 → mail.example.com

Per la posta, il nome PTR dovrebbe di norma ricondurre, tramite A o AAAA, allo stesso indirizzo.

HTTPS e SVCB

I record HTTPS e SVCB possono comunicare al client informazioni sul modo di connettersi al servizio, sugli endpoint alternativi, sui protocolli supportati e sui parametri necessari prima di stabilire la connessione.

Esempio concettuale:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"

Non si dovrebbe inserire ipv4hint o ipv6hint come sostituto di record di indirizzo corretti senza comprendere il comportamento dei client. Il record HTTPS RR è un meccanismo di ottimizzazione e segnalazione, non una correzione di un DNS o di un TLS errato.

2. TTL e la «propagazione DNS»

Il TTL definisce per quanto tempo un resolver può conservare la risposta in cache. Non esiste un unico orologio globale della propagazione. Dopo una modifica:

• una parte dei resolver ha ancora la vecchia risposta,
• una parte interroga subito il server,
• anche le risposte negative, come NXDOMAIN, possono essere memorizzate in cache,
• il sistema locale, il browser, l'operatore e l'applicazione possono avere cache separate.

Valori TTL ragionevoli

Situazione	Valore tipico
record di produzione stabile	3600-86400 s
preparazione della migrazione	300-600 s
record ACME DNS-01	30-300 s, se il provider lo consente
record NS o SOA	di solito più lungo
failover di emergenza	un TTL basso aiuta solo dopo la scadenza della cache precedente

Prima della migrazione, riduci il TTL con un anticipo pari ad almeno un vecchio periodo di TTL. Abbassare il TTL cinque minuti prima della modifica non elimina le risposte che il resolver ha già memorizzato per 24 ore.

Al termine della migrazione, aumenta il TTL per ridurre il numero di query e la dipendenza da problemi temporanei del DNS autoritativo.

3. DNSSEC: integrità delle risposte, non cifratura

DNSSEC aggiunge l'autenticazione dell'origine dei dati DNS e la protezione dell'integrità tramite firme digitali. Non cifra le query né nasconde i nomi di dominio al provider di rete o al resolver.

La catena di fiducia utilizza, tra l'altro:

• DNSKEY - le chiavi pubbliche della zona,
• RRSIG - le firme dei set di record,
• DS - l'impronta della chiave registrata nella zona superiore,
• NSEC o NSEC3 - la conferma crittografica dell'inesistenza di un nome o di un tipo.

root
  ↓ podpisana delegacja
TLD
  ↓ rekord DS
example.com
  ↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA

L'RFC 9364 definisce l'uso di DNSSEC per l'autenticazione dell'origine dei dati DNS come la buona pratica attuale.

Il rischio maggiore di DNSSEC

Il problema più frequente non è l'assenza di DNSSEC, bensì una catena DNSSEC errata. Se presso il registrar rimane un record DS che punta a una vecchia chiave, mentre il nuovo operatore DNS firma la zona con una chiave diversa, i resolver che eseguono la validazione restituiranno un SERVFAIL.

Una migrazione DNSSEC sicura richiede:

1. verificare chi firma la zona,
2. stabilire il metodo di trasferimento o di rollover delle chiavi,
3. pubblicare il DS corretto nel dominio superiore,
4. attendere il TTL dei record DNSKEY e DS,
5. solo in seguito rimuovere le vecchie chiavi o la vecchia zona,
6. testare tramite resolver che eseguono la validazione.

Non attivare DNSSEC se il provider non offre un processo chiaro per la gestione dei DS e la rotazione delle chiavi.

4. DNSSEC contro DoH e DoT

Questi meccanismi risolvono problemi diversi:

Meccanismo	Protegge	Non garantisce
DNSSEC	autenticità e integrità dei dati DNS	la riservatezza della query
DNS over TLS	cifratura tra client e resolver tramite TLS, di solito porta 853	l'autenticità dei dati senza la validazione DNSSEC
DNS over HTTPS	cifratura del DNS in HTTPS	l'autenticità dei dati senza DNSSEC
DNS normale	risoluzione di base dei nomi	la riservatezza e l'integrità crittografica

DNS over TLS è descritto dall'RFC 7858, mentre DNS over HTTPS dall'RFC 8484. Il trasporto cifrato protegge la query da un semplice intercettamento sul tratto client-resolver, ma l'operatore del resolver vede comunque le query e l'ulteriore risoluzione dipende dalla sua policy.

5. SSL e TLS: la terminologia corretta

«Certificato SSL» è ancora un'espressione di marketing molto diffusa, ma i siti moderni usano TLS. SSL 2.0 e SSL 3.0 sono obsoleti, mentre TLS 1.0 e 1.1 sono stati formalmente ritirati dall'IETF.

Nel 2026:

• TLS 1.3 dovrebbe essere preferito,
• TLS 1.2 rimane il minimo compatibile per i client più datati ancora supportati,
• TLS 1.0, TLS 1.1, SSLv2 e SSLv3 dovrebbero essere disattivati,
• la configurazione di TLS 1.2 dovrebbe usare suite moderne con AEAD e forward secrecy,
• il server non dovrebbe offrire algoritmi e scambi di chiavi obsoleti.

L'RFC 9325 contiene le raccomandazioni attuali per un uso sicuro di TLS e ha sostituito il precedente BCP 195.

6. Cosa verifica il browser nel certificato?

Durante una connessione TLS, il client verifica, tra l'altro:

1. se il certificato è nel periodo di validità,
2. se il nome host è presente in subjectAltName,
3. se la firma conduce, attraverso una catena intermedia corretta, a una root CA attendibile,
4. se il certificato non viene usato per uno scopo improprio,
5. se i parametri della connessione sono accettabili,
6. se le policy del browser non rifiutano il certificato.

L'identità del server viene oggi verificata in base ai SAN, non al campo Common Name come fonte principale del nome.

SAN

Un singolo certificato può coprire più nomi:

example.com
www.example.com
api.example.com

Ogni nome deve essere presente nei SAN.

Wildcard

*.example.com

copre:

www.example.com
api.example.com
shop.example.com

ma non copre automaticamente:

example.com
www.eu.example.com

Il dominio principale va aggiunto separatamente e il wildcard funziona solo per un singolo livello di etichetta.

SNI

Server Name Indication permette al client di comunicare il nome host durante l'handshake, così un singolo indirizzo IP può servire più certificati. Una configurazione SNI errata provoca spesso la visualizzazione del certificato di un altro dominio.

La catena dei certificati

Il server dovrebbe inviare il certificato del dominio e i certificati intermedi necessari, ma di solito non la root. L'assenza dell'intermediate può funzionare su un dispositivo che aveva già memorizzato il certificato e fallire su un altro.

7. Validità dei certificati nel 2026

Il CA/Browser Forum ha adottato un calendario per l'accorciamento dei certificati TLS pubblici:

Data di emissione	Validità massima
prima del 15 marzo 2026	398 giorni
15 marzo 2026 - 14 marzo 2027	200 giorni
15 marzo 2027 - 14 marzo 2029	100 giorni
dal 15 marzo 2029	47 giorni

Questo non significa che ogni CA emetta il certificato per il periodo massimo. Let's Encrypt continua a emettere per impostazione predefinita certificati di 90 giorni, dispone di certificati opzionali di sei giorni e di un profilo tlsserver con certificati di 45 giorni disponibile per le implementazioni iniziali da maggio 2026.

La conclusione è semplice: il rinnovo manuale dei certificati cessa di essere una pratica operativa ragionevole.

8. ACME e l'automazione dei certificati

ACME è il protocollo standard che automatizza la registrazione dell'account, la validazione del controllo del dominio, l'emissione, il rinnovo e la revoca del certificato.

HTTP-01

La CA scarica un file:

http://example.com/.well-known/acme-challenge/TOKEN

Vantaggi:

• configurazione semplice per un singolo server web,
• automazione facile,
• non richiede API DNS.

Limitazioni:

• richiede la porta 80 accessibile,
• non emette wildcard,
• la challenge deve raggiungere il server corretto,
• un AAAA errato, un proxy, un redirect oppure un load balancer possono interrompere la validazione.

Let's Encrypt raccomanda di mantenere la porta 80 per i server web pubblici e di reindirizzare il traffico normale verso HTTPS.

DNS-01

Il client pubblica un TXT:

_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"

Vantaggi:

• supporta i wildcard,
• funziona senza un server HTTP pubblico,
• è adatto alla gestione centralizzata dei certificati.

Rischi:

• richiede un accesso sicuro alle API DNS,
• la propagazione e la cache possono ritardare la validazione,
• un token API con diritto di modifica dell'intera zona aumenta le conseguenze di una fuga,
• vecchi TXT possono complicare la diagnostica.

Let's Encrypt raccomanda esplicitamente di usare DNS-01 con un provider che offre API, perché l'automazione dei rinnovi è fondamentale. Assegna al token l'ambito più ristretto possibile: preferibilmente solo per i record _acme-challenge, non per la gestione del dominio, dell'account o di tutte le zone.

Il wildcard in Let's Encrypt richiede DNS-01.

TLS-ALPN-01

La validazione avviene tramite una connessione TLS speciale sulla porta 443 e il protocollo ALPN. È utile per proxy specializzati e sistemi di gestione dei certificati, ma viene configurata manualmente più raramente.

Renewal Information

Un client ACME moderno dovrebbe supportare ACME Renewal Information, ossia ARI. Invece di rinnovare ogni certificato secondo un'unica soglia rigida, il client può ricevere dalla CA una finestra di rinnovo suggerita. Let's Encrypt raccomanda di controllare le informazioni ARI almeno due volte al giorno.

9. CAA e ACME: un esempio pratico

Per i certificati Let's Encrypt:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Se non vuoi il wildcard:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"

Prima dell'emissione, una CA pubblica è tenuta a verificare il CAA. Dal 15 marzo 2026 i requisiti del CA/Browser Forum impongono anche la validazione DNSSEC per le query relative al CAA eseguite dalla prospettiva di rete principale, e un errore di validazione DNSSEC non può essere trattato come un'autorizzazione all'emissione.

Dopo il cambio di CA, ricordati di aggiornare il CAA prima di avviare il nuovo processo di emissione.

10. HTTPS, reindirizzamenti e HSTS

Schema minimo:

http://example.com
        ↓ 301 lub 308
https://example.com

Dopo aver confermato il pieno funzionamento di HTTPS, si può aggiungere:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS comunica al browser di usare in futuro solo HTTPS e di non consentire di aggirare parte degli errori del certificato.

Non iniziare con un lungo max-age, includeSubDomains e preload se:

• esistono sottodomini senza HTTPS,
• parte dell'infrastruttura è gestita da un partner,
• il processo di rinnovo non è stato testato,
• non c'è monitoraggio dei certificati,
• non è chiaro se il vecchio servizio sarà ancora necessario.

HSTS preload inserisce la regola nella distribuzione dei browser. La rimozione della voce può richiedere settimane.

11. Gli errori DNS più comuni

Record AAAA errato

IPv4 funziona, ma una parte dei client sceglie un IPv6 non funzionante. I sintomi sono casuali a seconda della rete dell'utente.

CNAME e altri record sotto lo stesso nome

L'alias entra in conflitto con i record di indirizzo, MX o TXT. Il pannello del provider può bloccare la modifica oppure generare una zona ambigua.

Delega NS incoerente

Il registrar indica server diversi da quelli della zona oppure uno dei server ha una versione più vecchia dei dati.

DS obsoleto dopo il cambio di DNS

Il dominio restituisce SERVFAIL solo sui resolver che validano DNSSEC.

TTL troppo basso in modo permanente

Aumenta il numero di query e la sensibilità a un'indisponibilità temporanea del DNS, ma non garantisce automaticamente un failover rapido.

TTL troppo alto prima della migrazione

I vecchi indirizzi restano in cache per molte ore.

Record TXT lasciati in sospeso

I vecchi token di verifica e ACME complicano l'audit e aumentano il caos operativo.

Mancanza di coerenza tra www e apex

example.com e www.example.com puntano a sistemi diversi, hanno certificati diversi oppure creano un loop di reindirizzamenti.

12. Gli errori TLS e dei certificati più comuni

Certificato scaduto

Nella maggior parte dei casi la causa non è l'assenza di automazione, bensì un automatismo che ha smesso di funzionare senza alcun avviso.

Il certificato non copre l'host

Un certificato per example.com non protegge automaticamente www.example.com.

Chain incompleta

Manca il certificato intermedio. Il problema può manifestarsi solo su nuovi dispositivi o su determinati client.

Certificato errato a causa di SNI

Il reverse proxy ha un default virtual host errato oppure il nuovo dominio non è stato aggiunto alla mappatura.

Protocolli e cipher suite obsoleti

Il server offre ancora TLS 1.0/1.1 o suite vecchie, perché la configurazione risale a molti anni fa.

Mancanza di conformità su più livelli

La CDN ha un certificato pubblico valido, ma la connessione CDN→origin non è cifrata oppure non verifica il nome host.

Rinnovo eseguito, ma il processo non ha ricaricato il server

Il nuovo file del certificato esiste su disco, ma Nginx, Apache, HAProxy o l'applicazione continua a usare il vecchio certificato dalla memoria.

13. Diagnostica passo dopo passo

Record DNS

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Delega

dig example.com NS
dig +trace example.com

DNSSEC

dig example.com A +dnssec
delv example.com A

Un SERVFAIL a fronte di un funzionamento senza validazione è un forte segnale di un problema DNSSEC.

Certificato e SNI

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Date del certificato

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

TLS

openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2

HTTP e HSTS

curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/

Controlla il redirect, Strict-Transport-Security, il nome host, lo stato finale e l'assenza di loop.

Puoi anche usare gratuitamente l'Ispettore DNS e SSL di POLPROG, che mostra i record DNS e le informazioni sul certificato TLS. Completa il test con l'Ispettore degli header di sicurezza, il Controllo dello stato del sito e l'articolo Fondamenti di sicurezza delle applicazioni web.

14. Monitoraggio in produzione

Non monitorare solo la homepage da un'unica località. Set minimo:

• la risposta del DNS autoritativo,
• i record A, AAAA, CNAME, NS, MX e CAA,
• la validazione DNSSEC,
• la raggiungibilità su IPv4 e IPv6,
• le date del certificato,
• la conformità dei SAN,
• la chain completa,
• TLS 1.2 e TLS 1.3,
• il redirect finale HTTP→HTTPS,
• HSTS,
• la risposta dell'origin dietro la CDN,
• il funzionamento di ACME e l'ultimo rinnovo riuscito.

Soglie di allerta del certificato

Per un sistema completamente automatico:

Tempo rimanente	Reazione
30 giorni	avviso o controllo dell'andamento
14 giorni	alert che richiede analisi
7 giorni	incidente operativo
3 giorni	alert critico ed escalation
meno di 24 h	guasto imminente

Le soglie vanno adattate alla durata del certificato. Per i certificati di sei giorni o di 45 giorni, il monitoraggio deve reagire molto prima, in proporzione al ciclo di rinnovo.

15. Checklist sicura per DNS e TLS

Registrar e DNS

• L'account del registrar ha l'MFA.
• Il trasferimento del dominio è bloccato.
• I dati di contatto e la procedura di recupero sono aggiornati.
• Vengono usati almeno due server DNS autoritativi.
• I server operano in reti o località distinte.
• La delega NS presso il registrar e nella zona è coerente.
• I record A e AAAA puntano a un'infrastruttura attiva.
• IPv6 è effettivamente monitorato.
• I record MX, SPF, DKIM e DMARC vengono conservati durante le migrazioni.
• CAA consente solo le CA effettivamente usate.
• Non ci sono record TXT e token di verifica superflui.
• Il TTL è stato ridotto in anticipo prima della migrazione.
• Il TTL è stato aumentato dopo la stabilizzazione.
• L'accesso alle API DNS ha permessi minimi.

DNSSEC

• Il provider supporta DNSSEC e la rotazione delle chiavi.
• Il record DS presso il registrar corrisponde al DNSKEY attivo.
• I cambi di operatore DNS prevedono un piano di migrazione DNSSEC.
• I vecchi DS e le vecchie chiavi vengono rimossi solo dopo la scadenza della cache.
• Il dominio viene testato tramite un resolver che esegue la validazione.
• Un alert rileva i SERVFAIL e la scadenza delle firme.

Certificati

• I certificati vengono emessi e rinnovati tramite ACME.
• Il rinnovo è stato testato, non solo la prima emissione.
• Il processo ricarica il server dopo l'installazione del nuovo certificato.
• Tutti gli host sono presenti nei SAN.
• Il wildcard viene usato in modo consapevole.
• La chain contiene gli intermediate corretti.
• La chiave privata non lascia il sistema di competenza.
• I permessi sulla chiave sono limitati.
• Gli alert funzionano indipendentemente dal client ACME stesso.
• DNS-01 usa un token API con ambito limitato.
• HTTP-01 funziona su IPv4 e IPv6.
• La CA di staging viene usata per i test di automazione.

TLS e HTTPS

• TLS 1.3 è attivato.
• TLS 1.2 rimane solo per la compatibilità necessaria.
• TLS 1.0, TLS 1.1 e SSL sono disattivati.
• Il server non offre cipher suite obsolete.
• SNI restituisce il certificato corretto per ogni host.
• HTTP reindirizza direttamente a HTTPS.
• Non c'è mixed content.
• HSTS è stato implementato per fasi.
• includeSubDomains è sicuro per l'intero dominio.
• Il preload è stato analizzato prima dell'invio.
• Anche CDN→origin usa un TLS verificato correttamente.

Verdetto

Una buona configurazione di DNS e TLS nel 2026 si basa su quattro principi:

1. Il DNS deve essere coerente e resiliente sul piano operativo.
2. DNSSEC dovrebbe essere implementato solo con una corretta gestione dei DS e delle chiavi.
3. I certificati devono essere gestiti automaticamente tramite ACME.
4. TLS 1.3, una chain corretta, il monitoraggio e HSTS fanno parte di un unico processo e non di attività separate.

Il rischio maggiore non è l'assenza del «lucchetto verde» nel giorno del lancio. È un guasto silenzioso qualche mese dopo: un certificato scaduto, un record AAAA non aggiornato, un DS lasciato in sospeso, un token DNS con permessi eccessivi oppure un automatismo di rinnovo che nessuno ha monitorato.