Torna al blog
dns Pubblicato: AEU DNS Newsroom

DNSSEC aggiunge controlli sull'origine che HTTPS da solo non può fornire

DNSSEC aggiunge controlli sull'origine che HTTPS da solo non può fornire
Immagine generata dall'IA

DNSSEC autentica i dati DNS prima che inizi una connessione HTTPS, riducendo il rischio che query reindirizzate conducano gli utenti alla destinazione sbagliata.

DNSSEC aggiunge un livello di origin authentication che HTTPS non può fornire da solo, secondo una revisione di deSEC discussa da APNIC il 3 novembre 2026. DNSSEC, abbreviazione di Domain Name System Security Extensions, consente a un sistema di verificare che le informazioni DNS firmate provengano dall'operatore del dominio e non siano state alterate durante il percorso. Questo è importante perché DNS, il Domain Name System che converte il nome di un sito nella destinazione utilizzata dai computer, viene consultato prima che un browser possa iniziare a controllare la connessione cifrata di un sito web.

La revisione, pubblicata su CircleID, esamina affermazioni ricorrenti su DNSSEC, tra cui la sua complessità operativa, l'adozione incompleta e il più ampio valore sociale. APNIC evidenzia l'elenco IANIX come una parte importante di questa discussione. IANIX è un record mantenuto attivamente delle interruzioni legate a DNSSEC nell'intero sistema dei nomi di dominio e dimostra che gli errori di configurazione e operativi sono un problema reale, non un'obiezione ipotetica. In precedenza, deSEC ha inoltre discusso il key drift tra parent domain e child domain, situazione in cui le relative informazioni DNSSEC non corrispondono più, e la post-quantum cryptography in DNSSEC, che riguarda metodi progettati per rimanere sicuri contro futuri attacchi basati sul quantum computing.

Un'argomentazione comune sostiene che HTTPS protegga già i siti web, rendendo superfluo DNSSEC. HTTPS utilizza TLS, ossia Transport Layer Security, per cifrare la connessione di un browser e autenticare il server mediante un digital certificate. Tuttavia, il browser deve prima utilizzare DNS per sapere dove connettersi. TLS protegge quindi una connessione all'endpoint raggiunto dal browser, mentre DNSSEC aiuta a verificare i dati DNS firmati utilizzati in primo luogo per individuare tale endpoint. I due meccanismi proteggono parti diverse del percorso.

Se un intermediario reindirizza una query DNS non protetta, l'utente può essere inviato verso un'altra destinazione prima che il browser controlli un certificato TLS. La discussione di APNIC osserva che, a meno che il certificate pinning non venga applicato rigorosamente, un adversary potrebbe comunque riuscire a stabilire una connessione TLS supportata da una certificate authority. Il certificate pinning è un metodo che fa sì che un'applicazione si aspetti un particolare certificato o una specifica identità, invece di accettare qualsiasi certificato altrimenti considerato attendibile. Il browser potrebbe quindi mostrare una connessione cifrata anche se l'utente non ha raggiunto la destinazione prevista.

Gli Homograph attacks offrono un altro mezzo di inganno. Utilizzano caratteri visivamente simili per far assomigliare un nome di dominio a un altro, riducendo la capacità di una persona di riconoscere dove conduce una connessione. HTTPS può autenticare il dominio somigliante che è stato effettivamente aperto, ma ciò non lo rende il dominio che l'utente intendeva visitare. DNSSEC non sostituisce il controllo attento degli indirizzi, ma fornisce una prova verificabile per i dati firmati pubblicati da un registrant del dominio, cioè la persona o l'organizzazione che controlla la registrazione.

Questi dati DNS autenticati possono inoltre supportare altri sistemi di sicurezza. La revisione di deSEC identifica DANE, ossia DNS-based Authentication of Named Entities, come un'applicazione in grado di utilizzare record convalidati da DNSSEC per associare i servizi alle informazioni sui certificati. Indica inoltre CAA, ossia Certification Authority Authorization, che consente a un dominio di pubblicare quali certificate authority possono emettere certificati per esso. L'argomentazione centrale è che DNSSEC stabilisce una base di trust indipendente da una particolare applicazione o modalità di distribuzione, invece di competere con HTTPS per svolgere lo stesso compito.

La revisione affronta anche due obiezioni più ampie. Una è il timore che una struttura gerarchica di trust possa consentire un controllo statale dall'alto verso il basso sull'accesso alle informazioni. APNIC riconosce che il controllo statale dell'accesso a Internet fa parte dell'esperienza reale di molte persone, ma sostiene che le restrizioni giurisdizionali su siti web, contenuti e servizi online derivino da sistemi giuridici e sociali più ampi, indipendentemente dalla presenza di DNSSEC. Rifiutare DNSSEC non eliminerebbe di per sé tali controlli.

L'altra obiezione riguarda l'adozione incompleta. Un'implementazione parziale limita il numero di domini per i quali è possibile convalidare una chain completa di informazioni firmate, ma scegliere di non implementare la tecnologia non può risolvere tale limite. APNIC paragona il lungo processo di adozione a quello di IPv6 e Resource Public Key Infrastructure, o RPKI, un sistema che permette di autenticare quali reti sono autorizzate ad annunciare route Internet. Tecnologie di questo tipo possono richiedere molto tempo per raggiungere un livello di adozione utile e una massa critica.

L'articolo di deSEC si conclude con più di 60 adesioni da parte di professionisti attivi tra provider DNS, registry, registrar, organizzazioni di supervisione, ricerca e sviluppo di standard. Le adesioni non eliminano la complessità di DNSSEC né il rischio di interruzioni, ma dimostrano che il sostegno si estende a varie parti dell'ecosistema DNS. La conclusione pratica non è che DNSSEC sostituisca TLS, i certificati o una corretta gestione dei domini. È invece che ciascuno protegge un diverso anello della chain che conduce un utente da un nome digitato a un servizio autenticato.

Per i lettori che desiderano anche un servizio DNS privato, AEU DNS offre un DNS privato e sicuro per tutti, mentre DNSSEC rimane il meccanismo separato per autenticare le informazioni DNS firmate. I proprietari di siti web dovrebbero considerare DNSSEC una funzione di sicurezza operativa che richiede una configurazione corretta e un'attenzione costante, non un interruttore che può essere attivato e poi dimenticato.

Termini spiegati

DNSSEC
Domain Name System Security Extensions consente ai sistemi di verificare che le informazioni firmate di un dominio siano autentiche e non siano state modificate.
DNS
Il Domain Name System converte il nome leggibile di un sito web nella destinazione utilizzata dai computer.
TLS
Transport Layer Security cifra una connessione e aiuta a confermare l'identità del server raggiunto.
certificate pinning
Il certificate pinning fa sì che un'applicazione si aspetti un particolare certificato o una specifica identità, invece di accettarne uno qualsiasi ritenuto generalmente attendibile.
Homograph attacks
Gli Homograph attacks utilizzano caratteri visivamente simili per far assomigliare un dominio ingannevole a uno affidabile.
DANE
DNS-based Authentication of Named Entities utilizza record DNS autenticati per associare un servizio online alle informazioni sui certificati.
CAA
Certification Authority Authorization consente a un dominio di indicare quali certificate authority possono emettere certificati per esso.
RPKI
Resource Public Key Infrastructure aiuta a verificare quali reti sono autorizzate ad annunciare determinate route Internet.

Come proteggerti

  1. Chiedi al registrar del tuo dominio o al provider di hosting se DNSSEC può essere abilitato per il tuo dominio e se possono occuparsi della configurazione per te.
  2. Dopo aver cambiato il provider del dominio o le impostazioni DNS, verifica con il provider che le informazioni DNSSEC siano state aggiornate e continuino a corrispondere.
  3. Digita personalmente gli indirizzi dei siti web importanti oppure usa un segnalibro affidabile, invece di aprire link con grafie somiglianti.
  4. Controlla l'indirizzo completo del sito web prima di inserire password o dati di pagamento, anche quando il browser mostra una connessione cifrata.
  5. Se gestisci un sito web aziendale, predisponi il monitoraggio degli errori DNS, in modo da accorgerti rapidamente quando i visitatori non riescono a raggiungere il dominio.
Ottieni un DNS privato e cifrato