Capacidad

DNSSEC On-Prem

Firme zonas autoritativas en su propia infraestructura — integridad DNSSEC sin ceder la custodia de claves a un tercero.

DNSSEC convierte al DNS de una búsqueda no autenticada en un servicio criptográficamente verificable. El precio que la mayoría de las organizaciones paga es la custodia: los proveedores cloud de DNS gestionan las claves de firma, realizan la firma y sirven las respuestas firmadas — cómodo, pero las claves nunca residen dentro de su perímetro de seguridad. TR7 GTM ofrece firma y servicio DNSSEC en el propio appliance. El opt-in DNSSEC por dominio mantiene granular el despliegue. Los 35 tipos de registro DNS soportados coexisten con la capa DNSSEC — los registros DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS y CDNSKEY son de primera clase en el esquema, se transfieren por AXFR/IXFR como cualquier otro tipo de registro y se sirven junto al resto de la zona. Los modos de edición de SOA (DEFAULT YYYYMMDD01, INCREASE, EPOCH, OFF) dan al operador control sobre cómo avanzan los seriales de zona — importante tanto para DNSSEC como para la consistencia con los esclavos downstream. La transferencia de zona lleva los registros firmados tal cual, de modo que los esclavos en modo Express sirven las respuestas firmadas del maestro sin refirmar. El resultado: un plano DNS autoritativo capaz de DNSSEC que mantiene las claves de firma, las decisiones de rotación de claves y la integridad de zona bajo su control operativo — no bajo un contrato SaaS.

8
Tipos de registro DNSSEC — DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY
Por dominio
Opt-in DNSSEC — zonas firmadas y sin firmar coexisten
4 modos
Edición del serial SOA — DEFAULT, INCREASE, EPOCH, OFF
On-prem
La custodia de claves permanece bajo control del operador

La adopción de DNSSEC se frena por la custodia de claves, no por la complejidad criptográfica.

DNSSEC ha sido un estándar durante más de una década, pero su adopción sigue siendo irregular. La criptografía es bien entendida; el modelo operativo está bien documentado. Lo que detiene a muchas organizaciones de habilitarlo es la custodia: la key signing key (KSK) y la zone signing key (ZSK) son las raíces de confianza de toda la zona y la mayoría de las empresas no quieren esas claves en manos de un proveedor.

Los proveedores cloud de DNS ofrecen firma y servicio DNSSEC, pero las claves viven en el KMS del proveedor. El proveedor puede revocarlas, rotarlas o ser sometido a citación judicial — la integridad de su zona depende de la operación continuada del proveedor. Algunas organizaciones aceptan esta concesión; muchas de sectores regulados (gobierno, defensa, finanzas) no pueden.

La alternativa histórica es operar un pipeline de firma DNSSEC auto-gestionado: BIND con gestión de claves a medida, scripts para rotar claves según calendario, integración HSM externa, configuración de esclavos para recibir registros firmados. Esto funciona, pero la sobrecarga operativa es significativa y los modos de fallo son silenciosos (RRSIG expirada, cadena NSEC ausente).

TR7 GTM trae DNSSEC a la misma superficie de operador que el resto del plano DNS autoritativo — opt-in por dominio, registros firmados como datos de primera clase, transferencia de zona que lleva la firma — sin depender de un servicio de firma externo.

Nuestro enfoque

DNSSEC es un feature flag por dominio combinado con soporte de primera clase para todos los tipos de registro DNSSEC. La firma y el servicio ocurren en el nodo TR7 GTM; la custodia de claves permanece con el operador.

Opt-in DNSSEC por dominio

Cada dominio DNS en TR7 GTM habilita o deshabilita DNSSEC de forma independiente mediante un campo booleano de esquema. Los despliegues mixtos — algunas zonas firmadas, otras no — coexisten en la misma flota sin forzar un compromiso a nivel de flota.

Ocho tipos de registro DNSSEC como datos de primera clase

DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS y CDNSKEY forman parte de la lista de tipos de registro soportados junto a A, AAAA, CNAME, MX y el resto. El esquema los trata como datos, no como un subsistema separado.

Los modos de edición de SOA controlan el avance del serial

El operador elige cómo se incrementa el serial SOA: DEFAULT (formato YYYYMMDD01), INCREASE (+1 por cambio), EPOCH (marca de tiempo UNIX) o OFF (control manual). El avance del serial importa para los validadores DNSSEC y para los esclavos downstream.

La transferencia de zona lleva los registros firmados intactos

AXFR/IXFR transfieren los registros DNSSEC junto con otros tipos de registro. Los esclavos en modo Express sirven las respuestas firmadas del maestro sin refirmar — punto único de firma, múltiples puntos de servicio.

Capacidades

DNSSEC en TR7 GTM cubre la superficie operativa — esquema, transferencia, servicio, integridad — sin delegar en un firmante externo.

Flag booleano DNSSEC por dominio

Cada dominio DNS lleva un campo booleano `dnssec`. Cuando es true, la zona se trata como DNSSEC-activa: se esperan registros DNSKEY y DS, los registros RRSIG acompañan a cada RRset en el cable y los registros NSEC/NSEC3 cubren el espacio de nombres de la zona.

Gestión de registros DNSKEY

Los registros DNSKEY (las claves públicas de la zona) se gestionan como registros normales en el esquema. Los operadores importan o definen el contenido DNSKEY; la rotación se gestiona añadiendo nuevos registros DNSKEY antes de eliminar los antiguos, siguiendo patrones estándar de rollover con pre-publicación.

Soporte de registros DS para delegación de zona padre

Los registros DS (Delegation Signer) se gestionan en la zona padre. Cuando padre e hijo están alojados ambos en TR7 GTM, los registros DS se propagan naturalmente; cuando el padre está en otro lugar, los operadores exportan los registros DS para enviarlos upstream.

Denegación autenticada de existencia NSEC y NSEC3

Los registros NSEC y NSEC3 prueban que un nombre consultado no existe. NSEC3 añade salt e iteraciones para impedir la enumeración de zona. Ambos tipos de registro son de primera clase en el esquema y sirven como parte de la zona.

Registros de firma RRSIG

Los registros RRSIG llevan las firmas criptográficas sobre los RRsets. El esquema soporta RRSIG como tipo de registro; la transferencia AXFR/IXFR lleva los RRSIGs junto con los RRsets firmados.

CDS y CDNSKEY para actualizaciones automatizadas en el padre

Los registros CDS y CDNSKEY comunican el estado DS deseado de la zona hija al padre — habilitando la automatización del lado del padre (RFC 7344). Útil para organizaciones que operan delegaciones en múltiples proveedores DNS.

Modos de edición de SOA para control del serial

Cuatro modos seleccionables por el operador para el avance del serial SOA: DEFAULT (basado en fecha YYYYMMDD01), INCREASE (+1 por cambio), EPOCH (marca de tiempo UNIX), OFF (control manual). Los valores de serial son críticos para DNSSEC porque las zonas firmadas deben avanzar el serial en cada cambio para invalidar las firmas cacheadas.

IPs de servidor esclavo para replicación de zona firmada

Cada dominio puede listar IPs de servidores esclavos a los que envía las actualizaciones de zona firmada vía NOTIFY. Los operadores ejecutan sus propios esclavos downstream (PowerDNS, BIND, NSD) y reciben copias firmadas para servicio distribuido.

Compatible con el modo Express para firma con maestro oculto

Los dominios en modo Express descargados desde un maestro upstream heredan el estado DNSSEC del maestro. Si el maestro firma, TR7 sirve las respuestas firmadas; si el maestro no firma, TR7 sirve sin firmar. La decisión de firma pertenece al maestro.

35 tipos de registro DNS en total, incluyendo 8 tipos DNSSEC

La lista completa de tipos de registro (A, AAAA, AFSDB, ALIAS, CAA, CERT, CDNSKEY, CDS, CNAME, DNSKEY, DNAME, DS, HINFO, KEY, LOC, MX, NAPTR, NS, NSEC, NSEC3, NSEC3PARAM, OPENPGPKEY, PTR, RP, RRSIG, SOA, SPF, SSHFP, SRV, TKEY, TSIG, TLSA, SMIMEA, TXT, URI) incluye ocho tipos relacionados con DNSSEC como miembros de primera clase.

Profundidad operativa

DNSSEC en TR7 GTM se opera junto con la transferencia de zona, la rotación de claves, la delegación al padre y las expectativas del validador.

01

Granularidad del opt-in por dominio

DNSSEC se habilita por dominio. Los operadores despliegan DNSSEC zona a zona, validando cada una antes de expandir. Los estados mixtos se soportan indefinidamente — algunas zonas firmadas, otras no, en la misma flota TR7.

02

Rotación de claves mediante gestión de registros

El rollover de DNSKEY sigue los patrones estándar de pre-publicación / doble firma: añadir nueva clave como registro DNSKEY, esperar a que las cachés se refresquen, cambiar el firmante activo, retirar la clave antigua. El esquema trata cada clave como un dato; el calendario del rollover lo controla el operador.

03

Ventanas de validez de RRSIG

Los registros RRSIG llevan intervalos de validez. Los operadores definen la cadencia de refresco — típicamente las firmas se refrescan antes de su expiración para evitar fallos de validador durante problemas transitorios del pipeline de firma. La plataforma muestra las próximas expiraciones para acción del operador.

04

Selección NSEC frente a NSEC3

NSEC permite el zone walking (un atacante puede enumerar todos los nombres); NSEC3 añade salt e iteraciones para impedir el walking. Los operadores eligen por zona — las zonas expuestas al público suelen usar NSEC3 para impedir la enumeración; las zonas cerradas pueden usar NSEC por simplicidad.

05

Coordinación de delegación al padre

La delegación de zona requiere que el padre publique un registro DS. Cuando la zona padre está alojada en TR7, los registros DS forman parte del conjunto de registros del padre. Cuando el padre está en otro lugar, los operadores exportan valores DS desde los registros CDS y los envían upstream.

06

Compatibilidad con servidores esclavos

Los servidores esclavos downstream reciben zonas firmadas vía AXFR/IXFR y las sirven. Los esclavos no refirman; confían en las firmas del maestro. Esto soporta servicio distribuido (múltiples POPs esclavos, cachés regionales) sin sobrecarga de refirma.

Cuándo utilizarlo

Integridad DNS del sector público y defensa

Las zonas del sector público que requieren integridad DNSSEC por cumplimiento suelen tener que mantener las claves de firma dentro del perímetro de seguridad. El DNSSEC on-prem de TR7 da soporte a este requisito sin delegar en un proveedor cloud.

Zonas firmadas del sector financiero

Las zonas de banca y procesamiento de pagos usan DNSSEC para evitar ataques de spoofing DNS contra servicios cara al cliente. El opt-in por dominio permite a los bancos desplegar DNSSEC zona a zona, validando cada una antes de un despliegue más amplio.

Arquitecturas con maestro oculto y servicio firmado

El maestro firma la zona; los nodos TR7 actúan como esclavos Express y sirven las respuestas firmadas del maestro. La firma ocurre una vez; el servicio ocurre a escala sin sobrecarga de refirma en cada borde.

DNS multi-proveedor con coordinación al padre basada en CDS

Las organizaciones que usan múltiples proveedores DNS para redundancia publican registros CDS a través de TR7 para que la zona padre pueda aprender automáticamente los valores DS actuales. La automatización del lado del padre reduce la coordinación manual del rollover.

Preguntas frecuentes

¿Gestiona TR7 las claves DNSSEC o tengo que aportar las mías?
Las claves DNSSEC (registros DNSKEY) se gestionan como registros en el esquema. Los operadores importan claves existentes o generan nuevas; TR7 las almacena y las sirve, gestiona su ciclo de vida como dato y las empareja con los registros RRSIG. Las herramientas de generación de claves y la integración con HSM son elecciones del operador — el esquema es abierto sobre qué almacena las claves.
¿Puedo usar DNSSEC en zonas en modo Express?
Sí. Las zonas en modo Express heredan el estado DNSSEC del maestro. El maestro firma; TR7 descarga registros firmados vía AXFR/IXFR y los sirve. No se produce refirma en la capa TR7 — las firmas del maestro se sirven tal cual.
¿Cómo afecta el modo de edición de SOA a DNSSEC?
DNSSEC requiere que el serial SOA avance en cada cambio de zona para que los validadores y los resolvers cacheadores sepan que la zona se ha actualizado. Los modos de edición de SOA — DEFAULT (YYYYMMDD01), INCREASE (+1), EPOCH (marca de tiempo UNIX), OFF (manual) — permiten al operador elegir cómo se computa ese avance. DEFAULT e INCREASE son los más comunes para zonas firmadas.
¿Qué pasa con el zone walking de NSEC?
Los registros NSEC pueden recorrerse para enumerar la zona entera, lo cual a veces es una preocupación de privacidad o de reconocimiento. NSEC3 añade salt e iteraciones para impedir la enumeración. La elección entre NSEC y NSEC3 es por zona — los operadores equilibran simplicidad (NSEC) contra resistencia al walking (NSEC3).
¿Cómo se manejan los servidores esclavos con DNSSEC?
Los servidores esclavos reciben zonas firmadas vía transferencia AXFR/IXFR. Los esclavos sirven las firmas del maestro sin refirmar. TR7 GTM puede actuar tanto como maestro (firmando) como esclavo de otro maestro (sirviendo las firmas upstream). El servicio distribuido funciona sin sobrecarga de refirma.
¿Es DNSSEC compatible con las funcionalidades de GSLB y selección de DC?
Sí. DNSSEC opera en la capa de integridad de zona; GSLB y selección de DC operan en la capa de selección de respuesta. El GSLB elige qué registros devolver; la capa DNSSEC garantiza que esos registros lleguen con firmas válidas. Las dos son ortogonales — combinar DNSSEC con GSLB ponderado, geográfico y multi-fuente está soportado.

Firme sus zonas en su propia infraestructura.

Recorra el DNSSEC on-prem con TR7 GTM: opt-in por dominio, todos los tipos de registro DNSSEC como datos de primera clase, transferencia de zona que lleva las firmas intactas.