Qué es DNS
DNS es un sistema distribuido y jerárquico de nombres. RFC 1034 y RFC 1035 definen los conceptos y mecanismos fundamentales.
DNS permite que aplicaciones y usuarios trabajen con nombres estables mientras las direcciones y la infraestructura cambian. No es una simple tabla mundial: es un sistema jerárquico, distribuido, delegado y con caché. Esa arquitectura explica tanto su escalabilidad como muchos de sus problemas operativos.
Una consulta puede atravesar varios actores. El stub resolver del host pregunta normalmente a un resolver recursivo; éste consulta caché o sigue delegaciones hasta obtener una respuesta autoritativa.
Jerarquía
El espacio de nombres forma un árbol con raíz, TLD y dominios delegados. La autoridad se reparte entre servidores en lugar de depender de una base central única.
El espacio de nombres parte de la raíz, continúa por dominios de nivel superior y se divide mediante delegaciones. Cada etiqueta aporta contexto. La autoridad sobre una zona puede delegarse sin entregar control sobre todo el árbol superior.
Comprender la jerarquía evita pensar que todos los servidores DNS contienen todos los registros. Los servidores raíz y TLD orientan hacia la autoridad correspondiente; no suelen responder con el A final de un host cualquiera.
Recursivo y autoritativo
Un resolver recursivo busca respuestas para el cliente; un servidor autoritativo responde por las zonas que administra. Distinguirlos es fundamental para localizar un fallo.
El resolver recursivo actúa por el cliente, aplica caché y realiza las consultas necesarias. El servidor autoritativo publica datos de una zona concreta. Una misma organización puede operar ambos roles, pero conceptualmente son distintos y deben diagnosticarse por separado.
Si un registro existe en la autoridad pero un resolver devuelve información antigua, el problema puede ser la caché. Si la delegación apunta al servidor equivocado, cambiar el registro dentro de la zona no resolverá el camino de autoridad.
Registros principales
A publica IPv4, AAAA IPv6, CNAME un alias, MX servidores de correo, NS servidores autoritativos, PTR resolución inversa y TXT datos textuales usados por múltiples servicios.
A y AAAA asocian nombres con IPv4/IPv6. CNAME crea un alias hacia otro nombre. MX publica destinos de correo, NS identifica servidores de nombres, PTR se usa en resolución inversa y TXT transporta texto utilizado por múltiples mecanismos.
También son importantes SOA para metadatos de zona y SRV para localizar determinados servicios. La semántica de cada tipo importa: no todos pueden sustituirse entre sí aunque contengan nombres.
Zonas y delegación
Una zona representa una porción administrada del árbol. La delegación utiliza NS y, cuando es necesario, glue records para poder localizar los servidores de la zona hija.
Una zona es la porción del árbol que administra una autoridad. La delegación en el padre publica NS para la zona hija. Cuando el nombre del servidor de nombres está dentro de la propia zona delegada pueden necesitarse glue records en el padre para romper la dependencia circular inicial.
Los fallos de delegación suelen producir resultados diferentes según el resolver y la caché. Por eso herramientas como dig +trace son útiles para seguir la cadena desde la raíz.
Caché y TTL
El TTL permite cachear respuestas. Por eso un cambio puede tardar en verse desde todos los resolvers: distintas cachés expiran en momentos diferentes.
El TTL indica durante cuánto tiempo una respuesta puede permanecer en caché. Reducirlo antes de una migración puede acortar la persistencia de datos antiguos, pero no elimina copias cuyo TTL ya empezó a correr. Aumentarlo reduce carga a costa de menor velocidad de cambio.
Existe también caché negativa: respuestas como NXDOMAIN pueden conservarse durante un periodo. Esto explica por qué crear un registro justo después de una consulta fallida puede no hacerse visible inmediatamente desde todos los resolvers.
UDP y TCP 53
DNS usa el puerto 53 y puede funcionar sobre UDP o TCP según la operación y el tamaño. Decir que DNS siempre usa UDP es incorrecto.
DNS clásico utiliza puerto 53 tanto sobre UDP como sobre TCP. UDP es común en consultas normales; TCP se emplea, entre otros casos, cuando se necesita una respuesta que no cabe adecuadamente en UDP o en operaciones específicas como transferencias de zona. EDNS amplió capacidades de UDP, pero TCP sigue formando parte normal del protocolo.
DNSSEC
DNSSEC permite validar autenticidad e integridad mediante firmas y una cadena de confianza. No cifra las consultas ni oculta los nombres solicitados.
DNSSEC añade firmas que permiten validar origen e integridad de los datos mediante una cadena de confianza. No cifra el contenido de las consultas. Un despliegue mal encadenado puede provocar fallos de validación aunque los registros «existan».
DNSSEC tampoco sustituye a protocolos de transporte cifrado como DoT o DoH; resuelve un problema distinto.
Split DNS
Una organización puede responder de forma distinta a clientes internos y externos. Esto es útil pero exige documentación para evitar diagnósticos contradictorios.
En split DNS o split-horizon, un mismo nombre puede devolver respuestas distintas según el origen o la vista. Es útil para servicios internos/externos, pero aumenta la necesidad de documentar qué resolver consulta cada cliente.
Un diagnóstico debe anotar desde dónde se consulta y contra qué servidor; comparar sólo el nombre sin ese contexto puede llevar a conclusiones falsas.
Troubleshooting
Comprueba conectividad con el resolver, consulta explícitamente el registro, compara con otro resolver, valida NS y delegación, revisa TTL y distingue NXDOMAIN de timeout.
Primero verifica conectividad con el resolver configurado. Después consulta explícitamente el tipo de registro y observa código de respuesta, autoridad y TTL. Compara con un resolver alternativo y, si sospechas delegación, sigue la cadena desde raíz/TLD.
Distingue NXDOMAIN, respuesta vacía, SERVFAIL y timeout: describen situaciones diferentes. Si sólo falla un nombre, mira su zona; si falla todo, comprueba primero resolver, DHCP y conectividad.
Relación con DHCP
DHCP puede entregar la dirección de los resolvers DNS. Si un host tiene IP válida pero no conoce resolver, el problema puede estar en las opciones DHCP.
DHCP suele entregar la lista de resolvers a los clientes. Una opción incorrecta puede hacer que toda una VLAN tenga conectividad IP pero falle por nombre. También pueden existir mecanismos de actualización dinámica de DNS coordinados con DHCP en determinados entornos.
Referencias
RFC 1034 y 1035 son la base de DNS; RFC 4033 introduce los requisitos y conceptos de DNSSEC.
RFC 1034 y RFC 1035 constituyen la base clásica de DNS. RFC 4033 introduce DNSSEC y sus conceptos. Las extensiones modernas son numerosas, por lo que conviene verificar el RFC específico cuando se implementen funciones avanzadas.
Cómo continuar
Relaciona DNS con DHCP, que suele entregar los resolvers; con NTP para infraestructuras autenticadas y registros coherentes; y con routing si el resolver o autoridad están en otra red.
Ejemplo operativo
En una red real, DNS debe documentarse junto con direccionamiento, VLAN, rutas y políticas. El diagnóstico más fiable separa primero conectividad IP de la función del servicio, verifica el camino de ida y vuelta y después revisa la configuración específica. Esta disciplina evita atribuir a DNS fallos que en realidad pertenecen a Capa 2, routing, ACL o resolución de nombres.
También conviene registrar cambios y medir antes y después. Una configuración técnicamente válida puede tener un efecto operativo distinto al esperado si existen dependencias no documentadas o si varios dispositivos aplican políticas diferentes.
Después de migrar una aplicación, algunos usuarios ven el servidor nuevo y otros el antiguo. Si ambos destinos responden, el problema puede no estar en la aplicación ni en routing: distintos resolvers conservan respuestas con TTL todavía vigente. Consultar cada resolver y observar TTL permite demostrarlo.
Otro caso: un dominio devuelve SERVFAIL sólo en resolvers validadores. La existencia del A no basta; una cadena DNSSEC rota puede hacer que la respuesta sea considerada no válida.