DNS proxy vs solo DNS: cosa cambia e quando ciascuna modalità ha senso

La maggior parte dei team che migrano su Cloudflare trattano la scelta tra nuvola arancione e nuvola grigia come un dettaglio di configurazione. Si attivano tramite proxy per tutto, presumono che una maggiore protezione sia sempre meglio e scoprono l'errore settimane dopo, quando un database inizia a restituire timeout senza alcun messaggio di errore o quando si rendono conto che l'IP di origine è sempre stato esposto nei record che contavano davvero.

Cosa fa effettivamente la modalità proxy

Quando un record A o CNAME è in modalità proxy, il DNS autorevole di Cloudflare non restituisce l'IP del tuo server di origine. Restituisce un IP anycast da Cloudflare stesso. Il client si connette a uno dei nodi periferici della rete, che completa TLS, ispeziona la richiesta e solo successivamente inoltra il traffico al suo server, facoltativamente con la memorizzazione nella cache abilitata, con le regole WAF applicate e con i Worker che intercettano la richiesta a metà strada.

Il vero IP del server è nascosto dal DNS pubblico. Qualsiasi query esterna al registro restituisce IP Cloudflare, non i tuoi. Ciò ha implicazioni concrete: un utente malintenzionato che desideri bypassare WAF dovrebbe scoprire l’IP di origine attraverso altri mezzi: registri trapelati, certificati TLS storici in crt.sh, intestazioni e-mail o connessioni dirette a servizi ausiliari esposti senza proxy.

Il TTL visibile esternamente è sempre di 300 secondi, indipendentemente da quanto configurato internamente alla zona. Cloudflare controlla ciò che i risolutori esterni ricevono e memorizzano nella cache: la configurazione interna serve solo per la sincronizzazione tra i server dei nomi di Cloudflare.

Cosa offre la modalità solo DNS

Con l'icona grigia, Cloudflare funziona esclusivamente come DNS autorevole. La query del nome restituisce l'IP reale del server. Non c'è terminazione TLS sul perimetro, non c'è WAF, non c'è cache, non ci sono lavoratori nel percorso. Il client si connette direttamente al server di origine e Cloudflare non vede mai il traffico.

Per i record MX l'assenza di proxy è obbligatoria. Il flusso di recapito della posta elettronica richiede che i server di invio si connettano direttamente al server di posta elettronica indicato nel record MX. Se il record MX tentasse di passare attraverso il proxy Cloudflare, l'SMTP raggiungerebbe un nodo periferico che non sa cosa fare con il traffico sulla porta 25 e l'e-mail semplicemente non arriverebbe. Cloudflare non ti consente nemmeno di abilitare il proxy sui record MX; L'impostazione predefinita è solo DNS e non può essere modificata.

Lo stesso vale per qualsiasi servizio TCP diverso da HTTP o HTTPS sulle porte supportate. Il proxy Cloudflare comprende HTTP/HTTPS sulle porte 80 e 443 e un insieme limitato di porte alternative documentate: 8080, 8443 e poche altre. Tutto al di fuori di questo set è invisibile al proxy.

La trappola del database dietro un record proxy

Questo è lo scenario che appare più silenziosamente negli incidenti. Un record A punta a un server che esegue MySQL sulla porta 3306. Il team attiva la modalità proxy perché "vogliamo maggiore protezione". Il client tenta di connettersi alla porta 3306, ma ora si sta connettendo al nodo edge di Cloudflare, che non instrada traffico TCP arbitrario. La connessione si apre, attende e si chiude a causa di un timeout. Non esiste un chiaro messaggio di errore. MySQL non vede nemmeno il tentativo di connessione.

Lo stesso accade con PostgreSQL sulla porta 5432, con Redis sulla porta 6379, con qualsiasi protocollo binario diverso da HTTP. Il proxy scarta semplicemente il traffico che non può interpretare. Per esporre questi servizi, il registro deve essere in modalità solo DNS e la conseguenza diretta è che l'IP del server è visibile pubblicamente.

A questa categoria appartengono anche le registrazioni di sottodomini per SSH diretto. Se il team mantiene un record ssh.exemplo.com che punta a un server bastion, deve essere solo DNS. Il proxy interromperà la connessione allo stesso modo.

Controllare ciò che viene esposto nella tua zona

La domanda che vale la pena porsi periodicamente è semplice: quali record di zona sono in modalità solo DNS e il traffico che li attraversa è protetto in qualche altro modo?

I record solo DNS espongono IP che possono essere utilizzati per attaccare direttamente l'origine, ignorando qualsiasi regola WAF configurata nei record proxy. Se un server appare sia in un record proxy che in un diverso record solo DNS – o se l’IP è stato esposto in passato ed è indicizzato in servizi come Shodan – l’effetto protettivo del proxy è parziale.

Per eliminare completamente l'esposizione dell'IP di origine nei servizi HTTP, Cloudflare Tunnel risolve il problema in modo definitivo. Il server di origine stabilisce una connessione in uscita alla rete Cloudflare utilizzando il demone cloudflared. Il traffico degli utenti arriva all'edge, si incanala verso il server e il server non ha mai bisogno di accettare connessioni in entrata: non c'è nessuna porta aperta, nessun IP esposto. Per il traffico TCP arbitrario al di fuori di HTTP, Cloudflare Spectrum copre questo scenario ma è esclusivo del piano Enterprise.

Cosa rivedere prima di considerare chiusa la configurazione

Le zone che crescono nel tempo accumulano record creati in contesti diversi, da persone diverse, con intenzioni a volte non documentate. Un carattere jolly *.exemplo.com in modalità proxy è legittimo e utile per i sottodomini creati dinamicamente, ma può mascherare il fatto che record specifici all'interno di quel carattere jolly sono stati creati manualmente come DNS solo per ragioni che nessuno ricorda più.

I record TXT e CAA non vengono mai proxy: si tratta di dati che i clienti devono leggere direttamente e Cloudflare non interferisce. Anche SRV e NS sono esterni al proxy. In questi casi l'interfaccia non presenta nemmeno l'opzione.