Nel DNS standard un nome che contiene un record CNAME non può avere altri dati. Poiché l’apice di una zona deve avere almeno SOA e NS, un CNAME tradizionale sul dominio principale non è compatibile con la struttura della zona. Le alternative dipendono dal provider DNS e dal servizio di destinazione.
Indice dei contenuti
In sintesi
Nel DNS standard un nome che contiene un record CNAME non può avere altri dati. Poiché l’apice di una zona deve avere almeno SOA e NS, un CNAME tradizionale sul dominio principale non è compatibile con la struttura della zona. Le alternative dipendono dal provider DNS e dal servizio di destinazione.
Perché il CNAME all’apice è problematico
Un record CNAME trasforma un nome in alias di un altro nome canonico. Le regole DNS non consentono che lo stesso nome abbia contemporaneamente un CNAME e altri record ordinari. All’apice della zona, però, esistono necessariamente record come SOA e NS: per questo non puoi trattare example.com come un normale alias CNAME senza violare il modello DNS.
Il problema non riguarda invece un sottodominio come www.example.com: se a quel nome non servono altri record incompatibili, può essere tranquillamente un CNAME verso il nome fornito dal servizio esterno.
Alternative pratiche
- A e AAAA: usa indirizzi IPv4/IPv6 quando il servizio di destinazione fornisce IP stabili e documentati.
- ALIAS/ANAME o CNAME flattening: alcuni provider DNS offrono record sintetici o risoluzione lato autorevole che permettono di puntare l’apex verso un hostname mantenendo SOA e NS. Non sono un tipo CNAME standard universale: verifica comportamento, TTL e compatibilità del provider.
- Usare www come nome canonico: configura
www.example.comcome CNAME e fai rispondere l’apex con A/AAAA o con un redirect HTTP gestito da un servizio adatto. - Delegare un sottodominio: per piattaforme complesse può essere più pulito assegnare al servizio un nome come
app.example.como una zona dedicata.
Controlli DNS prima e dopo la modifica
- Interroga direttamente i nameserver autorevoli con
dig example.com A,dig example.com AAAAe, se previsto,dig www.example.com CNAME. - Controlla che SOA e NS dell’apex restino presenti e coerenti.
- Verifica eventuali record MX, TXT, CAA e DNSSEC che condividono il dominio principale: non devono sparire a causa di una configurazione di alias impropria.
- Confronta le risposte da più resolver solo dopo aver verificato l’autorevole; differenze temporanee possono dipendere dal TTL e dalla cache.
- Se usi flattening, controlla cosa restituisce realmente il provider agli utenti finali e come gestisce variazioni dell’IP di destinazione.
Verifica finale
La soluzione corretta non è quella che “sembra un CNAME” nel pannello, ma quella che produce risposte DNS valide e mantiene tutti i record necessari all’apice. Dopo la modifica testa sito, posta e certificati: MX, SPF/DMARC, CAA e DNSSEC possono dipendere dalla stessa zona anche se il cambiamento era nato soltanto per collegare il sito a un servizio esterno.
Guide Xlogic correlate
- Wildcard DNS non funziona per i sottodomini
- Nameserver autorevoli non rispondono
- DNS Anycast: vantaggi e controlli
Fonti
Domande frequenti
Posso creare un CNAME standard su example.com?
In una zona DNS normale l’apice deve avere SOA e NS e un nome con CNAME non può avere altri dati ordinari; per questo si usano alternative come A/AAAA o funzioni specifiche del provider.
ALIAS e ANAME sono uguali a un CNAME?
No. Sono soluzioni offerte da alcuni provider per ottenere un comportamento simile all’apex, ma non sono il normale record CNAME standard visibile ai resolver.
Cosa devo controllare dopo il cambio?
Verifica direttamente i nameserver autorevoli, poi controlla A/AAAA, SOA, NS, MX, TXT, CAA e l’eventuale DNSSEC, oltre al funzionamento del servizio web.