DNS Cloudflare: infrastruttura di rete che va ben oltre la risoluzione dei nomi

Il DNS viene trattato come un'infrastruttura di base: indichi i nameserver, configuri un record A e un record MX e te ne dimentichi. Ciò che Cloudflare fa con un record proxy infrange questa premessa: il protocollo esiste ancora, ma ciò che accade quando attivi la modalità proxy cambia il significato di DNS nella tua architettura.

Cosa cambia quando esegui il proxy di un record

Quando crei un record A in Cloudflare e abiliti il proxy (l'icona della nuvola arancione), l'indirizzo IP che i tuoi clienti ricevono nella risposta DNS non è il tuo IP di origine. Cloudflare restituisce uno dei propri IP, indirizzi che appartengono alla rete anycast dell'azienda, distribuita su oltre 300 punti di presenza in tutto il mondo.

Ogni richiesta HTTP e HTTPS che raggiunge quel dominio entra nella rete Cloudflare prima di raggiungere il tuo server. TLS termina al PoP più vicino al client. Il WAF esamina la richiesta. Vengono applicate regole di limitazione della velocità. La cache viene consultata. La mitigazione degli DDoS funziona a livello periferico. Solo allora, se la richiesta è passata attraverso tutti questi livelli, viene inoltrata alla sua origine, in una connessione separata, tramite la rete interna di Cloudflare. Il vero indirizzo IP del tuo server rimane nascosto a qualsiasi client esterno.

Il DNS, in questo modello, è il punto di ingresso dell’intera catena di sicurezza e prestazioni, non il servizio che lo precede.

Anycast: Perché 300 PoP sono importanti per la latenza

La maggior parte delle reti funziona con routing unicast: ogni IP viene pubblicizzato da un'unica posizione e il pacchetto percorre l'intera distanza fino a quel data center, indipendentemente da dove si trovi il cliente.

La rete Cloudflare funziona con anycast: lo stesso blocco di indirizzi IP viene annunciato simultaneamente da ciascuno degli oltre 300 punti di presenza, tramite BGP. Quando un cliente riceve un IP Cloudflare nella risposta DNS, l'infrastruttura BGP di Internet instrada il pacchetto al PoP geograficamente più vicino. TLS termina lì, a pochi millisecondi dal client. Il percorso verso la sua origine, che potrebbe trovarsi in un'altra regione del mondo, avviene tramite la rete privata di Cloudflare, con percorsi ottimizzati tra PoP, invisibili all'utente finale.

Propagazione, TTL e separazione tra autorevole e ricorsivo

Due ruoli distinti coesistono nell'offerta DNS di Cloudflare e confonderli porta ad aspettative errate durante gli incidenti. Il servizio autorevole, quando deleghi il tuo dominio ai nameserver di Cloudflare, è ciò che risponde con autorità sui tuoi record. 1.1.1.1 è un risolutore ricorsivo pubblico, un servizio separato che interroga i server autorevoli per conto dei client. Puoi utilizzare i nameserver Cloudflare per il tuo dominio senza mai utilizzare 1.1.1.1 e viceversa.

Quando modifichi un record nella dashboard di Cloudflare, la modifica si propaga attraverso la rete autorevole in circa 30 secondi, un numero impressionante per coloro che provengono da provider che impiegano ore per aggiornare le zone. Il problema è che la "propagazione", nel senso che colpisce gli utenti reali, dipende da un altro livello: i risolutori ricorsivi.

I risolutori come 8.8.8.8 di Google e i risolutori ISP memorizzano nella cache le risposte tramite il TTL del registro. Se il TTL era a 3600 secondi quando un risolutore ha effettuato la query, continuerà a rispondere con il vecchio valore fino a un'ora, anche se Cloudflare ha già servito il nuovo record per 30 secondi. La "propagazione completa" a tutti i client richiede esattamente il TTL massimo in vigore al momento della modifica.

Il TTL predefinito per le registrazioni senza proxy su Cloudflare è 300 secondi. I record proxy espongono sempre un TTL di 300 secondi esternamente, indipendentemente dal valore interno: Cloudflare ha bisogno di questa flessibilità per gestire i propri IP anycast. Prima di qualsiasi modifica pianificata (migrazione della sorgente, failover, rotazione IP) la procedura corretta è ridurre il TTL a 60 o 300 secondi in anticipo, attendere che i risolutori aggiornino la cache, eseguano la modifica e aumentino il TTL in un secondo momento. Farlo in ordine inverso significa convivere con una propagazione lenta proprio quando il costo è più alto.

CNAME Appiattimento e problema dell'apice

La specifica DNS originale proibisce CNAME all'apice del dominio (lo stesso exemplo.com senza un sottodominio) perché è in conflitto con i record SOA e NS richiesti. Per anni, questo ha costretto i team a fissare gli IP nel record A del dominio root, creando attriti con i servizi che non garantiscono IP statici: i bilanciatori di carico in AWS espongono solo nomi DNS, non IP.

Cloudflare risolve questo problema con l'appiattimento CNAME. Quando configuri un CNAME per l'apice, Cloudflare risolve il target in tempo reale — interrogando A e AAAA del target al momento della richiesta — e restituisce questi IP direttamente al client. Dal punto di vista del risolutore esterno si tratta di un normale record A.

Cosa richiede questo a chi gestisce la produzione

I team che trattano il DNS come una configurazione statica hanno problemi specifici quando operano su Cloudflare. La modalità proxy di ciascun registro, attivata o disattivata, determina se i sistemi di sicurezza e prestazioni dei dispositivi edge sono d'intralcio o meno. Un record A con proxy disabilitato espone l'IP reale dell'origine, invalida la protezione DDoS e rimuove il WAF dal flusso. Controllare quali record sono proxy e quali no non è un compito di implementazione iniziale; deve essere parte del processo di revisione del cambiamento.

TTL merita un'attenzione operativa continua. Un TTL elevato riduce il carico autorevole e migliora la cache nei risolutori, ma aumenta i tempi di ripristino per le modifiche del percorso. La tolleranza del tempo di propagazione è spesso diversa tra record critici come MX e sottodomini di servizi interni e questa differenza dovrebbe essere esplicita nelle impostazioni della zona.