DNS64: A Revolução Oculta da Internet IPv6 que os Especialistas Não Querem que Descubra!

Durante a inevitável e longa transição do IPv4 para o IPv6, uma batalha silenciosa está a decorrer: milhões de dispositivos em redes apenas IPv6 ainda precisam de aceder a serviços que continuam exclusivamente em IPv4. É aqui que entram em cena os heróis não celebrados da Internet moderna — o poderoso par NAT64 e DNS64.

DNS64 é a chave mágica que faz parecer que um servidor IPv4 suporta IPv6, enganando positivamente o cliente para garantir compatibilidade total. Quando um cliente IPv6-only tenta aceder a um domínio como www.v4-only.example, o pedido AAAA vai para um resolvedor DNS64. Este, ao não encontrar registos AAAA, interroga o name server autoritativo (como ns1.v4-only.example) à procura de registos A. E se encontrar, não os devolve diretamente! Em vez disso, gera registos AAAA falsos mas funcionais, com base num prefixo IPv6 configurado (como 64:ff9b::/96), transformando o IPv4 em algo que os clientes IPv6 conseguem compreender.

E o cliente acredita! Acha que está a comunicar com um destino compatível com IPv6. Mas, na verdade, está a falar com um servidor NAT64 que intercepta o pacote, traduz o endereço e encaminha-o para o verdadeiro servidor IPv4. O milagre repete-se na resposta: o servidor IPv4 envia a resposta ao NAT64, que a reconstrói como IPv6 e a envia de volta ao cliente.

Entenda passo a passo o processo ilustrado na imagem:

  1. O cliente envia uma query AAAA para www.v4-only.example, à procura de um endereço IPv6.
  2. O resolvedor recursivo DNS64 interroga o name server autoritativo ns1.v4-only.example, que não retorna registos AAAA.
  3. O DNS64 gera registos AAAA falsos (sintetizados) com base no endereço A obtido, utilizando o prefixo configurado (por ex., 64:ff9b::/96).
  4. O cliente envia um pacote IPv6 para esse endereço sintético, que é roteado diretamente para o servidor NAT64.
  5. O servidor NAT64 traduz o endereço e comunica-se com o servidor original IPv4.
  6. A resposta do servidor IPv4 é enviada de volta ao NAT64 via IPv4.
  7. O NAT64 converte novamente o pacote para IPv6 e entrega ao cliente como se fosse uma resposta nativa.

Com BIND 9.8.0+, esta magia é configurável com blocos dns64, permitindo:

  • definir prefixos personalizados;
  • aplicar apenas a determinados clientes com clients;
  • evitar a tradução de endereços internos com mapped;
  • excluir certos AAAA válidos com exclude;
  • restringir a queries recursivas com recursive-only;
  • e até quebrar intencionalmente a validação DNSSEC com break-dnssec.

Exemplo de configuração DNS64 com múltiplas opções:

Bash
dns64 64:ff9b::/96 {
    clients { 2001:db8:cafe:1::/64; };
    mapped { !10/8; !172.16/12; !192.168/16; any; };
    exclude { 64:ff9b::/96; };
    recursive-only yes;
    break-dnssec yes;
};

DNSSEC e DNS64: conflito silencioso

DNSSEC valida respostas DNS assinadas. Mas DNS64 quebra esse paradigma. Quando um cliente IPv6-only pede um registo AAAA e a zona está assinada, o servidor recursivo pode validar a ausência de AAAAs, mas ainda assim fabricar um AAAA falso baseado em registos A válidos. Isso destrói a confiança criptográfica — a menos que o pedido traga o sinalizador DNSSEC OK (DO), caso em que o BIND recusa-se a sintetizar. Para forçar mesmo assim, usa-se break-dnssec yes.

DNS64 e resolução reversa (reverse mapping)

Quer saber como uma morada IPv6 sintetizada é resolvida inversamente? Simples: o DNS64 responde com um CNAME redirecionando o nome sob ip6.arpa para o nome tradicional in-addr.arpa baseado no IPv4 original. Por exemplo:

Bash
1.0.0.0.8.a.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.6.4.0.0.ip6.arpa.    CNAME
1.0.168.192.in-addr.arpa.

Atenção ao uso misto com clientes dual-stack

Ao ativar DNS64 para todos os clientes, dispositivos dual-stack que poderiam usar IPv4 diretamente acabam por ser forçados a usar NAT64 — aumentando latência e sobrecarregando o servidor NAT64. A melhor prática é restringir o DNS64 a redes IPv6-only com ACLs bem definidas.

Prefixos personalizados e sufixos

Por padrão, usa-se o prefixo reservado 64:ff9b::/96, mas pode-se usar outros desde que respeitem RFCs e estejam configurados no NAT64. Prefixos como /32, /48 ou /64 permitem configurar um suffix, embora o sufixo seja opcional e por padrão seja ::.

Artigos Relacionados