Por que um registro CNAME não pode ser usado no ápice (também conhecido como raiz) de um domínio?

Esta é uma pergunta canônica sobre CNAMEs nos ápices (ou raízes) das zonas

É um conhecimento relativamente comum que CNAMEregistros no ápice de um domínio são uma prática tabu.

Exemplo: example.com. IN CNAME ithurts.example.net.

Na melhor das hipóteses, o software do servidor de nomes pode se recusar a carregar a configuração e, na pior das hipóteses, pode aceitar essa configuração e invalidar a configuração de exemplo.com.

Recentemente, uma empresa de hospedagem na web passou as instruções para uma unidade de negócios que precisávamos CNAME do ápice do nosso domínio para um novo registro. Sabendo que isso seria uma configuração suicida quando alimentado com o BIND, eu os avisei que não poderíamos cumprir e que esse era um conselho geral em geral. A empresa de hospedagem adotou a posição de que não é totalmente proibido pelas RFCs de definição padrão e que o software delas é compatível. Se não pudéssemos CNAME o ápice, o conselho deles era não ter nenhum registro do ápice e eles não forneceriam um servidor da web de redirecionamento. ...O que?

Muitos de nós sabemos que o RFC1912 insiste que A CNAME record is not allowed to coexist with any other data., mas sejamos honestos aqui, que o RFC é apenas informativo. O mais próximo que conheço de palavreado que proíbe a prática é o RFC1034 :

Se um RR CNAME estiver presente em um nó, nenhum outro dado deverá estar presente; isso garante que os dados para um nome canônico e seus aliases não possam ser diferentes.

Infelizmente, estou na indústria há tempo suficiente para saber que "não deveria" não é o mesmo que "não devo", e isso é corda suficiente para a maioria dos designers de software se envolver. Sabendo que qualquer coisa que não fosse um link conciso para um slam dunk seria um desperdício de tempo, acabei deixando a empresa escapar com uma bronca por recomendar configurações que poderiam quebrar o software usado sem a devida divulgação.

Isso nos leva às perguntas e respostas. Pela primeira vez, gostaria que fôssemos realmente técnicos sobre a loucura dos CNAMEs de ponta, e não contornássemos a questão como costumamos fazer quando alguém posta sobre o assunto. O RFC1912 está fora dos limites, assim como qualquer outro RFC informativo aplicável aqui que eu não tenha pensado. Vamos desligar esse bebê.

CNAMEos registros foram criados originalmente para permitir que vários nomes que fornecem o mesmo recurso sejam aliasados ​​a um único "nome canônico" do recurso. Com o advento da hospedagem virtual baseada em nome, tornou-se comum usá-los como uma forma genérica de alias de endereço IP. Infelizmente, a maioria das pessoas que tem experiência em hospedagem na web espera que os CNAMEregistros indiquem equivalência no DNS , o que nunca foi o objetivo. O ápice contém tipos de registro que claramente não são usados ​​na identificação de um recurso de host canônico ( NS, SOA), que não pode ser alternativo sem quebrar o padrão em um nível fundamental. (particularmente em relação a cortes de zona )

Infelizmente, o padrão DNS original foi escrito antes que os órgãos que governam os padrões percebessem que era necessária uma linguagem explícita para definir um comportamento consistente ( RFC 2119 ). Foi necessário criar o RFC 2181 para esclarecer vários casos de canto devido a termos vagos, e a palavreada atualizada deixa mais claro que um CNAME não pode ser usado para obter um alias de ápice sem quebrar o padrão.

6.1 Autoridade da zona

Os servidores autoritativos de uma zona são enumerados nos registros NS para a origem da zona, que, juntamente com um registro de início de autoridade (SOA), são os registros obrigatórios em todas as zonas. Esse servidor é autoritário para todos os registros de recursos em uma zona que não estão em outra zona. Os registros NS que indicam um corte de zona são propriedade da zona filho criada, assim como quaisquer outros registros para a origem dessa zona filho ou quaisquer subdomínios dela. Um servidor para uma zona não deve retornar respostas autorizadas para consultas relacionadas a nomes em outra zona, que inclui os registros NS e talvez A em um corte de zona, a menos que também seja um servidor para a outra zona.

Isso estabelece que SOAe os NSregistros são obrigatórios, mas não diz nada sobre Aou outros tipos que aparecem aqui. Pode parecer supérfluo que cite isso, mas se tornará mais relevante em um momento.

O RFC 1034 era um tanto vago sobre os problemas que podem surgir quando CNAMEexiste um ao lado de outros tipos de registro. O RFC 2181 remove a ambiguidade e declara explicitamente os tipos de registro que podem existir ao lado deles:

10.1 Registros de recursos CNAME

O registro DNS CNAME ("nome canônico") existe para fornecer o nome canônico associado a um nome alternativo. Pode haver apenas um nome canônico para qualquer apelido. Esse nome geralmente deve ser um nome que existe em outro lugar no DNS, embora existam alguns aplicativos raros para aliases com o nome canônico associado indefinido no DNS. Um nome alternativo (rótulo de um registro CNAME) pode, se o DNSSEC estiver em uso, possuir SIG, NXT e KEY RRs, mas pode não ter outros dados. Ou seja, para qualquer rótulo no DNS (qualquer nome de domínio), exatamente um dos seguintes é verdadeiro:

• existe um registro CNAME, opcionalmente acompanhado por SIG, NXT e KEY RRs,
• existe um ou mais registros, nenhum sendo CNAME,
• o nome existe, mas não possui RRs associados de qualquer tipo,
• o nome não existe.

"nome alternativo", neste contexto, refere-se ao lado esquerdo do CNAMEregistro. A lista com marcadores torna explicitamente claro que um SOA, NSe Aos registros não podem ser vistos em um nó onde um CNAMEtambém aparece. Quando combinamos isso com a seção 6.1, é impossível que CNAMEa exista no ápice, pois teria que viver ao lado de registros SOAe obrigatórios NS.

(Isso parece fazer o trabalho, mas se alguém tiver um caminho mais curto para a prova, dê uma olhada nele.)

Atualizar:

Parece que a confusão mais recente vem da recente decisão da Cloudflare de permitir que um registro CNAME ilegal seja definido no ápice dos domínios, para o qual eles sintetizarão os registros A. "Compatível com RFC", conforme descrito no artigo vinculado, refere-se ao fato de que os registros sintetizados pelo Cloudflare serão compatíveis com o DNS. Isso não altera o fato de que é um comportamento completamente personalizado.

Na minha opinião, isso é um desserviço para a comunidade DNS maior: na verdade, não é um registro CNAME e leva as pessoas a acreditar que outro software é deficiente por não permitir. (como minha pergunta demonstra)

O Internet Systems Consortium publicou recentemente um artigo no CNAME no ápice de uma zona , por que essa restrição existe e várias alternativas. É provável que isso não mude tão cedo, infelizmente:

Não podemos alterar como o registro CNAME especial é usado sem alterar todas as implementações de servidor DNS no mundo ao mesmo tempo. Isso ocorre porque seu significado e interpretação foram estritamente definidos no protocolo DNS; todas as implementações atuais de cliente e servidor DNS aderem a essa especificação. Tentar 'relaxar' ​​a maneira como o CNAME é usado em servidores autoritativos sem alterar simultaneamente todos os resolvedores de DNS atualmente em operação fará com que a resolução de nomes seja interrompida (e os serviços de web e email ficarão intermitentemente indisponíveis para as organizações que implementam soluções de servidor autoritativas 'relaxadas').

Mas há esperança:

Outra solução potencial atualmente em discussão seria adicionar um novo tipo de registro de recurso de DNS que os navegadores procurariam, que poderia existir no ápice. Esse seria um nome de host específico do aplicativo para solicitações http (semelhante à maneira como o MX funciona).

Prós: isso é completamente consistente com o design do DNS.
Contras: ainda não está disponível e exigiria uma atualização do cliente do navegador.

Se você estiver redirecionando uma zona inteira, use DNAME. De acordo com a RFC 6672 ,

O DNAME RR e o CNAME RR [RFC1034] fazem com que uma pesquisa (potencialmente) retorne dados correspondentes a um nome de domínio diferente do nome de domínio consultado. A diferença entre os dois registros de recurso é que o RR CNAME direciona a pesquisa de dados em seu proprietário para outro nome único, enquanto um RR DNAME direciona pesquisas de dados em descendentes do nome do proprietário para nomes correspondentes em um nó (único) diferente de a árvore.

Por exemplo, procure em uma zona (consulte RFC 1034 [RFC1034], Seção 4.3.2, etapa 3) o nome de domínio "foo.example.com", e um registro de recurso DNAME é encontrado em "example.com" indicando que todas as consultas em "example.com" sejam direcionadas para "example.net". O processo de pesquisa retornará à etapa 1 com o novo nome de consulta "foo.example.net". Se o nome da consulta fosse "www.foo.example.com", o novo nome da consulta seria "www.foo.example.net".