Resumo

  • O RFC 2672 criou o DNAME em 1999 para substituir o sufixo proprietário pelo sufixo-alvo em consultas a qualquer nome descendente. Uma regra passou a representar uma coleção aberta de aliases.
  • O proprietário do DNAME não é redirecionado e a regra não delega uma zona. O ápice ainda precisa de SOA e NS; delegação continua sendo um conjunto NS no pai, situado no corte da zona.
  • O RFC 6672 consolidou limites descobertos na operação: CNAME sintetizado por consulta, validação do DNAME assinado, ocultação de dados descendentes, rejeição do curinga, contenção de ciclos e YXDOMAIN para um resultado longo demais.

A operação que faltava

O DNS de RFC 1034 já distinguia duas formas de encaminhar uma busca. Um CNAME declarava um nome exato como alias de outro. Um conjunto NS em um corte de zona indicava os servidores autoritativos da zona filha.

Um mecanismo tratava de identidade em um nó; o outro distribuía administração. Nenhum deles dizia “preserve todas as etiquetas à esquerda e troque somente o sufixo compartilhado”.

Para uma organização saindo de antigo.example, criar um CNAME para www não cobria mail, lab.mail nem nomes futuros. Delegar antigo.example a outro operador mudaria a autoridade, embora a necessidade pudesse ser apenas manter caminhos antigos funcionando.

Havia espaço para algo maior que um alias individual e menor que uma transferência de zona. O DNAME foi desenhado para ocupar esse espaço sem fingir que as duas operações eram equivalentes.

Um sufixo virou regra

RFC 2672 publicou o DNAME, tipo 39, em agosto de 1999. Quando o proprietário do registro coincide com o final de um nome descendente, a resolução substitui esse sufixo pelo nome-alvo. A comparação ocorre por etiquetas DNS completas.

Se antigo.example aponta para novo.example, www.lab.antigo.example se torna www.lab.novo.example. A parte www.lab permanece. A zona de origem não copia os dados do destino e não adquire controle sobre eles.

O texto original relacionou a ideia a renumeração de redes, DNS reverso e mudança de nome organizacional. Esses exemplos explicam o problema de projeto; não medem uso atual. O ganho era administrativo: uma instrução alcançava descendentes conhecidos, desconhecidos e ainda inexistentes.

Essa compressão concentrava impacto. Um erro em uma linha podia mudar o trajeto de uma subárvore inteira. Menos configuração não significava menos poder.

O nome no topo não acompanhava os descendentes

O atual RFC 6672 torna explícita a exceção central. O DNAME redireciona nomes abaixo do proprietário, não o próprio proprietário.

Assim, www.antigo.example pode seguir para o novo espaço, enquanto antigo.example continua sendo respondido no ápice antigo. Outros tipos compatíveis podem existir ali. Se o proprietário for ápice de zona, SOA e NS continuam obrigatórios.

Por isso o DNAME não espelha uma zona inteira. Durante uma mudança institucional, o MX do ápice antigo talvez precise ser repetido. Servidor web, certificado e política de correio precisam aceitar o nome antigo. O DNS pode encontrar outro nome; não pode obrigar a aplicação a considerar as identidades iguais.

A exceção delimita a promessa correta. DNAME preserva uma relação estrutural entre descendentes. Não declara que dois domínios, duas organizações ou duas autoridades são uma só coisa.

O alias individual era criado no momento da resposta

Ao aplicar a substituição, o servidor inclui o DNAME e sintetiza um CNAME para a pergunta exata. A consulta por www.lab.antigo.example pode receber um CNAME para www.lab.novo.example, embora esse registro nunca tenha sido armazenado na zona.

O DNAME é a política geral publicada. O CNAME sintetizado é sua consequência para uma transação. Clientes familiarizados apenas com CNAME conseguem seguir o resultado, e servidores recursivos com cache devem poder realizar a síntese por eles.

A regra de TTL mudou com a experiência. O desenho original usava zero. O RFC 6672 passou a usar o TTL do DNAME, mas exige que resolvedores aceitem os dois valores porque implementações antigas continuaram em produção.

Também foi abandonada a ideia de um sinal EDNS que anunciasse entendimento de DNAME: ele nunca foi especificado. A compatibilidade veio de respostas comuns e comportamento verificável, não de uma negociação imaginária.

Assinar a regra bastava para verificar a derivação

Uma zona não sabe de antemão todos os nomes descendentes que serão perguntados e não pode pré-assinar infinitos CNAMEs. O DNSSEC assina o DNAME.

O validador confirma a assinatura, refaz a substituição e verifica se o CNAME não assinado corresponde exatamente ao resultado. A prova é formada por regra autenticada e cálculo determinístico. O servidor não recebe liberdade para inventar outro destino.

As etiquetas à esquerda precisam permanecer, o sufixo deve coincidir em fronteiras de etiquetas e o alvo deve vir do DNAME assinado. Uma resposta que viole qualquer ponto não deriva da regra comprovada.

Ainda assim, a primeira etapa válida não autentica todo o caminho. Podem seguir outro DNAME, CNAME, uma zona não assinada ou um erro. RFC 6604 esclarece que RCODE e bits de estado descrevem o resultado terminal da cadeia. Um redirecionamento autêntico pode terminar em ausência ou falha.

Apontar uma consulta não delegava poder

RFC 9499 chama de alias um subdomínio do proprietário de DNAME. Para delegação, a definição é outra: o pai adiciona um conjunto NS para a origem da zona filha em um corte de zona.

Uma referral NS muda os servidores aos quais o resolvedor atribui autoridade pelo nome original. O DNAME muda o nome que será procurado. O novo nome então percorre a hierarquia de delegações que já existe no destino.

Por isso um DNAME não pode dividir, fora do ápice, o mesmo proprietário com um NS que marca delegação. Se a zona filha usar DNAME no ápice, ele fica abaixo do corte, nos dados autoritativos da filha, ao lado de SOA e NS.

O operador da origem controla o ponteiro. Os operadores pai e filho controlam a delegação da origem. O operador do destino controla os dados finais. Uma resposta contínua não funde esses três poderes nem transfere obrigações entre eles.

A regra podia esconder o que ainda estava no arquivo

Não devem existir registros abaixo do proprietário de DNAME na mesma zona. Se o servidor os carregar, eles ficam ocultos: a busca encontra a regra antes e parte para o destino.

Adicionar uma linha pode, portanto, fazer vários nomes sumirem da visão pública sem removê-los do conteúdo da zona. Durante a transição, caches podem guardar dados descendentes antigos e um DNAME novo. O RFC tolera estratégias temporárias e espera que a expiração dos TTLs restaure consistência.

Uma implantação responsável começa pelo inventário da subárvore. A reversão também obedece ao tempo distribuído: apagar o registro na autoridade não revoga cópias ainda válidas nos caches.

O DNAME é único no proprietário e não convive ali com CNAME. Uma regra pode ter alcance amplo, mas o protocolo não permite duas instruções concorrentes no mesmo ponto.

Um curinga passaria a fabricar autoridade de redirecionamento

Um DNAME normal é uma regra fixa que produz CNAMEs específicos. Com proprietário curinga, a expansão criaria primeiro o dono da própria regra e depois essa regra criaria o redirecionamento.

RFC 4592 identificou aí não determinismo e ameaça à coerência dos caches. O RFC 6672 desaconselha a combinação e permite ao servidor avisar, rejeitar atualização ou recusar a zona.

O limite separa dois tipos de síntese. Derivar um resultado de um fato autoritativo fixo é auditável. Derivar também o fato que concede poder de redirecionar torna obscuros origem e escopo.

O DNS precisava aceitar uma quantidade aberta de perguntas. Não precisava inventar uma quantidade aberta de regras de controle ao respondê-las.

Ciclos e nomes grandes cobravam o preço da abstração

DNAMEs podem formar ciclos entre si ou com CNAMEs. Uma substituição pode devolver o nome ao espaço coberto pela própria regra. Resolvedores e servidores devem limitar recursos, embora algumas cadeias longas sejam legítimas.

Se a troca de sufixo produzir um nome maior que o limite do DNS, o servidor autoritativo retorna YXDOMAIN e inclui o DNAME e sua assinatura, quando houver. Não é NXDOMAIN: o nome original não foi simplesmente negado; o resultado calculado é impossível de representar.

Os alvos de NS, MX, PTR e SRV também precisam ser nomes canônicos. A busca por seus endereços não deve depender de CNAME ou DNAME. Nomes usados para sustentar a própria descoberta de autoridade e serviço ficam fora desse atalho.

Os limites distribuem custos. O administrador de origem evita ciclos e expansão excessiva. A autoridade comunica a falha correta. O resolvedor impede trabalho ilimitado. Economia de configuração não autoriza transferir custo sem teto aos demais.

Continuidade de resolução não é continuidade institucional

O DNAME pode manter nomes antigos alcançáveis. Ele preserva correspondência sintática e caminho de consulta; não preserva sozinho propriedade, contrato, chaves, certificados, disponibilidade nem aceitação pelo serviço.

Uma transição confiável registra três evidências: quem ainda pode alterar a regra de origem, quem controla os dados de destino e quem responde pela aceitação das identidades antiga e nova. Quanto mais suave parecer a resolução, mais importante é não inferir essas relações.

A história do DNAME mostra como a Internet amplia função sem apagar a fronteira que permite responsabilização. O registro conseguia mover uma busca pela árvore. Não conseguia mover a autoridade que organizava a árvore — e essa limitação tornava seu alcance confiável.

Fontes e limites da evidência

A arquitetura de CNAME, zonas e delegações está no RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html

A especificação original do DNAME está no RFC 2672: https://www.rfc-editor.org/rfc/rfc2672.html

O problema do DNAME curinga está no RFC 4592: https://www.rfc-editor.org/rfc/rfc4592.html

O estado terminal de cadeias de redirecionamento está no RFC 6604: https://www.rfc-editor.org/rfc/rfc6604.html

As regras atuais de substituição, síntese, DNSSEC e falha estão no RFC 6672: https://www.rfc-editor.org/rfc/rfc6672.html

As definições atuais de alias e delegação estão no RFC 9499: https://www.rfc-editor.org/rfc/rfc9499.html

As fontes não medem adoção global atual nem benefício operacional universal. Renumeração e mudança organizacional são exemplos de projeto. Uma resolução DNAME bem-sucedida não prova proprietário comum, aceitação pela aplicação, validade de certificado ou transferência de autoridade.