Roteiro DNS e failover

1) Papel DNS na resistência a falhas

• Disponibilidade (failover rápido/confiável);
• Desempenho (geo/latency-roting);
• Custo (minimizar egress interregional e 3rd-party chamadas);
• Segurança (DNSSEC, anti-hijack, controle CAA/DMARC/SPF).

Chave: TTL curtos onde a dinâmica é importante e arquitetura de área estável (público + private, split-horizonte).

2) Tipos de registros e práticas

A/AAAA - endereços principais; sempre publicar IPv6 onde possível.
CNAME vs ALIAS/ANAME: Use ALIAS/ANAME na raiz do domínio (ou apex-flattening de provedor).
TXT - SPF/DMARC/DKIM, verificações; O CAA é uma restrição aos emissores de certificados.
SRV/NS - serviço discovery e delegação.
SVCB/HTTPS é um moderno mecanismo alternativo de priorização e parâmetros (ALPN, portas).

Recomendação: fixe os padrões TTL por classe (edge/API/estático).

3) Políticas de rotação

Weighted (ponderado) - frações de tráfego controladas (canários/blue-green).
Latency-based é a escolha do pool mais próximo por atraso.
Geo-roting - país/continente/região; importante para o data residency.
Failover (primary/segundary) - Monitoramento e mudança ativo.
Multi-valor - vários A/AAAA; o cliente escolhe (não substitui os health-check).
O Proximity/ASN routing - em alguns provedores - pela rede do cliente.

Combinar geo → latency → weight → health.

4) TTL, cachê e encorajamento

TTL API/dinâmica: 30-120 s (equilíbrio entre velocidade e carga).
Static/CDN: 1–24 ч.
O TTL negativo (SOA 'Minimum') é de ≤ 60-300 s, ou o NXDOMAIN será «pegajoso».
Lembre-se: Os ressalvadores não são obrigados a arrancar o dinheiro imediatamente; Considerem a cauda suja.

5) Saúde e teste de endpoint

Health-checks de várias regiões: TCP/443 + HTTP 2xx/3xx e verificação de critérios de negócios lambda (por exemplo, sucesso '/health? deep = true 'com verificação de dependências).
Sintético (RUM/ativo): API em rotas principais, verificação TLS/OCSP, verificação DNSSEC.
Exponha '/ready '(profundo) e '/live' (superficial); Coloque o pool DNS em/ready.

6) Público vs privado DNS (split-horizonte)

Público one - Acesso ao cliente.
Private zona é uma resolução interna para private endpoants (VPC/VNet, on-prem).
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
Nome: 'api. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) Segurança: DNSSEC e política de domínio

DNSSEC: inclua a assinatura da zona (KSK/ZSK), vigie a rotação das chaves e a cadeia de confiança.
CAA: lista os CA válidos; Ligue 'iodef' para alertas.
SPF/DMARC/DKIM: reputação de correio e proteção contra phishing.
Registar-lock e MFA para as aulas do provedor DNS; Registro de alterações (armazenamento WORM).

8) Engenharia failover

8. 1 Modelos

Ativo-ativo: dois pulos mais saudáveis; o balanço via latency/weight, health-checks exclui os não saudáveis.
Ative-Passive: pool principal + reserva (0% peso antes do acidente).
Regional ring: tráfego para a região «vizinha» em caso de acidente local.
Modo Degraded: gravar para um site/lending «leve» se o backend não estiver disponível.

8. 2 Passos da cena

1. O monitoramento detecta a degradação '/ready '.
2. O DNS muda as respostas (excluindo o pool ou mudando de peso).
3. O tráfego vai para uma região saudável, a TTL determina a velocidade.
4. Após a estabilização, o período grace (15-30 min) e apenas depois o retorno da balança.

9) Exemplos de configuração

9. 1 AWS Route 53 — latency + health + weighted

hcl
Two latency aliases for different regions resource "aws_route53_record" "api_latency_eu" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1"
latency_routing_policy { region = "eu-central-1" }
alias { name = aws_lb. api_eu. dns_name zone_id = aws_lb. api_eu. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_eu. id ttl = 60
}

resource "aws_route53_record" "api_latency_us" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "us1"
latency_routing_policy { region = "us-east-1" }
alias { name = aws_lb. api_us. dns_name zone_id = aws_lb. api_us. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_us. id ttl = 60
}

Canary in EU: 10% of the weight of the resource "aws_route53_record" "api_weighted_canary" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1-canary"
weighted_routing_policy { weight = 10 }
alias { name = aws_lb. api_eu_canary. dns_name zone_id = aws_lb. api_eu_canary. zone_id evaluate_target_health = true }
ttl = 30
}

9. 2 Cloudflare - geo/ASN e failover pool (ideia)

Load Balancer Pools c health-check (HTTP/TCP), Load Balancer com Geo Steering (continentes/países) e Sessions affinity.
Fallback: Page Rule/Transfer Rule para backand simplificado a 5xx picos.

9. 3 Azure/GCP

Azure Traffic Manager: Priority/Weighted/Performance/Geographic.
Google Cloud Load Balancing + Cloud DNS policy: geo-policy + health-checks через External HTTP(S) LB.

10) Observabilidade e SLO DNS

SLI: sucess-rate resolva, 95 percurso de tempo de ressola, proporção de respostas recentes (não-stale) dentro da TTL.
SLO, por exemplo, '99. 95% de respostas bem sucedidas ≤ 100 ms.
Métricas: NXDOMAIN-rate, SERVFAIL-rate, health-state pool, proporção de tráfego por região, proporção de canários.
Exemplars: Vincule o SLI aos traçados HTTP através de 'trace _ id' no sintético.

11) Testes e operações

Sintéticos de diferentes regiões ASN (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/' delv 'para verificação DNSSEC;' dig + trace 'para anomalias.
Zona de estágio ('stg. example. com ') para ensaios de feelover; o script rehearsal muda peso/prioridades e devolve.
Runbook: quem e como aumenta/reduz o peso manualmente, como desativar o pool, como executar «freeze».

12) Antipattern

TTL = 3000 + em críticos A/AAAA → um feelover lento/caótico.
Não há health-checks ou verificação de apenas uma porta TCP sem invariantes empresariais.
Muitas cadeias de CNAME → frequências lentas, caos em dinheiro.
Único provedor DNS sem secundary/axfr-reserva.
Área não assinada quando o DNSSEC é exigido; CAA irrelevante.
Gravações que indicam IP público de backends privados/BD.

13) Especificidades do iGaming/Finanças

Jurisdição: geo-/country-routing para cumprimento de requisitos (redirecionamento para domínio/frente local).
PSP/KYC: Subterfúgios selecionados com TTL e políticas de feedback individuais; tradução rápida para PSP de reserva.
Jogo responsável: falsificações com páginas legais estão sempre disponíveis (status de reserva/CDN).
Auditoria: registro de alterações de área em armazenamento WORM, assinatura de alterações e revezamento regular.
Listras de bloco: regras DNS por região (edge-filtrar + routing DNS).

14) Folha de cheque pró-prontidão

• Perfis TTL por classe; TTL negativo ≤ 300 s.
• Duas redes anycast independentes DNS (primary/segundary), MFA/receptor-lock.
• Políticas: geo/latency/weight + health-checks de várias regiões.
• O DNSSEC está ativado, o CAA/DMARC/DKIM/SPF é válido.
• Split-horizonte (público/private), áreas privadas para tráfego interno.
• Runbook feelover/retorno, cenário rehearsal, domínios canários.
• Monitoramento do SLI/SLO, alertas para NXDOMAIN/SERVFAIL/Crescimento da RPT.
• Área de rebanho e «exercícios» regulares failover.
• Para iGaming: routing por jurisdição, domínios individuais para PSP/KYC, auditoria imutável.

15) TL; DR

Construa uma política combinada: geo/latency + health-check + peso, com TTL 30-120 com dinâmica. Divida o público/private (split-horizonte), inclua o DNSSEC e o CAA, mantenha o secundary DNS. Faça um feelover rehearsal e observe o SLI/SLO DNS. Para iGaming, leve em consideração a jurisdição e a reserva de domínios PSP/KYC, com regras e logs individuais de alterações no WORM.