Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

04 - CNAME (Apelido-Alias)

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

Registro CNAME (Canonical Name Record)

1. Definição e Especificação

O Registro CNAME (Canonical Name Record) é o mecanismo de abstração e aliasing do sistema de nomes de domínio. Padronizado nas RFCs 1034 e 1035 (1987), sua função técnica é mapear um nome de domínio "apelido" (alias) para um nome de domínio "real" ou canônico. Diferente do registro A, o CNAME não aponta para um endereço IP, mas sim para outro nome, permitindo que administradores gerenciem infraestruturas complexas de forma flexível e centralizada.

Características Formais

Atributo Valor
Tipo (TYPE) 5 (decimal)
Classe (CLASS) IN (Internet)
RFC de referência 1034, 1035, 2181
RDATA Nome de domínio (FQDN) canônico
TTL padrão comum 300-3600 s
Permite apex? Não (RFC 1034 seção 3.6.2)

2. Estrutura Técnica e a Busca em Segundo Salto

Quando o servidor DNS recursivo encontra um registro CNAME durante a resolução, ele deve iniciar um novo ciclo de busca para o nome apontado.

Exemplo Prático

Consulta: www.exemplo.com → Tipo A

Resposta da zona exemplo.com:
    www.exemplo.com.   3600  IN  CNAME  exemplo.com.
    exemplo.com.       3600  IN  A      192.0.2.10

Passo a passo do resolver:
    1. Recebe consulta A para www.exemplo.com
    2. Consulta servidor autoritativo de exemplo.com
    3. Recebe CNAME apontando para exemplo.com
    4. Inicia NOVA consulta A para exemplo.com
    5. Recebe 192.0.2.10
    6. Retorna ao cliente com ambos os registros

Este processo aumenta ligeiramente a latência de resolução devido à necessidade de consultas adicionais. Em cache quente (já houve consulta ao canônico), o custo é zero. Em cache frio, o custo é uma RTT adicional ao servidor autoritativo.

3. A Restrição Crítica: Exclusividade de Registros

Uma das regras mais rígidas e frequentemente violadas do DNS é a impossibilidade de coexistência do CNAME com outros tipos de registros para o mesmo nome.

RFC 1034 (Seção 3.6.2)

"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."

Esta restrição foi flexibilizada pela RFC 2181 (seção 10.1) apenas para SIG (DNSSEC) e NSEC, mas para todos os efeitos práticos em zonas sem DNSSEC, a regra permanece absoluta.

O Problema do Apex (Raiz da Zona)

Devido a essa regra, não é possível colocar um CNAME no domínio principal (ex: empresa.com.). Como a raiz da zona obrigatoriamente exige registros SOA e NS, o conflito impediria o funcionamento do domínio.

Solução Moderna: ALIAS/ANAME Records

Provedores como Route 53 (ALIAS), Cloudflare (CNAME Flattening), DNSimple (ALIAS) e NS1 (ANAME) implementam extensões proprietárias que resolvem o CNAME no lado do servidor autoritativo e retornam o registro A diretamente ao cliente, contornando a limitação do apex:

; Cliente consulta:
    empresa.com → A

; Servidor autoritativo (Cloudflare) resolve internamente:
    empresa.com → CNAME → d1234.cloudfront.net → A 13.224.10.10

; Retorna ao cliente apenas o A:
    empresa.com.   3600  IN  A   13.224.10.10

4. Aplicações em Infraestrutura Cloud e CDNs

O registro CNAME é o coração tecnológico da escalabilidade na nuvem.

CDNs (Content Delivery Networks)

Quando se usa CloudFront, Akamai ou Cloudflare, o domínio imagem.empresa.com aponta (CNAME) para um nome gerado pelo provedor (ex: d1234.cloudfront.net). Isso permite que o provedor mude os IPs dinamicamente de acordo com a carga sem que o cliente precise alterar as configurações DNS.

SaaS (Software as a Service)

Plataformas como Shopify, GitHub Pages, Heroku e Zendesk utilizam CNAMEs para permitir que empresas usem domínios customizados (ajuda.empresa.com) que apontam para a infraestrutura centralizada do serviço.

Exemplos Típicos de Configuração

; Zona exemplo.com
$ORIGIN exemplo.com.
@                   IN  SOA   ns1.exemplo.com. admin.exemplo.com. (
                          2024011501 ; serial
                          3600       ; refresh
                          900        ; retry
                          1209600    ; expire
                          3600       ; minimum
)
@                   IN  NS    ns1.exemplo.com.
@                   IN  NS    ns2.exemplo.com.
@                   IN  A     192.0.2.10
@                   IN  MX    10 mail.exemplo.com.

www                 IN  CNAME d1234.cloudfront.net.
blog                IN  CNAME exemplo.github.io.
suporte             IN  CNAME empresa.zendesk.com.
api                 IN  CNAME api.elb.amazonaws.com.

5. Perspectiva de Segurança: DNS como Vetor de Invasão

Para um analista de segurança, registros CNAME mal configurados são portas de entrada silenciosas para ataques graves.

Subdomain Takeover (Sequestro de Subdomínio)

  • Cenário: Uma empresa cria um CNAME campanha.empresa.com apontando para um serviço de nuvem de terceiros (ex: empresa-campanha.herokuapp.com). Ao final da campanha, a empresa cancela o serviço no Heroku, mas esquece de apagar o CNAME no DNS.
  • Ataque: Um atacante registra o mesmo nome de subdomínio no provedor de nuvem (empresa-campanha) e assume o controle total sobre o conteúdo exibido no domínio legítimo da empresa.
  • Impacto: Phishing autenticado, roubo de cookies via mesmo domínio, bypass de CSP.

Técnicas de Detecção de Subdomain Takeover

# Listando CNAMEs de uma zona para identificar dangling pointers
dig +nocmd +noall +answer CNAME exemplo.com axfr 2>/dev/null | rg CNAME

# Verificando se o destino do CNAME ainda existe (404 = vulnerável)
for sub in www blog suporte api; do
  curl -sI "https://${sub}.exemplo.com" | head -1
done

# Subfinder + subjack para varredura automatizada
subfinder -d exemplo.com -silent | subjack -w /dev/stdin -t 50

6. Diagnóstico e Auditoria de Cadeias CNAME

É vital auditar a cadeia de resoluções:

# Consultando se um domínio é um apelido (CNAME)
dig shop.empresa.com CNAME

# Rastreando a cadeia completa de apelidos
host -v api.exemplo.com

# Consulta recursiva com flag +trace
dig +trace api.exemplo.com

# Verificando TTLs e cadeia completa em uma saída legível
dig +multiline api.exemplo.com ANY

Análise de Cadeias (Chaining)

Múltiplos CNAMEs apontando uns para outros (ex: A → B → C → IP) devem ser evitados, pois cada salto aumenta o risco de falha e a latência. O ideal técnico é manter a cadeia com no máximo um salto.

Loops de Resolução (Circular References)

Um erro de configuração comum é o loop de CNAME (ex: A aponta para B e B aponta de volta para A). Servidores DNS recursivos detectam o loop após alguns saltos (tipicamente 8-16) e retornam um erro SERVFAIL (rcode 2). Em BIND, o limite é controlado por max-recursion-queries (default 75).

7. CNAME e DNSSEC

CNAME e DNSSEC (RFC 4035) têm interação sutil:

  • Cada CNAME deve ter um registro RRSIG correspondente
  • O destino do CNAME deve ser autenticável via cadeia de confiança
  • Records de Tipo A do destino também devem ser assinados
  • Em zonas assinadas, registros NSEC/NSEC3 são adicionados para provar inexistência

8. Resumo Comparativo

Registro Aponta para Permite coexistir? RFC
A IPv4 (32 bits) Sim 1035
AAAA IPv6 (128 bits) Sim 3596
CNAME Outro FQDN Não (regra estrita) 1034
ALIAS Outro FQDN (resolvido no servidor) Sim (extensão proprietária) Não-padronizado
DNAME Domínio inteiro (wildcard-like) Limitado 6672
NS Servidor autoritativo Sim (na raiz) 1035

9. Conclusão

O registro CNAME é o que confere ao DNS sua capacidade de abstração moderna. Ele permite que endereços IP mudem e infraestruturas migrem sem afetar a marca ou a experiência do usuário. Compreender a lógica de encadeamento, a restrição de exclusividade, o problema do apex e as soluções modernas (ALIAS/CNAME Flattening) é essencial para gestão profissional de DNS. Combinado com auditorias regulares de dangling CNAMEs e validação de DNSSEC, garante resiliência e segurança à infraestrutura de nomes de qualquer organização.