¿Se debe utilizar CNAME para los subdominios?


84

Administro varios sitios web que actualmente tienen la siguiente configuración de 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

¿Es este un uso apropiado de los registros CNAME? He buscado en línea y no he encontrado una respuesta clara. Algunas personas afirman que los registros CNAME son malos (sin embargo, no tienen claro por qué esto es así) y proponen la siguiente configuración:

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

¿Cuál de estos es el mejor enfoque (y por qué)?

Nota: Los subdominios no requieren sus propios registros MX, por lo que no es un problema aquí.


1
Siento que esto debería ser una respuesta wiki. El DNS es muy difícil de entender y ¿esta respuesta aceptada sigue siendo válida 6 años después?
the0ther

1
@ the0ther Sí, incluso hoy la respuesta validada, de Jesper Mortensen , sigue siendo válida (incluso si uno pudiera discutir sobre el nombre de las cosas o los valores TTL correctos para usar, pero estos son puntos separados del problema de usar registros CNAME o no) ) DNS es un protocolo de 30 años, por lo que cosas básicas como los registros CNAME no cambian con el tiempo.
Patrick Mevzek

Respuestas:


85

Sí, ese es un uso apropiado de CNAME. En las discusiones de las que he formado parte, los argumentos tienden a ser así:

Contra CNAME:

  • Hay una penalización de rendimiento (pequeña), ya que las memorias caché DNS posteriores deben realizar 2 búsquedas DNS, una para el CNAME y otra para el registro A al que apunta el CNAME.
  • Argumentos vagos y falsos acerca de que las CNAME tienen menos "autoridad" o problemas de compatibilidad.

A favor de CNAME:

  • Proporcionan una abstracción limpia entre hardware (servidores físicos) y servicios.
  • Simplifican la administración de DNS: cuando un servidor se mueve, solo necesita cambiar un registro.

Después de probar un par de formas diferentes de hacer esto, ahora tengo un estilo favorito personal. Está:

  • Un registro A para cada servidor físico; con un TTL bastante bajo (quizás 30 minutos); dando al servidor un nombre amigable para los humanos .
  • Un CNAME para cada servicio; con un alto TTL (quizás 24 horas); apuntando a los nombres de servidor anteriores.
  • Como única excepción a las reglas anteriores, la raíz del dominio es un Registro A, que apunta al servidor web / equilibrador de carga web. (Se requiere @ para ser un registro A).

Me parece que esta configuración funciona bien. Mantiene las búsquedas DNS adicionales para CNAMES inactivas; y si un servidor falla, todavía puedo cambiar el DNS público con bastante rapidez.

Aquí hay un ejemplo (improvisado) en la sintaxis 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
Gracias, finalmente, una opinión razonable sobre CNAME que se presenta de manera clara y concisa.
Tyler

@Jesper Mortensen: ¿podría actualizar un poco la respuesta con un pequeño ejemplo, particularmente no entendí su tercer punto cuando dice "Como única excepción a las reglas anteriores, la raíz del dominio es un Registro A", usted ya dijo en el primer punto que usa un Registro A para cada servidor de capa física. (Por cierto, los enlaces se han ido)
Marco Demaio

2
@Marco Demaio: Acerca del "Registro A raíz del dominio": Un dominio de segundo nivel como company.comes un vértice de zona. Necesita un registro SOA. Por lo tanto, debe ser un registro A y no un CNAME - ver serverfault.com/questions/170194/…
Jesper Mortensen

44
@ no está obligado a tener un registro A; más bien, un CNAME está prohibido.
Michael Hampton

1
Solo quería agregar que los CNAME son especialmente útiles si sus servidores también son compatibles con las direcciones IPv6, ya que necesitarán al menos dos entradas por servidor (una A y AAAA cada una) para usar un CNAME para subdominios En este caso es mucho, mucho más simple. Si usa las recomendaciones de Jesper para TTL (o su proveedor de DNS tiene un buen manejo automático), entonces no debería haber una penalización de rendimiento real.
Haravikk

13

Si es apropiado.

Mis mejores prácticas, que muchas personas comparten, son crear un registro de 1 A para cada IP del servidor; y use CNAMES para cualquier otra cosa.

Un ejemplo común sería:

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

Sé que en esta pregunta dijeron que el correo no es un problema aquí, pero supongamos que usa también el correo ¿cómo iría con los registros MX? ¡Gracias!
Marco Demaio

1
El registro MX también apuntaría al nombre del servidor. IN MX server1y por conveniencia Yo recomendaría también la creación de imapo popy smtpCNAME, posiblemente también mail, ya que muchos programas de correo electrónico adivinar esto. Configurar los registros SRV correctos también es una buena idea, pero dado que esta es una pregunta relativamente básica, los registros SRV pueden ser demasiado para una configuración simple.
Chris S

1
Un comentario rápido, los MXregistros no deben ser CNAME, consulte serverfault.com/a/232243/2874 Probablemente funcione bien en la práctica, pero aún así, mejor no hacerlo.
Jesper Mortensen

BIND se negará a cargar la zona si apunta un registro MX o SRV a un CNAME ... Probablemente debería haber dejado claro que el registro MX debe apuntar al registro A. Gracias.
Chris S

@ChrisS, ¿qué tal editar su respuesta y mencionar claramente el hecho de que un registro MX no puede apuntar a una entrada CNAME?
Alexis Wilke
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.