Li em vários blogs que um CNAME não pode coexistir com outros registros que tenham o mesmo nome do registro CNAME.
Não encontrei um bom exemplo explicando o problema.
Aqui está um exemplo do blog:
Os registros CNAME não podem coexistir com outros registros que tenham o mesmo FQDN que o registro CNAME porque eles substituem efetivamente todos os outros registros pelo mesmo FQDN.
Por exemplo, um registro CNAME FQDN é example.com e você deseja criar um registro A FQDN example.com. Isso não é permitido porque o FQDN do registro A é idêntico ao FQDN do registro CNAME, tornando o registro A sem propósito.
Não acho o exemplo claro o suficiente para entender o problema.
Estou tentando entender o que a explicação significa.
Imagine que eu configurei:
Nome do domínio | TTL | Aula | Tipo de registro | Valor |
---|---|---|---|---|
aliasnome.exemplo.com | 300 | EM | CNAME | nome.exemplo.com |
nome.exemplo.com | 300 | EM | A | 10.0.0.1 |
O que acontece nessa configuração?
EDIT : Estou corrigido pelas respostas de que meu exemplo acima está correto/válido.
Colocando uma configuração incorreta/inválida abaixo. O exemplo acima veio do meu entendimento errado de exemplos de texto sem ilustrações de tabela.
Nome do domínio | TTL | Aula | Tipo de registro | Valor |
---|---|---|---|---|
nome.exemplo.com | 300 | EM | CNAME | outronome.exemplo.com |
nome.exemplo.com | 300 | EM | A | 10.0.0.1 |
Meu entendimento é que a última configuração é inválida porque, de acordo com as RFCs, o CNAME é usado primeiro e o registro A nunca é usado.
Estou certo quanto à causa da incorreção desta última tabela?
Ou em geral o que acontece no caso desta última configuração?
O fato de o CNAME não poder coexistir com outros tipos de registro está relacionado a isto:
NÃO o cenário que você descreveu. A razão para ser inválido parece um tanto arbitrária, mas acredito que seja uma exigência das RFCs.
Seu cenário descrito é bastante válido – e amplamente utilizado. Por exemplo
Seu exemplo é válido.
O que não é válido é
cname.example.com
foo.example.org
cname.example.com
192.0.2.1
Seu último exemplo é inválido, não porque "algo é usado primeiro". É inválido porque viola a lógica por trás do CNAME.
A lógica da qual estou falando é que CNAME define o nome como um alias de algum outro nome, que é então chamado de nome canônico , sendo "cname" uma abreviação disso. O registro
alias CNAME canonical-name
diz literalmente: “ alias é a outra forma de nome canônico ”. É muito parecido com dizer: “Bob é a outra forma de Robert”. É um absurdo acrescentar: “e também alias é outra coisa”, não faria sentido, pelo menos, em informática. Ele não se enquadra no modelo de dados, portanto é explicitamente proibido pela RFC.O mesmo raciocínio está por trás do CNAME no ápice da zona : um ápice deve definir pelo menos dois registros, SOA e NS, o que já entra em conflito com o requisito de que o CNAME deve aparecer sozinho. (Inicialmente pensei em votar para que esta questão fosse encerrada como uma duplicata da pergunta vinculada, porque essa resposta realmente responde a esta também; no entanto, parece que esta é outra questão, mais ampla, e faria mais sentido fazer na direção oposta.)
Houve uma atualização nesta regra quando o DNSSEC foi introduzido. Os registros de assinatura devem aparecer junto com o CNAME para certificar sua validade em uma zona assinada. Mas nenhum outro registro pode. (RFC 2181 diz “pode”, mas o registro não funcionará sem assinar em uma zona assinada.)