Dominio A CNAME Sembra simile, ma svolge due compiti diversi nel DNS: Il record A assegna un dominio direttamente a un indirizzo IPv4, mentre il CNAME imposta un alias su un altro hostname. In questo articolo spiego la differenza pratica, i punti di forza di ciascun tipo di record e il modo in cui è possibile utilizzarli entrambi correttamente per assegnare in modo affidabile sottodomini, www e servizi esterni al nome host corretto. Indirizzo spettacolo.
Punti centrali
- Record AAssegnazione diretta di un dominio a un indirizzo IPv4
- CNAMEAlias da un sottodominio a un altro hostname
- PrestazioniA-Record solitamente più veloce, CNAME più flessibile
- Dominio Apexper il dominio principale di solito usano A-Record
- ManutenzioneL'IP viene modificato solo sul record A, i CNAME seguono
Il DNA spiegato in breve
Confronto DNS come un elenco telefonico: le persone memorizzano i nomi, i computer parlano gli IP e il DNS traduce le due cose. Se si richiama il sito example.de, il resolver recupera le voci corrispondenti dai server dei nomi autorevoli e fornisce l'IP in modo che il browser possa inviare la richiesta al server corretto. Server viene inviato. Per mantenere questo processo senza intoppi, i risolutori lavorano con memorie intermedie e rispettano il TTL definito, che regola il tempo in cui un risultato rimane valido. Per un'introduzione compatta, consiglio la spiegazione di DNS e sistema dei nomi di dominioche riassume gli elementi più importanti. Come regola di base: senza voci DNS corrette, un utente non sarà in grado di raggiungere il vostro sito web, anche se il server web è perfetto. corse.
A-Record: assegnazione diretta all'indirizzo IPv4
A Record A collega un dominio o sottodominio direttamente a un IPv4 specifico, come 203.0.113.10, in modo che la richiesta arrivi direttamente alla macchina desiderata senza alcuna deviazione. Questa immediatezza porta velocità, perché il resolver ha normalmente bisogno di una sola interrogazione, che può fornire tempi di risposta notevolmente ridotti. Utilizzate i record A per i domini principali e per i sottodomini con un proprio server di destinazione se controllate l'IP e non lo cambiate continuamente, in modo da mantenere il Sovranità attraverso la risoluzione. Pianificate il TTL in modo che corrisponda alla vostra frequenza di modifica: le modifiche poco frequenti consentono un TTL più lungo per ridurre il traffico DNS, mentre gli spostamenti frequenti beneficiano di un TTL breve in modo che i nuovi IP si diffondano più rapidamente. Se si utilizza anche l'IPv6, aggiungere il record AAAA, in quanto il record A copre solo i dati relativi all'IPv6. IPv4 da.
CNAME: Alias per nomi di host e sottodomini
A CNAME non punta a un IP, ma a un altro nome host, per questo è inteso come un alias che semplifica l'amministrazione di molti sottodomini. Esempio: www.beispiel.de punta come CNAME a example.de, l'IP effettivo è solo sul dominio principale e rimane il vostro unico punto di personalizzazione. Se l'IP del server cambia, basta modificare il record A del dominio principale e tutti i CNAME dipendenti seguiranno automaticamente il nuovo Obiettivo. In questo modo mantengo snelle le configurazioni con sottodomini di blog, negozi o app, soprattutto quando diversi servizi utilizzano lo stesso backend. In questo modo collego anche piattaforme esterne, come cdn.provider.net, senza dover conoscere o mantenere l'IP sottostante. mosto.
Confronto diretto: proprietà, prestazioni e utilizzo
Entrambi i tipi di voce svolgono compiti chiari, ma differiscono in termini di obiettivo, risoluzione e focus di utilizzo, che si notano nel lavoro quotidiano. Per il dominio Apex, di solito si usa la voce Record Aperché le voci di posta elettronica come MX devono essere in parallelo e un CNAME crea problemi. Per i sottodomini, il CNAME è più interessante perché riduce lo sforzo di manutenzione e mantiene chiara la configurazione, soprattutto in ambienti di grandi dimensioni. In termini di tempo di risposta, il record A guadagna punti perché è sufficiente una ricerca, mentre un CNAME richiede almeno un passaggio aggiuntivo, difficilmente misurabile a seconda del resolver, ma che può essere notevole per molte catene. La tabella seguente riassume i dati principali e mostra perché uso deliberatamente entrambi i metodi a seconda dell'obiettivo. miscela:
| Caratteristica | Record A | CNAME |
|---|---|---|
| Tipo di obiettivo | Indirizzo IP (IPv4) | Nome host (Alias) |
| Risoluzione | per lo più 1 ricerca | almeno 2 ricerche |
| Dominio principale (Apex) | adatto | problematico con MX |
| Manutenzione per cambio IP | Modificare tutti i record A interessati | solo il record A a destinazione, seguono i CNAME |
| Profilo di applicazione | solido, critico Obiettivi | molti sottodomini, servizi esterni |
Pratica: Esempi di configurazioni pulite
Per i nuovi progetti, inizio con una chiara separazione: il dominio Apex ottiene un Record Awww punta all'Apex tramite CNAME, e altri sottodomini seguono se necessario. Se un negozio punta a una piattaforma SaaS, imposto shop.deinedomain.de come CNAME a shop.example.net, in modo che le modifiche successive funzionino senza conoscere l'IP. Per gli strumenti interni con una propria macchina, come monitor.deinedomain.de, scelgo un record A, poiché controllo consapevolmente l'IP e preferisco la risoluzione diretta. La seguente mini-matrice rende tangibile la differenza e mostra quanto siano flessibili i CNAME in configurazioni più ampie. È così che mantengo la gestione del DNS chiaro e reattivo:
| sottodominio | Tipo | Obiettivo |
|---|---|---|
| www | CNAME | esempio.com |
| blog | CNAME | esempio.com |
| negozio | CNAME | shop.external.com |
| esempio.com | Record A | 192.0.2.10 |
TTL, prestazioni e catene di CNAME
Il sito TTL (Time to Live) influenza la durata della cache delle risposte dei resolver, che influisce direttamente sulle prestazioni e sulla tempestività. Per gli obiettivi statici, utilizzo TTL più lunghi per ridurre il numero di interrogazioni DNS, mentre abbasso il TTL prima degli spostamenti pianificati in modo che le modifiche arrivino rapidamente in tutto il mondo. Per i CNAME, ogni catena aggiuntiva aumenta il numero di risoluzioni; per questo motivo mantengo le catene corte e controllo regolarmente i percorsi degli alias. Assicuratevi che non si creino loop e che la destinazione finale possa essere effettivamente risolta con i record A o AAAA, altrimenti il sito web irraggiungibile. Testate le modifiche con strumenti come dig o nslookup, osservate i tempi di risposta e verificate se il resolver rispetta il TTL previsto.
Record AAAA e IPv6: doppiamente accessibile, priorità pulita
Oltre agli A-Record, uso costantemente Record AAAA in modo che i client possano connettersi anche tramite IPv6. Gli stack moderni utilizzano il metodo "happy eyeballs" e selezionano automaticamente il percorso più veloce: si guadagna in portata e resilienza. Importante: pubblicare un record AAAA solo se il servizio è completamente accessibile tramite IPv6 (firewall, routing, certificato TLS, VirtualHost/SNI). In caso contrario, un percorso IPv6 non funzionante causerà timeout, anche se IPv4 funzionerebbe. Mantengo il TTL di A e AAAA identico in modo che entrambi i percorsi invecchino in modo sincrono e verifico regolarmente con lo scavatore AAAA se la risposta è corretta.
Caratteri jolly: utilizzare i caratteri jolly in modo mirato.
Con una voce jolly (*.yourdomain.com) è possibile intercettare sottodomini sconosciuti, praticamente come ripiego o per host di prova di breve durata. Di solito imposto una voce CNAME a un obiettivo centrale o un record A a una pagina di destinazione. Si noti la priorità: le voci esplicite battono i caratteri jolly. Evitate MX o NS con caratteri jolly che potrebbero modificare involontariamente la struttura della posta o della zona. Mantenete le wildcard documentate in modo trasparente, in modo da sapere quali sottodomini sono effettivamente risolti tramite il segnaposto.
Più record A: valutare correttamente il round robin e il failover
Se si indossano diversi Registrazioni A per la stessa etichetta, i resolver spesso distribuiscono le risposte in modo circolare. Si tratta di un semplice bilanciamento del carico, ma non di un controllo dello stato di salute: se un target fallisce, le cache continuano a consegnarlo fino alla scadenza del TTL. Per un'alta disponibilità reale, combino il DNS con controlli a monte (ad esempio, un bilanciatore di carico o una CDN) o utilizzo le funzionalità del provider, come quelle ponderate/attive-passive. Pianificate il TTL in modo consapevole: abbastanza corto per un passaggio veloce, abbastanza lungo per evitare un carico inutile. Con set separati di A e AAAA, potete anche controllare sottilmente la famiglia senza rischiare un'accessibilità asimmetrica.
Alternative per domini, e-mail e CNAME di Apex
Sul Apice-Oltre al record A o AAAA, in un dominio sono spesso presenti altre voci, come MX per la posta elettronica, TXT per SPF e talvolta SRV (example.de), motivo per cui un CNAME genera conflitti. Alcuni provider offrono i cosiddetti tipi ALIAS o ANAME, che agiscono come CNAME all'Apex, ma presentano un IP al resolver in modo che esistano voci parallele senza interferenze. Se il vostro provider non offre questa possibilità, limitatevi ai record A e AAAA sull'Apex e usate i CNAME solo sui sottodomini per mantenere la configurazione stabile e a bassa manutenzione. Per la consegna delle e-mail, controllo sempre che MX sia impostato correttamente e che SPF, DKIM e DMARC siano completi, in modo che la consegna e la reputazione siano corrette. Questa organizzazione garantisce che il web e la posta elettronica funzionino insieme in modo affidabile e che si disponga della giusta Luogo cambiamento.
Email, MX e CNAME: regole che risparmiano problemi
Io mi attengo a due principi: 1) un'etichetta che ha MX o altri dischi ottiene nessun CNAME (regola "nessun CNAME e altri dati"). 2) I nomi host di destinazione in MX dovrebbero idealmente puntare direttamente ad A/AAAA e non a un CNAME, in modo che i server di posta non si imbattano in nulla. Per il DKIM, mi piace usare i CNAME sui selettori dei fornitori, perché sull'etichetta del selettore esiste solo il CNAME, che funziona correttamente. Per la consegna stessa, imposto record A/AAA dedicati sull'host di posta (ad esempio, mail.deinedomain.de) e mantengo SPF, DKIM e DMARC tramite TXT, in modo che i flussi di posta rimangano solidi.
Insidie: riconoscere rapidamente gli errori tipici
I problemi più frequenti sono rappresentati da una lunghezza eccessiva CNAME-Catene, cicli di alias e CNAME sul dominio Apex dove esistono già degli MX che generano conflitti. In questi casi, controllo il file di zona da cima a fondo, riduco le catene al minimo e imposto il record A dove sono necessarie altre voci. Un altro classico: non confondere l'ordine dei sottodomini www e apex, altrimenti i certificati e i reindirizzamenti divergeranno. Monitorate anche la propagazione dopo le modifiche, poiché le cache di tutto il mondo impiegano un po' di tempo per far apparire i nuovi valori, a seconda del TTL. Un monitoraggio strutturato consente di risparmiare la risoluzione dei problemi e il Visitatori raggiungere in modo affidabile la loro destinazione.
Implementare le modifiche in modo pulito con il provider
Prima di cambiare i record DNS, riduco il TTLattendere il runtime della cache e poi impostare i nuovi valori, in modo che gli utenti ricevano rapidamente i dati freschi. Esistono interfacce chiare con campi per A, AAAA, CNAME, MX, TXT e SRV per gli host più comuni, che consentono processi prevedibili. Se volete orientarvi su un esempio specifico, date un'occhiata al file compatto Guida alle impostazioni DNSche mostra i campi di input e le combinazioni tipiche. Dopo aver salvato, utilizzo dig/nslookup per verificare se le risposte e il TTL sono corretti e quindi verifico l'accessibilità al web e alla posta elettronica attraverso diverse reti. In questo modo mi assicuro che la modifica non causi problemi imprevisti. Lacune lascia dietro di sé.
Diagnosi in pratica: modelli di dig e nslookup
Uso comandi chiari per controlli rapidi. Con scava +traccia è possibile visualizzare l'intera catena di risoluzione fino al server autoritativo, ideale per visualizzare le catene CNAME o i problemi di delega. Con dig www.deinedomain.de A +ttlunità Verifico quale TTL restituisce effettivamente il resolver. E con dig cname.ziel.tld CNAME è possibile riconoscere se l'alias punta a un obiettivo risolvibile. È anche importante fare un test con AAAA per non dimenticare IPv6. Su Windows consegna nslookup risultati simili; ho impostato il server su 8.8.8.8 o 1.1.1.1 per ottenere risposte indipendenti ed escludere le cache locali.
Certificati e CNAME: cosa controlla realmente il browser
Anche se un nome host punta a una destinazione diversa tramite CNAME, il browser convalida la destinazione Certificato sempre rispetto al nome chiamato in origine. Il certificato deve quindi contenere il nome alias (SAN/CN), non necessariamente l'host di destinazione. Spesso utilizzo le sfide DNS-01 per l'automazione: l'etichetta _acme-challenge può essere delegato tramite CNAME a un provider che gestisce la convalida senza che io debba regolare manualmente i record TXT. Assicuratevi solo che il CNAME sia risolto correttamente e che non ci siano record paralleli sulla stessa etichetta.
Integrazione di CDN e SaaS: intestazioni host e strategie Apex
Con le CDN o i servizi SaaS, la Intestazione dell'host Fondamentale: il server di destinazione si aspetta il dominio originale nell'intestazione HTTP, anche se si punta a un nome host diverso tramite CNAME. Controllate se il vostro provider ha memorizzato "Custom Domains" incl. TLS per i vostri nomi host, altrimenti l'SNI fallirà. Per il dominio Apex senza ALIAS/ANAME, lavoro con reindirizzamenti 301 a www, che puntano alla CDN come CNAME - questo mantiene la risoluzione pulita e la coerenza SEO.
DNS a orizzonte diviso: interno o esterno
Nelle reti aziendali mi piace utilizzare Orizzonte divisoI resolver interni forniscono risposte diverse da quelli esterni (ad esempio, IP privati per servizi interni). In questo caso è importante una chiara separazione delle zone e etichette standardizzate. Documento quali nomi differiscono internamente e impedisco che i nomi di host interni diventino inavvertitamente pubblici. Impostate i CNAME con parsimonia per evitare catene attraverso i confini delle zone e mantenete il TTL corto all'interno per velocizzare l'implementazione.
Sicurezza: evitare i CNAME penzolanti e le acquisizioni di sottodomini
Particolarmente critici sono CNAME penzolanti a fornitori esterni il cui endpoint di destinazione non esiste più. Gli aggressori possono quindi registrare l'endpoint libero e distribuire contenuti sotto il vostro sottodominio. Le mie contromisure: Controllo regolarmente la zona, rimuovo i CNAME inutilizzati, documento le dipendenze esterne e pulisco attivamente i record DNS quando il progetto scade. Inoltre, imposto record CAA per limitare l'emissione di certificati e ridurre al minimo i caratteri jolly, per quanto necessario.
Aspetti SEO di alias e redirect
Le voci DNS risolvono i nomi, non sostituiscono InoltroPer questo motivo faccio attenzione anche ai reindirizzamenti HTTP e ai tag canonici coerenti, in modo che i motori di ricerca riconoscano l'indirizzo principale. Se si utilizza www come CNAME per l'Apex, allora si indirizzano tutti gli utenti a un URL preferito, in modo che i segnali vengano raggruppati. Per i sottodomini che agiscono come alias, faccio attenzione al linking interno e ai canonici, in modo che il contenuto non appaia due volte e il budget di crawling rimanga ragionevole. Potete trovare consigli pratici su alias e reach nell'articolo compatto su Alias di dominio e SEOche privilegia strutture pulite. Tenere separati DNS e SEO: Il DNS risolve rapidamente e Affidabile Il SEO controlla la visibilità e la coerenza.
Sintesi in testo semplice
Il sito Record A collega un dominio direttamente a un indirizzo IPv4 e offre velocità e controllo, soprattutto nel dominio Apex con voci MX e TXT parallele. Il CNAME imposta un alias a un nome di host e si rivela particolarmente utile quando molti sottodomini devono puntare allo stesso obiettivo o quando vengono integrati servizi esterni. Per le modifiche al target, di solito è sufficiente accedere al record A del dominio principale, mentre tutti i CNAME seguono automaticamente e la manutenzione rimane ridotta. Fate attenzione alle catene corte, ai TTL adeguati ed evitate i CNAME sull'apice se ci sono voci di posta elettronica, altrimenti rischiate di fallire. Con questa chiara divisione dei compiti, si seleziona la voce appropriata per ogni host, si mantiene la zona ordinato e garantire una risoluzione rapida e affidabile.
