Un resolver DNS tutto suo.
L'unico log a cui nessuno pensa di spostare.

Ci sono due macchine completamente diverse che si nascondono dietro la frase "il mio server DNS", e quasi ogni tutorial costruisce quella sbagliata. Decida questo prima di installare qualsiasi cosa, perché è la differenza tra uno strumento di privacy e un proxy per la politica sulla privacy di qualcun altro.

Un forwarder prende la sua query e la passa a un altro resolver — tipicamente Cloudflare, Google, Quad9 o il suo ISP — poi mette in cache qualsiasi cosa torni indietro. È semplice, è veloce, e consegna l'intero flusso delle sue query a un'unica terza parte. Ogni guida che finisce con "ora imposti il suo upstream su 1.1.1.1" ne ha costruito uno di questi.

Un resolver ricorsivo fa il lavoro da solo. Per trovare mail.example.com chiede a un server radice chi gestisce .com, chiede ai server di .com chi gestisce example.com, poi chiede ai nameserver stessi di example.com il record. Tre o quattro brevi conversazioni con tre o quattro operatori diversi, nessuno dei quali sa nulla degli altri. Con la QNAME minimisation attivata va oltre: alla radice viene chiesto solo di .com, e ai server di .com solo di example.com. Il nome completo viene rivelato a esattamente una parte — quella che ospita il nome, e che avrebbe comunque ricevuto la sua connessione trenta millisecondi dopo.

Le due colonne di destra non sono concorrenti — sono le due metà della stessa costruzione. AdGuard Home possiede la porta 53, applica le blocklist e termina i trasporti cifrati; Unbound sta dietro di essa su loopback e fa la risoluzione. Nessuna delle due metà fa bene il lavoro dell'altra, e la catena occupa in totale circa un centinaio di megabyte di RAM.

Se deve portarsi via una sola cosa da questa pagina, sia questa: un resolver che inoltra a un provider DNS pubblico non ha reso il suo DNS privato. Ha solo spostato il log di un salto e aggiunto un server alla sua lista di manutenzione. La ricorsione è tutto il punto.

Unbound è un resolver validante, ricorsivo e con cache, di NLnet Labs. È pacchettizzato ovunque, è ciò che gran parte di internet già esegue, e appena installato fa ricorsione — deve impegnarsi apposta per trasformarlo in un forwarder. Lo installi insieme al pacchetto dei root hints così che sappia dove si trovano i server radice senza doverne scaricare un elenco da nessuna parte:

apt update && apt install -y unbound dns-root-data
unbound -V | head -2

Il pacchetto dns-root-data installa i root hints in /usr/share/dns/root.hints e il trust anchor radice DNSSEC in /usr/share/dns/root.key, e mantiene entrambi aggiornati tramite il normale canale dei pacchetti. Questo è il modo noioso ma corretto di ottenerli; scaricare root.hints da un URL in un cron job è il modo che prima o poi fallisce in silenzio.

/etc/unbound/unbound.conf.d/nb-resolver.conf

server:
    # ---- Who may ask. Deny first, allow narrowly.
    interface: 127.0.0.1@5335
    interface: 10.8.0.1
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.8.0.0/24 allow

    # ---- Privacy of the recursion itself.
    qname-minimisation: yes
    qname-minimisation-strict: no
    hide-identity: yes
    hide-version: yes
    rrset-roundrobin: yes

    # ---- DNSSEC. The anchor is maintained by the dns-root-data package.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    root-hints: "/usr/share/dns/root.hints"
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-below-nxdomain: yes
    harden-large-queries: yes
    harden-short-bufsize: yes
    aggressive-nsec: yes
    val-clean-additional: yes

    # ---- Do not be a reflector, even by accident.
    refuse-any: yes
    ratelimit: 1000
    ip-ratelimit: 200
    edns-buffer-size: 1232

    # ---- Cache. This is where the 4 GB actually earns its keep.
    msg-cache-size: 128m
    rrset-cache-size: 256m
    cache-min-ttl: 60
    cache-max-ttl: 86400
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    serve-expired-ttl: 3600

    # ---- Never chase a name that has no business being on the internet.
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10

    num-threads: 2
    so-reuseport: yes
    verbosity: 0
    logfile: ""

remote-control:
    control-enable: yes
    control-interface: /run/unbound.ctl

Quattro di quelle righe fanno il lavoro vero e meritano una frase ciascuna.

• 01access-control: 0.0.0.0/0 refuse — la risposta predefinita a internet è "no". Tutto ciò che viene dopo è un'eccezione che ha scritto di proposito. Questa singola riga è ciò che ferma la storia dell'amplificazione del passo 02 ancora prima che debba intervenire il firewall.
• 02qname-minimisation: yes — ai server radice viene chiesto solo di .com, non dell'hostname completo. RFC 9156, attivo per impostazione predefinita nelle versioni recenti di Unbound, ed è il motivo per cui un resolver ricorsivo rivela meno di quanto suggerisca il diagramma. Lasci disattivata la modalità strict: un piccolo numero di zone mal configurate si rompe ancora con essa attiva.
• 03refuse-any: yes — le query ANY restituiscono la risposta più grande possibile per la domanda più piccola possibile, che è esattamente ciò che vuole un attacco di amplificazione. Nulla di legittimo ne ha bisogno.
• 04serve-expired: yes — quando un server autoritativo non è raggiungibile, distribuisce la risposta scaduta e la aggiorna in background invece di fallire. Questa è l'impostazione che impedisce a un'interruzione lontana di sembrare, a tutti in casa, come se internet fosse down.

Noti i due listener. Il loopback sulla porta 5335 è quello che AdGuard Home userà nel prossimo passo; 10.8.0.1 è l'indirizzo del tunnel, così i client sulla VPN possono interrogare Unbound direttamente se decide di saltare il livello di filtraggio. Se non sta ancora eseguendo WireGuard, per ora rimuova quella seconda riga dell'interfaccia — Unbound non si avvierà con un indirizzo che non esiste sulla macchina.

Lo avvii e dimostri che funziona:

unbound-checkconf
systemctl restart unbound && systemctl enable unbound

apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short

# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org  | grep 'status:'

Il flag ad sulla prima risposta significa che Unbound ha controllato la catena di firme dalla radice fino al record e ha retto. SERVFAIL sulla seconda significa che la validazione ha respinto una risposta manomessa invece di passargliela. Se la seconda restituisce invece un indirizzo, la validazione non è attiva e il trust anchor è la prima cosa da controllare.

Un resolver che nessuno può raggiungere non è utile, e un resolver che tutti possono raggiungere è la modalità di guasto del passo 02. Ci sono esattamente due buone risposte, e la maggior parte delle persone finisce per usarle entrambe — il tunnel a casa e sul portatile, il DNS cifrato sul telefono e sulle reti dove l'UDP viene filtrato.

Opzione A — su WireGuard. La migliore delle due, ed è il motivo per cui questa guida continua a rimandare alla guida a WireGuard. La porta 53 resta invisibile a internet, la query stessa non attraversa mai in alcuna forma una rete non fidata, e non c'è alcun certificato da rinnovare. Se il VPS è già la sua uscita VPN, questa è una riga nella configurazione di ogni peer:

# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1

Una sottigliezza che inganna molti: su Linux, wg-quick imposta quell'indirizzo tramite resolvconf o systemd-resolved, e se nessuno dei due è installato non fa nulla in silenzio mentre il tunnel si avvia perfettamente. Controlli con resolvectl status o leggendo /etc/resolv.conf dopo che il tunnel è attivo — un tunnel funzionante con ancora configurato il vecchio resolver è esattamente la fuga di cui parla tutto questo esercizio.

Opzione B — DNS-over-TLS e DNS-over-HTTPS. Necessaria quando il dispositivo non può essere sempre sul tunnel. Entrambi sono autenticati da un certificato, il che significa un hostname: punti un record A verso il VPS, poi lasci che AdGuard Home detenga il certificato direttamente, oppure lo metta dietro un reverse proxy che termina già il TLS per lei. I listener sono 853/tcp per DoT e 443/tcp per DoH.

ufw allow 853/tcp                     # DNS-over-TLS
ufw allow 443/tcp                     # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status

Assegni all'endpoint DoH un percorso non indovinabile — AdGuard Home le permette di servirlo sotto /dns-query/<random>, e un percorso diverso per ogni persona significa che l'accesso può essere revocato a una persona alla volta senza dover ruotare nulla per tutti gli altri. Non è un'autenticazione in senso forte, ma impedisce che un listener pubblico sia un resolver aperto con qualche passaggio in più.

La riga del router è quella su cui riflettere. Distribuire il suo resolver tramite DHCP copre ogni dispositivo in casa in una volta sola, compresi quelli senza una schermata di impostazioni — ma il salto dal router al VPS è a quel punto DNS in chiaro attraverso l'internet aperto, che è proprio ciò che si era proposto di fermare. Esegua il tunnel direttamente sul router, oppure accetti che l'ultimo miglio non sia cifrato e lasci che la ricorsione sia comunque il guadagno.

Un'ultima configurazione che vale la pena conoscere: un browser con DNS-over-HTTPS abilitato userà il proprio resolver e ignorerà silenziosamente l'impostazione di sistema, tunnel o no. Sia Firefox che Chrome lo attivano per impostazione predefinita in alcune regioni. O punti anche il browser verso il suo endpoint, oppure disattivi il suo DoH così che segua il sistema operativo.

Un resolver privato è un miglioramento reale e non è un mantello invisibile. Chiunque glielo venda come tale sta vendendo qualcos'altro. Ecco l'elenco di ciò che resta visibile una volta fatto tutto quanto sopra, perché conoscere la forma dell'esposizione residua è la differenza tra una difesa e una coperta di Linus.

La connessione avviene comunque. Un millisecondo dopo il lookup, il suo dispositivo apre una connessione TCP verso l'indirizzo che ha appena appreso. Chiunque osservi la sua linea vede quell'indirizzo. Per un sito sul proprio IP dedicato, l'indirizzo è il sito. Il DNS cifrato rimuove la domanda; non rimuove la risposta.

L'handshake TLS di solito rivela il nome del sito. Il Server Name Indication viene inviato in chiaro all'inizio di quasi ogni connessione HTTPS, quindi un osservatore passivo legge comunque l'hostname. L'Encrypted Client Hello risolve questo problema ed è distribuito in modo disomogeneo — dove sia il browser sia il sito lo supportano il nome è nascosto, e dove non lo supportano non lo è. Non dia per scontato che sia attivo.

L'operatore del resolver ora è lei, ed è una sola persona. Ogni server autoritativo con cui il suo resolver parla vede un unico indirizzo IP chiedere della propria zona. Attraverso molte zone, quell'IP ha uno schema distintivo, e lo schema è una famiglia. Questo è il costo in termini di insieme di anonimato del primo capitolo, e l'unica cosa che lo attenua è che l'IP non sia riconducibile a un nome — un VPS KYC-free pagato in crypto — e, idealmente, che sia lo stesso IP da cui esce già il suo traffico.

Il provider può vedere i pacchetti, come sempre. Il VPS gira sull'hardware di qualcuno, nel datacenter di qualcuno. NordBastion non ispeziona il traffico dei clienti, e il transparency report e il warrant canary descrivono cosa accadrebbe se venisse richiesto — ma l'affermazione onesta dal punto di vista architetturale è che una macchina che noleggia è una macchina che qualcun altro può fisicamente raggiungere. Ciò che cambia con il self-hosting è che non esiste un log delle query a livello di prodotto, nessuna pipeline di analytics e nessuna privacy policy che possa essere modificata; c'è solo un processo che tiene una cache in RAM, configurato da lei, in una giurisdizione scelta apposta da lei.

Ciò che ha effettivamente comprato, con precisione: la fonte più ricca ed economica in assoluto di dati comportamentali su di lei non viene più raccolta da un soggetto il cui modello di business consiste nel raccoglierla. È un'affermazione circoscritta, ed è vera. Nulla in questa pagina sostituisce Tor quando il modello di minaccia richiede Tor — e per quello, la guida ai servizi onion qui sotto è l'onesta lettura successiva.