La mayoría de las soluciones GSLB se centran en registros A, AAAA y CNAME para el routing básico de tráfico. Esto puede ser suficiente para la dirección de aplicaciones simple, pero las operaciones DNS empresariales reales cubren una superficie mucho más amplia: MX, TXT, SRV, PTR, CAA, TLSA, registros DNSSEC, zonas inversas, actualizaciones DNS dinámicas y transferencias de zona.
Cuando esa cobertura falta, la organización debe operar dos capas DNS separadas. Una interfaz para GSLB, otro servidor autoritativo para registros DNS avanzados, operaciones CLI separadas para DNSSEC, transferencias manuales para importación de zona y scripts adicionales para migración. El resultado es una propiedad fragmentada sobre el mismo dominio y un riesgo operativo aumentado.
La gestión DNSSEC es uno de los puntos más sensibles de esta fragmentación. Una zona firmada requiere generar y publicar correctamente registros DNSKEY, DS, RRSIG, NSEC y NSEC3. Dejar esto enteramente a comandos CLI o edición manual de ficheros aumenta el riesgo de error.
La migración de zona y las arquitecturas multi-autoritativas crean problemas similares. Coger registros de una fuente DNS heredada, gestionar registros en conflicto, fijar correctamente el comportamiento del serial SOA y proporcionar transferencias de zona a servidores secundarios requieren todos una política consistente. Los flujos de copia manual de fichero de zona y recarga son insuficientes para las operaciones GSLB modernas.
TR7 DNS Record Management hace de la gestión DNS completa una parte nativa de la plataforma GTM mediante 35 tipos de registro, DNSSEC, AXFR primario/secundario, DNS UPDATE, modos de edición de SOA y políticas inteligentes de colisión AXFR.
TR7 trata la gestión DNS no como una pantalla de entrada de registros, sino como una capa de operaciones que une la capacidad de DNS autoritativo con el motor de decisión GSLB.
TR7 combina capacidades de DNS autoritativo con una API REST y una interfaz de gestión. Los operadores gestionan tipos de registro, ajustes de zona, valores TTL y comportamientos GTM desde una única interfaz.
El soporte de DNSSEC puede activarse a nivel de dominio. DNSKEY, DS, RRSIG, NSEC, NSEC3 y tipos de registro relacionados se tratan como parte del modelo de gestión DNS.
TR7 puede actuar como primario y servir transferencias de zona a servidores secundarios, u operar como secundario y descargar zonas desde una fuente autoritativa externa vía AXFR. Este modelo se usa para migración, redundancia y arquitecturas DNS distribuidas.
Cuando los registros que llegan vía AXFR entran en conflicto con registros existentes, el operador puede seleccionar el comportamiento useNew, preserveCurrent o combine. La migración de zona y la consolidación multi-fuente nunca se convierten así en una sobreescritura ciega.
DNS Record Management consolida la cobertura clásica de registros DNS, DNSSEC, transferencia de zona, actualizaciones dinámicas y comportamientos de registro GTM en un único modelo.
TR7 cubre A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, DNSKEY, DS, RRSIG, NSEC, NSEC3, NSEC3PARAM, ALIAS, AFSDB, CERT, CDNSKEY, CDS, DNAME, HINFO, KEY, LOC, LUA, NAPTR, OPENPGPKEY, RP, SMIMEA, SPF, SSHFP, TLSA, TKEY, TSIG y URI. Esta amplitud importa para las operaciones DNS completas más allá de los registros GSLB. Las necesidades de correo, seguridad de certificados, descubrimiento de servicios, DNS inverso y DNSSEC pueden servirse todas en la misma plataforma, sin una herramienta DNS separada.
DNSSEC puede habilitarse a nivel de dominio. Los tipos de registro NSEC, NSEC3, NSEC3PARAM, RRSIG, DNSKEY, DS, CDS y CDNSKEY están soportados como parte de las operaciones DNSSEC. Esto aumenta la verificabilidad de la zona y añade una capa de seguridad frente a los riesgos de spoofing DNS. Los operadores ya no necesitan tratar DNSSEC como un proceso manual separado fuera de la gestión de registros GSLB.
En modo primario, TR7 puede actuar como fuente autoritativa de zona y servir transferencias de zona a servidores secundarios. La transferencia completa de zona y el comportamiento de transferencia incremental pueden usarse según la arquitectura DNS. Esto es requerido para alta disponibilidad y despliegues de múltiples servidores DNS. Gestionar la zona desde un único punto y propagarla a otros servidores garantiza consistencia operativa.
En modo secundario, TR7 puede recibir una zona desde otra fuente autoritativa vía AXFR. Este modelo es útil para migración, gestión express o transición a la capa TR7 GTM sin interrumpir la infraestructura DNS existente. Mientras los registros se descargan desde una fuente externa, la gestión y la integración con el motor de decisión pueden establecerse en el lado TR7. Es posible una migración gradual sin abandonar de golpe las inversiones DNS existentes.
DNS NOTIFY permite a las partes secundarias saber que se necesita una actualización tras un cambio de zona. TR7 puede evaluar las estadísticas de notificación entrantes dentro de su alcance de monitorización. Esta visibilidad es importante para entender si el comportamiento de transferencia de zona está realmente funcionando. En arquitecturas DNS grandes, los retrasos de transferencia y las cadenas de actualización son más fáciles de rastrear.
DNS UPDATE permite que componentes de aplicación o de infraestructura actualicen registros DNS programáticamente. Por ejemplo, un servidor de aplicación puede publicar dinámicamente su propio registro A. Este comportamiento es valioso en escenarios de automatización e infraestructura elástica. Los permisos de actualización dinámica deben restringirse cuidadosamente y planificarse junto con una política de seguridad.
El modo DEFAULT puede usar un enfoque de serial basado en fecha; el modo EPOCH apunta a tiempo Unix, el modo INCREASE apunta a un incremento de +1 y el modo OFF deshabilita el ajuste automático. El comportamiento del serial SOA es crítico para la cadena de transferencia primario/secundario. Una gestión incorrecta del serial puede hacer que los servidores secundarios pierdan cambios. TR7 hace que este comportamiento sea configurable como ajuste de dominio.
El TTL se gestiona por registro vía recordObj.ttl; el valor por defecto es de 3600 segundos. Un TTL bajo en registros GTM críticos habilita un switchover y failover rápidos, mientras que registros más estáticos pueden usar TTL alto para eficiencia de caché. El TTL es la disyuntiva fundamental entre rendimiento y velocidad de cambio en las operaciones DNS. TR7 presenta este valor como parte natural de la gestión de registros.
En modo local TR7 es propietario de la zona y los registros se vuelven totalmente editables. En modo express, los registros se descargan desde una fuente DNS externa vía AXFR, habilitando un modelo pass-through o de transición gradual. Esta distinción importa para organizaciones que no pueden migrar toda su infraestructura DNS en un solo paso. El proceso de migración se vuelve más controlado y reversible.
Durante la importación AXFR, los registros entrantes pueden entrar en conflicto con los existentes. El modo useNew promociona el nuevo registro, preserveCurrent retiene el existente y combine fusiona ambos. Estas opciones reducen el riesgo de pérdida de datos o sobreescrituras inesperadas durante la migración. El operador puede elegir la estrategia de colisión correcta para cada proceso de importación de zona.
La validación de dominio y subdominio garantiza que los registros se definan bajo la zona correcta. Las direcciones IPv4 e IPv6 se normalizan a forma canónica. El comportamiento del punto final se alinea con el estándar DNS. Estos controles reducen los errores tipográficos y de formato habituales en la entrada manual de registros.
Los campos de metadatos de dominio pueden llevar información adicional para el comportamiento de zona o integraciones con sistemas externos. El acceso REST API puede gestionarse por instancia DNS con una API key. Esta estructura importa para automatización, integración y operaciones DNS multi-instancia. La gestión de registros no se limita a la UI — también está abierta a procesos dirigidos por API.
La gestión de registros DNS opera junto con la estandarización de dominio, la normalización de IP, el comportamiento AXFR, los rangos de puertos, la caché y la gestión del serial SOA.
La comprobación de subdominio verifica que un registro introducido pertenece al dominio relevante. Se consideran tanto el punto final como la coincidencia de dominio. Este comportamiento reduce el riesgo de introducir registros bajo la zona equivocada.
Las cadenas de dominio DNS se manejan con un punto final en forma canónica. Un punto final ausente puede completarse automáticamente. Esto mantiene consistente el comportamiento del nombre de dominio absoluto.
Los registros A se normalizan usando la lógica correctForm de IPv4, los registros AAAA usando la lógica correctForm de IPv6. Esto evita que distintas notaciones de la misma IP creen ruido en el inventario de registros. La normalización simplifica las operaciones de auditoría y comparación.
En las operaciones de sincronización AXFR, los tipos de registro distintos de SOA pueden incluirse en el alcance de sincronización. SOA lleva un comportamiento separado de serial y autoridad y se maneja de forma especial. Esta distinción aumenta el control sobre las transferencias de zona.
Las opciones useNew, preserveCurrent y combine determinan cómo se manejan los registros en conflicto durante la importación. useNew favorece los datos entrantes, preserveCurrent favorece los existentes y combine pretende retener ambos registros. Debe seleccionarse el comportamiento correcto según el plan de migración.
Los rangos de puertos inner, API, forwarder inner y forwarder API para las instancias DNS pueden planificarse por separado. Esta separación reduce los conflictos de puertos en arquitecturas multi-instancia y de forwarder. El equipo de operaciones puede colocar los servicios DNS de una forma más organizada.
El TTL de la caché de consultas, el TTL de caché negativa de consultas y los valores máximos de entrada de caché pueden gestionarse a nivel de instancia. La caché tiene un efecto directo en el tiempo de respuesta DNS y en la carga sobre el backend autoritativo. Los registros GTM que requieran TTL bajo deben planificarse junto con el comportamiento global de caché.
El modo de edición de SOA determina cómo cambia el valor del serial en las escrituras del primario. Puede usarse un ajuste separado para el comportamiento de serial inferior en el lado secundario. Una gestión correcta del serial es la base de la transferencia continua de zona.
Una organización puede habilitar DNSSEC para sus dominios y traer bajo gestión la cadena DNSKEY, DS, RRSIG y NSEC/NSEC3. La zona se vuelve verificable. La seguridad DNS se gestiona dentro de TR7 DNS Management sin fragmentarse entre operaciones CLI manuales.
La zona se descarga vía AXFR desde la fuente autoritativa heredada y los registros se revisan en el lado TR7. En conflicto, se aplica una política useNew, preserveCurrent o combine. La organización puede migrar de forma controlada sin mover todo el DNS de una vez.
Los registros de zona mantenidos en múltiples DCs pueden recogerse mediante el proceso AXFR inteligente. Los registros en conflicto se fusionan o preservan según la política elegida. Esto se usa para centralizar un inventario DNS fragmentado.
Un servidor de aplicación o sistema de automatización puede actualizar su propio registro vía DNS UPDATE. En infraestructuras elásticas, un registro DNS puede crearse automáticamente cuando un nuevo nodo entra en servicio. Los permisos de actualización deben restringirse mediante una política de seguridad.
Las estructuras de zona inversa in-addr.arpa o IPv6 pueden mantenerse bajo TR7 DNS Management. Los registros PTR se gestionan para las necesidades de inventario de red y resolución inversa. La seguridad de la zona inversa también puede reforzarse junto con DNSSEC.
Los registros CAA pueden usarse para restringir qué autoridades de certificación pueden emitir certificados para el dominio. Los registros TLSA publican el contexto de vinculación de certificados sobre DNS en escenarios DANE. Estos registros unen la seguridad DNS con las operaciones de aplicación y certificados.
35 tipos de registro, DNSSEC, transferencia de zona AXFR y DNS UPDATE — en una única capa de gestión. Permítanos hacer un recorrido en vivo sobre su propia infraestructura.