CNAME dovrebbe essere utilizzato per i sottodomini?


84

Gestisco più siti Web che attualmente hanno la seguente configurazione DNS:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - CNAME    - example.com
beta.example.com - CNAME    - test.example.com
dev.example.com  - CNAME    - test.example.com

È questo un uso appropriato dei record CNAME? Ho cercato online e non ho trovato una risposta chiara. Alcune persone affermano che i record CNAME sono errati (non sono tuttavia chiari sul perché) e propongono la seguente configurazione:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - A Record - Production Server IP
beta.example.com - A Record - Test Server IP
dev.example.com  - A Record - Test Server IP

Quale di questi è l'approccio migliore (e perché)?

Nota: i sottodomini non richiedono i propri record MX, quindi non è un problema qui.


1
Sento che questa dovrebbe essere una risposta wiki. Il DNS è così difficile da ottenere correttamente e questa risposta accettata è ancora valida 6 anni dopo?
altro

1
@ the0ther Sì, anche oggi la risposta convalidata, da Jesper Mortensen , è ancora valida (anche se si potrebbe discutere sulla denominazione delle cose o sui valori TTL corretti da usare, ma questi sono punti separati dal problema dell'utilizzo dei record CNAME o meno ). Il DNS è un protocollo vecchio di 30 anni, quindi le cose di base come i record CNAME non cambiano nel tempo.
Patrick Mevzek,

Risposte:


85

Sì, è un uso appropriato dei CNAME. Nelle discussioni di cui ho preso parte, gli argomenti tendono ad andare così:

Contro i CNAME:

  • Vi è una (minuscola) penalità prestazionale, poiché le cache DNS downstream devono eseguire 2 ricerche DNS, una per il CNAME e una per il record A a cui punta il CNAME.
  • Argomentazioni vaghe e false sui CNAME che hanno meno "autorità" o problemi di compatibilità.

A favore dei CNAME:

  • Forniscono una chiara astrazione tra hardware (server fisici) e servizi.
  • Semplificano la gestione DNS: quando si sposta un server, è necessario modificare solo un record.

Dopo aver provato un paio di modi diversi per farlo, ora ho uno stile preferito personale. È:

  • Un record A per ciascun server fisico; con un TTL abbastanza basso (forse 30 minuti); dare al server un nome amico dell'uomo .
  • Un CNAME per ogni servizio; con un TTL alto (forse 24 ore); puntando ai nomi dei server sopra indicati.
  • Come unica eccezione alle regole precedenti, la radice del dominio è un record A, che punta al bilanciamento del carico web server / web. (@ Deve essere un record A.)

Trovo che questa configurazione funzioni bene. Mantiene le ricerche DNS extra per CNAMES inattivo; e se un server si arresta in modo anomalo posso comunque cambiare DNS pubblico abbastanza velocemente.

Ecco un esempio (improvvisato) nella sintassi di BIND:

;name     ttl   class rr     value 
server01  30m   IN    A      192.168.0.3
server02  30m   IN    A      192.168.0.4

webmail   24h   IN    CNAME  server01
extranet  24h   IN    CNAME  server02
ftp       24h   IN    CNAME  server02

1
Grazie, infine, un'opinione ragionevole sui CNAME è espressa in modo chiaro e conciso.
Tyler,

@Jesper Mortensen: potresti per favore aggiornare un po 'la risposta con un piccolo esempio, in particolare non ho capito il tuo terzo punto quando dici "Come unica eccezione alle regole sopra, la radice del dominio è un record A", già detto al 1 ° punto che usi un record A per ciascun server di livello fisico. (A proposito i collegamenti sono andati)
Marco Demaio,

2
@Marco Demaio: A proposito del "record radice A dominio": un dominio di secondo livello come company.comun apice di zona. Ha bisogno di un record SOA. Quindi deve essere un record A e non un CNAME - vedi serverfault.com/questions/170194/…
Jesper Mortensen

4
@ non è richiesto per avere un record A; piuttosto, un CNAME è proibito.
Michael Hampton

1
Volevo solo aggiungere che i CNAME sono particolarmente utili se i tuoi server supportano anche gli indirizzi IPv6, poiché avrai bisogno di almeno due voci per server (un record A e AAAA ciascuno), quindi utilizzando un CNAME per i sottodomini in questo caso è molto, molto più semplice. Se usi i consigli di Jesper per TTL (o il tuo provider DNS ha una buona gestione automatica), non ci dovrebbe essere alcuna penalità per le prestazioni.
Haravikk,

13

Sì, è appropriato.

Le mie migliori pratiche, che molte persone condividono, sono di creare un record 1 A per ciascun IP del server; e usa CNAMES per qualsiasi altra cosa.

Un esempio comune sarebbe:

server1.example.com.      IN A      192.168.0.1
server2.example.com.      IN A      192.168.5.2
www                       IN CNAME  server1
ftp                       IN CNAME  server1
beta                      IN CNAME  server2

So che in questa domanda hanno detto che la posta non è un problema qui, ma supponiamo che tu usi anche la posta come andresti con i record MX? Grazie!
Marco Demaio,

1
Il record MX punta anche al nome del server. IN MX server1e per comodità consiglierei anche di impostare imapo pope smtpCNAME, possibilmente anche mail, come molti programmi di posta elettronica indovinano. Anche l'impostazione dei record SRV corretti è una buona idea, ma poiché si tratta di una domanda relativamente semplice i record SRV potrebbero essere un po 'troppo per una semplice configurazione.
Chris S,

1
Un breve commento, i MXrecord non devono essere CNAME, vedi serverfault.com/a/232243/2874 Probabilmente funziona bene nella pratica, ma è comunque meglio non farlo.
Jesper Mortensen,

BIND rifiuterà di caricare la zona se punti un record MX o SRV su un CNAME ... Probabilmente avrei dovuto chiarire che il record MX deve puntare al record A. Grazie.
Chris S,

@ChrisS, che ne dici di modificare la tua risposta e menzionare chiaramente il fatto che un record MX non può indicare una voce CNAME?
Alexis Wilke,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.