DNS Desde los Primeros Principios

Nota: Este es contenido de ejemplo creado para demostrar el blog. Sustitúyelo por tu propio texto.

Durante buena parte de mi carrera traté el DNS como la mayoría de los ingenieros: como una caja negra que "simplemente funciona" hasta que deja de hacerlo. No fue hasta que tuve que depurar una configuración split-horizon en la red de un cliente cuando realmente me detuve a leer las RFC relevantes. Esta entrada es la explicación que hubiera querido tener antes — corta, fundamentada y centrada en lo que importa para quien trabaja en seguridad.

El Problema Que Resuelve DNS#

El Domain Name System es, en esencia, una base de datos distribuida y eventualmente consistente que mapea nombres legibles para humanos a datos utilizables por máquinas. El mapeo más conocido es nombre → dirección IP, pero el sistema transporta bastante más que eso (servidores de correo, delegaciones de servidores de nombres, registros de texto, pistas de descubrimiento de servicios, pruebas criptográficas).

Dos presiones de diseño moldean todo en DNS:

1. El espacio de nombres es enorme y cambia constantemente. Ningún servidor único podría almacenarlo.
2. Las consultas ocurren en el camino crítico de casi todas las conexiones. La latencia importa.

El resultado es un sistema jerárquico y fuertemente cacheado, en el que la autoridad se delega de arriba hacia abajo desde la raíz, y cada participante puede recordar durante un tiempo lo que aprendió.

El Flujo de Resolución#

Cuando escribes https://example.com en el navegador, la parte que le importa a DNS es example.com. Antes de cualquier handshake TLS, antes de cualquier conexión TCP, el navegador necesita una dirección IP. Este es el camino que la petición suele recorrer.

El Stub Resolver#

Tu aplicación no habla DNS por sí misma. Le pasa el nombre a un stub resolver dentro del sistema operativo (getaddrinfo de glibc, el resolver de musl, la API getaddrinfo de Win32). El stub resolver lee /etc/resolver.conf o la configuración de red del sistema para encontrar un resolvedor recursivo — normalmente el anunciado por DHCP, o uno definido manualmente como 1.1.1.1 o 8.8.8.8.

El Resolvedor Recursivo#

El resolvedor recursivo (también llamado caching resolver o recursor) es la parte que realmente recorre el árbol. Si ya tiene la respuesta en caché, la devuelve de inmediato. Si no, realiza una consulta iterativa comenzando por la raíz:

1. Pregunta a un servidor de la raíz: "¿dónde está .com?"
2. Pregunta a un servidor TLD de .com: "¿dónde está example.com?"
3. Pregunta al servidor autoritativo de example.com: "¿cuál es la dirección de example.com?"

Cada paso devuelve una referencia — un apuntador al siguiente servidor, más cercano a la respuesta — en lugar de la propia respuesta. El recursor cachea cada referencia y cada respuesta con un TTL.

Servidores Autoritativos#

Los servidores autoritativos son la fuente de verdad de una zona. No hacen recursión; responden a partir de sus propios datos o se rechazan. Una sola zona suele ser servida por varios servidores autoritativos por redundancia, y en configuraciones modernas se esconden tras servicios como Cloudflare, Route 53 o NS1.

Un atajo mental útil: el resolvedor recursivo hace preguntas en nombre de los clientes; el servidor autoritativo responde preguntas sobre zonas que posee. Un mismo software (BIND, Unbound, Knot) puede desempeñar ambos roles, pero en producción casi siempre se despliegan como roles separados.

Tipos de Registro#

Los registros DNS están tipados. El tipo indica qué clase de dato transporta el registro. Estos son los que más uso a diario:

Tipo	Propósito	Ejemplo
A	Dirección IPv4 para un nombre	93.184.216.34
AAAA	Dirección IPv6 para un nombre	2606:2800:220:1:248:1893:25c8:1946
CNAME	Nombre canónico — un alias hacia otro nombre	www.example.com → example.com
MX	Mail exchanger (con prioridad)	10 mail.example.com
TXT	Texto arbitrario (SPF, DKIM, verificación de dominio)	"v=spf1 -all"
NS	Servidores autoritativos de una zona	a.iana-servers.net
SOA	Start of authority — metadatos de la zona	serial, refresh, retry, expire, minimum
PTR	Búsqueda inversa — IP → nombre	34.216.184.93.in-addr.arpa → example.com

CNAME merece una nota: un nombre con un registro CNAME no puede tener ningún otro tipo de registro. Por eso, bajo la lectura estricta de las RFC originales, no se puede colocar un CNAME en el ápex de una zona (el example.com desnudo) — aunque los proveedores ofrecen "flattening" o pseudo-registros ALIAS/ANAME para sortearlo.

Consultar DNS Por Ti Mismo#

dig es la herramienta que toco primero cuando algo se siente raro. Es verboso, predecible y viene en la mayoría de sistemas macOS / Linux. Algunas recetas que uso cada semana:

# Consulta por defecto de registro A contra el resolvedor del sistema.
dig example.com

# Consulta a un resolvedor específico (aquí: el 1.1.1.1 de Cloudflare).
dig @1.1.1.1 example.com

# Solo la respuesta corta — ideal para scripts.
dig +short example.com AAAA

# Sigue la cadena de delegación manualmente. Muestra cada
# referencia desde la raíz hasta la respuesta autoritativa.
dig +trace example.com

# Trae registros TXT — útil para verificar SPF / DKIM.
dig +short TXT example.com

Una respuesta típica de +short es solo el dato:

$ dig +short example.com
93.184.216.34

Una respuesta completa de dig incluye la cabecera, la sección de pregunta, la respuesta, autoridad y registros adicionales, junto con una línea de estado. Presta atención a status: NOERROR frente a status: NXDOMAIN — el primero significa "el nombre existe, aquí está la respuesta (o su ausencia)"; el segundo significa "el nombre no existe en ninguna parte bajo la autoridad de esta zona".

Consideraciones de Seguridad#

DNS se diseñó en un mundo donde se asumía que la red era cooperativa en general. Esa asunción no se sostiene desde hace décadas, y la historia de seguridad de DNS es, en gran parte, la historia de retrofitar autenticidad y confidencialidad sobre un protocolo que originalmente no tenía ninguna de las dos.

Spoofing de DNS y Envenenamiento de Caché#

Un ataque de spoofing ocurre cuando un atacante engaña a la víctima para que acepte una respuesta DNS forjada. El clásico ataque Kaminsky (2008) demostró cómo un atacante off-path podría envenenar la caché de un resolvedor recursivo compitiendo con respuestas forjadas contra las legítimas, explotando la previsibilidad de los IDs de transacción y los puertos de origen. Los resolvers modernos aleatorizan ambos, lo que eleva el coste pero no elimina el problema subyacente.

La corrección estructural es DNSSEC (RFC 9364), que firma registros criptográficamente para que el resolvedor pueda verificar que una respuesta provino genuinamente del operador de la zona y no fue alterada en tránsito. El despliegue de DNSSEC es desigual — muchos TLD lo soportan, muchas zonas individuales no — pero vale la pena entenderlo porque la cadena de confianza (raíz → TLD → zona) es un ejemplo limpio de cómo hacer firma jerárquica.

DoH y DoT#

Incluso con DNSSEC, el DNS plano no está cifrado. Cualquiera en el camino entre tú y tu resolvedor puede ver qué nombres estás consultando. Dos protocolos abordan esto:

• DNS-over-TLS (DoT) (RFC 7858) ejecuta DNS sobre TLS en el puerto 853.
• DNS-over-HTTPS (DoH) (RFC 8484) ejecuta DNS sobre HTTPS, normalmente en el puerto 443.

DoT es la opción más limpia para configuración a nivel de sistema — puerto dedicado, fácil de filtrar, fácil de monitorizar. DoH es la mejor opción cuando necesitas que el DNS parezca tráfico web normal para atravesar una red restrictiva, por eso los navegadores lo usan por defecto para su propia resolución interna.

Ni DoT ni DoH autentican el contenido de la respuesta — autentican el transporte. Para el contenido sigue haciendo falta DNSSEC. Ambos son complementarios, no sustitutos.

Un Checklist Práctico de Hardening#

Cuando audito la postura DNS de una red, las preguntas que recorro son más o menos:

1. ¿Los resolvedores recursivos en uso soportan validación DNSSEC, y está habilitada?
2. ¿Los stub resolvers usan DoT o DoH donde la red lo permite?
3. ¿Las zonas autoritativas están firmadas con DNSSEC, y el registro DS está publicado en el padre?
4. ¿Hay registros TXT de SPF, DKIM y DMARC presentes y alineados para los dominios que envían correo?
5. ¿Existen registros PTR para los servidores de correo saliente? (Muchos destinatarios rechazan correo sin uno.)
6. ¿Los TTL son razonables? TTLs muy largos convierten los cambios de emergencia en algo doloroso; muy cortos transforman el DNS en un plano de control oculto.

Notas Finales#

DNS es uno de esos sistemas en los que los fundamentos — jerarquía, delegación, caché, TTLs — explican casi todo lo que verás en la práctica. Cuando eso encaja, depurar comportamientos raros de resolución pasa de "estoy adivinando" a "estoy siguiendo la cadena". Las extensiones de seguridad (DNSSEC, DoT, DoH) tienen mucho más sentido cuando logras separar integridad del transporte de autenticidad de los datos de confidencialidad en el medio.

Para profundizar, las referencias canónicas son la RFC 1034 y la RFC 1035 para el protocolo original, el conjunto de RFCs de DNSSEC para firma, y la documentación de PowerDNS para una visión operativa bien escrita desde una stack real autoritativa + recursiva.