Gerenciamento DNS e Rotação

Resumo breve

O DNS é um roteador de nível de nomes. O TTL, as zonas e as políticas adequadas dependem do quão rápido e previsível os usuários entrarão nas frentes/passarelas desejadas. O conjunto mínimo é o provedor Anycast, TTL saudável, health-checks com failover automático, DNSSEC + CAA, controle IaC e observabilidade (SLO por resposta e tempo de ressalva).

Arquitetura básica

Servidores autorizados (zonas) - responsáveis pelos domínios da empresa.
Ressalvas recorsais (cliens/ISP/próprias) - Perguntam a raiz → TLD → credíveis.
Anycast é o mesmo endereço IP em várias PoP, o PoP médio responde mais rapidamente e sofre acidentes.

Áreas e delegações

Área de raiz do domínio → 'NS' em provedores de servidores credíveis.
Falsificações (por exemplo, 'api. example. com ') você pode delegar para «NS »/provedores individuais para independência.

Tipos de gravação (mínimo)

'A '/' AAAA' - IPv4/IPv6 endereço.
'CNAME' é um pseudônimo para o nome; não use na raiz da zona (em vez disso, ALIAS/ANAME nos provedores).
'TXT' - verificações, SPF, marcas de custo.
'MX' - correio (se usado).
'SRV' - Serviços (SIP, LDAP etc.).
'CAA' - quem pode emitir certificados de domínio.
'NS '/' SOA' - delegação/configuração de zona.
'DS' é a chave DNSSEC para o TLD pai.

Exemplo de zona (fatia)

$TTL 300
@    IN SOA ns1.dns.example. noc.example. (2025110501 3600 600 604800 300)
IN NS ns1.dns.example.
IN NS ns2.dns.example.
@    IN A  203.0.113.10
@    IN AAAA 2001:db8::10 api   IN CNAME api-prod.global.example.
_www  IN CNAME cdn.example.net.
_caa  IN CAA 0 issue "letsencrypt.org"

TTL e armazenamento em dinheiro

TTL curto (30-300 c) - para dinâmicas (API, failover).
TTL médio (300-3600 c) - para CDN/estático.
TTL longo (≥ 1 dia) - para alterações raras (MX/NS/DS).
Ao planejar a migração, reduza o TTL com 24 a 72 horas de antecedência.
Leve em conta o Negative Caching TTL (NXDOMAIN): controlado por 'SOA MÍNIMO'.

Políticas de rotação (nível GSLB)

Failover (ativo/passive) - Damos o IP principal antes do feel health-check 'om, depois a reserva.
Weighted (traffic-split) - Distribuição de tráfego (por exemplo, canary 5/95).
Latency-based é o RR/região mais próximo em atraso de rede.
Geo-roting - país/continente; útil para leis locais/PCI/PII.
Multivalue - vários 'A/AAAA' com verificações de saúde de cada um.

Dicas

Para APIs críticas, junte latency-based + health-checks + TTL curto.
Para lançamentos suaves - weighted e crescimento gradual da participação.
Para limitações regionais - geo e listas de provedores autorizados.

Saúde e câmbio automático

Health-checks: HTTP (S) (200 OK, corpo/cabeçalho), TCP (porta), ICMP.
Reputação/fingerprint: verifique não apenas a porta, mas também a correção do backend 'a (versão, build-id).
O limite de sensibilidade é 'N' para verificações seguidas de sucesso e incompletas para evitar o flapping.
Comemos a métrica, a proporção de healthy-endpoint, o tempo de reação, o número de mudanças.

Áreas privadas e split-horizonte

Private DNS: áreas internas em VPC/VNet/On-prem (por exemplo, 'svc. local. example`).
Split-horizonte: diferentes respostas para clientes internos e externos (IP vs interno).
Proteção contra vazamentos: não use nomes internos; Verifiquem se as áreas privadas não falam através de provedores públicos.

Segurança DNS

DNSSEC: assinaturas de zonas (ZSK/KSK), publicação de 'DS' na área do pai, roll de chaves.
CAA: Limite o lançamento de sertões TLS a uma CA confiável.
Para os recursores, criptografar as solicitações dos clientes.
ACL/Rate-limit sobre autoritários: proteção contra pedidos DDoS/ANY refletidos.
Subdomain Takeover: escaneie regularmente CNAME/ALIAS pendentes para serviços remotos (recurso removido - CNAME permaneceu).
Gravações NS/Glue: consistência entre o receptor e o provedor DNS.

SLO e observabilidade

SLO (exemplos)

Disponibilidade de respostas autoritárias: ≥ 99. 99 %/30 dias.
Tempo de resposta ao recorsor (p95): ≤ 50 ms localmente/ ≤ 150 ms globalmente.
Health-checks: ≥ 99. 9%, falhas falsas, ≤ 0. 1%.
Tempo de saída após a alteração (propagation): ≤ 5 min a TTL 60 s.

Métricas

RCODE (NOERROR/NXDOMAIN/SERVFAIL), QPS, p50/p95 tempo de resposta.
Participações IPv6/IPv4, EDNS tamanho, Truncated (TC) respostas.
Em mudanças de health-check, flapping, erros de assinaturas DNSSEC.
Proporções de solicitações DoH/DoT (se você controlar o recorsor).

Logs

Consultas (qname, qtype, rcode, cliente ASN/geo), anomalias (tempestades ANY, frequentes NXDOMAIN de um prefixo).

IaC e automação

Terraform/Provedores DNS: Mantenha as áreas no repositório, o revezamento PR, o plano/apresento.
ExternalDNS (K8s): criando/removendo automaticamente registros do Ingress/Service.
Ambientes intermediários: prefixos 'dave '/' stg.' e contas individuais do provedor DNS.

Terraform (exemplo simplificado)

hcl resource "dns_a_record_set" "api" {
zone = "example.com."
name = "api"
addresses = ["203.0.113.10","203.0.113.20"]
ttl = 60
}

resource "dns_caa_record" "caa" {
zone = "example.com."
name = "@"
ttl = 3600 record {
flags = 0 tag  = "issue"
value = "letsencrypt.org"
}
}

Ressalvas, dinheiro e desempenho

Os recursores próprios (Unbound/Knot/Bind) estão mais próximos dos aplicativos → menos de p95.
Ative os registros quentes preferch, serve-stale quando a autoridade não estiver disponível.
EDNS (0) e o tamanho correto do tampão, cookies DNS, minimal-responses.
Separe os fluxos de ressalva e o tráfego de aplicativos (QoS).
Leve em conta a TTL Negative: muito NXDOMAIN de um cliente «batido» pode marcar o dinheiro.

DDoS e sustentabilidade

Provedor Anycast com PoP globais e agregação de tráfego bot.
Response Rate Limiting (RRL) sobre autoritários, proteção contra amplificação.
Proibição de 'ANY', limitação de tampão EDNS, filtros para tipos 'pesados'.
Segmentação de zonas: crítica - em um provedor com o melhor escudo DDoS; menos crítico, separadamente.
Provedor de reserva (segundaries) com 'AXFR/IXFR' e um feedback automático NS no nível de gravador.

Operações e processos

As alterações são PR-review, gravações canary, armazenamento (TTL baixo → deploy → reaver TTL).
Rollover DNSSEC: regulamento, janelas, monitoramento de validade (RFC 8901 KSK/ZSK).
Runbook: queda de PoP, delegação NS incorreta, health check-check, SERVFAIL em massa.
Plano DR.: provedor DNS alternativo, modelos de área prontos, acesso ao receptor, SLA para substituir o NS.

Folha de cheque de implementação

• Dois provedores independentes e autoritários/RR (Anycast) corretos 'NS' do receptor.
• Estratégia TTL: curto para dinâmica, longo para gravações estáveis; TTL negativo sob controle.
• Health-checks e políticas: failover/weighted/latency/geo por perfil de serviços.
• DNSSEC (KSK/ZSK/DS), 'CAA' limita a produção de sertões.
• IaC para áreas ExternalDNS para K8s, ambientes/contas individuais.
• Monitoramento: rcode/QPS/latency/propagation, alertas SERVFAIL/assinaturas.
• DDoS: Anycast, RRL, restrições EDNS, bloco lista/LCA.
• Regulamentos de migração de domínios e rebaixamento de TTL de 48 a 72 h.
• Auditoria regular de «pendentes» CNAME/ALIAS, MX/SPF/DKIM/DMARC (se for usado o correio).

Erros típicos

Um TTL muito grande nos críticos 'A/AAAA' é uma migração longa/feelowers.
Um provedor DNS/um PoP é SPOF.
Falta de DNSSEC/CAA - risco de troca/surto descontrolado.
Split-horizonte incoerente para vazamento de nomes internos para fora.
Nada de health-checks no GSLB - mudança de mãos e atrasos.
CNAME esquecido para serviços externos → risco takeover.
Falta de IaC → «flocos de neve» - configs e erros nas edições manuais.

Especificidades para iGaming/Fintech

Versões regionais e PSP: geo/latency-roting, listas brancas de parceiros IP/ASN, passarelas failover rápida.
Picos (jogos/torneios): TTL curto, CDN aquecido, nomes individuais para iventes ('event-N. example. com ') com uma política controlada.
Correção legal: verifique a hora e a versão das áreas em alterações críticas (registro para auditoria).
Proteção antifrod/BOT: nomes individuais para tiebreakers/capchi/cheque-endpoint; uma saída rápida para o «buraco negro» (sinkhole) nos ataques.

Mini playbooks

1. `api-canary. example. com '→ 5% do tráfego; 2) monitor de p95/p99/erros; 3) aumentamos para 25/50/100%; 4) encurtamos com a degradação.

1. TTL 60 s; 2) health-check marcou a região down → GSLB retirou das respostas; 3) verificar os ressalvadores externos; 4) comunicação de status.

1. Importar uma área para um novo provedor; 2) Incluímos o secundary sincronizado no antigo; 3) Trocar 'NS' do receptor para uma janela «silenciosa»; 4) Observando os erros SERVFAIL/val.

Resultado

Um circuito DNS confiável é uma autoridade Anycast + TTL/Rotação inteligente sobre saúde/atraso + DNSSEC/CAA + IaC e observabilidade. Verifique os processos de migração e rollover, mantenha o seu provedor de reserva, verifique regularmente a área para gravações pendentes - e os seus usuários estarão estáveis nas frentes desejadas, mesmo na hora mais quente.