Enrutamiento DNS y failover

1) Función de DNS en la tolerancia a fallas

• Disponibilidad (failover rápido/confiable);
• Rendimiento (geo/latency-routing);
• Costo (minimización de las llamadas interregionales y de la tercera parte);
• Seguridad (DNSSEC, anti-hijack, control CAA/DMARC/SPF).

Clave: TTL cortos donde la dinámica es importante, y arquitectura zonal estable (público + privado, split-horizon).

2) Tipos de registros y prácticas

A/AAAA - direcciones principales; publique siempre IPv6 donde sea posible.
CNAME vs ALIAS/ANAME: en la raíz del dominio, use ALIAS/ANAME (o apex-flattening provider).
TXT - SPF/DMARC/DKIM, verificación; CAA - Limitación de los emisores de certificados.
SRV/NS - Servicio de discovery y delegación.
SVCB/HTTPS es un moderno mecanismo alternativo con priorización y parámetros (ALPN, puertos).

Recomendación: fije los estándares TTL por clase (edge/API/static).

3) Políticas de enrutamiento

Weighted (ponderado) - partes controladas del tráfico (canario/azul-verde).
Latency-based: selecciona la agrupación más cercana al retraso.
Geo-routing - por país/continente/región; importante para la residencia de datos.
Failover (primario/secundario) - monitoreo activo y conmutación.
Multi-valor - varios A/AAAA; el cliente elige (no reemplaza los cheques de salud).
Proximity/ASN routing - en algunos proveedores: a través de la red del cliente.

Combine: geo → latency → weight → health.

4) TTL, almacenamiento en caché y propagación

API/altavoces TTL: 30-120 s (equilibrio entre la velocidad del failover y la carga).
Static/CDN: 1–24 ч.
El TTL negativo (SOA 'Minimum') es ≤ 60-300 s, de lo contrario NXDOMAIN será «pegajoso».
Recuerde: los resólveres no están obligados a desechar la caché instantáneamente; tenga en cuenta la «cola sucia».

5) Salud y control de endpoints

Cheques de salud de varias regiones: TCP/443 + HTTP 2xx/3xx y comprobación lambda de criterios empresariales (por ejemplo, éxito '/salud? deep = true 'con comprobación de dependencias).
Sintética (RUM/active): muestras API en las rutas principales, comprobación TLS/OCSP, comprobaciones DNSSEC.
Exponer '/ready '(profundo) y '/live' (superficial); Ajuste la agrupación DNS a/ready.

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

Zona pública - Acceso del cliente.
Zona privada - Resolución interna a los puntos de vista privados (VPC/VNet, on-prem).
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
Nomenclatura: 'api. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) Seguridad: DNSSEC y política de dominio

DNSSEC: active la firma de zona (KSK/ZSK), supervise la rotación de claves y la cadena de confianza.
CAA: enumere las CA válidas; habilita 'iodef' para alertas.
SPF/DMARC/DKIM: reputación de correo y protección contra phishing.
Registrar-lock y MFA en cuentas de proveedor de DNS; registro de cambios (almacenamiento WORM).

8) Diseño failover

8. 1 Modelos

Active-Active: dos + grupos saludables; equilibrio a través de latency/weight, health-checks eliminan insalubres.
Active-Passive: grupo principal + reserva (0% de peso antes del accidente).
Anillo regional: tráfico a una región «vecina» en un accidente local.
Modo degradado: escribir en un sitio web/landing «fácil» si el backend no está disponible.

8. 2 Escena paso a paso

1. El monitoreo registra la degradación '/ready '.
2. El DNS cambia las respuestas (excluye la agrupación o cambia los pesos).
3. El tráfico va a una región saludable, TTL determina la velocidad.
4. Una vez estabilizado es el período grace (15-30 min) y sólo entonces el retorno de las escalas.

9) Ejemplos de configuraciones

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 y failover pool (idea)

Load Balancer Pools c health-checks (HTTP/TCP), Load Balancer con Geo Steering (continentes/países) y Session affinity.
Fallback: Page Rule/Transforme Rule a backend simplificado en picos de 5xx.

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) Observabilidad y SLO DNS

SLI: resolva de tasa de éxito, resolva de tiempo percentil 95, proporción de respuestas frescas (no stale) dentro de TTL.
SLO: por ejemplo, '99. 95% 'de respuestas exitosas ≤ 100 ms.
Métricas: tasa NXDOMAIN, tasa SERVFAIL, reservas de estado de salud, proporción de tráfico por región, proporción de Canarias.
Exemplars: asocia SLI con tracks HTTP a través de 'trace _ id' en sintético.

11) Pruebas y operaciones

Sintética de diferentes ASN/regiones (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/' delv 'para comprobar DNSSEC;' amb + trace 'en anomalías.
Staging zone ('stg. example. com ') para ensayos de feilover; rehearsal-script cambia el peso/las prioridades y retrocede.
Runbook: quién y cómo aumentar/bajar de peso manualmente, cómo desactivar la piscina, cómo ejecutar «freeze».

12) Antipatternas

TTL = 3000 + en el crítico A/AAAA → un failover lento/caótico.
La ausencia de controles de salud o la verificación de sólo un puerto TCP sin invariantes comerciales.
Una pila de cadenas CNAME → resolvas lentas, caos en caché.
El único proveedor de DNS sin respaldo secundario/axfr.
Zona no firmada cuando se requiere DNSSEC; CAA irrelevantes.
Registros que indican la IP pública de los backends privados/BD.

13) Especificidad de iGaming/finanzas

Jurisdicciones: geo-/country-routing para cumplir con los requisitos (redireccionamiento a dominio local/frente).
PSP/KYC: subdominios dedicados con TTL separados y políticas de Feilover; traducción rápida a PSP redundante.
Juego responsable: subdominios con páginas legales siempre disponibles (statics de respaldo/CDN).
Auditoría: registro de cambios de zona en el almacén WORM, firma de cambios y rugido regular.
Hojas de flujo: reglas de cumplimiento DNS por región (filtrado edge + enrutamiento DNS).

14) Lista de comprobación prod

• Perfiles TTL por clase; TTL negativo ≤ 300 con.
• Dos redes independientes anycast DNS (primario/secundario), MFA/registrador-lock.
• Políticos: geo/latency/weight + health-checks de varias regiones.
• DNSSEC incluido, CAA/DMARC/DKIM/SPF actualizado.
• Split-horizon (público/privado), zonas privadas para el tráfico interno.
• Feilover/devoluciones de runbook, script rehearsal, dominios canarios.
• Monitoreo de SLI/SLO, alertas en NXDOMAIN/SERVFAIL/crecimiento de RTT.
• La zona de estadía y las «enseñanzas» regulares son falleras.
• Para iGaming: routing por jurisdicciones, dominios separados para PSP/KYC, auditoría inmutable.

15) TL; DR

Construye una política combinada: geo/latency + health-checks + pesos, con TTL 30-120 s en el altavoz. Comparta público/privado (split-horizon), incluya DNSSEC y CAA, mantenga el DNS secundario. Haga un failover rehearsal y observe SLI/SLO DNS. Para iGaming, tenga en cuenta las jurisdicciones y reservas de dominios PSP/KYC con reglas separadas y la lógica de los cambios en WORM.