Come le CDN usano il DNS per instradare il traffico

La promessa di fondo di una CDN è servire i contenuti da un server fisicamente vicino a ciascun visitatore, invece di far servire tutto il mondo a un unico server di origine. Nella maggior parte delle implementazioni il meccanismo che lo rende possibile è il DNS: in particolare, dare a visitatori diversi risposte diverse alla stessa identica query.

Stesso dominio, risposta diversa, di proposito

Quando un dominio sta dietro una CDN, i suoi record DNS in genere puntano (spesso tramite un CNAME) all'infrastruttura del provider della CDN e non a un singolo IP di origine. I nameserver della CDN rispondono poi a ogni query in arrivo in base al luogo da cui sembra provenire, restituendo l'indirizzo IP del nodo edge più vicino, o meno carico, per quel preciso visitatore. Due persone ai lati opposti del mondo che interrogano lo stesso dominio possono, correttamente, ricevere due indirizzi IP completamente diversi.

• Ecco perché, se esegui due volte lo stesso lookup da dominio a IP da due posizioni diverse, risultati differenti non sono un bug: è il sistema che funziona come previsto.
• È anche il motivo per cui i domini dietro una CDN tendono a risolversi in più indirizzi in lookup ripetuti: non esiste una risposta «corretta», ma solo risposte appropriate in quel momento.
• Su questi record è comune un TTL breve proprio perché la CDN possa spostare rapidamente il traffico lontano da un nodo edge in difficoltà, senza aspettare che scada una lunga finestra di cache.

Cosa significa quando fai debug

Se un sito dietro una CDN si comporta in modo strano per alcuni visitatori e non per altri, controllare a cosa risolvono il dominio i diversi punti di osservazione è spesso il modo più rapido per capire se il problema è un singolo nodo edge e non l'origine o l'applicazione stessa. Uno strumento che risolve direttamente e mostra la risposta grezza, senza la cache DNS del browser davanti, restituisce un quadro più pulito di ciò che viene servito in questo momento a una determinata regione.

L'indirizzo reale del server di origine è nascosto di proposito

Un effetto collaterale da conoscere: risolvere un dominio dietro una CDN ti restituisce l'indirizzo della rete edge, non quello del server di origine che sta dietro, e di solito è voluto, non un caso. Tenere l'IP reale dell'origine fuori dal DNS pubblico è una delle difese più semplici ed efficaci di un sito contro un attacco denial-of-service diretto all'infrastruttura vera e propria invece che alla capacità, molto più ampia, della CDN che la precede. Significa anche che un lookup del dominio da solo non può dirti dove un sito sia «davvero» ospitato, ma solo dove il suo traffico entra al momento nella rete della CDN: è una domanda decisamente diversa.

Cercare il WHOIS o l'ASN di un indirizzo risolto

Un modo rapido e pratico per capire se un dominio sta dietro una CDN è controllare chi possiede davvero l'indirizzo IP risolto, separatamente dal lookup del dominio. Un indirizzo risolto registrato sotto l'ASN (autonomous system number) di una CDN o di un provider cloud noto è un segnale forte che stai guardando una rete edge e non un server di origine, e spiega subito perché lo stesso dominio possa mostrare un indirizzo diverso da una regione diversa senza che nulla non funzioni. È un utile secondo passo dopo un lookup, non un suo sostituto: la risposta DNS ti dice l'indirizzo attuale e il lookup di proprietà ti dice a che tipo di infrastruttura appartenga quell'indirizzo.