Resumo

  • O CNAME torna um owner name um alias para um único alvo. Para impedir que alias e destino produzam respostas incompatíveis, esse nome não pode reter dados comuns A, MX, TXT, NS ou equivalentes.
  • O resolvedor guarda o CNAME e recomeça a busca no alvo. A zona de origem controla o desvio; a autoridade do alvo controla os dados terminais. Isso não é delegação nem prova de identidade.

Um nome não podia cumprir dois papéis incompatíveis

Suponha que portal.example seja um CNAME para service.example.net. Ao receber uma consulta de endereço, o servidor de origem entrega o alias e o resolvedor procura A ou AAAA no alvo. Se a zona de origem também publicar um A próprio para portal.example, qual endereço o cache deve aceitar: o ligado diretamente ao nome antigo ou o alcançado pelo desvio?

O RFC 1034, publicado em novembro de 1987, não deixou o conflito para cada implementação. O owner do CNAME é o alias; o nome em RDATA é o destino canônico. Se há um CNAME num nó, nenhum outro dado comum deve existir ali.

Não era preferência estética. A regra impedia divergência entre dados do nome canônico e do alias. Também permitia ao resolvedor usar um CNAME em cache sem voltar à autoridade de origem para descobrir se outro tipo naquele owner contradizia o desvio.

A exclusividade criou uma autoridade pequena: o CNAME não determina endereço ou serviço. Determina onde a pergunta deve continuar.

A resposta mudava a próxima pergunta

O CNAME não é apenas outra grafia devolvida como dado. Quando QTYPE não é CNAME, o algoritmo do RFC 1034 coloca o registro na Answer, troca o QNAME de trabalho pelo alvo e reinicia a procura. Consultar CNAME é a exceção, pois o objetivo é examinar o desvio em si.

O RFC 9499 distingue o QNAME original enviado na Question, os QNAME efetivos visitados na cadeia e o QNAME final. Assim, a resposta pode repetir a pergunta original enquanto o RRset que realmente responde pertence a outro nome.

Essa distinção contém a evidência negativa. O alias pode existir e ter resposta autoritativa, embora o alvo não exista, esteja em falha ou pertença a outra zona. Um NXDOMAIN terminal não prova que o alias original nunca existiu.

Desvio não era delegação

Alias e delegação fazem o resolvedor avançar, mas transferem coisas diferentes. Um RRset NS no zone cut identifica os servidores com autoridade sobre a zona descendente. O CNAME permanece um dado publicado pela autoridade de origem sobre seu próprio nome. Ele inicia outra busca; não entrega a zona ao operador do alvo.

A origem cria, altera ou remove portal.example e escolhe o TTL do alias. A autoridade de service.example.net governa A, AAAA e outros dados terminais com seus próprios TTLs. Apontar para o alvo não concede poder de editá-lo; receber a referência não permite editar a origem.

O RFC 6604 esclareceu os estados em cadeias CNAME e DNAME. Uma resposta pode ser autoritativa no primeiro alias e carregar uma referência ou falha posterior. Autoridade sobre a primeira afirmação não é garantia do percurso inteiro.

Um alvo por alias não quer dizer um nome por máquina

“Canônico” levou a uma inferência excessiva: cada host ou interface teria apenas um nome oficial. O RFC 2181 recusou essa leitura. O DNS não impõe identidade nominal única a uma máquina.

A regra é mais estreita: um owner CNAME tem um único alvo canônico. Chamar o próprio owner de “um CNAME” também encobre a direção; o owner é o alias, enquanto o valor do registro é o nome canônico nessa relação.

Vários nomes podem conduzir ao mesmo serviço. Um nome que não seja alias pode conter diversos RRsets comuns. O que ele não pode fazer é ordenar “continue em outro lugar” e, ao mesmo tempo, apresentar-se como destino independente.

Por que o apex não podia usar o atalho

O apex de uma zona precisa conter SOA e NS. Como o owner CNAME não pode conviver com esses dados, o apex não pode ser um CNAME comum. O RFC 1912 registrou o perigo com um exemplo histórico de BIND: combinar CNAME e NS no apex podia fazer o servidor ignorar os demais recursos e tornar invisíveis os nomes abaixo da zona.

O comportamento exato era daquelas versões; a contradição pertence ao modelo. Um provedor pode sintetizar endereços no apex ou oferecer flattening. Pode ser um produto útil, mas não é o mesmo que um CNAME RR no wire. Misturá-los apaga as fronteiras de autoridade e cache necessárias ao diagnóstico.

NS e MX não podiam esconder o próximo endereço atrás de alias

O RFC 2181 também impede alias como target de NS ou exchange de MX. Respostas NS e MX podem acrescentar endereços em Additional para evitar consultas previsíveis. Esse processamento não segue primeiro um CNAME para depois anexar o endereço do nome canônico.

Usar alias nessas posições acrescenta consultas e carga; em situações difíceis de delegação, a falta do endereço pode impedir a resolução. O administrador deve resolver o alias uma vez e publicar diretamente o nome que possui os RRsets de endereço.

Não é uma proibição geral de nomes apontarem para nomes. É proteção para posições em que a descoberta previsível de endereço integra o caminho operacional.

O DNSSEC acrescentou prova, não outro destino

“Nenhum outro dado” ganhou uma exceção necessária com o DNSSEC. O RFC 2181 permitia registros de segurança da época; o RFC 4034 passou a exigir RRSIG e NSEC no owner CNAME de uma zona assinada.

Esses registros não competem com o alvo. RRSIG autentica o RRset CNAME; NSEC participa da negação autenticada e da evidência de tipos. Eles provam o estado do nó alias sem devolver endereço, rota de correio ou conteúdo de aplicação próprios.

O RFC 4033 limita a conclusão: DNSSEC oferece autenticação de origem, integridade e negação autenticada. Não certifica saúde do serviço, pessoa, empresa, contrato ou titularidade jurídica do nome de origem.

Cadeias eram aceitas; loops precisavam parar

Um alias pode apontar para outro. O RFC 1034 recomenda evitar muitos níveis por ineficiência, mas não transforma uma cadeia finita em erro. O resolvedor deve detectar loops e alvos terminais inexistentes.

O objeto operacional é um grafo. Cada aresta tem owner, autoridade, TTL e talvez estado DNSSEC; o RRset terminal tem outra vida. Dois caches podem mostrar fases diferentes de uma migração porque as arestas antigas expiram em momentos distintos.

Esse desacoplamento tem valor. A origem move um nome conhecido sem copiar dados finais; o alvo muda endereços sem editar todas as zonas que o referenciam. O preço é permitir mudanças independentes enquanto caches preservam afirmações anteriores.

Coordenação mínima exigia uma verdade sem mistura

O CNAME resolveu manutenção distribuída com um mecanismo deliberadamente fino. Não exigiu cadastro global de nomes equivalentes nem árbitro central para decidir qual endereço “pertence” ao alias. Bastou uma aresta inequívoca, armazenável e repetível por qualquer resolvedor.

A exclusividade é o centro institucional do projeto. O nome de origem pode ser desvio ou destino, não ambos. Ao escolher o desvio, mantém autoridade real e estreita: publicar um alvo, preservar a evidência da cadeia e deixar os dados terminais sob a autoridade que os controla.

Fontes e limites

O modelo e o algoritmo vêm do RFC 1034 e do RFC 1035; erros operacionais e esclarecimentos, dos RFC 1912 e 2181; exceções DNSSEC, dos RFC 4033 e 4034; estados de cadeia e terminologia, dos RFC 6604 e 9499. Eles não provam implantação atual, flattening específico, limites modernos de cadeia, frequência de alias abandonado, propriedade de aplicações ou disponibilidade presente.