Por que um registro CNAME não pode ser usado no apex (aka root) de um domínio?

Question

This is a Canonical Question about CNAMEs at the apices (or roots) of zones

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

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

Em um cenário de melhor caso, o software de servidor de nomes pode se recusar a carregar a configuração e, no pior dos casos, pode aceitar essa configuração e invalidar a configuração de example.com.

Recentemente, pedi a uma empresa de hospedagem de sites que passasse instruções para uma unidade de negócios de que precisávamos para CNAME o ápice de nosso domínio para um novo registro. Sabendo que isso seria uma configuração de suicídio quando alimentado com o BIND, eu os avisei que não poderíamos cumprir e que isso era um aviso de boa aparência em geral. A empresa de webhosting assumiu a postura de que não é totalmente proibido pelas RFCs de definição padrão e que o software deles oferece suporte. Se não pudéssemos CNAME o apex, o conselho deles era não ter nenhum registro de apex e eles não forneceriam um servidor de redirecionamento. ... o que?

A maioria de nós sabe que RFC1912 insiste que A CNAME record is not allowed to coexist with any other data. , mas sejamos honestos conosco mesmos, essa RFC é apenas informativo. O mais próximo que eu sei de palavrões que proíbe a prática é de RFC1034 :

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

Infelizmente eu estive na indústria por tempo suficiente para saber que "não deveria" não é o mesmo que "não deve", e isso é suficiente para a maioria dos desenvolvedores de software se enforcarem. Sabendo que qualquer coisa menos do que um link conciso para um slam dunk seria um desperdício do meu tempo, acabei deixando a empresa escapar com uma bronca por recomendar configurações que poderiam quebrar software comumente usado sem divulgação adequada.

Isso nos leva ao Q & A. Pela primeira vez, gostaríamos que obtivéssemos realmente técnicas sobre a loucura dos CNAMEs do apex e não contornássemos o problema como geralmente fazemos quando alguém posta no assunto. O RFC1912 está fora dos limites, assim como qualquer outro RFC informativo aplicável aqui que eu não tenha pensado. Vamos calar esse bebê.

    

Answer 1

CNAME registros foram originalmente criados para permitir que vários nomes forneçam o mesmo recurso ser alias para um único "nome canônico" para o recurso. Com o advento da hospedagem virtual baseada em nome, tornou-se comum usá-los como uma forma genérica de alias de endereços IP. Infelizmente, a maioria das pessoas que vêm de um histórico de hospedagem na Web espera que CNAME registros indiquem equivalência no DNS , o que nunca foi a intenção. O ápice contém tipos de registro que são claramente não usados na identificação de um recurso de host canônico ( NS , SOA ), que não pode ter um alias sem quebrar o padrão em um nível fundamental. (particularmente em relação aos cortes de zonas )

Infelizmente, o padrão DNS original foi escrito antes de os órgãos de governança perceberem que o palavreado explícito era necessário para definir um comportamento consistente ( RFC 2119 ). Foi necessário criar o RFC 2181 para esclarecer vários casos pontuais devido à formulação vaga, e o palavreado atualizado torna mais claro que um CNAME não pode ser usado para obter o alias do apex sem quebrar o padrão.

6.1. Zone authority

The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone. Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone.

Isso estabelece que os registros SOA e NS são obrigatórios, mas não diz nada sobre A ou outros tipos que aparecem aqui. Pode parecer supérfluo citar isso então, mas se tornará mais relevante em um momento.

RFC 1034 foi um pouco vago sobre os problemas que podem surgir quando um CNAME existe ao lado de outros tipos de registro. A RFC 2181 elimina a ambiguidade e declara explicitamente os tipos de registro que podem existir ao lado deles:

10.1. CNAME resource records

The DNS CNAME ("canonical name") record exists to provide the canonical name associated with an alias name. There may be only one such canonical name for any one alias. That name should generally be a name that exists elsewhere in the DNS, though there are some rare applications for aliases with the accompanying canonical name undefined in the DNS. An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data. That is, for any label in the DNS (any domain name) exactly one of the following is true:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

"nome do alias" neste contexto refere-se ao lado esquerdo do registro CNAME . A lista com marcadores deixa claro que os registros SOA , NS e A não podem ser vistos em um nó onde também aparece CNAME . Quando combinamos isso com a seção 6.1, é impossível que exista um CNAME no ápice, já que ele teria que conviver com os registros SOA e NS obrigatórios.

(Isto parece fazer o trabalho, mas se alguém tiver um caminho mais curto para a prova, por favor, dê uma chance a isso.)

Atualização:

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

Na minha opinião, isso é um desserviço à comunidade DNS maior: não é, de fato, um registro CNAME, e engana as pessoas, acreditando que outro software é deficiente por não permitir isso. (como minha pergunta demonstra)

    

Answer 2

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

The DNAME RR and the CNAME RR [RFC1034] cause a lookup to (potentially) return data corresponding to a domain name different from the queried domain name. The difference between the two resource records is that the CNAME RR directs the lookup of data at its owner to another single name, whereas a DNAME RR directs lookups for data at descendants of its owner's name to corresponding names under a different (single) node of the tree.

For example, take looking through a zone (see RFC 1034 [RFC1034], Section 4.3.2, step 3) for the domain name "foo.example.com", and a DNAME resource record is found at "example.com" indicating that all queries under "example.com" be directed to "example.net". The lookup process will return to step 1 with the new query name of "foo.example.net". Had the query name been "www.foo.example.com", the new query name would be "www.foo.example.net".