Panoramica DNS

Il Sistema dei Nomi di Dominio (DNS) è la 'rubrica dell'Internet'. Il DNS traduce i nomi di dominio in indirizzi IP, così che i browser e altri servizi possano caricare le risorse di Internet, tramite una rete decentralizzata di server.

Cos'è il DNS?

Quando visiti un sito web, è restituito un indirizzo numerico. Ad esempio, quando visiti privacyguides.org, viene restituito l'indirizzo 192.98.54.105.

Il DNS esiste dagli albori di Internet. Le richieste DNS da e verso i server DNS non sono generalmente crittografate. In un ambiente residenziale, un cliente riceve dei server dall'ISP tramite DHCP.

Le richieste DNS non crittografate sono facilmente sorvegliabili e modificabili durante il transito. In alcune parti del mondo, gli ISP devono eseguire un primitivo filtraggio DNS. Quando richiedi il blocco dell'indirizzo IP di un dominio, il server potrebbe non rispondere o fornire un indirizzo IP differente. Poiché il protocollo DNS non è crittografato, l'ISP (o qualsiasi operatore della rete), può utilizzare la DPI per monitorare le richieste. Gli ISP possono inoltre bloccare le richieste secondo caratteristiche comuni, indipendentemente da quale server DNS è utilizzato.

Di seguito, discutiamo e forniamo un tutorial per provare ciò che un osservatore esterno possa vedere, utilizzando il DNS non crittografato e il DNS crittografato.

DNS non crittografato

Utilizzando tshark (parte del progetto Wireshark) possiamo monitorare e registrare il flusso di pacchetti Internet. Il comando registra i pacchetti che soddisfano le regole specificate:
```
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
```
Quindi, possiamo utilizzare dig (Linux, MacOS, etc.) o nslookup (Windows) per inviare la ricerca DNS a entrambi i server. I software come i browser web, svolgono automaticamente tali ricerche, a meno che non siano configurati per utilizzare il DNS crittografato.
Linux, macOSWindows
dig +noall +answer privacyguides.org @1.1.1.1 dig +noall +answer privacyguides.org @8.8.8.8
nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8
Successivamente, vogliamo analizzare i risultati:
Wiresharktshark
wireshark -r /tmp/dns.pcap
tshark -r /tmp/dns.pcap

Se esegui il comando di Wireshark precedente, il pannello superiore mostra i "quadri", mentre quello inferiore mostra tutti i dati sul quadro selezionato. Le soluzioni di filtraggio e monitoraggio aziendali (come quelle acquistate dai governi), possono svolgere il processo automaticamente, senza l'interazione umana, e possono aggregare tali quadri per produrre dati statistici, utili all'osservatore della rete.

N.	Tempo	Sorgente	Destinazione	Protocollo	Lunghezza	Info
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Standard query 0x58ba A privacyguides.org OPT
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Standard query 0xf1a9 A privacyguides.org OPT
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT

Un osservatore potrebbe modificare uno qualsiasi di questi pacchetti.

Cos'è il "DNS crittografato"?

Il DNS cifrato può fare riferimento a uno dei diversi protocolli, i più comuni dei quali sono DNSCrypt, DNS over TLS e DNS over HTTPS.

DNSCrypt

DNSCrypt fu uno dei primi metodi per la crittografia delle richieste DNS. DNSCrypt opera sulla porta 443 e funziona con entrambi i protocolli di trasporto TCP e UDP. DNSCrypt non è stato mai inviato alla Task Force Ingegneristica di Internet (IETF), né ha superato il processo di Richiesta dei Commenti (RFC), quindi non è stato utilizzato ampiamente, al di fuori di poche implementazioni. Di conseguenza, è stato ampiamente sostituito dal più popolare DNS-over-HTTPS.

DNS-over-TLS (DoT)

DNS-over-TLS è un altro metodo per crittografare le comunicazioni DNS, definito in RFC 7858. Il supporto è stato implementato per la prima volta in Android 9, iOS 14 e su Linux nella versione 237 di systemd-resolved. La preferenza nel settore è stata allontanarsi dal DoT al DoH negli ultimi anni, poiché DoT è un protocollo complesso, avente una conformità variabile al RFC tra le implementazioni che esistono. Inoltre, DoT opera su una porta 853 dedicata, facilmente bloccabile dai firewall restrittivi.

DNS-over-HTTPS (DoH)

DNS over HTTPS, come definito nell'RFC 8484, impacchetta le query nel protocollo HTTP/2 e garantisce la sicurezza con HTTPS. Il supporto è stato aggiunto per la prima volta nei browser web come Firefox 60 e Chrome 83.

L'implementazione nativa di DoH è arrivata su iOS 14, macOS 11, Microsoft Windows e Android 13 (tuttavia, non sarà abilitata di default). Il supporto generale per i desktop Linux è in attesa dell'implementazione di systemd, quindi è necessario installare un software di terze parti.

Supporto Nativo del Sistema Operativo

Android

Android 9 e successive supportano il 'DNS over TLS'. Le impostazioni si possono trovare in: Impostazioni → Rete e Internet → DNS Privato.

Dispositivi Apple

Le versioni più recenti di iOS, iPadOS, tvOS e macOS, supportano sia DoT che DoH. Entrambi i protocolli sono supportati nativamente tramite i profili di configurazione o tramite l'API delle Impostazioni DNS.

Dopo l'installazione di un profilo di configurazione o di un'app che utilizza l'API delle Impostazioni DNS, è possibile selezionare la configurazione DNS. Se una VPN è attiva, la risoluzione nel tunnel VPN utilizzerà le impostazioni DNS della VPN e non le impostazioni di sistema.

Apple non fornisce un'interfaccia nativa per la creazione di profili DNS crittografati. Secure DNS profile creator è uno strumento non ufficiale per creare i propri profili DNS crittografati, tuttavia, non saranno firmati. I profili firmati sono da preferire; la firma convalida l'origine di un profilo e contribuisce a garantire l'integrità. Un'etichetta verde "Verificato" è data ai profili di configurazione firmati. Per ulteriori informazioni sulla firma del codice, consulta Informazioni sulla firma del codice.

Linux

systemd-resolved, che molte distribuzioni Linux usano per eseguire le ricerche DNS, non supporta ancora DoH. Se vuoi utilizzare DoH, è necessario installare un proxy come dnscrypt-proxy e configurarlo per intercettare tutte le query DNS dal tuo resolver di sistema e inoltrarle su HTTPS.

Cosa può vedere una parte esterna?

In questo esempio registreremo cosa si verifica quando effettuiamo una richiesta DoH:

Prima di tutto, avvia tshark:

tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"

Poii, effettua una richiesta con curl:

curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org

Dopo aver effettuato la richiesta, possiamo interrompere la cattura del pacchetto con CTRL + C.
Analizza i risultati su Wireshark:
```
wireshark -r /tmp/dns_doh.pcap
```

Possiamo vedere la creazione della connessione e l'handshake TLS che si verifica con qualsiasi connessione crittografata. Osservando i successivi pacchetti di "dati dell'applicazione", nessuno di essi contiene il dominio richiesto o l'indirizzo IP restituito.

Perché non dovrei utilizzare il DNS crittografato?

Nei luoghi in cui esiste il filtraggio (o censura) di Internet, visitare le risorse proibite potrebbe avere delle conseguenze, che dovresti considerare nel tuo modello di minaccia. Noi non suggeriamo di utilizzare il DNS crittografato per tale scopo. Utilizza invece Tor o una VPN. Se stai utilizzando una VPN, dovresti utilizzare i server DNS della tua VPN. Utilizzando una VPN, stai già affidando loro tutta la tua attività di rete.

Quando effettuiamo una ricerca DNS, generalmente è perché desideriamo accedere a una risorsa. Di seguito, discuteremo di alcuni dei metodi che potrebbero divulgare le tue attività di navigazione, anche utilizzando il DNS crittografato:

Indirizzo IP

Il metodo più semplice per determinare l'attività di navigazione, potrebbe essere quello di esaminare gli indirizzi IP accessibili ai tuoi dispositivi. Ad esempio, se l'osservatore sa che privacyguides.org si trova a 198.98.54.105 e il tuo dispositivo sta richiedendo dei dati da 198.98.54.105, è molto probabile che tu stia visitando Privacy Guides.

Questo metodo è utile soltanto quando l'indirizzo IP appartiene a un server che ospita soltanto alcuni siti web. Non è molto utile se il sito è ospitato su una piattaforma condivisa (es., GitHub Pages, Cloudflare Pages, Netlify, WordPress, Blogger, ecc.). Inoltre, non è molto utile se il server è ospitato dietro un proxy inverso, molto comune sull'Internet moderno.

Indicazione del Nome del Server (SNI)

L'Indicazione del Nome del Server è tipicamente utilizzata quando un indirizzo IP ospita molti siti web. Potrebbe trattarsi di un servizio come Cloudflare, o di qualche altra protezione dagli attacchi di Denial-of-service.

Riavvia la cattura con tshark. Abbiamo aggiunto un filtro con il nostro indirizzo IP, così che tu non catturi molti pacchetti:
```
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
```
Quindi, visitiamo https://privacyguides.org.
Dopo aver visitato il sito web, vogliamo interrompere la cattura dei pacchetti con CTRL + C.
Poi, vogliamo analizzare i risultati:
```
wireshark -r /tmp/pg.pcap
```
Vedremo l'instaurazione della connessione, seguita dall'handshake TLS per il sito web di Privacy Guides. Intorno al quadro 5, visualizzerai un "Saluto del Client".

Espandi il triangolo ▸ affianco a ogni campo:

▸ Transport Layer Security
  ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello
    ▸ Handshake Protocol: Client Hello
      ▸ Extension: server_name (len=22)
        ▸ Server Name Indication extension

Possiamo vedere il valore SNI che rivela il sito web che stiamo visitando. Il comando tshark può darti direttamente il valore per tutti i pacchetti contenenti un valore SNI:
```
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```

Ciò significa che, anche se stiamo utilizzando dei server "DNS Crittografati", il dominio sarà probabilmente divulgato tramite SNI. Il protocollo TLS v1.3 prevede l'Encrypted Client Hello, che impedisce questo tipo di perdita.

I governi, in particolare Cina e Russia, hanno già iniziato a bloccarlo o hanno espresso il desiderio di farlo. Di recente, la Russia ha iniziato a bloccare i siti web stranieri, che utilizzano lo standard HTTP/3. Questo perché il protocollo QUIC, parte di HTTP/3, richiede che anche ClientHello sia crittografato.

Protocollo di Stato del Certificato Online (OCSP)

Un altro modo in cui il tuo browser può divulgare le tue attività di navigazione è con il Protocollo di Stato del Certificato Online. Visitando un sito web HTTPS, il browser potrebbe verificare se il certificato del sito web è stato revocato. Ciò avviene generalmente tramite il protocollo HTTP, a significare che non è crittografato.

La richiesta OCSP contiene il "numero di serie" del certificato, che è univoco. Viene inviato al "risponditore OCSP", per poterne verificare lo stato.

Possiamo simulare ciò che un browser farebbe, utilizzando il comando openssl.

Ottieni il certificato del server e utilizza sed per mantenere soltanto la parte importante e scriverla in un file:

openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert

Ottieni il certificato intermedio. Normalmente, le Autorità di Certificazione (CA) non firmano direttamente un certificato; utilizzano ciò che è noto come certificato "intermedio".
```
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
Il primo certificato in pg_and_intermediate-.cert è in realtà il certificato del server dal passaggio 1. Possiamo riutilizzare sed per eliminare fino alla prima istanza di END:
```
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
    /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
Ottieni il risponditore OCSP per il certificato del server:
```
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Il nostro certificato mostra il risponditore del certificato Lets Encrypt. Se desideri visualizzare tutti i dettagli del certificato, puoi utilizzare:
```
openssl x509 -text -noout -in /tmp/pg_server.cert
```

Avvia la cattura dei pacchetti:

tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"

Effettua la richiesta OCSP:

openssl ocsp -issuer /tmp/intermediate_chain.cert \
             -cert /tmp/pg_server.cert \
             -text \
             -url http://r3.o.lencr.org

Apri la cattura:

wireshark -r /tmp/pg_ocsp.pcap

Ci saranno due pacchetti con il protocollo "OCSP": una "Richiesta" e una "Risposta". Per la "Richiesta", possiamo visualizzare il "numero di serie" espandendo il triangolo ▸ affianco a ogni campo:

▸ Online Certificate Status Protocol
  ▸ tbsRequest
    ▸ requestList: 1 item
      ▸ Request
        ▸ reqCert
          serialNumber

Anche per la "Risposta" possiamo visualizzare il "numero di serie":

▸ Online Certificate Status Protocol
  ▸ responseBytes
    ▸ BasicOCSPResponse
      ▸ tbsResponseData
        ▸ responses: 1 item
          ▸ SingleResponse
            ▸ certID
              serialNumber

Altrimenti, utilizza tshark per filtrare i pacchetti per il Numero di Serie:

tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber

Se l'osservatore della rete ha il certificato pubblico, disponibile pubblicamente, può abbinare il numero di serie a tale certificato e, dunque, determinare da ciò il sito che stai visitando. Il processo è automatizzabile e può associare gli indirizzi IP ai numeri di serie. Inoltre, puoi verificare i registri di Trasparenza del Certificato per il numero di serie.

Dovrei utilizzare il DNS crittografato?

Abbiamo creato questo diagramma di flusso per descrivere quando dovresti utilizzare il DNS crittografato:

graph TB
    Inizio[Inizio] --> anonymous{"Cerchi di<br> essere anonimo?"}
    anonymous --> | Sì | tor(Usa Tor)
    anonymous --> | No | censura{"Vuoi evitare<br> la censura?"}
    censura--> | Sì | vpnOrTor(Usa<br> VPN o Tor)
    censura --> | No | privacy{"Vuoi privacy<br> dall'ISP?"}
    privacy --> | Sì | vpnOrTor
    privacy --> | No | obnoxious{"L'ISP fa<br> reindirizzamenti<br> odiosi?"}
    obnoxious --> | Sì | encryptedDNS(Usa<br> DNS criptato<br> di terze parti)
    obnoxious --> | No | ispDNS{"L'ISP supporta<br> DNS criptato?"}
    ispDNS --> | Sì | useISP(Usa<br> DNS criptato<br> con l'ISP)
    ispDNS --> | No | nothing(Non fare nulla)

Il DNS Criittografato con unaa terza parte dovrebbe sempre essere utilizzato per aggirare i reindirizzamenti e il blocco DNS di base, quando puoi assicurarti che non sussisteranno conseguenze, o se sei interessato a un fornitore che svolge del filtraggio rudimentale.

Elenco dei server DNS consigliati

Cosa sono le DNSSEC?

Le Estensioni di Sicurezza del Sistema di Nome del Dominio (DNSSEC), sono una funzionalità del DNS che autentica le risposte per le ricerche del nome di dominio. Non forniscono protezione della privacy per tali ricerche, ma impediscono ai malintenzionati di manipolare o avvelenare le risposte alle richieste DNS.

In altre parole, le DNSSEC firmano digitalmente i dati, per aiutare ad assicurarne la validità. Per poter garantire una ricerca sicura, la firma si verifica a ogni livello nel processo di ricerca del DNS. Di conseguenza, tutte le risposte dal DNS sono affidabili.

Il processo di firma delle DNSSEC è simile a quello di firma di un documento legale, con una penna; il firmatario utilizza una firma univoca, che nessun altro può creare e un esperto del tribunale può osservare tale firma e verificare che il documento sia stato firmato da una data persona. Queste firme digitali garantiscono che i dati non siano stati manomessi.

Le DNSSEC implementano una politica di firma digitale gerarchica, tra tutti i livelli del DNS. Ad esempio, nel caso di una ricerca di privacyguides.org, un server DNS di radice firmerebbe una chiave per il nome del server .org, e il nome del server .org, dunque, firmerebbe un chiave per quello autoritativo di privacyguides.org.

Adattato da DNS Security Extensions (DNSSEC) overview di Google e DNSSEC: An Introduction di Cloudflare, entrambi con licenza CC BY 4.0.

Cos'è la minimizzazione dei QNAME?

Un QNAME è un "nome qualificato", ad esempio discuss.privacyguides.net. In passato, quando si risolveva un nome di dominio, il resolver DNS chiedeva a ogni server della catena di fornire tutte le informazioni di cui disponeva sulla query completa. Nell'esempio seguente, la richiesta di trovare l'indirizzo IP di discuss.privacyguides.net viene richiesta a ogni provider di server DNS:

Server	Domanda fatta	Risposta
Server root	Qual è l'IP di discuss.privacyguides.net?	Non lo so, chiedi al server .net...
Il server .net	Qual è l'IP di discuss.privacyguides.net?	Non lo so, chiedi al server di Privacy Guides...
Server di Privacy Guides	Qual è l'IP di discuss.privacyguides.net?	5.161.195.190!

Con la "minimizzazione del QNAME", il resolver DNS chiede solo le informazioni necessarie per trovare il server successivo nella catena. In questo esempio, al server root vengono chieste solo le informazioni sufficienti per trovare il nameserver appropriato per il TLD .net e così via, senza conoscere il dominio completo che si sta cercando di visitare:

Server	Domanda fatta	Risposta
Server root	Qual è il nameserver per .net?	Fornisce il server di .net
Il server .net	Qual è il nameserver di privacyguides.net?	Fornisce il server di Privacy Guides
Server di Privacy Guides	Qual è il nameserver di discuss.privacyguides.net?	Questo server!
Server di Privacy Guides	Qual è l'IP di discuss.privacyguides.net?	5.161.195.190

Sebbene questo processo possa essere leggermente più inefficiente, in questo esempio né il nameserver root centrale né i nameserver del TLD ricevono mai informazioni sulla query completa, riducendo così la quantità di informazioni trasmesse sulle abitudini di navigazione dell'utente. Un'ulteriore descrizione tecnica è definita nel RFC 7816.

Cos'è la Sottorete del Client EDNS (ECS)?

La Sottorete del Client EDNS è un metodo per un risolutore DNS ricorsivo, per specificare una sotto-rete per l'host o il client che sta effettuando la richiesta DNS.

Esiste per "velocizzare" la consegna dei dati, dando al client una risposta appartenente a un server nei suoi pressi, come una rete di consegna dei contenuti, spesso utilizzate nello streaming di video e per servire app web in JavaScript.

Questa funzionalità ha un costo in termini di privacy, in quanto comunica al server DNS alcune informazioni sulla posizione del client, in genere la tua rete IP. Ad esempio, se il tuo indirizzo IP è 198.51.100.32, il provider DNS potrebbe condividere 198.51.100.0/24 con il server autoritativo. Alcuni provider DNS anonimizzano questi dati fornendo un altro indirizzo IP approssimativamente vicino alla tua posizione.

Se hai installato dig, puoi verificare se il tuo provider DNS fornisce informazioni EDNS ai server dei nomi DNS con il seguente comando:

dig +nocmd -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

Si noti che questo comando contatterà Google per il test e restituirà il tuo IP e le informazioni sulla subnet del client EDNS. Se desideri testare un altro resolver DNS, è possibile specificare il suo IP, per testare ad esempio 9.9.9.11:

dig +nocmd @9.9.9.11 -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

Se i risultati includono un secondo record TXT edns0-client-subnet (come mostrato di seguito), il server DNS sta trasmettendo informazioni EDNS. L'IP o la rete mostrata dopo è l'informazione precisa che è stata condivisa con Google dal tuo provider DNS.

o-o.myaddr.l.google.com. 60 IN TXT "198.51.100.32"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 198.51.100.0/24"
;; Query time: 64 msec
;; SERVER: 9.9.9.11#53(9.9.9.11)
;; WHEN: Wed Mar 13 10:23:08 CDT 2024
;; MSG SIZE  rcvd: 130

Stai visualizzando la copia in Italiano di Privacy Guides, tradotta dal nostro fantastico team di lingue su Crowdin. Se noti un errore, o vedi eventuali sezioni non tradotte in questa pagina, considerare di dare una mano! Visita Crowdin

You're viewing the Italian copy of Privacy Guides, translated by our fantastic language team on Crowdin. If you notice an error, or see any untranslated sections on this page, please consider helping out!