Seu DNS é um ponto único de falha. Aqui está o Playbook Multi‑DNS de 2026

Grátis não é o mesmo que resiliente. A Bunny acabou de tornar o DNS gratuito para acelerar a web. Ótimo. Mas se você ainda opera seu domínio de produção em um único provedor de DNS — gratuito ou pago — você manteve um ponto único de falha no único plano de controle que toda requisição atinge primeiro.

Falhas de DNS são feias porque são binárias e imediatas: quando o caminho do seu resolvedor quebra, você não fica degradado — você desaparece. Se o TTFB da sua página inicial sobe 200 ms, a receita continua. Se seu domínio para de resolver por 5 minutos, não continua. Pergunte a quem passou pelo DDoS da Dyn em 2016 ou por bloqueios de registradores e quedas de provedores mais recentes. Em 2026, com agentes de IA espirrando tráfego nos seus endpoints e redes móveis adicionando jitter, sua margem para erros de DNS fica ainda menor.

Este post traz um playbook multi‑DNS pragmático e neutro em relação a fornecedores: como decidir se você precisa disso, como construir (sem gambiarras sob medida), quais registros e recursos importam agora (DNSSEC, SVCB/HTTPS, ECH, flattening no apex) e como testar e operar como um SRE, não como hobby.

Por que agora: desempenho é barato, autoridade não é

A iniciativa da Bunny de tornar o DNS gratuito é parte de uma tendência maior: desempenho via anycast virou condição básica. Em uma rede anycast decente, a consulta recursivo‑para‑autoritativo mediana na América do Norte/Europa fica em 12–25 ms; no Brazil e no México, 35–60 ms é o típico. O problema não é velocidade bruta — é risco de dependência. Dois modos de falha dos quais você não consegue se livrar com um único fornecedor:

• Interrupções no nível do provedor e vazamentos de rota: Mesmo redes anycast tier‑1 são afetadas. Um deploy ruim, um vazamento de rota ou um ataque grande pode jogar no buraco negro seu conjunto de NS em regiões que importam para você.
• Problemas de conta e de registrador: Credenciais comprometidas, 2FA desabilitado ou uma falha de cobrança podem pausar sua zona ou seu registrador. Se você não consegue mudar NS ou DS rapidamente, vai apenas assistir os gráficos despencarem.

Enquanto isso, a stack está evoluindo. Os registros SVCB/HTTPS antecipam dicas de protocolo (ALPN, H3) e configs de ECH para que os clientes evitem idas e voltas extras. Usados corretamente, isso economiza 1–2 RTTs — 30–120 ms no mobile no mundo real. Mas nem todos os provedores implementam esses registros de forma consistente, e alguns escondem recursos atrás de botões proprietários. Multi‑DNS é em parte sobre redundância, em parte sobre portabilidade de recursos modernos de DNS.

Um critério simples de decisão: você realmente precisa de multi‑DNS?

Adote DNS com dois provedores quando ao menos um dos itens abaixo for verdadeiro:

• Seu custo de indisponibilidade é >US$ 5.000 por minuto (típico para comércio B2C, fintech ou mídia apoiada em anúncios).
• Audiência global com tráfego relevante em LATAM/APAC (20%+), onde incidentes de roteamento regional são comuns.
• Você opera multi‑CDN ou regiões active‑active e faz steering via DNS. Essa lógica é inútil se o próprio DNS estiver fora.
• Pressão de compliance ou auditoria exige capacidade de failover demonstrável de sistemas de “plano de controle”.

Se nada disso se aplica e você é uma startup somente nos EUA com GMV abaixo de US$ 50 milhões, você pode adiar, mas faça o preparo: DNS como código, DNSSEC ligado, bloqueio no registrador e uma migração testada para um segundo provedor em staging.

Arquiteturas que funcionam em 2026 (e as que não funcionam)

1) Primário/Secundário com AXFR/IXFR e assinatura dupla

Padrão: Um provedor é o primário. Você publica a zona nele e replica para um secundário via AXFR/IXFR sobre TSIG. Ambos servem seu conjunto de NS. Você habilita DNSSEC em ambos e publica múltiplos registros DS no registrador (ou usa um KSK coordenado).

Prós: Modelo mental simples; bom suporte dos provedores; superfície operacional pequena. Contras: Descompasso de recursos (por ex., GEO/health checks) e a gestão de chaves DNSSEC pode ficar complicada. Alguns provedores ainda não suportam DNS secundário com DNSSEC corretamente.

2) Dual‑primary via IaC (o modelo “declare uma vez, renderize duas”)

Padrão: Trate DNS como código. A fonte da verdade é uma única especificação de zona (Terraform, dnscontrol ou seu próprio gerador). O CI renderiza e aplica em dois provedores independentes. Sem transferências de zona; ambos são autoritativos.

Prós: Sem limitações de AXFR; mais fácil manter paridade de recursos; sem lock‑in em health checks. Contras: Requer boa cobertura de testes para evitar drift; as APIs dos provedores diferem; você precisa implementar sua própria validação e gates de rollout.

3) Delegação dividida para stacks complexas (use com parcimônia)

Padrão: Mantenha o apex e e‑mail (MX/TXT) no Provedor A; delegue app.example.com, api.example.com e media.example.com para o Provedor B com seus próprios conjuntos de NS.

Prós: Limita o raio de impacto e o acoplamento de recursos. Contras: Mais ruído operacional; adiciona mais lookups de NS; quebra failover ingênuo a menos que seja cuidadosamente planejado.

O que evitar em 2026: Failover proprietário de fornecedor único que só troca dentro da zona deles, e qualquer coisa que exija baixar os TTLs do apex para 30 segundos para compensar automação instável. Se seu failover requer hacks emergenciais de TTL, você não tem um plano — você tem uma esperança.

Os 9 recursos que realmente importam

• DNSSEC bem feito: ECDSAP256SHA256, rotação automatizada de ZSK, rotação segura de KSK. Assinatura dupla multi‑provedor com dois registros DS no registrador é o ideal. Teste “DS remove” e “DS add” em staging antes do prod.
• DNS secundário com DNSSEC: Se você optar por primário/secundário, exija IXFR + TSIG e DNSSEC validado no secundário. Alguns provedores ainda só assinam no primário; não é suficiente.
• Flattening de CNAME/ANAME no apex: Você vai apontar o apex para um CDN/edge. Garanta que ambos os provedores implementem flattening de uma forma que seu CDN suporta.
• Registros SVCB/HTTPS: Pré‑anuncie ALPN=h3, alt service e config de ECH. O suporte em Chrome/Firefox já existe; iOS/macOS estão alcançando. Meça o RTT que você economiza.
• Paridade em IPv6: Publique AAAA. Metade dos seus usuários já está em IPv6, e alguns ASNs celulares o preferem. Não deixe www diferir do apex.
• Steering por geo/latência com padrões: EDNS Client Subnet é legado; provedores modernos derivam steering a partir de telemetria de resolvedores. Prefira steering atrelado a políticas bem definidas que você consegue replicar entre vendors.
• APIs e rate limits previsíveis: Você fará mudanças em massa (rotadores de DKIM, renovações de certificados wildcard). Confirme limites de burst e o comportamento de 429 cedo.
• Independência do registrador: Mantenha o registrador separado dos hosts de DNS. Trave os domínios, habilite registry locks quando possível e guarde códigos de autorização offline.
• Ganchos de auditoria: Toda mudança deve ir ao seu SIEM com diffs em nível de registro. DNS é crítico para segurança; trate como controle de mudança de firewall.

Desempenho: onde estão os ganhos reais em 2026

Em mobiles modernos, idas e voltas são o inimigo. SVCB/HTTPS permite antecipar detalhes de protocolo para que o cliente vá direto para H3 ou escolha o Alt‑Svc correto sem tentativa e erro. Na prática, vemos:

• Economia de 1–2 RTT em carregamentos frios de página quando o RR de HTTPS é honrado, traduzindo em 30–120 ms de ganho real em conexões 4G/5G.
• TTFB 5–15% menor na primeira requisição quando combinado com autoritativo anycast e um CDN forte que honra suas dicas.
• 20–40 ms a menos no p50 de tempo de resolução para usuários no Brazil, Colômbia e México ao sair de um DNS único centrado nos EUA para duas redes anycast com PoPs regionais.

Não são números de fantasia. Meça antes/depois com sondas sintéticas em São Paulo, Bogotá, Mexico City e Miami. Se 20–30% da sua receita passa por LATAM, você verá o ganho.

O plano de implementação (90 dias, sem drama)

Dia 0–15: escolha provedores e torne o DNS definido por código

• Escolha dois vendors que cubram seus indispensáveis: assinatura dupla de DNSSEC, flattening no apex, SVCB/HTTPS, APIs utilizáveis e, ou DNS secundário robusto ou providers de Terraform sólidos. Combinações que vimos funcionar: Route 53 + Cloudflare, DNS Made Easy + Bunny, NS1 + Azure DNS. Isso não é um endosso; é uma dica de compatibilidade.
• Suba um repositório da zona (Terraform ou dnscontrol). Declare todos os registros, incluindo e‑mail (SPF, DKIM), TXT de verificação (Google, Apple) e desafios ACME.
• Escreva um validador da zona que faça o CI falhar se os conjuntos de registros divergirem entre provedores (comparações case‑insensitive, políticas de TTL idênticas onde importa).

Dia 16–45: assine, sincronize e rode em staging

• Habilite DNSSEC em ambos, gere KSK/ZSK e publique o DS de staging no seu registrador de staging. Pratique a rotação de KSK.
• Escolha sua topologia: Se for primário/secundário, habilite AXFR/IXFR com TSIG e confirme secundários assinados. Se for dual‑primary, conecte o CI para aplicar em ambos os provedores com subconjuntos canário de registros.
• Publique SVCB/HTTPS e AAAA em staging. Verifique que os clientes (Chrome/Firefox/Safari) os honram. Meça a economia de RTT e o reaproveitamento de conexões.
• Rode carga e caos: Checks sintéticos de 10+ pontos de observação (EUA/UE/LATAM/APAC) por 7 dias. Injete testes negativos: NXDOMAIN, SERVFAIL, RRSIG expirado e DS obsoleto para garantir que os alertas disparem.

Dia 46–75: virada para produção sem quebrar SEO ou e‑mail

• Adicione o segundo conjunto de NS à produção mantendo o primeiro. Se estiver usando assinatura dupla, publique ambos os DS. Caso contrário, coordene uma janela de troca de KSK com 48 horas de observação.
• Mantenha TTLs conservadores onde importa: 300–600 segundos para registros de app e CDN, 3600–86400 para MX, DKIM e TXT de verificação. Defina o cache negativo do SOA (MINIMUM) para 300–600 para que erros de digitação em DNS não envenenem caches por horas.
• Flatte o apex com cuidado: Verifique se o ANAME/flattening de ambos os provedores gera o mesmo A/AAAA para a borda do seu CDN no p95 mundial.
• Monitore e‑mail do GSuite/Microsoft 365 por 72 horas após mudanças de MX/DKIM. As ferramentas de Postmaster vão capturar erros antes dos clientes.

Dia 76–90: operacionalize

• Acesso e autenticação: Chaves de hardware para admins de DNS, acessos de curta duração (1–8 horas) e janelas de mudança. Bloqueio no registrador e registry lock habilitados. Guarde os códigos de autorização do domínio offline.
• Runbooks: Uma página para remover/adicionar DS, outra para remover/adicionar NS, outra para desabilitar um conjunto de registros com problema. Timebox para ações de 15 minutos. Pratique trimestralmente.
• Observabilidade: Acompanhe tempo de lookup p95 por região (metas: <50 ms EUA/UE, <80 ms LATAM), disponibilidade de DNS (99,99%+), taxa de falha de consultas assinadas (<0,1%). Alerta para expiração de RRSIG e mismatches de DS/RRSIG.

Registros que costumam morder equipes (e como domá‑los)

• Inchaço de SPF/DKIM: Lookups de SPF limitam em 10. Colapse includes. Chaves DKIM giram trimestralmente; automatize com IaC e teste o e‑mail de saída antes das trocas.
• Desafios ACME para certificados wildcard: Se sua AC usa DNS‑01, seu IaC deve criar e limpar registros TXT de _acme-challenge de forma atômica em ambos os provedores. TXT obsoleto é causa comum de falhas de renovação.
• Deriva entre apex e www: Se você publicar SVCB/HTTPS em www, espelhe no apex (ou vice‑versa). Drift aqui anula os ganhos das dicas de protocolo.
• Health checks: Prefira health checks externos (seus ou de terceiros neutros) dirigindo toggles simples de registros. Não prenda tudo na lógica proprietária de um único vendor.

Segurança: DNS agora faz parte do seu perímetro zero‑trust

• Evidência de mudança: Toda mudança em DNS deve produzir um diff estruturado (quem, quando, antigo/novo) enviado ao seu SIEM. Mantenha 1 ano de retenção.
• Higiene de chaves TSIG: Rotacione as chaves TSIG de AXFR a cada 90 dias. Armazene em um gerenciador de segredos, nunca em variáveis de CI em texto puro.
• Comprometimentos de registrador são reais: Use registry lock quando disponível (Verisign para .com), que exige aprovação humana fora de banda para mudanças de NS/DS. Sim, é mais lento. Esse é o ponto.

Custos e trade‑offs (seja honesto consigo mesmo)

DNS moderno é barato — até deixar de ser:

• Uso: Precificação de commodity fica em ~US$ 0,40–0,60 por milhão de queries nos hyperscalers; políticas de geo/latência podem adicionar 2–3x para esses registros. Provedores menores vendem planos (US$ 30–US$ 300/mês) com limites generosos de queries.
• Pessoas: Espere 4–6 horas de engenheiro/mês para manter DNS com dois provedores saudável (reviews, rotações, testes). No primeiro trimestre, você vai gastar 20–30 horas em setup e prática.
• Gratuito vs. pago: DNS gratuito (como o da Bunny) é excelente para performance e como segunda perna. Mas nunca assuma SLAs de suporte no gratuito. Balanceie com um provedor que ofereça SLAs explícitos e canais de suporte para escalonamentos.

O upside é quantificável. Se sua receita combinada é US$ 8.000/min e o dual‑DNS evita uma indisponibilidade de resolução total de 20 minutos por ano, isso são US$ 160.000 protegidos. Sua conta anual de DNS e o tempo de engenharia serão uma fração disso.

Como testar failover sem incendiar a produção

• Servir stale de propósito: Escolha um registro inócuo (staging-echo.yourdomain.com) com TTL=300 e mude apenas no Provedor A. Verifique que 50% dos resolvedores recursivos ainda resolvem via Provedor B nos tempos esperados.
• Drills de blackhole de NS: Null‑route temporariamente os NS de um provedor nos seus agentes de teste sintético para garantir que a disponibilidade permaneça 100% pelo outro provedor.
• DNSSEC break glass: Em uma zona não voltada a clientes, expire o RRSIG e observe os alertas. Pratique remover e readicionar DS no registrador.
• Dicas de protocolo: Remova HTTPS/SVCB em um provedor por 24 horas. Meça a regressão de TTFB onde clientes batem naquele conjunto de NS. Você vai quantificar o valor de manter as dicas de protocolo em sincronia.

Realidade regional: Brazil e LATAM não são casos de borda

Se 20–30% do seu tráfego está em LATAM, trate DNS regional como de primeira classe:

• Escolha provedores com PoPs em São Paulo, Santiago, Bogotá e Mexico City. Isso rende 20–40 ms a menos no p50 de resolução em comparação com footprints anycast somente nos EUA.
• Teste a partir de ASNs de ISPs reais, não apenas de regiões de cloud. Vivo, Claro, TIM, Telmex e Tigo têm comportamentos de peering diferentes dos das regiões da AWS/GCP.
• Publique AAAA de IPv6 em todo lugar. Muitos ASNs móveis no Brazil preferem IPv6. Não degrade esses usuários forçando fallback para v4.

Uma palavra sobre agentes de IA e carga no DNS

Tráfego de agentes tende a espikar em rajadas e a partir de ASNs diversos que você não planejou. Isso é bom para o negócio e ruim para configs ingênuas de DNS. Observe o volume de consultas em torno de lançamentos de modelos ou ações de marketing. Garanta que os limites por zona e por segundo dos seus provedores não vão te estrangular. Pré‑carregar cache com registros de baixa rotatividade é seu aliado; não reduza TTLs para 30 segundos esperando “ficar ágil”. Agilidade pertence ao CI, não aos resolvedores.

Em resumo

Deixar o DNS mais rápido (e barato) é bem‑vindo. Mas melhorias de performance não endereçam o risco fundamental de plano de controle de depender de um único provedor. Multi‑DNS em 2026 não é exótico. Com assinatura dupla de DNSSEC, SVCB/HTTPS, paridade no flattening do apex e um bom IaC, você reduz um cenário de indisponibilidade de sete dígitos por algumas centenas de dólares por mês e poucas horas de SRE.

Pontos‑chave

• Adote DNS com dois provedores se seu custo de indisponibilidade é >US$ 5k/minuto, você roda multi‑CDN/active‑active ou 20%+ dos usuários estão fora dos EUA.
• Escolha provedores que suportem assinatura dupla de DNSSEC, flattening no apex, SVCB/HTTPS, APIs sensatas e, ou DNS secundário, ou um Terraform robusto.
• Use primário/secundário com AXFR/IXFR+TSIG ou dual‑primary via IaC. Evite failover proprietário de fornecedor único.
• Mantenha TTLs saudáveis: 300–600s para app/CDN, 1–24h para MX/DKIM. Defina o cache negativo do SOA para 300–600.
• Meça ganhos reais: 1–2 RTTs com HTTPS/SVCB (30–120 ms no mobile), 20–40 ms a menos no p50 de resolução em LATAM com anycast duplo.
• Operacionalize: chaves de hardware, registrador/registry lock, validação em CI e drills trimestrais (blackhole de NS, adicionar/remover DS).
• Espere 4–6 horas de engenheiro/mês para rodar multi‑DNS; o primeiro trimestre de setup custa 20–30 horas. A indisponibilidade evitada paga isso muitas vezes.