Administración y enrutamiento DNS
Resumen breve
El DNS es un «router de nivel de nombres». De un TTL competente, zonas y políticas depende la rapidez y previsibilidad con que los usuarios lleguen a los frentes/gateways deseados. Conjunto mínimo: Proveedor Anycast, TTL saludable, checks de salud con failover automático, DNSSEC + CAA, control de IaC y observabilidad (SLO por respuesta y tiempo resolve).
Arquitectura básica
Servidores autorizados (zones): son responsables de los dominios de la empresa.
Resólveres recursivos (clientes/ISP/propios) - preguntar la raíz de → TLD → autorizados.
Anycast es el mismo direccionamiento IP en múltiples PoP: el PoP cercano responde más rápido y sobrevive a accidentes.
Zonas y delegación
La zona raíz del dominio → 'NS' en los proveedores de servidores de autoridad.
Subdominios (por ejemplo, 'api. example. com ') se puede delegar en "NS'/proveedores individuales para la independencia.
Tipos de registros (mínimo)
'A '/' AAAA' - IPv4/IPv6 direcciones.
'CNAME' es un seudónimo a nombre; no utilice en la raíz de la zona (en su lugar, ALIAS/ANAME en los proveedores).
'TXT' - verificación, SPF, etiquetas personalizadas.
'MX' - Correo (si se utiliza).
'SRV' - servicios (SIP, LDAP, etc.).
'CAA' - Quién puede emitir certificados para un dominio.
'NS '/' SOA' - Delegación/parámetros de zona.
'DS' son las claves DNSSEC en el TLD padre.
Ejemplo de zona (fragmento)
$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 y almacenamiento en caché
TTL corto (30-300 c) - para altavoces (frentes API, failover).
TTL promedio (300-3600 c) - para CDN/estática.
TTL largo (≥ 1 día) - para cambios raros (MX/NS/DS).
Al planificar una migración, reduzca la TTL en 24-72 horas con anticipación.
TTL de cacheo negativo (NXDOMAIN): controlado por 'SOA MINIMUM'.
Políticas de enrutamiento (nivel GSLB)
Failover (active/passive): le damos la IP principal a fail health-check 'om, luego la reserva.
Weighted (traffic-split): distribución del tráfico (por ejemplo, canario 5/95).
Latency-based - RoR/región más cercana a la latencia de red.
Geo-routing - por país/continente; útil para las leyes locales/PCI/PII.
Multivalue - varios 'A/AAAA' con controles de salud de todos.
Consejos
Para APIs críticas, conecte latency-based + health-checks + TTLs cortos.
Para lanzamientos suaves - weighted y el crecimiento gradual de la participación.
Para las restricciones regionales - geo y listas de proveedores permitidos.
Salud y cambio automático
Controles de salud: HTTP (S) (200 OK, cuerpo/cabecera), TCP (puerto), ICMP.
Reputación/huella dactilar: compruebe no sólo el puerto, sino también la corrección de backend 'a (versión, build-id).
Umbral de sensibilidad: 'N' de comprobaciones exitosas/fallidas seguidas para evitar el flapping.
Comamos la métrica: proporción de puntos de inflexión, tiempo de reacción, número de conmutaciones.
Zonas privadas y split-horizon
DNS privado: zonas interiores en VPC/VNet/On-prem (por ejemplo, 'svc. local. example`).
Split-horizon: diferentes respuestas para clientes internos y externos (IP interna vs pública).
Protección contra fugas: no use nombres «internos» hacia afuera; compruebe que las zonas privadas no resuelvan a través de proveedores públicos.
Seguridad DNS
DNSSEC: firmas de zona (ZSK/KSK), publicación de 'DS' en la zona padre, rollover de claves.
CAA: limite la liberación de los servidores TLS a CA de confianza.
DoT/DoH para recursivos: encriptación de solicitudes de clientes.
ACL/Rate-limit en autoritativo: protección contra solicitudes DDoS/ANY reflectantes.
Subdominio Takeover: escanea regularmente CNAME/ALIAS «colgantes» en servicios remotos (se ha eliminado el recurso - CNAME se ha quedado).
Registros NS/Glue: consistencia entre el registrador y el proveedor DNS.
SLO y observabilidad
SLO (ejemplos)
Disponibilidad de respuestas autoritarias: ≥ 99. 99 %/30 días.
Tiempo de respuesta al recursor (p95): ≤ 50 ms localmente/ ≤ 150 ms globalmente.
Éxito de health-checks: ≥ 99. 9%, falsos positivos - ≤ 0. 1%.
Tiempo de salida después del cambio (propagation): ≤ 5 min a TTL 60 s.
Métricas
RCODE (NOERROR/NXDOMAIN/SERVFAIL), QPS, p50/p95 tiempo de respuesta.
Compartimientos de IPv6/IPv4, tamaño EDNS, respuestas Truncated (TC).
Conmutación col-en por health-check, flapping, errores de firma DNSSEC.
Porcentaje de consultas DoH/DoT (si controla el recursor).
Logi
Consultas (qname, qtype, rcode, client ASN/geo), anomalías (tormentas ANY, NXDOMAIN frecuentes con un prefijo).
IaC y automatización
Terraform/Proveedores de DNS: mantenga las zonas en el repositorio, el rugido de PR, el plan/approw.
ExternalDNS (K8s): creación/eliminación automática de registros de Ingress/Service.
Entornos intermedios: prefijos de 'dev. '/' stg.' y cuentas individuales del proveedor de DNS.
Terraform (ejemplo 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"
}
}
Resolutores, caché y rendimiento
Sus propios recursivos (Unbound/Knot/Bind) están más cerca de las aplicaciones → menos de p95.
Habilite el prefetch de registros en caliente, serve-stale cuando la autoridad no esté disponible.
EDNS (0) y el tamaño correcto del búfer, DNS Cookies, respuestas mínimas.
Separe los flujos de resolve y el tráfico de aplicaciones (QoS).
Tenga en cuenta Negative TTL: un montón de NXDOMAIN de un cliente «bate» puede marcar la caché.
DDoS y sostenibilidad
Un proveedor anycast con PoP globales y agregación de tráfico de bot.
Response Rate Limiting (RRL) sobre autoritativo, protección contra amplificación.
Prohibición de 'ANY', restricción del búfer EDNS, filtros para tipos «pesados».
Segmentación de zonas: crítica: el proveedor con el mejor escudo DDoS; menos crítico - por separado.
Proveedor de respaldo (secondaries) con 'AXFR/IXFR' y failover NS automático a nivel de grabadora.
Operaciones y procesos
Cambios: revisión PR, registros canarios, calentamiento de cachés (baja TTL → deploy → devolver TTL).
Rollover DNSSEC: reglamento, ventanas, control de validez (RFC 8901 KSK/ZSK).
Runbook: caída de PoP, delegación NS incorrecta, cheque de salud caído, SERVFAIL masivo.
Plan DR: proveedor de DNS alternativo, plantillas de zona terminadas, acceso al registrador, SLA para reemplazar a NS.
Lista de comprobación de implementación
- Dos proveedores autoritarios independientes/RoR (Anycast), correctos 'NS' en el registrador.
- Estrategia TTL: corto para altavoces, largo para registros estables; negative TTL bajo control.
- Health-checks y políticas: failover/weighted/latency/geo por perfil de servicio.
- DNSSEC (KSK/ZSK/DS), 'CAA' limita la liberación de azufre.
- IaC para zonas, ExternalDNS para K8s, entornos/cuentas individuales.
- Monitoreo: rcode/QPS/latency/propagation, alertas por SERVFAIL/firmas.
- DDoS: Anycast, RRL, restricciones EDNS, bloque de listas/ACL.
- Regulaciones de migración de dominios y reducción de TTL en 48-72 h.
- Auditoría periódica de «colgantes» CNAME/ALIAS, MX/SPF/DKIM/DMARC (si se utiliza correo).
Errores típicos
Demasiada TTL en los críticos 'A/AAAA' - largas migraciones/failover.
Un proveedor DNS/uno PoP es SPOF.
La ausencia de DNSSEC/CAA es el riesgo de sustitución/serts no controlados.
Un split-horizon inconsistente → fugas de nombres internos hacia afuera.
Sin cheques de salud en GSLB: cambio de manos y retraso.
Olvidado CNAME a los servicios externos → el riesgo de takeover.
Falta de IaC → «copo de nieve» -configuras y errores en las correcciones manuales.
Especificidad para iGaming/fintech
Versiones regionales y PSP: geo/latency-routing, listas blancas de socios IP/ASN, rápido failover gateways.
Picos (partidos/torneos): TTL corto, calentamiento CDN, nombres individuales para eventos ('event-N. example. com ') con una política administrada.
Corrección legal: capture la hora y la versión de las zonas cuando se produzcan cambios críticos (registro para auditoría).
Protección antifraude/BOT: nombres individuales para tiebreakers/capchi/check-endpoints; una rápida desviación al «agujero negro» (sinkhole) en los ataques.
minipleybuki
Lanzamiento del frente canario (weighted):1. `api-canary. example. com '→ 5% del tráfico; 2) monitorim r95/r99/error; 3) aumentar a 25/50/100%; 4) se contraen en la degradación.
Failover de emergencia:1. TTL 60 s; 2) health-check etiquetó la región down → GSLB retiró de las respuestas; 3) inspección de los resólveres externos; 4) comunicación de estado.
Migración del proveedor de DNS:1. Importar una zona a un nuevo proveedor; 2) Activar secondary sincrónico en el antiguo; 3) Cambiamos el 'NS' por el registrador en una ventana «tranquila»; 4) Observamos errores SERVFAIL/val.
Resultado
Un circuito DNS confiable es Anycast-autorities + TTL razonable + enrutamiento de salud/latencia + DNSSEC/CAA + IaC y observabilidad. Fije los procesos de migración y los rollovers, mantenga un proveedor de respaldo, revise regularmente la zona en busca de registros «colgantes», y sus usuarios llegarán constantemente a los frentes deseados incluso en la hora más «caliente».