Il record CNAME (Canonical Name) funziona come un alias a livello di dominio. Invece di risolvere un hostname direttamente in un indirizzo IP, il CNAME indica al resolver DNS che la destinazione è un altro nome di dominio. Quando un resolver incontra un CNAME, riavvia l'intera sequenza di ricerca, interrogando il nuovo dominio canonico finché non arriva a risolvere in un record A o AAAA terminale. È molto usato dagli sviluppatori che integrano piattaforme SaaS di terze parti, Content Delivery Networks (CDN) o ambienti PaaS come Vercel e Heroku, dove l'assegnazione di IP statici non è garantita e l'infrastruttura cambia spesso.

Il limite del dominio apex (RFC 1034)

Una delle regole più rigide dell'architettura DNS, definita in RFC 1034, stabilisce che un record CNAME non può coesistere nello stesso nodo con alcun altro tipo di record. Poiché l'apex di un dominio (es. example.com) è obbligato a contenere i record SOA (Start of Authority) e NS (Name Server) per funzionare, è impossibile piazzare un CNAME standard alla radice. Se ci provi, la zona si rompe, causando fallimenti catastrofici della posta (MX) e del routing. Per aggirare questo limite, i moderni provider DNS gestiti (come Cloudflare, AWS Route 53 e DNSimple) hanno sviluppato pseudo-record proprietari di "CNAME Flattening" o "ALIAS". Questi sistemi risolvono la destinazione del CNAME internamente, lato server, e consegnano un record A sintetico direttamente al client richiedente, mantenendo un rigoroso rispetto delle RFC.

Subdomain takeover e record dangling

I record CNAME introducono un vettore di sicurezza serio noto come Subdomain Takeover. Si verifica quando un amministratore crea un CNAME che punta un sottodominio (es. docs.example.com) a un servizio di terze parti come un endpoint GitHub Pages o Zendesk. Se l'azienda elimina poi il suo account Zendesk ma dimentica di rimuovere il record CNAME dalla zona DNS, l'alias diventa "dangling". Un attore malevolo può quindi registrare quell'endpoint abbandonato presso il provider di terze parti e prendere istantaneamente il controllo completo del sottodominio di fiducia, abilitando attacchi di phishing e furto di cookie. Audit periodici delle catene di CNAME sono una pratica di sicurezza obbligatoria.

Penalità di risoluzione e loop infiniti

Incatenare alias (es. puntare Alias A a Alias B, che punta a Alias C) comporta una penalità di prestazioni significativa. Ogni salto richiede al client una ricerca DNS aggiuntiva, aggiungendo millisecondi misurabili al Time to First Byte (TTFB). Inoltre, configurazioni sbagliate possono creare facilmente loop di routing infiniti, facendo abbandonare la ricerca al resolver con un errore NXDOMAIN. Validare la struttura dei tuoi alias a livello globale assicura un routing efficiente e diretto.