Come proteggere il DNS: DNSSEC, DoH, DoT, filtering e sicurezza del dominio

Nel primo episodio di questa serie abbiamo imparato a leggere una URL. Abbiamo visto che un link non e solo qualcosa da cliccare, ma una piccola istruzione tecnica fatta di protocollo, dominio, path, query string, parametri e frammenti.

Nel secondo episodio siamo scesi sotto quel livello e ci siamo chiesti: quando scriviamo www.scrivocodice.it, come fa il computer a sapere quale server contattare? La risposta era il DNS, il sistema che traduce nomi leggibili in indirizzi IP.

Ora facciamo il passo successivo: se il DNS ti dice dove andare, che cosa succede se quella risposta viene osservata, bloccata o manipolata?

Questa e la domanda centrale quando parliamo di sicurezza DNS. Il DNS e comodo, veloce e spesso invisibile, ma proprio perche entra in gioco all’inizio della navigazione e anche una parte delicata dell’infrastruttura web.

In questo articolo vediamo come proteggere il DNS con tecnologie e pratiche come DNSSEC, DNS over HTTPS, DNS over TLS, DNS filtering, Anycast, rate limiting e controllo degli account che gestiscono il dominio.

Il DNS come superficie di sicurezza

Quando il tuo computer chiede:

Qual e l'indirizzo IP di scrivocodice.it?

vuoi almeno tre cose.

Prima: vuoi che la risposta arrivi. Questa e la disponibilita.

Seconda: vuoi che la risposta sia corretta. Questa e l’integrita.

Terza: vuoi che la richiesta non venga osservata o manipolata facilmente. Questa e la riservatezza.

Disponibilita, integrita e riservatezza sono tre concetti classici della sicurezza informatica. Applicati al DNS diventano molto concreti: se il DNS non risponde, il sito sembra non funzionare; se la risposta e alterata, l’utente puo essere mandato nel posto sbagliato; se la richiesta e visibile, qualcuno puo ricostruire una parte delle abitudini di navigazione.

Per questo il DNS non e solo una “rubrica di Internet”. E un livello di controllo tecnico, operativo e di sicurezza.

Prima di proteggere il DNS, bisogna saperlo osservare

Una cosa importante da chiarire subito: non tutte le distribuzioni Linux gestiscono il DNS nello stesso modo. Alcune usano systemd-resolved, altre NetworkManager, altre ancora scrivono direttamente la configurazione in /etc/resolv.conf.

Se provi:

resolvectl status

e ricevi un errore del tipo:

Failed to connect to service /run/systemd/resolve/io.systemd.Resolve

non significa necessariamente che hai sbagliato comando o che serva sudo. Significa che su quella macchina systemd-resolved non e attivo, oppure non e il componente che sta gestendo il DNS.

Il punto di partenza piu semplice e:

cat /etc/resolv.conf

Se vedi qualcosa come:

nameserver 192.168.1.1

vuol dire che il primo interlocutore DNS della tua macchina e probabilmente il router di casa. Il computer chiede al router; poi il router chiede ai resolver configurati dall’operatore o impostati manualmente.

Se il sistema usa NetworkManager, puoi controllare anche i DNS associati alle interfacce di rete:

nmcli dev show | grep DNS

Il messaggio e semplice: il DNS non e magia. E configurazione.

Risolvere un dominio, non una URL intera

Il DNS non risolve una URL completa. Se la URL e:

https://www.scrivocodice.it/blog/come-funziona-dns/

la parte che interessa al DNS e il nome host:

www.scrivocodice.it

Per vedere come il sistema risolverebbe un nome puoi usare:

getent hosts scrivocodice.it

Questo comando passa dalla configurazione locale, dalla cache, dal resolver e dalle regole del sistema.

Se hai dig installato, puoi ottenere piu dettagli:

dig scrivocodice.it

Con dig puoi osservare risposta, tipo di record, tempo di risposta, server che ha risposto e TTL. Per una visualizzazione rapida:

dig +short scrivocodice.it

Puoi anche confrontare resolver diversi:

dig scrivocodice.it
dig @1.1.1.1 scrivocodice.it
dig @8.8.8.8 scrivocodice.it
dig @9.9.9.9 scrivocodice.it

Questo confronto e utile perche quando diciamo “il DNS” stiamo parlando anche di chi risponde alla nostra domanda. Cambiando resolver possono cambiare tempi, cache, filtri, policy e comportamento visibile all’utente.

Integrita: come sapere se la risposta DNS e corretta

Il primo problema di sicurezza e l’integrita.

Come facciamo a sapere che la risposta DNS ricevuta e davvero quella pubblicata dal proprietario del dominio?

Immagina di scrivere correttamente il dominio della tua banca, ma di ricevere un indirizzo IP sbagliato. Tu pensi di andare nel posto giusto, ma qualcuno ti sta indirizzando altrove.

Questo tipo di scenario si collega a concetti come spoofing, avvelenamento della cache, manipolazioni locali, router compromessi o resolver non affidabili.

Qui entra in gioco DNSSEC.

DNSSEC significa Domain Name System Security Extensions. Attenzione pero: DNSSEC non serve principalmente a cifrare le richieste DNS e non nasce per nascondere quale dominio stai cercando. DNSSEC serve a firmare crittograficamente le risposte DNS, in modo che un resolver possa verificare se una risposta e autentica e non alterata.

Una metafora utile e il sigillo su una lettera. Il sigillo non rende necessariamente segreto il contenuto, ma aiuta a capire se qualcuno lo ha modificato.

Con dig puoi vedere se una zona espone informazioni DNSSEC usando:

dig +dnssec cloudflare.com

Nel risultato potresti vedere record come RRSIG, cioe firme DNSSEC. Puoi anche chiedere un record specifico:

dig DNSKEY cloudflare.com

Il record DNSKEY fa parte del meccanismo usato da DNSSEC per costruire la catena di fiducia.

DNSSEC, pero, non e una bacchetta magica. Deve essere configurato bene, non tutti i domini lo usano e una configurazione sbagliata puo rendere un dominio non risolvibile per i resolver che validano DNSSEC.

Questa e una lezione importante: una misura di sicurezza mal gestita puo diventare un problema operativo.

Riservatezza: perche il DNS puo rivelare molto

Il secondo problema e la riservatezza.

Storicamente, molte richieste DNS viaggiano in chiaro. Questo significa che qualcuno lungo il percorso, per esempio una rete Wi-Fi non fidata, un provider o un apparato intermedio, puo vedere quali domini stai risolvendo.

Anche se poi il sito usa HTTPS, la richiesta DNS puo rivelare molto. Magari non mostra la pagina esatta che stai leggendo, ma mostra il dominio. Se risolvi il dominio della posta, della banca o di un servizio medico, stai gia lasciando tracce significative.

Per ridurre questo problema esistono DNS over HTTPS e DNS over TLS.

DNS over HTTPS, spesso abbreviato DoH, incapsula le richieste DNS dentro HTTPS. In pratica, il traffico DNS viaggia cifrato verso un resolver che supporta DoH.

DNS over TLS, o DoT, usa invece TLS direttamente per proteggere la comunicazione DNS su una porta dedicata.

Possiamo fare un esempio pratico con curl, interrogando un resolver DoH pubblico:

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=scrivocodice.it&type=A'

Qui non stiamo usando il DNS tradizionale configurato nel sistema. Stiamo facendo una richiesta HTTPS a un servizio che risponde con dati DNS in formato JSON.

Questo non e il modo in cui normalmente navighi, ma e un esempio utile per vedere l’idea: una richiesta DNS puo viaggiare dentro HTTPS.

DoH e DoT non eliminano la fiducia: la spostano

DoH e DoT proteggono il tratto tra il tuo dispositivo e il resolver scelto. Non rendono anonima tutta la navigazione. Il resolver scelto puo comunque vedere le richieste.

Quindi la domanda corretta non e:

Con DoH sono invisibile?

La domanda corretta e:

Di chi mi sto fidando?

Ti fidi del resolver del provider? Di un resolver pubblico? Di un resolver aziendale? Di un resolver configurato da te?

La sicurezza non elimina la fiducia. La sposta.

In casa, scegliere un resolver affidabile, magari con protezioni contro malware e phishing, puo avere senso. In azienda, pero, il discorso cambia: il DNS e spesso usato anche per logging, policy, incident response e protezione da domini malevoli.

Se ogni browser o applicazione usa un resolver DoH diverso, l’azienda puo perdere visibilita su una parte importante del traffico. Questo non significa che DoH sia sbagliato. Significa che il contesto conta.

DNS filtering: bloccare domini malevoli prima della connessione

Un’altra misura molto pratica e il DNS filtering.

Il DNS filtering blocca o modifica le risposte verso domini considerati pericolosi: phishing, malware, command and control, truffe, contenuti indesiderati.

Immagina un utente che riceve una mail di phishing. Clicca il link. Prima che il browser apra il sito, il computer deve risolvere il dominio. Se il resolver usa liste di blocco aggiornate e quel dominio e gia noto come malevolo, la richiesta puo essere bloccata.

Non e una protezione perfetta. Un dominio appena creato potrebbe non essere ancora classificato. Un attaccante puo cambiare dominio rapidamente. Un link puo usare servizi legittimi compromessi.

Pero il DNS filtering e un buon livello difensivo, soprattutto per utenti non tecnici, famiglie, scuole e piccole aziende.

In ambienti gestiti esistono anche le Response Policy Zones, spesso abbreviate in RPZ. Sono meccanismi che permettono di applicare policy DNS: bloccare, riscrivere o controllare risposte in base a regole definite dall’organizzazione.

QNAME minimization: condividere meno informazioni

Un concetto meno conosciuto, ma importante, e la QNAME minimization.

Il nome sembra complicato, ma l’idea e abbastanza elegante: quando un resolver cerca informazioni DNS, non dovrebbe rivelare piu del necessario a ogni livello della gerarchia.

Se vuoi risolvere www.blog.example.com, un root server non ha bisogno di sapere tutto il nome completo. Gli basta sapere che stai cercando qualcosa sotto .com. Il server del TLD .com non ha bisogno di sapere tutti i dettagli finali se deve solo indirizzarti ai nameserver di example.com.

QNAME minimization riduce la quantita di informazione inviata ai server intermedi. Non risolve tutti i problemi di privacy, ma e un miglioramento concreto: meno dati condivisi dove non servono.

Disponibilita: Anycast DNS e rate limiting

Il DNS deve rispondere rapidamente e in modo affidabile. Se un resolver non funziona, se i nameserver autoritativi sono irraggiungibili o se il dominio e configurato male, l’utente vede semplicemente “il sito non va”.

Una tecnologia importante per la disponibilita e Anycast DNS.

Con Anycast, lo stesso indirizzo IP puo essere annunciato da piu nodi distribuiti nel mondo. Quando fai una richiesta, la rete ti porta verso un nodo vicino o piu conveniente. Se un nodo ha problemi, altri nodi possono continuare a rispondere.

Questo migliora velocita, resilienza e capacita di assorbire traffico, anche in scenari di attacco DDoS.

Un’altra tecnica utile e il rate limiting. Il DNS puo essere sfruttato in attacchi di amplificazione: un attaccante invia richieste falsificando l’indirizzo della vittima e sfrutta server DNS mal configurati per generare molte risposte verso quella vittima.

Il rate limiting aiuta a ridurre questo tipo di abuso, limitando risposte e comportamenti sospetti.

Proteggere il dominio e importante quanto proteggere il server

Una piccola azienda ha un sito, una posta aziendale e un gestionale cloud. Il dominio e stato registrato anni prima da un consulente. Le credenziali del pannello DNS sono condivise in modo informale. La MFA non e attiva. Nel tempo sono stati aggiunti record vecchi, CNAME verso servizi abbandonati, record TXT per verifiche non piu necessarie, sottodomini di test mai rimossi.

Tutto funziona, quindi nessuno guarda piu quella configurazione.

Poi un giorno iniziano i problemi: alcuni clienti ricevono email strane, un sottodominio porta a una pagina sospetta, la posta finisce in spam, il sito sembra comportarsi in modo incoerente.

Il problema potrebbe non essere nel codice dell’applicazione. Potrebbe essere nel controllo debole del dominio.

Questa e una lezione importante della sicurezza moderna: non basta proteggere il server web e non basta scrivere codice sicuro. Bisogna proteggere anche l’infrastruttura che porta gli utenti verso quel codice.

Chi controlla il dominio controlla una parte enorme della fiducia.

Checklist minima per un dominio importante

Per un dominio aziendale o professionale, una checklist minima dovrebbe includere:

• sapere chi ha accesso al registrar;
• attivare MFA sugli account del registrar e del provider DNS;
• usare email amministrative protette;
• tenere un inventario dei record DNS;
• rimuovere sottodomini non usati;
• controllare CNAME verso servizi esterni;
• configurare correttamente SPF, DKIM e DMARC per la posta;
• valutare DNSSEC quando si ha la capacita di gestirlo;
• monitorare modifiche inattese ai record.

Queste attivita sembrano amministrative, ma sono sicurezza applicata.

Cosa significa per utenti, sviluppatori e aziende

Per un utente normale, proteggere il DNS significa evitare configurazioni casuali, aggiornare router e dispositivi, non installare profili DNS o VPN suggeriti da app sconosciute e capire che “cambiare DNS” non e solo un trucco per rendere Internet piu veloce.

E una scelta di fiducia.

Per uno sviluppatore, significa configurare bene i record del proprio dominio, usare TTL sensati, proteggere l’accesso al registrar e al provider DNS, attivare MFA sugli account critici e valutare DNSSEC quando appropriato.

Per una piccola azienda, significa non ignorare il DNS nella strategia di sicurezza: logging, filtering, protezione del dominio, controllo dei nameserver, inventario dei record e procedure di recupero account.

In azienda, la risposta non e semplicemente “attiviamo DoH ovunque”. A volte serve centralizzare il DNS per applicare policy, individuare malware, ricostruire incidenti e proteggere gli utenti. L’obiettivo non e usare la sigla piu moderna, ma progettare un equilibrio tra privacy, controllo, logging e protezione.

Una sequenza pratica di comandi

Per sviluppare consapevolezza, puoi partire da questi comandi:

cat /etc/resolv.conf
nmcli dev show | grep DNS
getent hosts scrivocodice.it
dig scrivocodice.it
dig +short scrivocodice.it
dig +dnssec cloudflare.com
dig @1.1.1.1 scrivocodice.it

Non servono per “hackerare” nulla. Servono per vedere che dietro un dominio c’e una risposta, dietro la risposta c’e un resolver, dietro il resolver c’e una catena di fiducia e di configurazioni.

Conclusione

Il DNS non e solo “quello che fa funzionare i nomi dei siti”. E un livello di controllo.

Controllo tecnico, perche decide dove vengono indirizzate le richieste.

Controllo di sicurezza, perche puo bloccare domini malevoli.

Controllo di privacy, perche puo rivelare abitudini di navigazione.

Controllo operativo, perche una configurazione sbagliata puo interrompere servizi.

La domanda corretta non e:

Quale tecnologia devo attivare per essere sicuro?

La domanda corretta e:

Quale rischio sto cercando di ridurre, in quale contesto, con quale costo operativo?

Nel web la fiducia non inizia quando inserisci la password.

Inizia molto prima.

Inizia quando il tuo computer chiede:

Dove si trova questo dominio?