Cadeias de CNAME: do alias até o IP

Um registro CNAME torna um nome DNS um alias de outro nome de host canônico. O alias em si não contém um endereço IPv4 ou IPv6: o resolvedor segue o destino e procura ali os dados solicitados. Uma cadeia ocorre quando um alias aponta para um nome que também é um alias, ou quando a configuração de DNS de um provedor introduz vários destinos gerenciados antes de um endereço ser retornado. Isso é comum em plataformas de hospedagem e CDNs. Entender a cadeia ajuda a explicar por que uma consulta simples pode mostrar primeiro um nome de host e só depois de etapas adicionais de resolução um IP.

Siga cada elo com atenção

Suponha que www.example.com seja um CNAME para customer.hosting.example, que por sua vez é alias de um nome de serviço regional. O resolvedor continua seguindo a cadeia até encontrar os dados de endereço solicitados ou chegar a um erro ou a uma configuração inválida. Cada destino de alias é um nome DNS separado e pode ter o seu próprio TTL e a sua própria titularidade no provedor. Ao depurar, registre cada elo em vez de apenas o endereço final. Se o destino estiver com erro de digitação, inexistente ou apontar de volta para um loop, a resolução pode falhar mesmo que o primeiro registro CNAME pareça corretamente formatado em um painel.

As regras do CNAME impõem restrições. Um nome que é um CNAME geralmente não pode ter outros dados não relacionados no mesmo nome de proprietário, exceto registros relacionados ao DNSSEC e implementações especiais de provedores. É por isso que um CNAME no apex da zona entra em conflito com os registros SOA e NS exigidos no DNS padrão. Alguns serviços de DNS oferecem recursos como ALIAS, ANAME ou flattening para dar uma conveniência semelhante no apex, mas implementam esses recursos de maneiras diferentes e retornam publicamente registros de endereço sintetizados. Não presuma que um recurso da interface de um provedor chamado alias seja necessariamente um CNAME literal na rede.

TTL e a titularidade no provedor importam

Cada etapa de uma cadeia de resolução pode ser armazenada em cache de forma independente. Uma alteração no destino final pode não substituir imediatamente uma resposta de alias já guardada em cache por um resolvedor recursivo, e elos diferentes podem ter valores de TTL diferentes. Se um provedor pedir que você adicione um CNAME para verificação de domínio, use exatamente o nome e o destino que ele especificar, inclusive qualquer prefixo de sublinhado exigido. Não redirecione um CNAME existente sem identificar o que depende dele hoje. Uma cadeia é tão confiável quanto os registros e os serviços por trás de cada elo.

• Capture todos os destinos CNAME, do alias até o endereço.
• Verifique A e AAAA no destino final de forma independente.
• Evite aliases circulares e registros conflitantes no mesmo nome.
• Confirme se o apex flattening é um recurso do provedor ou um registro DNS padrão.
• Compare os TTLs quando um destino atualizado não aparece em todos os lugares.

Usando uma cadeia em uma migração

Os CNAMEs facilitam para um provedor de hospedagem trocar os seus endereços IP subjacentes sem exigir que o cliente edite um registro A a cada vez. O custo é a dependência do nome de destino e do seu provedor. Antes de migrar de plataforma, confirme o novo destino, atualize o alias na autoridade DNS correta e verifique a cadeia inteira a partir de um resolvedor público. Mantenha o serviço anterior ativo enquanto os caches ainda puderem referenciar o destino antigo. Se uma ferramenta de consulta parar no primeiro alias, use um resolvedor ou verificador que consiga exibir os elos seguintes e, depois, teste o serviço final pelo nome de host pretendido.

Para a diferença essencial entre registros de endereço e de alias, leia CNAME vs. registro A. A referência de registros DNS explica outros tipos comuns, e a ferramenta de consulta de domínio pode mostrar os dados públicos de DNS de um nome de host. Um CNAME visível é um ponteiro, e não o destino em si; rastrear a cadeia completa é a maneira confiável de entender para qual endpoint o DNS leva neste momento.

Evite cadeias frágeis durante mudanças de provedor

Cada alias adicional acrescenta mais uma dependência que precisa continuar válida e pode introduzir mais um tempo de vida de cache. Uma cadeia longa não está automaticamente quebrada, mas torna a resposta final mais difícil de raciocinar e pode complicar migrações quando vários provedores são donos de elos diferentes. Mantenha a cadeia o mais curta possível na prática, documente qual parte controla cada destino e verifique periodicamente se os nomes de plataformas antigas deixaram de ser referenciados. Antes de encerrar uma conta ou trocar de fornecedor, procure na zona por aliases que apontem para os nomes de host dele. Caso contrário, um primeiro CNAME de aparência correta pode continuar dependendo de um destino desativado, que só falha depois que o provedor antigo for desligado.