DNS: el protocolo que ya no puedes permitirte no entender

Hay un protocolo que interviene en prácticamente todo lo que haces en Internet (cada API que llamas, cada modelo de IA al que pides una respuesta, cada repositorio que clonas) y que la mayoría de los profesionales de tecnología jamás ha estudiado en serio. El DNS convierte nombres en direcciones, sí, pero también decide si tu tráfico va al servidor legítimo o a uno suplantado, filtra información sobre a qué servicios te conectas y puede convertirse en un canal de exfiltración que atraviesa casi cualquier firewall. Básicos DNS interactivo es un curso gratuito, publicado en GitHub Pages, que recorre este protocolo desde la primera consulta hasta la validación DNSSEC, y lo hace con una metodología práctica: mapas clicables, un simulador de resolución, un laboratorio de consultas local y un quiz autocorregido.

Llevo tiempo convencido de que el DNS es la superficie de ataque más olvidada de la infraestructura moderna. Auditaríamos una API antes que un resolver. Revisaríamos un modelo antes que un registro DS. Y sin embargo, la cadena nombre → IP → conexión es la primera decisión de confianza de todo el stack. Este curso, construido por David como proyecto educativo estático con HTML, CSS y JavaScript puro, ataca exactamente ese hueco de conocimiento. En este artículo lo analizo a fondo: qué contiene cada sección, cómo funciona su mecánica interactiva, por qué el DNS importa como superficie de ataque y cómo sacarle el máximo partido con un plan de estudio concreto.

Para quién es este curso y qué ganas al completarlo

El curso está pensado para tres perfiles que se solapan más de lo que parece:

• Desarrolladores que consumen APIs, despliegan servicios y configuran dominios sin entender qué pasa por debajo cuando escriben api.openai.com o github.com.
• Profesionales de seguridad que necesitan una base sólida de DNS antes de adentrarse en ataques específicos: respuestas suplantadas, resolvers abiertos usados en amplificación, transferencias de zona expuestas o fugas de privacidad en las consultas.
• Personas que trabajan con IA y quieren entender el tráfico que generan sus herramientas: cada llamada a un endpoint de inferencia empieza por una resolución DNS, y la privacidad de esa resolución dice mucho de ti.

Al completarlo serás capaz de leer una respuesta DNS y entender sus secciones (Answer, Authority, Additional), interpretar códigos como NOERROR, NXDOMAIN, NODATA, SERVFAIL o FORMERR, razonar sobre TTL y caché antes de una migración, entender qué aporta y qué no aporta DNSSEC, y reconocer señales de riesgo operativo como delegaciones lame o resolvers abiertos. Es el curso de fundamentos que hace que después los ataques DNS tengan sentido, no un curso de exploits.

Anatomía del curso, sección por sección

El curso está organizado en bloques que siguen una progresión deliberada: primero el mapa global del ecosistema, después el recorrido de una consulta, luego la zona y sus registros, el laboratorio de consultas, los riesgos operativos, el quiz y el material de repaso. Voy a por cada uno.

Mapa del ecosistema: once piezas y sus relaciones

La primera sección es un grafo interactivo (construido con Cytoscape.js) donde cada nodo es una pieza del sistema DNS y cada arista una relación real: el stub pregunta al recursivo, el recursivo consulta a la caché y, si no sabe, a la raíz; la raíz delega al TLD, el TLD delega al autoritativo, que sirve la zona, que contiene registros, que se guardan por TTL en caché. También hay aristas de seguridad: el recursivo valida con DNSSEC y puede proteger las consultas con los mecanismos de privacidad, mientras el transporte UDP/TCP transporta tanto al recursivo como al autoritativo.

Los once componentes documentados son: el stub resolver (la pieza local del sistema operativo o navegador que no recorre la jerarquía por sí misma), el resolver recursivo (que busca la respuesta completa y cachea resultados positivos y negativos), los servidores raíz (que no conocen cada host final, solo delegan), el TLD (.com, .org, .es, que devuelve NS de la zona hija y glue records, y puede publicar DS para enlazar DNSSEC), el autoritativo (que responde con el bit AA cuando la respuesta pertenece a su zona), el archivo de zona (con SOA, NS y registros de servicio), los registros de recurso (RR, agrupados en RRsets), la caché y el TTL, el transporte UDP/TCP (con EDNS anunciando capacidades), DNSSEC (firmas y cadena de confianza) y la privacidad (DoT, DoH, DoQ y QNAME minimisation). Al pulsar cada nodo, el panel lateral muestra su categoría (Cliente, Resolución, Jerarquía, Autoridad, Datos, Rendimiento, Protocolo, Seguridad), un resumen, tres detalles clave y enlaces directos a los RFC correspondientes. Es, en la práctica, un mapa mental navegable del protocolo.

Ruta de resolución: una consulta en siete pasos

Esta sección simula el recorrido completo de una consulta, con controles de anterior, siguiente y reinicio, y un contador de progreso. Los siete pasos son:

1. Preguntar por un nombre. La aplicación formula la consulta con QNAME (www.empresa.example.), QTYPE (A) y QCLASS (IN). Aquí se explica la sintaxis del nombre completamente cualificado con el punto raíz final.
2. Mirar caché. El resolver comprueba si conserva una respuesta vigente; se introduce la caché negativa y el riesgo operativo de que cambios recientes no se vean hasta que expire el TTL.
3. Consultar raíz. La raíz no da la IP final; devuelve un referral hacia los servidores del TLD. Se menciona cómo QNAME minimisation evita enviar el nombre completo a cada autoridad.
4. Preguntar al TLD. El TLD devuelve los NS de la zona hija, posiblemente con glue records, y pública el registro DS si hay DNSSEC.
5. Consultar autoritativo. El servidor de la zona responde (respuesta directa, CNAME, NODATA o NXDOMAIN) con el bit AA activado; respuestas grandes, DNSSEC o truncadas pueden requerir TCP.
6. Validar si hay DNSSEC. El resolver validador comprueba la cadena raíz → TLD → DS → DNSKEY → RRSIG; una firma inválida acaba en SERVFAIL y el resultado es secure o bogus; el bit AD indica datos autenticados.
7. Responder y cachear. La respuesta vuelve al cliente, se cachea con su TTL restante decreciente y el siguiente usuario puede recibirla sin repetir el recorrido.

Cada paso muestra el actor implicado, el artefacto técnico que aparece en ese momento (QNAME, TTL, referral, delegación, respuesta AA, RRSIG y DNSKEY, answer section) y una mini-tabla con las piezas concretas del estado. Como diagrama mental del flujo:

App ──> Stub ──> Recursivo ──┬──> Caché (¿vigente?)
                              │ no
                              ├──> Raíz ──> referral
                              ├──> TLD ───> NS + DS
                              └──> Autoritativo ──> AA + RRSIG
                                     │
                          validación DNSSEC (secure/bogus)
                                     │
App <──────── respuesta + caché (TTL) ────────┘

Anatomía de una zona: de SOA a RCODE

La tercera sección presenta un archivo de zona didáctica de empresa.example dividido en piezas clicables: el origen de la zona, el registro SOA (con servidor primario, contacto hostmaster y parámetros de sincronización), los NS, los registros A/AAAA, un CNAME y el bloque DNSSEC (DNSKEY, DS y RRSIG construyendo la cadena de confianza). Complementan la anatomía dos piezas más orientadas a la lectura de respuestas: los flags (QR, RD, RA, AA, TC, AD y CD, que explican cómo se procesó la consulta) y el RCODE (NOERROR, NXDOMAIN, SERVFAIL, REFUSED y otros). Cada pieza tiene un nivel asignado (Básico, Intermedio o Pro), lo que permite autoevaluar por dónde empezar.

La zona didáctica incluye registros reales de uso común que van más allá de lo básico: un TXT de SPF (v=spf1 mx -all), un TXT de DMARC en _dmarc, un registro TLSA en _443._tcp (DANE, con digest de certificado), un DNSKEY, y dos CNAME encadenados (blog → www → empresa). Esta variedad es lo que hace útil el laboratorio de la siguiente sección: hay material suficiente para provocar respuestas de todos los tipos.

Laboratorio de consulta: NOERROR, NODATA, NXDOMAIN, SERVFAIL y bucles

Aquí está, para mi gusto, el corazón didáctico del curso. El laboratorio permite escribir un nombre, elegir un tipo de registro (A, AAAA, CNAME, MX, NS, TXT, SOA o DNSKEY) y pulsar Resolver. La resolución ocurre en local contra la zona didáctica, sin red, y el informe resultante se estructura igual que una respuesta DNS real: tarjeta de RCODE, sección Answer, sección Authority y sección Additional (con los glue records A de los NS y MX resueltos).

La lógica de resolución implementada distingue con precisión los casos que en la práctica real más confunden:

• NOERROR con datos: la zona contiene un RRset compatible; si algún registro está marcado como firmado, la respuesta se destaca visualmente como datos DNSSEC.
• NODATA (NOERROR sin datos): el nombre existe pero no tiene registros del tipo pedido (por ejemplo, pedir MX de www), con el SOA en la sección Authority, que es exactamente lo que hace un servidor real para que el cliente pueda cachear la negativa.
• NXDOMAIN: el nombre no existe en la zona, y el curso recuerda que el resultado negativo también puede cachearse.
• SERVFAIL por validación DNSSEC: el nombre especial bogus.empresa.example simula datos firmados que no validan, reproduciendo el síntoma clásico: el dominio funciona con un resolver no validador y falla con uno validador.
• SERVFAIL por bucle de CNAME: loop.empresa.example y loop2.empresa.example se apuntan mutuamente; el laboratorio detecta el ciclo y lo explica.
• Seguimiento de cadena CNAME: resolver blog.empresa.example devuelve la cadena completa de alias hasta el registro final, con detección de ciclos.
• FORMERR para la consulta vacía.

Hay también un botón de ejemplo DNSSEC que carga una consulta firmada. Comparar lo que devuelve secure.empresa.example frente a bogus.empresa.example es la forma más rápida de interiorizar qué significa un validador estricto.

Fallos y riesgos frecuentes: una checklist con pesos

La sección de riesgos es una checklist interactiva de ocho señales observables en una incidencia DNS, cada una con un peso: NXDOMAIN inesperado (2), SERVFAIL en resolvers validadores (4), delegación lame (4), TTL no preparado para cambios (2), CNAME largo o en bucle (3), resolver abierto a Internet (4), transferencia AXFR expuesta (3) y consultas sensibles sin protección de privacidad (2). Al marcar señales, el panel suma el score y clasifica la prioridad en baja (menos de 5), media (5-9) o alta (10 o más), con una recomendación operativa distinta por nivel: en prioridad alta, comprobar autoritativos, DNSSEC, delegación y exposición antes de tocar registros; en prioridad media, comparar resolvers, revisar TTL y consultar autoritativos directamente; en prioridad baja, empezar por nombre, tipo, TTL y caché.

Esta sección es la más orientada a ciberseguridad y la que conecta con la idea del DNS como superficie de ataque: un resolver abierto es materia prima para amplificación DDoS, y un AXFR sin restringir filtra el inventario completo de una zona interna. El curso no explota nada; enseña a reconocer la exposición, que es el paso previo a defenderla o a auditarla.

Quiz autocorregido

El quiz consta de ocho preguntas de opción múltiple que cubren el temario completo: quién recorre la jerarquía (el recursivo, no el stub), qué significa el TTL, qué indica NXDOMAIN, qué registro devuelve IPv6 (AAAA), qué aporta DNSSEC (autenticidad e integridad, no cifrado), qué RFC define DoH (8484), qué pasa con una respuesta UDP truncada con TC (reintento por TCP) y qué es una delegación. La mecánica es una pregunta por pantalla, con puntuación acumulada visible, botones que quedan deshabilitados al responder, marcado visual de la opción correcta y de la incorrecta elegida, y una explicación textual inmediata (el reason) antes de pasar a la siguiente. Al terminar muestra el resultado sobre ocho, el porcentaje y un veredicto: con 80% o más, «Buen dominio de DNS»; por debajo, «Buen repaso, toca reforzar». Hay botón para repetir el quiz completo.

Guía de repaso, referencias y glosario

El cierre del curso es una guía de repaso con seis tarjetas de puntos clave: pensar en jerarquía, el tipo de registro importa, la caché no es un error (sino una decisión de TTL), DNSSEC no cifra (valida datos; DoT, DoH y DoQ protegen el transporte), depurar por capas (resolver local → comparar con otro recursivo → consultar autoritativos directamente) y mirar el RCODE antes de improvisar. Le sigue un catálogo de referencias oficiales filtrable por categoría (Base, Caché, Transporte, Seguridad, Privacidad, Registros, Operación) y con buscador de texto: desde los RFC 1034/1035 fundacionales y el RFC 9499 de terminología, pasando por EDNS (6891), DNS sobre TCP (7766), caché negativa (2308), la tríada DNSSEC (4033/4034/4035), DNS Cookies (7873), DoT/DoH/DoQ (7858/8484/9250), QNAME minimisation (9156), SVCB/HTTPS (9460) y AXFR (5936). El glosario final, en formato desplegable, define FQDN, RRset, TTL, NXDOMAIN, delegación y validación DNSSEC.

La mecánica interactiva: cómo está construido

Merece la pena mirar bajo el capó porque el proyecto en sí es una lección de ingeniería frugal. El repositorio contiene exactamente cuatro archivos relevantes: index.html (unas 300 líneas con toda la estructura semántica, con roles ARIA, enlaces de saltar al contenido y regiones aria-live para los paneles que se actualizan), styles.css (24 KB con tema claro y oscuro), script.js (47 KB con toda la lógica y los datos) y una imagen. No hay framework, no hay npm install, no hay build, no hay backend ni API externa: se abre el index.html directamente en el navegador y funciona.

Toda la parte didáctica (los once componentes del mapa, los siete pasos de la ruta, las piezas de la zona, los veinte registros de la zona didáctica, las ocho señales de riesgo, las tarjetas de repaso, las quince referencias y las ocho preguntas del quiz) vive en el propio JavaScript como arrays y objetos de datos, separados de las funciones de renderizado. Eso hace el código legible y, sobre todo, auditable: puedes verificar que cada afirmación del curso corresponde a un dato real en el fuente.

La única dependencia externa es Cytoscape.js 3.34.1 cargado desde jsDelivr para el grafo del mapa, con versión fijada. Y aquí hay un detalle de robustez que aplaudo: si la CDN no carga, el código detecta que window.cytoscape no existe y renderiza un mapa alternativo con botones por componente, de modo que el contenido nunca se pierde. Para uso totalmente offline, el README explica cómo descargar el archivo a una carpeta vendor/ y cambiar la etiqueta. El color del grafo se resuelve dinámicamente desde las variables CSS del tema, de modo que respeta el modo claro u oscuro activo.

Otras decisiones técnicas visibles en el código: todo el contenido dinámico pasa por una función escapeHtml antes de inyectarse (buena higiene incluso siendo datos propios), el tema elegido se persiste en localStorage bajo la clave basicos-dns-theme, las secciones aparecen con animación de revelado mediante IntersectionObserver (con fallback si el navegador no lo soporta), y el laboratorio de consultas implementa una lógica de resolución real (normalización de nombres, filtrado de RRsets, seguimiento recursivo de CNAME con un Set de nombres vistos para detectar bucles, construcción de secciones Answer/Authority/Additional y cálculo de glue), que es una versión honesta y simplificada de lo que hace un resolver de verdad.

Por qué importa: el DNS como superficie de ataque olvidada

Aquí conecto con la razón por la que este curso me parece más pertinente que nunca para el público de IAcademy. La seguridad de las aplicaciones de IA se discute casi siempre en términos de prompts, inyecciones y permisos de agentes. Pero piensa en la cadena real de una herramienta de IA típica: un asistente que llama a una API de modelos, descarga contexto de un vector database y consulta fuentes externas. Cada uno de esos pasos empieza con una resolución DNS. Y esa resolución hereda una serie de supuestos de confianza que casi nadie audita.

El curso enseña exactamente los controles que definen esa confianza:

• Autenticidad e integridad con DNSSEC. Sin validación, un atacante en posición de interceptar puede suplantar respuestas (spoofing) y enviar tu tráfico a un servidor bajo su control. El curso cubre la cadena raíz → DS → DNSKEY → RRSIG y el comportamiento de un validador estricto que devuelve SERVFAIL ante datos bogus, con el caso práctico bogus.empresa.example. Incluso referencia las DNS Cookies del RFC 7873 como mitigación de spoofing en las consultas.
• Exposición de infraestructura. Un AXFR abierto filtra el inventario completo de nombres de una organización: el mapa interno de servicios, hosts y subdominios que un atacante agradecería. Un resolver abierto a Internet es un amplificador de ataques de denegación. Ambos son señales ponderadas en la checklist del curso.
• Privacidad de las consultas. Cada consulta DNS en claro revela a quien la observe (proveedor, intermediarios, servidores autoritativos) a qué servicios te conectas: qué APIs de IA usas, qué herramientas internas resuelves, desde dónde. El curso cubre DoT, DoH, DoQ y QNAME minimisation como capa de protección del transporte y de minimización de datos. Es la misma sensibilidad de privacidad que aplicamos a los logs de una aplicación, aplicada al protocolo que los precede.
• Y la que no se nombra pero se infiere de estos fundamentos: un canal DNS que resuelve hacia afuera puede usarse para exfiltración y túneles (codificar datos en nombres de dominio es la técnica clásica de DNS tunneling). Entender caché, TTL, delegación y qué consultas salen de tu red (el vocabulario completo que enseña este curso) es requisito para detectar ese abuso. El curso no incluye un módulo de tunneling; te da la base conceptual sin la cual ese tema es indescifrable.

La síntesis mental que propone el curso me parece muy acertada: leer el DNS en cuatro capas (caché (rendimiento), autoridad (jerarquía), firma (DNSSEC) y privacidad (transporte cifrado)). Una lectura en capas que sirve igual para diagnosticar una incidencia que para razonar sobre seguridad.

Cómo usar el curso: un plan de estudio de una semana

El curso se completa en una o dos horas de interacción, pero propongo un plan de estudio en el curso repartido en cinco sesiones cortas para que el conocimiento se fije:

1. Día 1: El mapa (20-30 min). Recorre los once componentes del grafo leyendo el detalle de cada uno y abriendo al menos dos RFC enlazados (sugiero el RFC 9499 de terminología y el RFC 1034). Objetivo: poder dibujar el ecosistema de memoria.
2. Día 2: La ruta (20 min). Ejecuta la simulación de resolución paso a paso, sin saltarte ninguno, y en cada paso relaciona el artefacto técnico (referral, delegación, AA, RRSIG) con el nodo correspondiente del mapa del día anterior.
3. Día 3: Zona y laboratorio (40 min). Estudia la anatomía de la zona pieza a pieza y después juega en el laboratorio con una lista concreta de consultas: www.empresa.example tipo A (cadena CNAME), www.empresa.example tipo MX (NODATA), noexiste.empresa.example (NXDOMAIN), bogus.empresa.example (SERVFAIL por validación), loop.empresa.example (bucle), empresa.example tipo SOA, _443._tcp.empresa.example tipo TLSA y el ejemplo DNSSEC del botón. Compara las secciones Answer, Authority y Additional de cada respuesta.
4. Día 4: Riesgos y guía (20 min). Trabaja la checklist de riesgos como si fuera un escenario: marca combinaciones y observa cómo cambia la prioridad y la recomendación. Después lee las seis tarjetas de la guía de repaso y el glosario.
5. Día 5: Quiz y consolidación (20 min). Haz el quiz sin mirar nada. Si no llegas al 80%, repite los pasos flacos y vuelve a intentarlo. Cierra explorando el catálogo de referencias filtrando por Seguridad y Privacidad, que es la ruta de profundización natural.

Si además quieres llevarlo a tu entorno real, el complemento natural es repetir las mismas preguntas del laboratorio con dig contra dominios propios: la traducción es casi uno a uno, porque el informe del laboratorio replica la estructura de secciones de una respuesta DNS auténtica.

Conclusión

Básicos DNS interactivo hace algo poco común: convierte un protocolo de 1983 en un objeto manipulable. El mapa clicable sustituye a diez diagramas estáticos, el simulador convierte la resolución en una narración con actores, el laboratorio reproduce con fidelidad la semántica de NOERROR, NODATA, NXDOMAIN y SERVFAIL, y la checklist de riesgos introduce el razonamiento de triaje operativo. Todo sin una sola dependencia de instalación, en un archivo que puedes abrir offline. Para quien construye o usa herramientas de IA, entender el DNS deja de ser un tema de redactores de red y pasa a ser higiene de base: es la primera decisión de confianza de cada conexión que realizan tus sistemas. Empieza por el mapa, termina en el quiz, y abre los RFC que el propio curso te pone a un clic.

Preguntas frecuentes