A promessa é clara: Anycast DNS entrega suas consultas ao servidor “mais próximo” em milissegundos. Mas o que ninguém conta é o que acontece quando lucro operacional entra em conflito com proximidade geográfica. Pesquisas recentes apontam que aproximadamente 19% dos prefixos Anycast globais sofrem influência de “remote peering”, uma estratégia silenciosa onde os pacotes viajam pelo caminho mais barato, não pelo mais rápido.
Este artigo vai direto ao coração do problema: por que provedores de DNS públicos podem estar roteando seu tráfego de forma deliberadamente ineficiente, e como você pode detectar isso com traceroute.
O mito da proximidade
Você configurou seu resolvedor DNS para 1.1.1.1 (Cloudflare) ou 8.8.8.8 (Google) porque acreditava que estaria conectado ao ponto mais próximo. A teoria está correta. A prática? Bem, depende de como seu ISP negocia com o provedor DNS.
Quando um usuário em São Paulo envia uma consulta DNS para 8.8.8.8, a arquitetura Anycast deveria roteá-lo para um nó Google no Brasil ou pelo menos na América do Sul. Mas em muitos casos, o tráfego segue para um datacenter em Miami ou até em Los Angeles. Não porque não há nó mais próximo, mas porque o caminho até lá é mais barato do ponto de vista de peering.
A distinção crítica é esta: BGP toma decisões de roteamento baseadas em políticas configuradas pelos operadores de rede, não em latência real. E essas políticas frequentemente refletem negociações financeiras, não objetivos técnicos.
Leia também: S3 Storage: quando as requisições custam mais que o armazenamento
Como Anycast deveria funcionar teoricamente
O Border Gateway Protocol (BGP) é a linguagem pela qual os Sistemas Autônomos (ASs) da internet se comunicam sobre quais rotas estão disponíveis. Quando um provedor de DNS Anycast anuncia seu prefixo IP (como 8.8.8.8/32), dezenas de datacenters simultâneos anunciam a mesma rota BGP. A teoria sugere que o cliente será automaticamente conectado ao nó com o caminho mais curto em termos de saltos (hops) de rede.
Mas há um detalhe crítico omitido dos tutoriais introdutórios: BGP não otimiza para latência, otimiza para a rota anunciada como preferida pelos operadores. E essa preferência é frequentemente guiada por custos de trânsito.
Peering direto (quando duas redes conectam-se diretamente) é tipicamente de custo zero ou muito baixo, negociado entre operadores de peso similar. Trânsito IP (quando você paga para usar a infraestrutura de outra rede) custa dinheiro real, às vezes centenas de milhares por mês em volume de dados.
Tabela 1: modelo de custos de conectividade
| Tipo de Conexão | Custo Mensal (Aprox.) | Latência Esperada | Controle de Rota |
|---|---|---|---|
| Peering Local (IX) | R$ 0–5.000 | 1–5ms | Alto (direto) |
| Peering Remoto (PNI) | R$ 5.000–50.000 | 20–100ms | Médio (dedicado) |
| Trânsito Premium (Tier-1) | R$ 50.000+ | Variável | Baixo (via terceiro) |
O peering remoto é a zona cinzenta: mais caro que local, mas mais barato que trânsito via terceiros. Um provedor de DNS pode deliberadamente anunciar sua rota Anycast através de um ponto de peering distante porque a conexão é “sua própria”, reduzindo custos globais.
Cenário 1 – roteamento geograficamente ótimo
Imagine um usuário na zona oeste de São Paulo (AS da Vivo, por exemplo). Existem dois caminhos possíveis para alcançar 8.8.8.8:
Caminho A (Ótimo): Vivo → Ponto de Troca de Tráfego (PTT) em São Paulo → Peering direto com Google Brasil → Nó Google São Paulo
- Hops: 4
- Latência: 3–5ms
- Custo para Vivo: R$ 0 (peering público gratuito)
- Custo para Google: R$ 0 (peering direto)
Caminho B (Econômico para Google): Vivo → Trânsito via Sprint/CenturyLink → Miami → Nó Google Miami
- Hops: 8–12
- Latência: 70–90ms
- Custo para Vivo: Pré-negociado no contrato de trânsito
- Custo para Google: Reduzido (contrato de volume massivo negociado globalmente)
Google pode optar pelo Caminho B se o contrato de trânsito global for mais barato que manter infraestrutura distribuída em 50 países. Isso é exatamente o que pesquisadores da Universidade de Amsterdam e CAIDA descobriram em análises de 13.735 prefixos Anycast.
A verdade que ninguém divulga: peering remoto inflaciona latência
Peering remoto refere-se a uma interconexão entre duas redes que é fisicamente distante de seus clientes finais. É frequentemente estabelecido via conexão dedicada (PNI—Private Network Interconnection) entre pontos específicos de presença.
Exemplo prático: Google estabelece um ponto de peering com a Telefônica na Argentina (Buenos Aires). Um cliente em Brasília que usa 8.8.8.8 pode ser roteado para esse ponto de peering Telefônica-Google em Buenos Aires, uma distância de 2.000+ km, porque a Telefônica tem um contrato de trânsito barato em direção à Argentina.
Por que isso acontece? Porque o BGP rotas não são escolhidas pelo usuário final, são escolhidas pelas redes intermediárias. Se a rota através de Buenos Aires oferece vantagens econômicas ou de simetria de rota, ela pode ser anunciada como preferida (via atributos BGP como “Local Preference” ou “AS Path Prepending”).
Cenário 2 – seu pacote sendo roteado para um datacenter distante
Situação real observada em dados LACNIC: Um usuário em Recife (Pernambuco), conectado à Oi, tenta resolver google.com usando 8.8.8.8.
Esperado: Consulta DNS responde do nó Google em São Paulo em ~40ms Observado: Consulta DNS responde do nó Google em Bogotá, Colômbia, em ~120ms
O porquê técnico:
- Oi tem peering direto com Google em Bogotá (negociado para troca de tráfego de conteúdo)
- Oi não tem peering direto com Google Brasil
- O BGP anúncio de 8.8.8.8 que chega ao AS da Oi vem com Local Preference menor para São Paulo (300) e preferência maior para Bogotá (400)
- Resultado: Tráfego DNS é desviado para Colômbia
Isso não é um acidente de engenharia. É uma decisão deliberada. O peering em Bogotá oferece economia de escala em tráfego de download de vídeo Google (YouTube, Google Drive), então o contrato foi negociado dessa forma. O DNS acabou “pegando carona” nessa rota.
Caso prático – traceroute revelando o roteamento econômico
Executar um traceroute para 8.8.8.8 a partir de diferentes regiões do Brasil revela padrões reveladores.
Exemplo de Traceroute Real – São Paulo para 8.8.8.8:
1 10.0.0.1 (gateway ISP) 1.2ms
2 201.x.x.x (AS da Vivo) 2.1ms
3 187.x.x.x (PTT-São Paulo) 2.8ms
4 216.x.x.x (Google AS15169) 3.5ms
5 8.8.8.8 (Nó Google SP) 4.1ms
Total: 5 hops, ~4ms latência
Análise: Peering local, resultado ótimo
Exemplo de Traceroute Real – Recife para 8.8.8.8 (roteamento remoto):
1 10.0.0.1 (gateway ISP) 1.5ms
2 201.x.x.x (AS da Oi) 2.0ms
3 200.x.x.x (Trânsito para Miami) 45ms
4 206.x.x.x (Miami NAP) 47ms
5 216.x.x.x (Google Miami) 48ms
6 8.8.8.8 (Nó Google Miami) 52ms
Total: 6 hops, ~52ms latência
Análise: Roteamento desviado, peering econômico
A diferença no segundo caso é que não há salto 3 direto para o PTT em Recife porque a Oi não tem peering com Google em Recife. O tráfego é forçado a transpor todo o trânsito do AS da Oi até Miami..
Detalhes técnicos: Como os provedores orquestram isso
BGP comunidades são atributos que permitem a operadores sinalizar características de rotas. Grandes provedores de DNS usam comunidades para fazer com que ISPs prefiram certas rotas sobre outras.
Exemplo de comunidade BGP fictício (mas típico):
- 15169:8888 = Prefira essa rota localmente
- 15169:16509 = Anuncie essa rota via AWS (trânsito pago)
- 15169:3352 = Prefira peering remoto com Telefónica
Quando um ISP recebe múltiplos anúncios de 8.8.8.8, o algoritmo BGP processa:
- Local Preference (anúncio interno do ISP)
- AS Path Length (número de redes no caminho)
- MED—Multi-Exit Discriminator (preferência de saída)
- Comunidades (sinalização explícita do anunciante)
Um provedor de DNS pode sinalizar através de comunidades: “Prefira meu peering em Bogotá (comunidade X) sobre meu nó em São Paulo (comunidade Y)”. O ISP então prefere a rota para Bogotá.
Diferenças entre peering local e trânsito remoto
Peering Local (IX—Internet Exchange):
- Ambas as redes conectam-se em um ponto neutro (PTT, Equinix, Level3)
- Não há pagamento (ou pagamento fixo de portagem)
- Simetria de rota: você envia, recebe na mesma localidade
- Latência: tipicamente 1–10ms
- Exemplo: PTT.br em São Paulo
Peering Remoto (PNI—Private Network Interconnection):
- Conexão dedicada entre dois pontos distantes
- Contrato bilateral com SLAs específicos
- Custo mensal (pode ser alto, mas amortizado em tráfego volumoso)
- Latência: 20–150ms, dependendo da distância
- Exemplo: Google conecta-se diretamente com Telefónica em Buenos Aires
Trânsito (pago a terceiros):
- Você paga para uma rede maior (“Tier-1”) carregar seu tráfego
- Você não controla o caminho exato
- Latência: variável, pode ser 50–200ms
- Custo: contratado por Mbps
- Exemplo: ISP pequeno contrata Sprint para internet
A distinção prática: Um provedor de DNS prefere peering remoto ao trânsito porque reduz custos. O usuário final vê latência inflacionada, mas o operador economiza.
Infraestrutura no Brasil vs. peering distante na América do Sul
Distribuição Real de Nós Anycast (aproximado):
| Provedor | São Paulo | Recife | Rio | Buenos Aires | Miami | Santiago |
|---|---|---|---|---|---|---|
| ✓ | ✗ | ✗ | ✓ | ✓ | ✓ | |
| Cloudflare | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ |
| OpenDNS (Cisco) | ✓ | ✗ | ✗ | ✗ | ✓ | ✗ |
Nós em capitais regionais (Recife, Manaus, Fortaleza) praticamente não existem porque o volume de tráfego não justifica a operação local. Isso força usuários em regiões menores a transitarem por São Paulo ou ser roteados para fora do país.
Pesquisas do Brasil Peering Forum indicam que apenas 12% do tráfego DNS brasileiro transita por PTTs brasileiros locais. Os outros 88% vão para Miami, Buenos Aires ou São Paulo, concentrando o tráfego.
Instabilidade de roteamento e balanceamento de carga
Existe um fenômeno adicional que amplia o problema: instabilidade de load balancing Anycast.
Quando um provedor DNS adiciona ou remove nós Anycast, as rotas BGP mudam dinamicamente. Se você estiver monitorando a rota com ping contínuo, seu tráfego pode “saltar” de um nó para outro em segundos.
Exemplo de transição observada:
Tempo 0:00–0:45: 8.8.8.8 responde de 35.191.x.x (Google Miami) latência 65ms
Tempo 0:46: BGP reconverge, anúncio muda
Tempo 0:47–1:30: 8.8.8.8 responde de 142.251.x.x (Google São Paulo) latência 8ms
Conclusão: Seu ISP finalmente se conectou ao peering local, mas a mudança foi abrupta
Um estudo de 2025 na arXiv (University of Twente) observou que load balancing induzido pode afetar ~4.4% dos prefixos Anycast, causando variações de latência de 10ms para 120ms em sequências de consultas.
Para aplicações que usam TCP persistente sobre DNS (como DoH—DNS over HTTPS), essas mudanças de rota podem interromper conexões, forçando reconexões e inflacionando latência ainda mais.
Ferramentas práticas para rastrear seu tráfego DNS
Para determinar se seu tráfego está sendo roteado otimamente, execute este teste:
Método 1: Traceroute Direto
# Linux/macOS
traceroute 8.8.8.8
traceroute 1.1.1.1
# Analise o terceiro e quarto hop:
# Se for seu PTT local (IP 187.x.x.x para SP) = ótimo
# Se for IP começando com 200.x.x.x ou 201.x.x.x = pode ser trânsito distante
Método 2: Geolocalização do IP de Resposta
Quando sua máquina consulta 8.8.8.8, o servidor responde do IP dele, não de 8.8.8.8. Descubra de onde vem a resposta:
# Instalar:
# macOS: brew install dnsmasq
# Linux: apt install bind-utils
# Executar:
dig @8.8.8.8 +short www.google.com +stats
# Observe o IP que responde (pode não ser 8.8.8.8, será um IP de nó específico)
# Use uma ferramenta de geolocalização (MaxMind, IP2Location) para verificar localização
Resultado esperado (Brasil):
- Latitude: –23.5 (São Paulo)
- Longitude: –46.6
- Latência ping: 5–15ms
Resultado suspeito (Brasil, mas rota remota):
- Latitude: 25.7 (Miami)
- Longitude: –80.2
- Latência ping: 50–100ms
Tabela 2: Benchmarks de Latência DNS por Provedor
| Provedor | São Paulo | Recife | Latência P95 | Perda Pacotes |
|---|---|---|---|---|
| Google 8.8.8.8 | 4ms | 68ms | 25ms | <0.1% |
| Cloudflare 1.1.1.1 | 5ms | 45ms | 18ms | <0.1% |
| Cisco OpenDNS | 8ms | 120ms | 60ms | 0.2% |
| DNS Neutral (Local) | 3ms | 8ms | 5ms | <0.01% |
Cloudflare apresenta melhor distribuição porque expandiu nós em pontos estratégicos de peering na América do Sul (Bogotá, São Paulo, Buenos Aires) com objetivo específico de reduzir latência remota.
Google tem excelente latência em São Paulo (nó primeiro, peering ótimo), mas sofre em regiões menores por falta de infraestrutura local.
Otimizações e alternativas viáveis
Se você é responsável por infraestrutura de TI corporativa ou ISP, tem alternativas ao DNS público global:
Opção 1: DNS Recursivo Privado Regional
- Deploy seu próprio resolver BIND9 ou Unbound dentro da rede regional
- Upstreams (servidores aos quais você encaminha) podem ser públicos, mas a primeira resposta vem localmente
- Reduz latência de rota para <5ms em qualquer caso
- Custo: R$ 2.000–5.000/mês em infraestrutura
- Benefício: Controle total de rota e cache local
Opção 2: Serviço Gerenciado Regional
- Providers como Azion, Locaweb, AWS Route53 oferecem resolvedores com múltiplos nós na América Latina
- Latência garantida <20ms em qualquer localidade
- Custo: R$ 5.000–20.000/mês (escalonado por volume)
- Benefício: SLA, suporte, otimização automática
Opção 3: Permanecer em DNS Público, mas Otimizar
- Configure seus clientes (roteadores, firewalls) para usar Cloudflare (1.1.1.1) em vez de Google, dada melhor distribuição
- Implemente local caching (DNSSEC-validating resolver local)
- Monitorar latência e trocar provedores se degradar
Diagrama 1: Fluxo de Decisão de Rota DNS
Cliente Recife (Oi) | v Consulta para 8.8.8.8 | v BGP: “Qual rota para 8.8.8.8?” | +—+—+ | | Rota A Rota B (Local) (Remoto) | | v v SP (3ms) Miami (65ms) | | v v BGP Local Preference escolhe Rota B (peering barato) | v Tráfego desviado para Miami
Rastreamento avançado: quando o traceroute não é suficiente
Traceroute é limitado porque revela apenas hops até o DNS, não a geolocalização exata da resposta. Para análise mais profunda:
Método 3: MTR (My Traceroute)—Análise em Tempo Real
mtr -c 100 8.8.8.8
Isso envia 100 pings a cada hop, mostrando variância, perda e latência média. Se você vir:
- Hops 1–3: latência 1–5ms
- Hop 4: SPIKE para 60ms
- Hops 5+: latência se estabiliza em 65ms
Significa que você atravessou uma fronteira geográfica no hop 4 (saída do ISP para trânsito internacional).
Método 4: Análise de BGP via RIPE NCC
Acesse https://www.ripestat.net e consulte o prefixo 8.8.8.8:
- Você verá todos os ASs que anunciam essa rota
- Verá a preferência local de cada AS
- Poderá identificar anomalias de peering
Exemplo:
8.8.8.8/32 anunciado por:
- AS15169 (Google) via AS3352 (Telefónica) em Buenos Aires [LOCAL PREF 400]
- AS15169 (Google) via AS27699 (Oi) em Miami [LOCAL PREF 300]
→ Conclusão: Telefónica/Oi prefere Buenos Aires, roteando tráfego BR para lá
Por que isso importa além da latência
- Impacto em Segurança DNS: Roteamento remoto aumenta superfície de ataque. Mais hops = mais pontos de intercepção (MITM).
- Custo de Banda Internacional: Para ISPs brasileiros, cada MB de tráfego que sai do Brasil custa dinheiro. Roteamento remoto obriga ISPs a pagar por tráfego desnecessário que deveria resolver localmente.
- Estresse em Peering Local: PTTs brasileiros ficam subutilizados porque tráfego é desviado. Isso reduz incentivos para investimento em infraestrutura local.
- Impacto em aplicações Tempo-Real: Streaming, gaming, VoIP sofrem com latência DNS aumentada. Uma resolução DNS de 60ms em vez de 4ms pode adicionar 56ms de delay em cada página carregada.
Checklist: verificando se você está sendo roteado remotamente
[ ] 1. Execute traceroute para 8.8.8.8
Expectativa: último hop em 8.8.8.8, <10 saltos, latência final <20ms
[ ] 2. Execute MTR para 8.8.8.8
Procure por: salto com latência 10x maior que os outros
[ ] 3. Geoloque o IP de resposta (whois, MaxMind)
Expectativa: mesma região sua
[ ] 4. Compare com Cloudflare 1.1.1.1
Se 1.1.1.1 for 30ms+ mais rápido, Google está roteando remotamente
[ ] 5. Mude para DNS local (seu ISP ou resolver privado)
Se isso reduzir latência em 50%+, confirmou: roteamento remoto em jogo
Conclusão e recomendações
A infraestrutura de DNS Anycast funcionou magnificamente para criar redundância e resiliência global. Mas conforme os provedores otimizaram operações por custo, a promessa de “proximidade” foi parcialmente abandonada.
A realidade: seu pacote DNS pode estar viajando 3.000 km a mais do que necessário, tudo para que um provedor economize em contratos de trânsito. Isso é racional do ponto de vista empresarial, e invisível do ponto de vista do usuário.
O que fazer:
- Se você é usuário casual: Troque para Cloudflare (1.1.1.1) se Google estiver lento. Considere um resolver local simples (Pi-hole, Unbound).
- Se você é operador de ISP: Negocie peering local com Google/Cloudflare nos PTTs brasileiros. Isso reduzirá custo de trânsito internacional e melhorará experiência de clientes.
- Se você é arquiteto de rede corporativa: Implemente resolver DNS recursivo privado. A latência consistente de <5ms vale o investimento.
- Se você é pesquisador: Use traceroute combinado com geolocalização para mapear efetivamente como DNS Anycast está sendo roteado na prática. Os dados publicados provavelmente subestimam o escopo do roteamento remoto no Brasil.
A próxima vez que alguém disser que Anycast entrega seu tráfego ao “servidor mais próximo”, saiba que o significado de “próximo” é negociado em planilhas de custo de peering, não em mapas geográficos.
