Dia 24: DNS Avançado — Split-Horizon, DLZ, CDN e DoH

No Dia 1 abordámos os fundamentos de redes e no Dia 8 configurámos DNS básico. Hoje, no Dia 24 do curso de redes, avançamos para técnicas que vão além da simples resolução de nomes: split-horizon DNS, load balancing via round-robin, integração com CDN, DNS-over-HTTPS (DoH), DNS-over-TLS (DoT) e DLZ (Dynamically Loadable Zones).

Tempo de leitura: ~12 minutos

Neste artigo

• 1. Introdução ao DNS Avançado
• 2. Split-Horizon DNS
• 3. DNS Load Balancing (Round-Robin)
• 4. CDN e DNS
• 5. DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT)
• 6. DLZ — Dynamically Loadable Zones
• 7. Erros Comuns e Lista de Verificação

1. Introdução ao DNS Avançado

O DNS básico resolve nomes em endereços IP usando ficheiros de zona estáticos e um servidor recursivo. Mas em ambientes modernos — redes empresariais, infra-estruturas na nuvem, fornecedores de CDN — o DNS precisa de fazer muito mais: servir respostas diferentes consoante quem pergunta, distribuir carga entre múltiplos servidores, integrar-se com bases de dados dinâmicas e proteger a privacidade das consultas através de encriptação.

As técnicas que vamos cobrer neste artigo são amplamente utilizadas em produção. O split-horizon é comum em redes corporativas. O round-robin DNS é a forma mais simples de load balancing. A integração CDN-DNS é o que faz com que sites globais carreguem rapidamente em qualquer continente. DoH e DoT são cada vez mais adoptados por navegadores e sistemas operativos. E o DLZ permite que o DNS tire dados de bases de dados externas em tempo real.

2. Split-Horizon DNS

Split-horizon DNS (também chamado split-view DNS) é uma configuração em que o servidor DNS responde de forma diferente dependendo do endereço IP de origem da consulta. A ideia é simples: clientes internos recebem um conjunto de registos, enquanto clientes externos recebem outro conjunto — possivelmente com menos informações ou com endereços IP públicos em vez de privados.

Por exemplo, uma empresa pode ter intranet.empresa.pt a resolver para 192.168.1.50 quando consultado de dentro da rede, e para um IP público (ou NXDOMAIN) quando consultado da Internet. Isto mantém os endereços internos privados sem precisar de nomes diferentes.

No BIND, isto faz-se com directivas view. Cada vista tem regras de match-clients que determinam qual a vista activa para cada consulta:

# Split-horizon com BIND
# Vista interna
view "internal" {
    match-clients { 192.168.1.0/24; };
    zone "exemplo.pt" {
        type master;
        file "/etc/bind/zones/internal/exemplo.pt";
    };
};
# Vista externa
view "external" {
    match-clients { any; };
    zone "exemplo.pt" {
        type master;
        file "/etc/bind/zones/external/exemplo.pt";
    };
};

A ordem das vistas é importante: o BIND avalia de cima para baixo e usa a primeira vista cujo match-clients corresponde ao IP de origem. Por isso, a vista interna (mais específica) deve vir antes da externa (com any).

A zona interna contém registos com IPs privados (RFC 1918), enquanto a zona externa contém apenas os registos públicos. É fundamental garantir que os ficheiros de zona externa não vazam endereços internos — uma má configuração pode expor a topologia da rede.

3. DNS Load Balancing (Round-Robin)

O round-robin DNS é a técnica mais simples de distribuir tráfego entre múltiplos servidores. Consiste em associar vários registos A ao mesmo nome de hospedeiro. O servidor DNS roda a ordem das respostas a cada consulta, fazendo com que diferentes clientes se liguem a servidores diferentes.

# Round-robin DNS
www  IN  A  192.168.1.10
www  IN  A  192.168.1.11
www  IN  A  192.168.1.12

Quando um cliente consulta www.exemplo.pt, o DNS devolve os três endereços numa ordem rotativa. O primeiro cliente recebe 192.168.1.10 primeiro, o segundo recebe 192.168.1.11 primeiro, e assim por diante.

Esta abordagem tem limitações importantes. O DNS round-robin não verifica a saúde dos servidores — se um servidor cair, o DNS continua a enviá-lo como resposta, causando falhas para os clientes que o recebem. Além disso, os caches DNS dos ISPs e dos navegadores podem interferir com a rotação, reduzindo a eficácia da distribuição.

Para mitigar estes problemas, surgem soluções mais avançadas como o DNS-based Global Server Load Balancing (GSLB), que combina verificações de saúde, proximidade geográfica e carga em tempo real para devolver o melhor IP. Ferramentas como PowerDNS com módulos geoip e BIND com políticas de resposta (RPZ) oferecem esta funcionalidade.

4. CDN e DNS

Uma Content Delivery Network (CDN) é uma rede de servidores distribuídos geograficamente que armazena cópias de conteúdo estático (imagens, CSS, JavaScript, vídeos) perto dos utilizadores. O DNS desempenha um papel central na forma como as CDNs funcionam — é o DNS que decide qual servidor edge vai servir cada utilizador.

O fluxo típico funciona assim: quando um utilizador em Portugal acede a um site que usa uma CDN, o DNS do site (geralmente um CNAME que aponta para o domínio da CDN) resolve para o IP do servidor edge mais próximo — tipicamente em Lisboa, Madrid ou outro ponto de presença na Europa. Um utilizador no Brasil recebe o IP de um servidor edge em São Paulo. Isto reduz drasticamente a latência.

Existem duas formas principais de integrar DNS com CDN:

1. CNAME delegation: O registo DNS do site é um CNAME que aponta para o domínio da CDN (ex: www.exemplo.pt CNAME exemplo.pt.cdn.cloudflare.net). A CDN resolve o CNAME e devolve o IP do edge mais próximo.

2. DNS provider gerido pela CDN: Os nameservers do domínio ficam sob controlo da CDN (ex: usar os nameservers da Cloudflare). A CDN tem controlo total sobre a resolução e pode aplicar regras avançadas como balancing por carga, geolocalização e failover automático.

O TTL dos registos DNS que apontam para CDNs é tipicamente baixo (30 a 60 segundos) para permitir que mudanças de tráfego entre edges propaguem rapidamente. TTLs altos podem fazer com que utilizadores sejam encaminhados para um edge saturado durante minutos ou horas.

5. DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT)

O DNS tradicional (porta 53, UDP/TCP) envia consultas em texto limpo. Qualquer pessoa na rede — ISP, administrador de Wi-Fi, atacante — pode ver quais sites está a consultar. DoH e DoT resolvem este problema encriptando as consultas DNS.

Mesmo com DoH/DoT activo, a ligação posterior ao servidor web revela o destino através do SNI (Server Name Indication) no TLS handshake. Para privacidade total seria necessário ECH (Encrypted Client Hello), que ainda não está amplamente implementado.

DNS-over-TLS (DoT) usa a porta 853 e uma ligação TLS dedicada para o servidor DNS. É definido nas RFCs 7858 e 8310. O Unbound, resolvedor popular, suporta DoT nativamente:

# DNS-over-TLS com Unbound
server:
    tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
    forward-tls-upstream: yes
    forward-zone:
        name: "."
        forward-addr: 1.1.1.1@853#cloudflare-dns.com

Para testar se o DoT está a funcionar:

# Testar DoT
dig @127.0.0.1 kbase.pt +tls

DNS-over-HTTPS (DoH) encapsula consultas DNS em pedidos HTTPS normais (porta 443). Isto torna o tráfego DNS indistinguível de tráfego web regular, dificultando o bloqueio ou filtragem. DoH é definido na RFC 8484 e é usado por navegadores como Firefox, Chrome e Edge.

Para testar DoH manualmente usando o endpoint JSON da Cloudflare:

# Testar DoH
curl -s 'https://cloudflare-dns.com/dns-query?name=kbase.pt&type=A' -H 'accept: application/dns-json' | python3 -m json.tool

6. DLZ — Dynamically Loadable Zones

DLZ (Dynamically Loadable Zones) é uma funcionalidade do BIND que permite carregar dados de zona a partir de fontes externas em vez de ficheiros de zona estáticos. Com DLZ, o BIND pode consultar uma base de dados MySQL, PostgreSQL, LDAP, um ficheiro CSV ou até uma API REST para resolver nomes — tudo em tempo real, sem necessidade de recarregar zonas.

Isto é especialmente útil em ambientes onde os registos DNS mudam frequentemente — provedores de hosting que criam domínios dinamicamente, plataformas SaaS que adicionam subdomínios por cliente, ou sistemas de serviço discovery onde novos serviços aparecem e desaparecem constantemente.

A configuração do DLZ no BIND faz-se no ficheiro named.conf com um bloco dlz que especifica o driver e a string de ligação:

# DLZ com MySQL no BIND
dlz "mysql_zone" {
    database "mysql
    {host=127.0.0.1 port=3306 dbname=dns user=dns pass=segredo}
    {SELECT zone FROM records WHERE zone='$zone$'}
    {SELECT ttl, type, data FROM records WHERE zone='$zone$' AND host='$record$'}";
};

Cada consulta DNS que o BIND recebe é traduzida numa query SQL. As variáveis $zone$ e $record$ são substituídas pelos valores da consulta. Se a base de dados tiver um novo registo, este fica imediatamente disponível — sem rndc reload ou reinício.

O DLZ tem algumas desvantagens: cada consulta implica uma operação na base de dados, o que pode introduzir latência. Para mitigar isto, o BIND mantém um cache interno de respostas DLZ. Além disso, a configuração é mais complexa e requer que a base de dados esteja altamente disponível — se a DB cair, o DNS deixa de resolver.

Alternativas modernas ao DLZ incluem o PowerDNS com o seu backend genérico (que suporta MySQL, PostgreSQL, LDAP, Pipe e Remote), e o CoreDNS que usa plugins para integrar com Kubernetes, etcd, Consul e outras fontes dinâmicas.

7. Erros Comuns e Lista de Verificação

A configuração de DNS avançado introduz complexidade adicional. Pequenos erros podem causar problemas difíceis de diagnosticar. Aqu estão os erros mais comuns e uma lista de verificação para os evitar.

Erros frequentes

• Ordem incorrecta das vistas no split-horizon: Colocar a vista any antes da vista interna faz com que todos os clientes recebam a resposta externa. A vista mais específica deve vir sempre primeiro.
• Round-robin sem verificação de saúde: Um servidor que cai continua a receber tráfego porque o DNS não detecta a falha. Usar monitorização externa e remover registores A de servidores inactivos, ou migrar para GSLB.
• TTL alto com CDN: TTLs de 3600s ou mais impedem que a CDN ajuste o encaminhamento rapidamente. Usar TTLs de 30-60s para registos geridos por CDN.
• DoH sem validar o certificado: Desactivar a verificação do certificado TLS no cliente DoH abre a porta a ataques man-in-the-middle. O tls-cert-bundle deve apontar para uma CA store válida.
• DLZ sem cache: Consultar a base de dados a cada pedido DNS sem cache pode degradar seriamente a performance. Configurar max-cache-size e TTLs apropriados.
• Esquecer o DNSSEC: Ao mudar para DoH/DoT, alguns administradores desactivam o DNSSEC assumindo que a encriptação TLS é suficiente. O DNSSEC garante autenticidade dos dados; o TLS garante confidencialidade do transporte. São complementares, não substitutos.

Lista de verificação

Artigos Relacionados

• Dia 1: Fundamentos — Modelo OSI e TCP/IP
• Dia 8: DNS — Configuração e Resolução de Nomes
• RFC 8484: DNS Queries over HTTPS (inglês)