Arquitectura DNS Alineada a TOGAF: Principios, Registros, Seguridad y Roadmap

El servicio invisible que sostiene a toda la empresa

Hay una pieza de infraestructura que casi nadie ve y de la que todo depende. Cuando falla, no cae "una aplicación": cae el correo, cae el portal, caen las integraciones, cae la telefonía IP y caen los certificados. El DNS es el sistema nervioso de la conectividad corporativa y, paradójicamente, suele gestionarse como si fuera una configuración menor en un panel olvidado.

Tratar el DNS con la seriedad de una arquitectura empresarial cambia radicalmente el resultado. Y para eso no hace falta inventar un método: TOGAF ya ofrece el andamiaje para describir cualquier capacidad tecnológica con principios, dominios, catálogos, matrices, diagramas, gobernanza y un roadmap de evolución. Este artículo aplica ese rigor al DNS de punta a punta: desde los principios que deben guiarlo hasta la documentación exhaustiva de cada tipo de registro, pasando por el flujo de resolución, los estados AS-IS y TO-BE, la seguridad con DNSSEC, la alta disponibilidad con Anycast y GeoDNS, y un plan de adopción por fases.

Principios arquitectónicos del DNS

Todo trabajo arquitectónico serio parte de principios: enunciados estables que gobiernan las decisiones cuando aparecen las inevitables tensiones entre costo, seguridad y velocidad. Estos son los que deberían regir una arquitectura DNS empresarial.

Principio	Enunciado	Implicación práctica
DNS como servicio crítico	El DNS se gestiona con el mismo nivel de criticidad que la red o la identidad	SLA formal, presupuesto propio, guardia 24/7
Autoridad centralizada, operación federada	Una única fuente de verdad para las zonas, con delegación controlada	IPAM/DDI central, delegación por subzona
Seguridad por diseño	Integridad y autenticidad antes que comodidad	DNSSEC, CAA, filtrado, registros firmados
Alta disponibilidad por defecto	Ninguna resolución depende de un solo proveedor o región	Anycast, DNS secundario, multi-proveedor
Trazabilidad y control de cambios	Todo cambio es auditable y reversible	DNS-as-Code, versionado, aprobación
Estandarización de nombres	Convenciones consistentes de nomenclatura	Estándar de naming corporativo

Estos principios no son decorativos: son el criterio con el que se resuelven los dilemas de los pasos siguientes. Cuando alguien pida bajar un TTL a cinco segundos "por comodidad", el principio de alta disponibilidad y el de control de cambios dan el lenguaje para decir por qué no.

El DNS en los dominios de TOGAF

TOGAF organiza cualquier arquitectura en cuatro dominios. El DNS los atraviesa todos, y verlo así evita el error clásico de tratarlo como un asunto puramente técnico.

Arquitectura de Negocio. El DNS habilita capacidades de negocio concretas: presencia digital, entregabilidad de correo, confianza de marca (un dominio secuestrado es una crisis reputacional) y continuidad operativa. Los interesados incluyen marketing (dominios de campaña), legal (propiedad de dominios), seguridad y operaciones.

Arquitectura de Datos. Las zonas y sus registros son datos maestros. El sistema de registro (la fuente autoritativa), la clasificación de zonas (internas, externas, DMZ) y el ciclo de vida de cada registro son gobernanza de datos pura.

Arquitectura de Aplicaciones. Cada aplicación consume nombres: el portal resuelve su balanceador, el correo depende de MX y de los registros de autenticación, las integraciones dependen de CNAME y SRV. El DNS es una dependencia transversal del portafolio aplicativo.

Arquitectura Tecnológica. Aquí viven los resolutores, los servidores autoritativos, el Anycast, el DDI y la integración con la red. Es la capa más visible, pero —como muestra este mapeo— la menos importante si las otras tres no están alineadas.

Catálogos, matrices y diagramas

La disciplina de TOGAF se materializa en artefactos: catálogos (listas), matrices (relaciones) y diagramas (representaciones). Estos son los mínimos que una arquitectura DNS debe producir y mantener.

Catálogo de zonas y servicios DNS

Zona	Tipo	Autoritativo	Criticidad	Propietario
empresa.com	Externa	Proveedor Anycast + secundario	Crítica	Plataforma
corp.empresa.com	Interna	DNS interno (DDI)	Crítica	Redes
dmz.empresa.com	DMZ	DNS DMZ	Alta	Seguridad
dev.empresa.com	Interna	DNS interno	Media	Desarrollo

Matriz de dependencias aplicación ↔ registro DNS

Aplicación	Registros que consume	Impacto si falla
Portal web	A/AAAA, CNAME, CAA, HTTPS	Caída total del sitio
Correo corporativo	MX, TXT (SPF), DKIM, DMARC	Pérdida de correo y entregabilidad
VoIP / colaboración	SRV, A/AAAA	Fallo de registro de clientes
Emisión de certificados	CAA, TXT	Imposible emitir/renovar TLS

Matriz RACI de gobernanza DNS

Actividad	Redes	Seguridad	Plataforma	Negocio
Alta/baja de registros	R	C	A	I
Firma DNSSEC y rotación de llaves	C	A/R	C	I
Compra y renovación de dominios	I	C	R	A
Respuesta a incidentes DNS	R	A	R	I

Diagrama descriptivo de la jerarquía

                 [ . ]  Root (13 identidades, Anycast global)
                   |
          +--------+--------+
        [ com ]          [ org ]        Top-Level Domains (TLD)
           |
     [ empresa.com ]                    Zona autoritativa de la empresa
        /     |      \n   [ www ] [ mail ] [ api ]             Registros / subdominios

Este árbol es la clave para entender por qué el DNS escala: la autoridad se delega hacia abajo. Nadie tiene que conocer todos los nombres del mundo; cada nivel solo sabe a quién preguntar en el siguiente.

El flujo de resolución DNS, paso a paso

Entender la resolución es entender por qué el DNS es rápido, resiliente y, a la vez, un objetivo de ataque. Sigamos una consulta por www.empresa.com desde cero, sin nada en caché.

Cliente                Resolutor recursivo         Servidores autoritativos
  |  www.empresa.com?         |                             |
  |-------------------------->|                             |
  |                           |  ?  -> pregunta a Root       |
  |                           |---------------------------->[ . ]
  |                           |<-- "pregunta al TLD .com" ---|
  |                           |---------------------------->[ com ]
  |                           |<-- "pregunta a empresa.com"--|
  |                           |---------------------------->[ empresa.com ]
  |                           |<---- A = 203.0.113.10 -------|
  |<---- 203.0.113.10 -------|  (guarda en caché según TTL)  |

El resolutor recursivo hace el trabajo pesado: consulta de forma iterativa a la raíz, luego al servidor del TLD y finalmente al servidor autoritativo de la zona, que entrega la respuesta. El cliente solo ve la respuesta final. La caché, gobernada por el TTL de cada registro, evita repetir todo este recorrido en cada consulta: es lo que hace que el sistema soporte billones de peticiones diarias sin colapsar.

Dos matices críticos para la empresa: los glue records (que veremos más abajo) evitan un bucle imposible cuando el servidor de nombres está dentro de la propia zona que resuelve, y el DNS de vista dividida (split-horizon) permite que corp.empresa.com resuelva a direcciones internas para empleados y a otra respuesta —o a ninguna— desde Internet.

Documentación de los registros DNS

El corazón operativo del DNS son sus registros. Cada uno resuelve un problema concreto; conocerlos a fondo es la diferencia entre una zona robusta y una fuente crónica de incidentes.

Registros de dirección: A y AAAA

El registro A mapea un nombre a una dirección IPv4; AAAA, a una IPv6. Son la base de casi todo.

www.empresa.com.   3600   IN   A      203.0.113.10
www.empresa.com.   3600   IN   AAAA   2001:db8::10

Restricciones y buenas prácticas. El valor debe ser una IP válida; conviene publicar A y AAAA en paralelo para dual-stack. Caso empresarial: apuntar el nombre a la IP de un balanceador, no a un servidor concreto, para permitir escalado sin tocar el DNS.

CNAME (alias de nombre)

Un CNAME declara que un nombre es alias de otro nombre canónico. La resolución continúa sobre el destino.

blog.empresa.com.   3600   IN   CNAME   empresa.hosting-externo.net.

Restricción clave: un CNAME no puede coexistir con otros registros en el mismo nombre, y por eso no se permite en el ápex del dominio (empresa.com a secas), que obligatoriamente tiene SOA y NS. Caso empresarial: delegar un subdominio a un SaaS (soporte, blog, status) sin gestionar su IP.

ALIAS / ANAME

Son extensiones propietarias de algunos proveedores que imitan a un CNAME pero sí funcionan en el ápex. El servidor autoritativo resuelve el destino y devuelve un registro A/AAAA al cliente, sorteando la restricción anterior.

empresa.com.   300   IN   ALIAS   destino.balanceador-cloud.net.

Restricción: no es un estándar universal; depende del proveedor. Caso empresarial: apuntar el dominio raíz a un CDN o balanceador cloud cuya IP cambia.

MX (servidores de correo)

El registro MX indica qué servidores reciben el correo del dominio y con qué prioridad (menor número, mayor preferencia).

empresa.com.   3600   IN   MX   10   mail1.empresa.com.
empresa.com.   3600   IN   MX   20   mail2.empresa.com.

Restricción: el destino debe ser un nombre con registro A/AAAA, nunca una IP ni un CNAME. Caso empresarial: dos MX con prioridades distintas dan failover automático del correo entrante.

TXT y la tríada de autenticación de correo: SPF, DKIM, DMARC

El registro TXT almacena texto libre; su uso más importante es la autenticación de correo, que no son "tipos" propios sino convenciones sobre TXT (salvo matices).

SPF declara qué servidores pueden enviar correo en nombre del dominio:

empresa.com.   3600   IN   TXT   "v=spf1 include:_spf.proveedor.com -all"

DKIM publica la llave pública con la que se firman los mensajes, en un selector:

selector1._domainkey.empresa.com.   3600   IN   TXT   "v=DKIM1; k=rsa; p=MIGfMA0..."

DMARC define la política cuando SPF o DKIM fallan, y dónde reportar:

_dmarc.empresa.com.   3600   IN   TXT   "v=DMARC1; p=reject; rua=mailto:[email protected]"

Restricción: un dominio debe tener un solo registro SPF (los múltiples rompen la validación) y respetar el límite de 10 consultas de include. Caso empresarial: la combinación SPF + DKIM + DMARC con p=reject es hoy el requisito de facto para que grandes proveedores no marquen el correo corporativo como spam.

NS (servidores de nombres) y SOA (autoridad de zona)

Los registros NS declaran qué servidores son autoritativos para una zona; el SOA (Start of Authority) contiene los parámetros de gobierno de la zona: servidor primario, contacto, número de serie y temporizadores de refresco/reintento/expiración.

empresa.com.   86400   IN   NS    ns1.proveedor.com.
empresa.com.   86400   IN   NS    ns2.proveedor.com.
empresa.com.   86400   IN   SOA   ns1.proveedor.com. hostmaster.empresa.com. (
                                   2026082801 ; serial
                                   7200 3600 1209600 3600 )

Restricción: toda zona debe tener exactamente un SOA y al menos dos NS. Caso empresarial: el número de serie del SOA es el que dispara la transferencia de zona hacia los DNS secundarios; incrementarlo mal rompe la replicación.

SRV (localización de servicios)

El registro SRV publica el host y puerto de un servicio concreto, con prioridad y peso.

_sip._tls.empresa.com.   3600   IN   SRV   10 60 5061 sip1.empresa.com.

Restricción: el nombre sigue el formato _servicio._protocolo. Caso empresarial: VoIP/SIP, Microsoft 365 (autodiscover), XMPP y Active Directory dependen de SRV para localizar sus servicios.

CAA (autorización de autoridades de certificación)

El registro CAA declara qué autoridades de certificación pueden emitir certificados TLS para el dominio.

empresa.com.   3600   IN   CAA   0 issue "letsencrypt.org"
empresa.com.   3600   IN   CAA   0 iodef "mailto:[email protected]"

Restricción: las CA están obligadas a respetarlo antes de emitir. Caso empresarial: evita la emisión fraudulenta o accidental de certificados por una CA no autorizada — un control barato con alto retorno de seguridad.

PTR (resolución inversa)

El registro PTR hace lo contrario que un A: mapea una IP a un nombre, dentro de zonas especiales in-addr.arpa (IPv4) o ip6.arpa (IPv6).

10.113.0.203.in-addr.arpa.   3600   IN   PTR   mail1.empresa.com.

Restricción: normalmente lo gestiona quien controla el bloque IP (el proveedor o el área de red). Caso empresarial: imprescindible para la entregabilidad del correo saliente; muchos receptores rechazan servidores sin PTR coherente (forward-confirmed reverse DNS).

SVCB y HTTPS (registros de servicio modernos)

Los registros SVCB (Service Binding) y su especialización HTTPS permiten publicar parámetros de conexión —protocolo ALPN, puerto, pistas de IP, ECH— en el propio DNS, antes de conectar.

empresa.com.   3600   IN   HTTPS   1 . alpn="h3,h2" ipv4hint=203.0.113.10

Restricción: requiere clientes y resolutores modernos. Caso empresarial: habilita HTTP/3 y el cifrado del SNI (ECH) desde la primera conexión, y permite apuntar el ápex de forma estándar — la evolución natural del truco ALIAS/ANAME.

NAPTR (reescritura de nombres)

El registro NAPTR (Naming Authority Pointer) aplica reglas de reescritura basadas en expresiones regulares, normalmente encadenado con SRV.

empresa.com.   3600   IN   NAPTR   100 10 "U" "E2U+sip" "!^.*$!sip:[email protected]!" .

Restricción: es complejo y de nicho. Caso empresarial: ENUM (mapeo de números telefónicos a URIs SIP) y descubrimiento de servicios en telecomunicaciones.

Glue Records (registros de pegamento)

Un glue record es un registro A/AAAA del propio servidor de nombres, entregado por la zona padre, que rompe una dependencia circular: si ns1.empresa.com es autoritativo de empresa.com, resolver su IP requeriría... preguntar a empresa.com. El glue, publicado en el TLD .com, entrega esa IP directamente.

; en la zona .com (padre)
empresa.com.        NS   ns1.empresa.com.
ns1.empresa.com.    A    198.51.100.5     ; <- glue record

Restricción: solo es necesario cuando los NS están dentro de la zona que sirven. Caso empresarial: obligatorio al operar servidores de nombres propios bajo el mismo dominio; olvidarlo deja la zona irresoluble.

Arquitectura AS-IS y TO-BE

La arquitectura no vive en el vacío: describe un punto de partida y un destino. Este es un contraste típico en organizaciones que aún no han profesionalizado su DNS.

Estado actual (AS-IS)

[ Registrador ] --- panel manual ---> [ DNS único proveedor ]
     |                                        |
  dominios dispersos                 sin DNSSEC, sin secundario
  en varias cuentas                  TTLs arbitrarios, cambios sin registro

Síntomas habituales: dominios repartidos en cuentas personales, un único proveedor sin DNS secundario, ausencia de DNSSEC, TTLs fijados sin criterio, cambios manuales sin trazabilidad y ninguna vista dividida entre interno y externo. Cada uno de estos puntos es un incidente esperando su momento.

Estado objetivo (TO-BE)

              [ IPAM / DDI central: fuente de verdad ]
                 |            (DNS-as-Code, GitOps)
     +-----------+-----------+
 [ Proveedor A ]        [ Proveedor B ]     <- multi-proveedor Anycast
  Anycast global         Anycast global\   secundario con transferencia de zona
     |                       |
  DNSSEC firmado         DNSSEC firmado
  vistas split-horizon   GeoDNS + failover por salud

El destino: una fuente única de verdad gestionada como código, publicada a dos proveedores Anycast independientes, con DNSSEC firmado, GeoDNS y failover por chequeos de salud, vistas separadas para interno y externo, y todo cambio pasando por revisión y versionado. La brecha entre ambos estados es exactamente lo que ordena el roadmap final.

Seguridad, disponibilidad y rendimiento

DNSSEC: integridad y autenticidad

El DNS nació sin seguridad: una respuesta puede ser falsificada (cache poisoning) y el cliente no lo notaría. DNSSEC firma criptográficamente cada registro con una cadena de confianza que va desde la raíz hasta la zona, mediante registros RRSIG (firmas), DNSKEY (llaves) y DS (delegación de confianza publicada en el padre). El resolutor valida la firma y rechaza cualquier respuesta manipulada.

No cifra —DNSSEC garantiza autenticidad e integridad, no confidencialidad; para eso están DoH/DoT— y exige disciplina operativa: la rotación de llaves (KSK y ZSK) y la publicación correcta del DS en el registrador son los puntos donde más despliegues fallan.

TTL: el equilibrio entre frescura y resiliencia

El TTL decide cuánto tiempo se cachea un registro. Un TTL alto (24 h) reduce carga y latencia pero ralentiza los cambios; uno bajo (300 s) agiliza migraciones pero aumenta las consultas y la dependencia del autoritativo. La práctica arquitectónica: TTL alto en registros estables (NS, MX) y bajar el TTL de forma planificada 24-48 h antes de una migración, para volver a subirlo después.

Alta disponibilidad: Anycast, secundarios y failover

Anycast anuncia la misma IP desde muchos puntos de presencia; la red enruta a cada cliente al más cercano, lo que da baja latencia y absorción natural de ataques DDoS. Complementado con un DNS secundario de otro proveedor (transferencia de zona vía serial del SOA), elimina el proveedor único como punto de fallo. El failover basado en chequeos de salud retira automáticamente de las respuestas a un destino caído.

GeoDNS: respuesta según ubicación

GeoDNS devuelve una respuesta distinta según la localización del cliente: dirige a los usuarios europeos al centro de datos europeo y a los americanos al suyo. Mejora latencia y ayuda al cumplimiento de residencia de datos, aunque introduce complejidad de pruebas (una consulta responde distinto según desde dónde se haga).

Otras consideraciones

Cerrar los resolutores abiertos, aplicar rate limiting (RRL) contra ataques de amplificación, registrar y monitorizar consultas hacia un SIEM, y proteger las cuentas del registrador con MFA y bloqueo de transferencia (registry lock) completan una postura defensiva madura.

Gobernanza y operación

La tecnología sin gobierno se degrada. El modelo operativo del DNS debe definir, como mínimo, tres cosas. Primero, propiedad clara: cada zona con un dueño y un proceso de aprobación de cambios (la matriz RACI anterior). Segundo, DNS-as-Code: las zonas como archivos versionados en un repositorio, con revisión por pares y despliegue automatizado, de modo que cada cambio sea trazable, revisable y reversible — el fin de los cambios manuales sin registro. Tercero, gestión del ciclo de vida: inventario de dominios con alertas de expiración (un dominio caducado es una interrupción autoinfligida), revisiones periódicas de registros obsoletos (los "dangling" que habilitan secuestros de subdominio) y métricas de servicio.

Enmarcar esta gobernanza en NIST AI/Cyber frameworks e ISO/IEC 27001 —gestión de cambios, de accesos y de proveedores— la hace auditable y sostenible, no dependiente del héroe que "sabe cómo está configurado el DNS".

Roadmap de adopción por fases

Llevar el DNS del AS-IS al TO-BE no se hace de golpe. Este roadmap secuencia el esfuerzo por valor y riesgo.

Fase 1 — Descubrimiento y consolidación (mes 1-2). Inventariar todos los dominios y zonas, centralizarlos en cuentas corporativas con MFA, documentar el catálogo de zonas y las dependencias aplicativas. Sin visibilidad no hay arquitectura.

Fase 2 — Higiene y estandarización (mes 2-3). Depurar registros obsoletos, unificar convenciones de naming, racionalizar TTLs, corregir SPF/DKIM/DMARC y publicar registros CAA. Victorias rápidas de seguridad y entregabilidad.

Fase 3 — Resiliencia (mes 3-5). Incorporar un segundo proveedor Anycast como DNS secundario, implementar failover por salud y, donde aplique, GeoDNS. Eliminar el punto único de fallo.

Fase 4 — Seguridad avanzada (mes 5-7). Desplegar DNSSEC con un plan de rotación de llaves, activar registry lock, cerrar resolutores y enviar la telemetría al SIEM.

Fase 5 — Automatización y gobierno (mes 7-9). Migrar a DNS-as-Code con GitOps, formalizar la matriz RACI y el proceso de cambios, e instrumentar métricas y alertas de expiración. El DNS pasa a operarse como un producto.

Conclusión: del panel olvidado al activo arquitectónico

El DNS rara vez aparece en las presentaciones de estrategia tecnológica, y sin embargo casi ninguna capacidad digital funciona sin él. Esa asimetría entre su criticidad y la atención que recibe es precisamente el espacio donde una arquitectura bien planteada genera más valor con menos inversión.

Aplicar TOGAF al DNS no es sobrediseñar: es dejar de improvisar. Los principios dan criterio, los dominios dan perspectiva, los catálogos y matrices dan visibilidad, los diagramas dan entendimiento compartido, la gobernanza da control y el roadmap da un camino. Documentar cada registro —de la A al glue, del MX al DMARC, del CAA al HTTPS— convierte el conocimiento tácito de una persona en un activo de la organización.

El objetivo final es simple de enunciar y exigente de lograr: que el sistema nervioso de su conectividad sea invisible porque funciona, no porque nadie lo mira. Una arquitectura DNS madura — centralizada, firmada, distribuida, gobernada y automatizada — es de esas inversiones que solo se notan el día que evitan la crisis que nunca llegó a ocurrir.