Che cos'è il DNS (Domain Name System)?

Spesso viene chiamato "l'elenco del telefono di internet" ma, volendo utilizzare un'analogia più moderna, si può dire che il DNS gestisce i nomi di dominio come uno smartphone gestisce i contatti. Gli smartphone fanno sì che gli utenti non debbano ricordare a memoria i singoli numeri di telefono, salvandoli invece in elenchi di contatti facilmente ricercabili.

Analogamente, il DNS consente agli utenti di connettersi ai siti web utilizzando i nomi di dominio internet invece degli indirizzi IP. Invece di dover ricordare che il server web si trova su "192.0.2.1", ad esempio, gli utenti possono semplicemente andare alla pagina web "www.esempio.com" per ottenere i risultati desiderati.

Per capire come funziona il DNS, è importante prima comprendere i componenti coinvolti.

Fin dall'inizio, il DNS è stato progettato con una struttura di database gerarchica e distribuita per facilitare un approccio più dinamico alla risoluzione dei nomi di dominio, in grado di tenere il passo con una rete di computer in rapida espansione. La gerarchia inizia con il livello principale, indicato da un punto (.), e si ramifica in domini di primo livello (TLD), come ".com", ".org", ".net" o TLD con codice paese (ccTLD) come ".uk" e ".jp", e domini di secondo livello.

Le architetture DNS sono costituite da due tipi di server DNS: server ricorsivi e server autorevoli. I server DNS ricorsivi sono quelli che "chiedono", cercando le informazioni che collegano un utente a un sito web. I server autorevoli forniscono le "risposte".

I server ricorsivi, noti anche come resolver ricorsivi o resolver DNS, sono generalmente gestiti da internet service provider (ISP) o provider di DNS Services di terze parti. Un'organizzazione può anche ospitare e gestire il proprio resolver.

I resolver ricorsivi agiscono per conto dell'utente finale per risolvere il nome di dominio in un indirizzo IP. Inoltre, i resolver ricorsivi memorizzano nella cache (immagazzinano temporaneamente i risultati delle recenti ricerche DNS) le risposte a una richiesta per un periodo di tempo specifico (definito dal valore time-to-live, o TTL) per migliorare l'efficienza del sistema per le future query allo stesso dominio.

Quando un utente digita un indirizzo web in un browser, il browser si connette a un server DNS ricorsivo per risolvere la richiesta. Se il server ricorsivo ha la risposta memorizzata nella cache, può connettere l'utente e completare la richiesta. Altrimenti, il resolver ricorsivo interroga la gerarchia DNS fino a trovare i record A (o AAAA) contenenti l'indirizzo IP di un determinato dominio.

I nameserver autorevoli conservano i record definitivi per un dominio e rispondono alle richieste relative ai nomi di dominio memorizzati all'interno delle rispettive zone (in genere, con risposte configurate dal proprietario del dominio). Esistono diversi server autorevoli, ciascuno responsabile di una parte distinta del namespace.

I root nameserver si trovano in cima alla gerarchia DNS e sono responsabili del servizio della zona root (il database centrale per il DNS). Esistono 13 "identità" o "autorità" di root nameserver (raggruppamenti logici di root server) identificate dalle lettere da A a M. Rispondono alle query per i record memorizzati nella zona root e indirizzano le richieste al name server TLD appropriato.

I server TLD sono responsabili della gestione del livello successivo della gerarchia, inclusi i domini di primo livello generici (gTLD). I nameserver TLD indirizzano le query ai nameserver autoritativi per i domini specifici all'interno del loro TLD. Quindi, il name server TLD per ".com" indirizzerebbe i domini che terminano in ".com", il name server TLD per ".gov" indirizzerebbe i domini che terminano in ".gov" e così via.

I server di nomi di dominio di secondo livello (la maggior parte dei server di nomi di dominio) conservano il file di zona con l'indirizzo IP del nome di dominio completo (ad esempio, "ibm.com").

Oltre ai principali tipi di server, il DNS utilizza i file di zona e diversi tipi di record per agevolare il processo di risoluzione. I file di zona sono file basati su testo che includono mappature e informazioni su domini specifici all'interno di una zona DNS.

Ogni riga di un file di zona specifica un record di risorse DNS (una singola informazione sulla natura di un particolare tipo o segmento di dati). I record delle risorse aiutano a garantire che, quando un utente invia una query, il DNS possa convertire rapidamente i nomi di dominio in informazioni fruibili che indirizzano le query al server corretto.

I file di zona DNS iniziano con due record obbligatori: il record nameserver (NS), che indica il name server autorevole per un dominio, e il record start of authority (SOA), che specifica il nameserver autorevole primario per la zona DNS.

Dopo i due record principali, un file di zona può contenere diversi altri tipi di record. Eccone alcuni:

Ogni query (a volte chiamata richiesta DNS) segue la stessa logica per risolvere gli indirizzi IP. Esistono diversi modi in cui vengono avviate le query; ad esempio, consideriamo una persona che utilizza un browser web.

Quando l'utente inserisce un URL nel proprio browser web, il browser invia la query al risolutore DNS, che interroga progressivamente i server DNS autorevoli per localizzare l'authoritative DNS che contiene i record del dominio, incluso l'indirizzo associato. L'indirizzo IP viene restituito al browser e l'utente è connesso al sito web.

Più nello specifico, la risoluzione delle query nel DNS coinvolge diversi processi e componenti chiave

• Avvio della query. Un utente immette un nome di dominio, ad esempio "ibm.com", in un browser o un'app. Se l'indirizzo IP del sito in questione non è nella cache del browser, la richiesta viene inviata a un risolutore DNS ricorsivo. In genere, il dispositivo dell'utente dispone di impostazioni DNS predefinite, fornite dall'ISP, che determinano quale resolver ricorsivo riceve la richiesta.
  
  *Questo processo è in continua evoluzione, poiché molti browser moderni supportano il DNS over HTTPS (DoH), che consente la risoluzione DNS tramite HTTPS, e molti provider dispongono di server configurati per questo tipo di risoluzione. Ad esempio, se si utilizza Firefox negli Stati Uniti, per impostazione predefinita la query verrà inviata a un server DoH Cloudflare anziché al resolver del provider di servizi Internet locale. Il DoH sta diventando sempre più popolare perché offre maggiore privacy, migliori prestazioni e altri benefici.

• Resolver ricorsivo. Il risolver ricorsivo controlla la cache per l'indirizzo IP corrispondente del dominio. Se il resolver ricorsivo non dispone dei record necessari nella cache, avvia il processo di ricerca, a partire dal server principale.

• Server dei nomi radice. Il resolver ricorsivo interroga un root nameserver, che risponde con un rinvio al server TLD appropriato per il dominio in questione (il TLD name server responsabile, in questo caso, per i domini ".com").

• Nameserver TLD. Il resolver interroga il nameserver TLD ".com", che risponde con l'indirizzo del nameserver autorevole per "ibm.com".

• Server dei nomi di dominio. Il resolver interroga il nameserver del dominio, che cerca il file di zona DNS e risponde con il record corretto per il nome di dominio fornito.

• Risoluzione delle query. Il resolver ricorsivo restituisce l'indirizzo IP al dispositivo dell'utente. Il browser o l'app possono quindi avviare una connessione al server host a quell'indirizzo IP e accedere al sito web o al servizio richiesto. Il browser e il resolver memorizzano nella cache i record in base alle rispettive configurazioni e ai TTL.

Il DNS è fondamentalmente un protocollo pubblico. I DNS pubblici e privati non sono necessariamente termini e concetti esatti e universalmente usati e compresi, e il loro utilizzo è spesso impreciso.

Il DNS pubblico viene spesso utilizzato per riferirsi al processo di risoluzione DNS "standard", o resolver DNS pubblico, in cui un resolver ricorsivo interroga una serie di server autorevoli che contengono record DNS pubblicamente disponibili per individuare un indirizzo IP e, infine, connettere un utente al sito web che sta cercando. Spesso si tratta di un resolver fornito dal provider di servizi Internet (ISP) dell'utente o da un servizio DNS Services come il DNS pubblico "quad 8" di Google. I resolver privati possono anche essere configurati per interrogare il DNS pubblico, ma sono più comunemente utilizzati per reti limitate o aziendali.

Questa ricerca DNS standard viene probabilmente definita DNS pubblico a causa dei resolver disponibili pubblicamente e del fatto che i record DNS su questi server autorevoli sono accessibili a chiunque abbia accesso a Internet.

L'uso del "DNS privato" è ancora più confuso. A volte viene utilizzato per descrivere l'uso di protocolli di crittografia come DNS over TLS (DoT) o DNS over HTTPS (DoH). Tuttavia, tutto questo è descritto più accuratamente come "caratteristiche di privacy" o "protocolli di privacy" piuttosto che come "DNS privato". Il processo di risoluzione rimane lo stesso, in quanto un resolver utilizza il DNS pubblico per trovare ciò di cui ha bisogno. In questo caso, viene eseguito solo con un trasferimento crittografato.

Il DNS privato viene anche utilizzato per riferirsi alla ricerca all'interno di una rete interna chiusa, come reti aziendali o cloud privati virtuali, con accesso limitato agli utenti autorizzati. In un sistema del genere, i resolver privati configurati localmente interrogano i server privati per localizzare risorse e siti all'interno di una rete interna. Questi server sono configurati per servire solo zone private e indirizzi IP interni e la rete mantiene gli URL e gli indirizzi IP interni nascosti al resto di Internet. Questo tipo di DNS privato offre alle organizzazioni maggiore controllo e sicurezza.

Esistono molti modi per configurare questo tipo di rete, ad esempio attraverso un dominio per uso speciale come .local utilizzato per la risoluzione sulle reti locali. Un altro è avere sottodomini privati di domini pubblicamente disponibili su internet. Questo sottodominio privato sarebbe disponibile solo per individui o agenti che utilizzano dei resolver all'interno della rete interna.

Una configurazione aziendale comune che combina DNS "pubblico" e "privato" è chiamata "split-horizon DNS", o "split brain DNS". In questa configurazione, è presente un recursor locale che interroga i server autorevoli locali e privati per le richieste interne e si basa sul DNS standard per le query esterne. Solitamente esiste un elenco di nomi di dominio, una sorta di "lista di autorizzazione", che indica al server quali richieste devono essere indirizzate ai server interni e quali inoltrate a Internet.

Il DNS gestito è un servizio di terze parti che consente a un'organizzazione di esternalizzare l'hosting, le operazioni e la gestione della propria infrastruttura DNS. Con il DNS gestito, i record di authoritative DNS per i domini di un'organizzazione sono ospitati sulla rete di server distribuita globalmente del fornitore. In molti casi, i provider di DNS gestiti offrono un control plane, una dashboard o delle API che consentono ai clienti di gestire e automatizzare i propri record DNS e altre impostazioni.

I DNS Services gestiti spesso forniscono caratteristiche come routing Anycast, bilanciamento del carico, accordi sul livello di servizio (SLA) del tempo di attività, protezione dal failover, DNSSEC e strumenti di monitoraggio e risoluzione dei problemi che possono consentire una risoluzione del dominio più rapida, affidabile e sicura rispetto alle tradizionali configurazioni DNS autogestite.

Anche i migliori sistemi DNS possono essere vulnerabili a problemi di cybersecurity. Gli attacchi correlati al DNS includono:

Lo spoofing DNS (detto anche cache poisoning), che si verifica quando un utente malintenzionato inserisce record di indirizzi falsi nella cache di un resolver DNS, facendo sì che il resolver restituisca un indirizzo IP errato e reindirizzi gli utenti su siti dannosi. Lo spoofing può compromettere i dati sensibili e portare ad attacchi di phishing e distribuzione di malware.

L'amplificazione DNS è un tipo di attacco distributed denial-of-service (DDoS) in cui un aggressore invia piccole query a un server DNS con l'indirizzo di ritorno spoofed all'indirizzo IP della vittima. Questi attacchi approfittano della natura stateless dei protocolli DNS e del fatto che una piccola query può generare una risposta esterna.

A seguito di un attacco di amplificazione, il server DNS risponde con risposte molto più grandi, il che amplifica la quantità di traffico diretto all'utente, sovraccaricandone le risorse. Ciò può impedire il funzionamento del DNS e bloccare l'applicazione.

Il tunneling DNS è una tecnica utilizzata per bypassare le misure di sicurezza incapsulando il traffico non DNS, come HTTP, all'interno di query e risposte DNS. Gli aggressori possono utilizzare i tunnel DNS per inoltrare comandi malware o per esfiltrare informazioni DNS da una rete compromessa, spesso codificando il payload all'interno delle query e delle risposte DNS per evitare il rilevamento.

Le voci DNS trascurate per i sottodomini che puntano a servizi dismessi sono obiettivi primari per gli aggressori. Se un servizio (ad esempio un host cloud) è stato disattivato ma la voce DNS rimane, un utente malintenzionato può potenzialmente rivendicare il sottodominio e configurare un sito o un servizio dannoso al suo posto.

Indipendentemente dai DNS Services scelti da un'organizzazione, è importante implementare i protocolli di sicurezza per ridurre al minimo le superfici di attacco DNS, mitigare i potenziali problemi di sicurezza e ottimizzare il DNS nei processi di rete. Alcune pratiche utili per consolidare la sicurezza DNS includono:

• Implementazione delle estensioni di sicurezza DNS (DNSSEC). Il DNSSEC aggiunge un ulteriore livello di sicurezza alle query DNS, richiedendo che le risposte DNS siano firmate digitalmente. Il DNSSEC può proteggere dagli attacchi di spoofing del DNS autenticando l'origine delle richieste e verificando l'integrità dei dati DNS.

• Adottare procedure di limitazione della velocità. Limitando la velocità sui server DNS è possibile mitigare gli attacchi DDoS, riducendo il numero di risposte o la velocità con cui i server inviano le risposte a un singolo richiedente in un determinato periodo di tempo.

• Richiedere l'autenticazione a due fattori (2FA) per i registrar di dominio. L'implementazione dell'autenticazione a due fattori (2FA) per gli account dei registrar di dominio può rendere più difficile per gli aggressori ottenere l'accesso non autorizzato ai server e riduce il rischio di hijacking del dominio.

• Utilizzo delle ridondanze. Distribuire il DNS in una configurazione ridondante su diversi server geograficamente disseminati può aiutare a garantire la disponibilità della rete in caso di attacco o interruzione. Se il server primario non funziona, i server secondari possono assumere il controllo dei servizi di risoluzione DNS.

• Implementazione del flush DNS. L'eliminazione della cache DNS rimuove tutte le voci dalla rete locale, e questo può essere utile per eliminare record DNS non validi o compromessi che potrebbero indirizzare gli utenti a siti dannosi. In genere, si tratta di un servizio on-demand fornito dall'operatore del resolver. In caso contrario, le cache vengono eliminate con la scadenza dei TTL.
  
  
• Rimanere informati sulle minacce DNS. Gli aggressori e le minacce alla sicurezza si evolvono più o meno di pari passo con i sistemi che compromettono. Rimanere al passo con le ultime vulnerabilità e minacce DNS aiuta i team a non farsi superare dagli aggressori.

Prima del DNS, internet era una rete di computer in crescita, utilizzata principalmente da istituzioni accademiche e di ricerca. Gli sviluppatori hanno mappato manualmente i nomi host sugli indirizzi IP utilizzando semplici file di testo chiamati HOSTS.TXT, gestiti da SRI International e distribuiti su tutti i computer su Internet. Tuttavia, con l'espansione della rete, questo approccio è diventato sempre più insostenibile.

Per affrontare le limitazioni di HOSTS.TXT e creare un sistema più scalabile, Paul Mockapetris, computer scientist della University of Southern California, inventò il sistema di nomi di dominio nel 1983. Il gruppo di pionieri di Internet che ha contribuito alla creazione del DNS ha anche redatto le prime richieste di commenti (RFC) che specificavano le caratteristiche del nuovo sistema, ovvero le RFC 882 e RFC 883. RFC 1034 e RFC 1035 hanno poi sostituito le precedenti RFC.

Col tempo, con l'espansione del DNS, la gestione del DNS è diventata responsabilità dell'Internet Assigned Numbers Authority (IANA), prima di passare infine sotto il controllo dell'organizzazione no-profit Internet Corporation for Assigned Names and Numbers (ICANN), nel 1998.