CNAME deve ser usado para subdomínios?

Eu gerencio vários sites que atualmente têm a seguinte configuração 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

Esse é um uso apropriado dos registros CNAME? Procurei on-line e não encontrei uma resposta clara. Algumas pessoas afirmam que os registros CNAME são ruins (no entanto, não estão claros sobre o motivo) e propõem a seguinte configuração:

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

Qual delas é a melhor abordagem (e por que)?

Nota: Os subdomínios não requerem seus próprios registros MX, portanto, isso não é um problema aqui.

domain-name-system cname-record

— Joseph Sturtevant
fonte

Eu sinto que isso deve ser uma resposta wiki. O DNS é tão difícil de corrigir e essa resposta aceita ainda é boa 6 anos depois?

— the0ther

@ the0ther Sim, ainda hoje a resposta validada, de Jesper Mortensen , ainda é válida (mesmo que alguém possa discutir sobre a nomeação de coisas ou os valores TTL corretos para usar, mas esses são pontos separados da questão de usar ou não registros CNAME ) O DNS é um protocolo de 30 anos, portanto, coisas básicas como registros CNAME não mudam com o tempo.

— Patrick Mevzek 4/03/19

Respostas:

Sim, esse é um uso apropriado dos CNAMEs. Nas discussões das quais participei, os argumentos tendem a ser assim:

Contra CNAMEs:

Há uma (pequena) penalidade de desempenho, pois os caches DNS a jusante precisam executar 2 pesquisas DNS, uma para o CNAME e outra para o registro A para o qual o CNAME aponta.
Argumentos vagos e falsos sobre CNAMEs terem menos "autoridade" ou problemas de compatibilidade.

A favor dos CNAMEs:

Eles fornecem uma abstração limpa entre hardware (servidores físicos) e serviços.
Eles simplificam o gerenciamento de DNS - quando um servidor se move, você só precisa alterar um registro.

Depois de tentar algumas maneiras diferentes de fazer isso, agora tenho um estilo favorito pessoal. Isto é:

Um registro para cada servidor físico; com um TTL razoavelmente baixo (talvez 30 minutos); dando ao servidor um nome amigável ao ser humano .
Um CNAME para cada serviço; com um TTL alto (talvez 24 horas); apontando para os nomes de servidor acima.
Como única exceção às regras acima, a raiz do domínio é um registro A, apontando para o servidor da web / balanceador de carga da web. (O @ é necessário para ser um registro A.)

Acho que essa configuração funciona bem. Mantém pesquisas extras de DNS para o CNAMES inativas; e se um servidor travar, ainda posso alterar o DNS público rapidamente.

Aqui está um exemplo (improvisado) na sintaxe 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

— Jesper Mortensen
fonte

Obrigado, finalmente, uma opinião razoável sobre o CNAMEs é apresentada de forma clara e concisa.

— Tyler

@ Jesper Mortensen: você poderia atualizar um pouco a resposta com um pequeno exemplo, particularmente eu não entendi o seu terceiro ponto quando você diz "Como única exceção às regras acima, a raiz do domínio é um registro A", você já disse no 1º ponto que você usa um registro A para cada servidor da camada física. (BTW, os links foram embora) #

— 22263 Marco Demaio 21/02

@Marco Demaio: Sobre o "registro A da raiz do domínio": Um domínio de segundo nível como company.comé o ápice da zona. Ele precisa de um registro SOA. Portanto, ele deve ser um registro A e não um CNAME - consulte serverfault.com/questions/170194/…

— Jesper Mortensen

@ não é necessário ter um registro A; em vez disso, um CNAME é proibido.

— Michael Hampton

Só queria acrescentar que os CNAMEs são especialmente úteis se os seus servidores também suportam endereços IPv6, pois você precisará de pelo menos duas entradas por servidor (um registro A e AAAA cada), portanto, use um CNAME para subdomínios neste caso, é muito, muito mais simples. Se você usar as recomendações de Jesper para TTL (ou se o seu provedor de DNS tiver um bom manuseio automático), não haverá uma penalidade real de desempenho.

— Haravikk

Sim, é apropriado.

Minhas práticas recomendadas, que muitas pessoas compartilham, devem criar um registro de 1 A para cada IP do servidor; e use CNAMES para qualquer outra coisa.

Um exemplo comum seria:

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

— Chris S
fonte

Sei que nesta pergunta eles disseram que o correio não é um problema aqui, mas vamos supor que você use também o correio, como iria com os registros MX? Obrigado!

— Marco Demaio

O registro MX também apontaria para o nome do servidor. IN MX server1e por conveniência eu recomendaria também a criação imapou pope smtpCNAMEs, possivelmente também mail, como muitos programas de correio electrónico acho que isso. Configurar os registros SRV corretos também é uma boa idéia, mas como essa é uma pergunta relativamente básica, os registros SRV podem ser um pouco demais para uma configuração simples.

— Chris S

Um comentário rápido: os MXregistros não devem ser CNAMEs; consulte serverfault.com/a/232243/2874 . Provavelmente funciona bem na prática - mas, ainda assim, é melhor não fazer isso.

— Jesper Mortensen

O BIND se recusará a carregar a zona se você apontar um registro MX ou SRV para um CNAME ... Eu provavelmente deveria ter deixado claro que o registro MX precisa apontar para o registro A. Obrigado.

— Chris S

@ChrisS, que tal editar sua resposta e mencionar claramente o fato de que um registro MX não pode apontar para uma entrada CNAME?

— Alexis Wilke