DNS subzona: qué es y cómo funciona dentro de una zona DNS

Informatec Digital » Recursos » DNS subzona: qué es y cómo funciona dentro de una zona DNS

Si trabajas con dominios y hosting o simplemente administras una web, tarde o temprano te toparás con expresiones como zona DNS, subzona, archivos de zona y registros. Suenan técnicos, pero en cuanto los bajas a tierra verás que todo tiene bastante lógica y que, con unas cuantas ideas claras, puedes manejar tu propio DNS sin morir en el intento.

En las siguientes líneas vamos a ver con calma qué es una zona DNS y una subzona, cómo encajan en la jerarquía del sistema de nombres de dominio, qué tipos de zonas existen, cómo se delegan, cuáles son los registros más habituales, qué problemas dan guerra y cómo evitarlos, todo ello explicado en un español de a pie, pero sin perder el rigor técnico.

Recordatorio rápido: cómo funciona el DNS por dentro

Para entender qué pinta una subzona DNS hay que tener claro primero el propio Sistema de Nombres de Dominio (DNS). El DNS es un sistema jerárquico y distribuido que se encarga de traducir nombres legibles por humanos (como ejemplo.com) en direcciones IP que entienden los ordenadores.

Mucha gente compara el DNS con una “guía telefónica de Internet”, aunque hoy cuadra más la idea de agenda de contactos del móvil: tú buscas por nombre, y el sistema ya se apaña para encontrar el número sin que tú tengas que memorizarlo.

Cuando escribes un dominio en el navegador, se lanza una consulta DNS (búsqueda o resolución). El dispositivo del usuario pregunta a un “resolver recursivo” (normalmente el DNS de tu proveedor de Internet o de algún servicio público tipo Google o Cloudflare), y ese resolver es quien va interrogando distintos servidores DNS hasta dar con el registro correcto.

La resolución sigue una estructura jerárquica muy clara: primero se consulta a los servidores raíz, que gestionan la zona raíz del DNS y devuelven qué servidores llevan cada dominio de nivel superior (TLD) como .com, .es, .ovh, etc.

Después, el resolver pregunta al servidor de nombres del TLD correspondiente (.com, .gov, .ovh…) para que le diga qué servidores de nombres tienen autoridad sobre el dominio concreto, por ejemplo midominio.com. Finalmente, esos servidores de nombres autorizados para el dominio son los que responden con los registros DNS concretos: IP de la web, servidor de correo, subdominios, etc.

Jerarquía de dominios, FQDN y estructura por niveles

Todo este sistema se basa en que un dominio se compone de bloques separados por puntos, que se resuelven de derecha a izquierda. El nombre de dominio totalmente cualificado, el famoso FQDN (Fully Qualified Domain Name), incluye todos esos niveles y termina en un punto raíz, aunque ese punto final no se muestre normalmente en el navegador.

Así, en un nombre como soporte.mydomain.ovh, el bloque más a la derecha es el TLD (.ovh), a su izquierda está el dominio de segundo nivel (mydomain), y luego van los subdominios (soporte, www, blog, etc.). El DNS va resolviendo cada bloque en orden inverso: primero la raíz, luego el TLD, luego el dominio, luego el subdominio.

Cada conexión a Internet suele tener asociados al menos un servidor DNS principal y uno secundario, que se obtienen automáticamente vía DHCP. El secundario sirve de respaldo si falla el principal, lo que ayuda a mantener la web y los servicios accesibles.

Al recibir una consulta, el servidor DNS puede comportarse de dos formas: si ya conoce el dominio porque lo tiene en caché, responde al instante usando la información almacenada, limitada por el parámetro TTL (Time To Live); si no lo conoce, inicia toda la cadena de consultas hacia raíz, TLD y servidores autoritativos hasta llegar a la zona que contiene el subdominio o dominio solicitado.

Qué es una zona DNS y qué es una subzona DNS

Dentro de ese gran árbol de nombres, el espacio DNS se organiza en zonas DNS. Una zona DNS es una parte del espacio de nombres que está administrada por una entidad concreta (una empresa, un proveedor de hosting o un administrador).

En la práctica, una zona DNS es una unidad administrativa: define hasta dónde se tiene autoridad para crear, modificar y borrar registros. Puede abarcar solo el dominio base (por ejemplo ecohosting.cl) o también incluir uno o varios de sus subdominios.

Imagina el dominio ecohosting.cl con estos subdominios: soporte.ecohosting.cl, clientes.ecohosting.cl y blog.ecohosting.cl. Si soporte y clientes son servicios sencillos ligados al propio hosting principal, lo cómodo es gestionarlos en la misma zona que ecohosting.cl. Pero si el blog es un proyecto independiente, desarrollado por otro equipo o en otro proveedor, tiene todo el sentido darle su propia zona DNS.

En ese caso, ecohosting.cl, soporte.ecohosting.cl y clientes.ecohosting.cl compartirían una zona, mientras que blog.ecohosting.cl constituiría una subzona DNS delegada, con sus propios servidores de nombres y su propio archivo de zona. Ahí es donde aparece la idea de “DNS subzone”: una parte del dominio asignada a otra zona distinta para delegar el control.

Las zonas DNS no tienen por qué estar separadas físicamente en servidores distintos: se trata más bien de una separación lógica para delegar autoridad. En un mismo servidor de nombres puedes tener múltiples zonas, cada una con su archivo de zona independiente.

Tipos de zonas DNS: primaria, secundaria, directa, inversa y stub

Cuando profundizas un poco en administración DNS, verás que no todas las zonas son iguales. Existen distintos tipos de zonas DNS, pensados para cubrir necesidades diferentes dentro de la infraestructura.

La zona DNS primaria es la copia de lectura y escritura principal de una zona. Sus datos se guardan en un archivo maestro en un servidor determinado, y cualquier cambio en los registros debe hacerse ahí. Solo puede haber un archivo maestro por zona en un servidor concreto.

La zona DNS secundaria es una copia de solo lectura de la zona primaria. Se mantiene sincronizada con el maestro usando transferencias completas AXFR o incrementales IXFR. Su función principal es dar redundancia y disponibilidad: si el servidor primario cae, los resolvers pueden seguir consultando los servidores secundarios que figuran en los registros NS.

También tenemos la llamada zona de búsqueda directa, que es la que se usa para traducir nombres de dominio en direcciones IP. En ella se almacenan registros A (para IPv4) y AAAA (para IPv6), junto con otros tipos de registros asociados al nombre.

En el lado contrario está la zona de búsqueda inversa, que hace el camino inverso: a partir de una IP devuelve el nombre de dominio, usando registros PTR. Es muy habitual que servicios de correo y sistemas de seguridad revisen esta relación inversa para validar que una IP realmente corresponde al dominio que dice ser.

Por último, existe un tipo especial llamado zona stub, una versión reducida de una zona que solo contiene registros imprescindibles: NS para saber qué servidores son autoritativos, A/AAAA para que esos servidores sean localizables, y el SOA. Este tipo de zona ayuda a que grandes redes mantengan listas actualizadas de servidores autoritativos para zonas delegadas, sin necesidad de almacenar todos los registros.

Archivos de zona DNS y elementos clave

Toda la información de una zona se almacena en su archivo de zona DNS, que es un archivo de texto plano en el servidor de nombres. Cada línea representa un registro de recursos, y la colección de todos ellos describe por completo cómo debe resolverse ese dominio y sus subdominios.

Cada archivo de zona debe comenzar con un registro SOA (Start of Authority). El SOA indica cuál es el servidor de nombres principal de la zona, quién es el responsable técnico, números de serie y tiempos que regulan la caché, las transferencias a secundarios y los reintentos.

Un parámetro crítico en todo esto es el TTL (Time To Live), que le dice a los resolvers cuánto tiempo pueden conservar en caché cada registro antes de volver a preguntar. Un TTL alto reduce tráfico DNS pero hace que los cambios tarden más en propagarse; un TTL bajo acelera los cambios, pero aumenta el número de consultas.

En estos archivos de zona se incluyen los diferentes tipos de registros: direcciones IP, servidores de correo, registros de texto para seguridad del correo, alias de subdominios, etc. Cada registro usa una sintaxis DNS muy concreta, parecida a pequeñas “instrucciones” que el servidor entiende para saber qué responder.

Tipos de registros DNS más habituales en una zona o subzona

Dentro de una zona DNS vas a trabajar sobre todo con un grupo de registros muy concretos. Estos son los registros DNS más comunes que encontrarás al gestionar una zona o una subzona.

El registro A vincula un nombre de dominio o subdominio con una dirección IPv4. Por ejemplo, www.midominio.com apuntando a 203.0.113.10. Es el básico para que una web cargue desde una IP concreta.

El registro AAAA cumple la misma función, pero apuntando a una dirección IPv6. Cada vez es más habitual verlo en entornos modernos, sobre todo si tu proveedor ya soporta IPv6 de forma completa.

Los registros MX indican los servidores de correo responsables de recibir emails para el dominio. Suelen ir acompañados de una prioridad numérica que marca qué servidor se usa primero y cuáles quedan como respaldo.

Los registros CNAME sirven para crear alias: un nombre apunta a otro nombre, no a una IP. Por ejemplo, blog.midominio.com podría ser un CNAME de midominioblog.hostingexterno.com. No devuelven IP directamente, sino que redirigen a otro nombre que sí la tendrá.

Los registros NS especifican qué servidores de nombres son autoritativos para una zona o subzona. Son la clave para la delegación: cuando creas una subzona DNS para un subdominio, registras en la zona principal unos NS que apuntan a los servidores autoritativos de esa subzona.

El ya mencionado registro SOA almacena los datos de autoridad: servidor maestro, email del administrador (formateado de forma especial), número de serie de la zona y distintos tiempos de refresco, reintentos, expiración y TTL mínimo.

Los registros TXT guardan cadenas de texto arbitrarias asociadas al dominio. Se usan muchísimo para temas de seguridad de correo (SPF, DKIM, DMARC), verificación de dominio en servicios externos (Google, Microsoft, etc.) y metadatos varios.

Los registros SRV indican qué host y puerto proporcionan un servicio concreto (por ejemplo, VoIP, mensajería o determinados servicios internos), mientras que los registros PTR se utilizan en las zonas inversas para mapear IP a nombre de dominio.

Registros DNS menos frecuentes pero importantes

Además de los clásicos, el estándar DNS define un buen puñado de registros menos conocidos que se utilizan en contextos muy específicos, muchas veces relacionados con seguridad o servicios avanzados.

El registro AFSDB se diseñó para el sistema de ficheros distribuido Andrew (AFS) y ayuda a localizar celdas AFS en estructuras de almacenamiento en red.

El registro APL es experimental y se usa para almacenar listas de rangos de direcciones, algo muy poco habitual en entornos comunes.

Los registros CAA son cada vez más importantes: permiten que el propietario del dominio especifique qué autoridades de certificación (CA) pueden emitir certificados para ese dominio, lo que refuerza la seguridad de la capa TLS. Si no hay CAA, cualquier CA podría emitir certificados para ese dominio.

El registro DNSKEY almacena claves públicas usadas por DNSSEC (Domain Name System Security Extensions), el conjunto de extensiones que añade firmas criptográficas a los registros DNS para evitar manipulaciones.

El registro CDNSKEY es básicamente una copia “hija” de DNSKEY pensada para ser transferida a la zona padre, facilitando la validación en cadenas DNSSEC.

El registro CERT guarda certificados de claves públicas, mientras que el registro DHCID almacena información usada por DHCP (el protocolo de configuración dinámica de host) para coordinar asignaciones y evitar conflictos.

El registro DNAME es similar a CNAME pero a otro nivel: crea un alias de dominio completo, de forma que no solo el nombre apuntado sino todos sus subdominios quedan redirigidos a otro árbol de nombres.

El registro LOC puede almacenar información geográfica (latitud, longitud, altitud) asociada a un dominio, algo que a veces se aprovecha en servicios de geolocalización o documentación interna.

El registro NAPTR combinado con SRV permite crear dinámicamente URIs de servicios según patrones, algo útil en ciertas aplicaciones de voz sobre IP o mensajería.

En el mundo DNSSEC aparecen también los registros NSEC, que sirven para demostrar criptográficamente que un registro NO existe, y los registros RRSIG, que almacenan las firmas digitales de los conjuntos de registros.

Por último, existen otros como el registro RP (persona responsable, que apunta al email del responsable del dominio) o el registro SSHFP, que permite publicar huellas de claves públicas SSH para reforzar la seguridad de conexiones remotas.

DNSSEC, seguridad y buenas prácticas en la gestión de zonas

Las zonas y subzonas DNS son objetivos muy jugosos para atacantes, porque alterar unos pocos registros puede redirigir tráfico web, secuestrar correos o suplantar servicios. Por eso la seguridad en la gestión de la zona es tan crítica.

Un primer paso es proteger las credenciales del panel de DNS (sea cPanel, Plesk, un panel propio del proveedor o un panel como core-admin). Conviene usar contraseñas robustas, no compartir accesos y activarlo todo con doble factor de autenticación cuando sea posible.

La activación de DNSSEC añade una capa extra de protección: los registros DNS se firman digitalmente y los resolvers que validan DNSSEC pueden detectar si alguien intenta inyectar respuestas falsas o manipular registros en tránsito.

También es clave revisar con cuidado cada cambio de registros para evitar errores de configuración: una prioridad equivocada en MX, una IP mal escrita en un A, una CNAME que se queda en bucle o un punto que falta al final de un nombre pueden dejar tu web o correo fuera de juego.

Conviene acostumbrarse a utilizar herramientas de comprobación DNS para validar los cambios: CMD (dig, nslookup), paneles de diagnóstico del propio proveedor o servicios online de comprobación de propagación y de estado de DNSSEC.

Propagación de cambios y TTL en zonas y subzonas

Cuando editas la zona o una subzona DNS (por ejemplo, cambiando la IP del servidor de la web o modificando los MX), los cambios se aplican de inmediato en los servidores autoritativos, pero no se reflejan instantáneamente en todo el planeta.

La causa es la caché: los resolvers DNS almacenan las respuestas durante el tiempo marcado por el TTL del registro. Hasta que no expira ese TTL, seguirán sirviendo la versión antigua, de ahí la famosa “propagación DNS”.

Ese proceso puede durar desde unos pocos minutos hasta 24-48 horas en escenarios extremos, dependiendo de los valores de TTL configurados y de cómo cachea cada ISP. Por eso, en cambios críticos conviene bajar temporalmente el TTL unos días antes, esperar a que se propaguen esos nuevos TTL y luego hacer el cambio “gordo”.

Durante la propagación es posible que algunos usuarios vean la web o el correo viejo, y otros ya estén llegando al nuevo servidor. Puedes monitorizar este proceso con herramientas online que revisan tus registros desde múltiples ubicaciones.

Uso de subdominios, subzonas y redirecciones

Crear subdominios es una forma muy flexible de organizar tu proyecto: puedes tener blog.midominio.com, tienda.midominio.com, soporte.midominio.com y así separar servicios, tecnologías o incluso proveedores.

Para muchos subdominios bastará con gestionarlos en la misma zona del dominio principal, añadiendo registros A, AAAA o CNAME según toque. Pero cuando un subdominio se vuelve muy complejo o quieres que lo gestione otro equipo o proveedor, puede tener sentido delegarlo a una subzona DNS independiente.

Esa delegación se hace creando registros NS dentro de la zona principal apuntando a los servidores de nombres del subdominio. Desde ese momento, todas las consultas para esa rama del espacio de nombres se resuelven en la subzona.

Además de subdominios, también es habitual usar redirecciones HTTP de un dominio o subdominio a otro, algo que se define en el servidor web o mediante servicios de redirect del propio registrador. Esto no es un registro DNS como tal (salvo casos concretos con registros especializados), sino una respuesta del servidor HTTP.

Paneles como cPanel, Plesk, ISPConfig o los paneles propios de cada proveedor de hosting suelen ofrecer asistentes gráficos para crear subdominios, editar zonas y configurar redirecciones sin tener que tocar directamente el archivo de zona.

Beneficios de dividir en zonas y subzonas DNS

Repartir un gran espacio de nombres en varias zonas y subzonas DNS tiene ventajas claras, sobre todo a medida que crece un proyecto o una organización.

Por un lado está la descentralización: distintas unidades, departamentos o proveedores pueden administrar sus propios trozos del dominio sin pisarse unos a otros.

También mejora el rendimiento y la escalabilidad: al tener archivos de zona más pequeños, las actualizaciones y las transferencias entre primarios y secundarios son más ligeras, y se reparte la carga entre varios servidores de nombres.

La delegación de subzonas facilita además la distribución del tráfico entre distintos centros de datos o proveedores, lo que ayuda a equilibrar cargas, mejorar latencias y aumentar la resiliencia frente a caídas de un solo proveedor.

Desde el punto de vista organizativo, permite una gestión granular: cada equipo controla únicamente los registros que le afectan, lo que reduce riesgos de errores en dominios o servicios ajenos.

Delegación de una subzona DNS paso a paso (conceptualmente)

La delegación de una subzona DNS consiste en partir una zona grande en zonas más pequeñas y asignar cada una a servidores autoritativos diferentes, normalmente para subdominios concretos.

Supongamos que tienes el dominio yourdomain.com y quieres que it.yourdomain.com lo gestione otro equipo o proveedor. Lo primero es crear en la zona principal un conjunto de registros NS para it.yourdomain.com apuntando a los nombres de los servidores DNS que llevarán esa subzona.

Si esos servidores están dentro del propio dominio (por ejemplo ns1.yourdomain.com), en la zona principal deberás añadir también registros A (o AAAA) para esos servidores, de forma que sean resolvibles y los resolvers puedan encontrarlos correctamente.

A partir de ahí, en el servidor designado para la subzona it.yourdomain.com se crea un archivo de zona nuevo con su propio SOA, sus NS y todos los registros necesarios (A, MX, TXT, etc.) para ese subdominio.

De esta manera, las consultas para www.yourdomain.com seguirán resolviéndose en la zona principal, mientras que las que vayan a it.yourdomain.com o a subdominios dentro de esa rama pasarán a la subzona delegada, que será ahora la autoridad en esa parte del árbol.

Cambios, monitorización y problemas típicos en zonas DNS

Cada vez que añades, modificas o borras un registro en la zona o subzona DNS estás realizando un cambio de zona. Aunque parezcan cambios sencillos, un despiste puede tener consecuencias serias sobre la disponibilidad de la web, del correo o de servicios críticos.

Algunos sistemas permiten activar notificaciones de cambio de zona (ZCN) o mecanismos similares para que los servidores secundarios o servicios externos sepan que ha habido actualizaciones y sincronicen la nueva versión.

Un primer problema muy común son los retrasos de propagación debidos a TTL largos. Usuarios en diferentes partes del mundo pueden estar viendo versiones antiguas y nuevas a la vez, lo que complica diagnósticos si no tienes claro qué resolver está respondiendo a quién.

Otro bloque de fallos habituales tiene que ver con errores de configuración: IP equivocadas, prioridades incorrectas en MX, CNAME mal construidos, nombres sin punto final cuando deberían llevarlo, registros duplicados o conflictivos, etc.

Para minimizar riesgos, es buena idea usar una metodología de cambios controlada: documentar modificaciones, aplicar cambios primero en entornos de prueba cuando sea posible y verificar después con herramientas de diagnóstico DNS que todo responde como debería.

Diferencia entre zona DNS, subzona y servidor DNS

Es fácil confundir la zona DNS con el propio servidor DNS o con el concepto de dominio, pero son cosas distintas que conviene separar mentalmente.

Una zona DNS es el ámbito administrativo que define hasta dónde llega la autoridad de un archivo de zona concreto. Puede abarcar un dominio completo y todos sus subdominios o solo una parte delegada como una subzona específica.

Un servidor DNS es la máquina (física o virtual) o el software que almacena esos archivos de zona y responde a las consultas. En un mismo servidor pueden convivir múltiples zonas y subzonas pertenecientes a dominios distintos.

El dominio es el nombre que se registra en un TLD (midominio.com, midominio.es, etc.). Ese dominio puede implementarse a nivel DNS como una única zona o como varias subzonas, dependiendo de cómo quieras repartir la administración y la carga.

Separar las zonas por subdominios no es obligatorio, pero es una práctica muy útil cuando la infraestructura crece, porque permite delegar, escalar y aislar mejor problemas. La clave siempre está en definir bien qué parte de tu árbol de nombres necesita independencia administrativa o técnica.

Cuando se entienden estos conceptos y se tiene claro qué es una zona, una subzona, qué papel juegan los archivos de zona y los distintos tipos de registros, gestionar el DNS deja de ser territorio oscuro; con una buena planificación de zonas y subzonas, un uso sensato de TTL y herramientas de diagnóstico a mano, es bastante más fácil mantener dominios, subdominios y servicios funcionando con estabilidad, rendimiento y seguridad.