DNS, DHCP y protocolos básicos: qué son, cómo funcionan y por qué importan

Es la decimoquinta y última lección de la Tanda 12 de /aprende. Cada vez que abres una página web, tu dispositivo ejecuta una serie de pasos invisibles: primero necesita una dirección IP para existir en la red, luego tiene que averiguar la IP del servidor que quieres visitar, después debe descubrir la dirección física del router que sacará tu mensaje de la red local, y finalmente empaqueta los datos y los envía. Todo eso ocurre en milisegundos gracias a protocolos como DHCP, DNS, ARP, ICMP, TCP y UDP.

Entender estos protocolos es fundamental si quieres dedicarte a la ciberseguridad. No puedes analizar tráfico en Wireshark, interpretar los resultados de un escaneo con Nmap ni entender cómo funciona un ataque de red si no sabes qué hace cada protocolo y en qué momento interviene. Esta lección te lo explica desde cero, con analogías y ejemplos prácticos.

Vamos a recorrer cada protocolo en el orden en que tu dispositivo los usa cuando se conecta a una red y visita un sitio web. Al final serás capaz de consultar registros DNS, entender cómo se asignan las direcciones y distinguir cuándo se usa TCP y cuándo UDP.

Analiza tráfico y ejecuta consultas DNS solo en redes propias o entornos autorizados, como los laboratorios de whoami-labs. Interceptar comunicaciones ajenas o manipular DNS de terceros es un delito.

Qué es DNS#

Imagina que quieres llamar a un restaurante pero solo recuerdas su nombre, no su número de teléfono. Abres la guía telefónica, buscas el nombre y encuentras el número. DNS hace exactamente eso con internet: traduce nombres legibles como whoami-labs.com a direcciones IP como 104.21.45.12, que es lo que los ordenadores necesitan para comunicarse.

DNS significa Domain Name System, o sistema de nombres de dominio. Sin él, tendrías que memorizar secuencias de números para cada sitio web que quisieras visitar. Es uno de los servicios más críticos de internet: si DNS falla, todo parece caído aunque los servidores estén funcionando perfectamente.

Cuando escribes una dirección en el navegador, tu sistema operativo primero mira su propia caché local (por si ya visitaste ese sitio antes). Si no la tiene, pregunta al servidor DNS que tu red le asignó, normalmente llamado resolver recursivo. Ese servidor hace todo el trabajo pesado: si tampoco tiene la respuesta en caché, va preguntando a una cadena de servidores autoritativos hasta encontrar la IP correcta.

Por qué es importante#

DNS es la primera pieza que toca cualquier conexión a internet. Si un atacante controla las respuestas DNS que recibes, puede redirigirte a un sitio falso sin que lo notes: escribes la dirección correcta en el navegador, pero llegas a una copia maliciosa. Ese ataque se llama DNS spoofing o envenenamiento de caché DNS.

Desde el punto de vista defensivo, los registros DNS de un dominio revelan información valiosa durante la fase de reconocimiento. Puedes descubrir servidores de correo, subdominios ocultos, direcciones IP y configuraciones de seguridad como SPF y DKIM, todo sin enviar un solo paquete al objetivo. Por eso las herramientas de reconocimiento empiezan casi siempre con consultas DNS.

Además, DHCP, ARP e ICMP son los protocolos que permiten que tu dispositivo se una a una red, se comunique con el router y compruebe si otros equipos están activos. Sin entenderlos, cada resultado de Nmap o cada captura de Wireshark será un misterio.

Conceptos clave#

Registros DNS#

Un dominio puede tener muchos tipos de registros. Cada uno guarda información diferente:

Resolución recursiva vs iterativa#

Hay dos formas de resolver un nombre DNS. En la resolución recursiva, tu dispositivo le pide al resolver que haga todo el trabajo: el resolver consulta a los servidores raíz, luego a los servidores del TLD (.com, .org) y finalmente al servidor autoritativo del dominio, y te devuelve la respuesta completa. Es como pedirle a un amigo que busque un número de teléfono por ti.

En la resolución iterativa, el resolver pregunta a cada servidor, pero cada uno solo le dice a quién preguntar después en lugar de dar la respuesta final. El resolver va siguiendo las pistas paso a paso. Normalmente tu dispositivo hace una consulta recursiva al resolver local, y este hace consultas iterativas hacia arriba.

DHCP: cómo tu dispositivo obtiene una IP#

Cuando conectas tu portátil a una red WiFi, no configuras la IP a mano. El protocolo DHCP (Dynamic Host Configuration Protocol) se encarga automáticamente. El proceso tiene cuatro pasos que se recuerdan con la sigla DORA:

• Discover: tu dispositivo grita a toda la red «necesito una IP, alguien que me ayude»
• Offer: el servidor DHCP responde «te ofrezco la IP 192.168.1.50»
• Request: tu dispositivo contesta «acepto esa IP, dámela a mí»
• Acknowledge: el servidor confirma «hecho, la IP es tuya por 24 horas»

Junto con la IP, DHCP te entrega la máscara de subred, la puerta de enlace (el router) y los servidores DNS que usarás. Todo configurado en milisegundos.

ARP: de IP a dirección física#

Una vez que tienes tu IP y conoces la IP del router (por ejemplo 192.168.1.1), necesitas saber su dirección MAC para enviarle tramas por la red local. Ahí entra ARP (Address Resolution Protocol). Tu dispositivo pregunta a toda la red local: «¿quién tiene la IP 192.168.1.1?», y el router responde con su dirección MAC.

El problema es que ARP no verifica quién responde. Si un atacante en la misma red responde antes que el router, tu dispositivo le enviará todo el tráfico al atacante. Eso es un ataque de ARP spoofing, y es una de las razones por las que las redes locales sin protección son peligrosas.

ICMP: ping y traceroute#

ICMP (Internet Control Message Protocol) no transporta datos de usuario. Es un protocolo de control que sirve para diagnosticar la red. Los dos usos más comunes son el ping, que envía un mensaje «echo request» y espera un «echo reply» para comprobar si un equipo está activo y medir la latencia, y el traceroute, que descubre la ruta que siguen los paquetes hasta un destino mostrando cada router intermedio.

TCP vs UDP#

Piensa en TCP como enviar una carta certificada: confirmas la entrega, te aseguras de que llegó y puedes reclamar si se pierde. UDP es como echar una postal en el buzón: es más rápido porque no esperas confirmación, pero no sabes si llegó.

TCP establece una conexión antes de enviar datos (el saludo de tres pasos: SYN, SYN-ACK, ACK), garantiza que todo llega en orden y reenvía lo que se pierde. Es más lento pero fiable. Lo usan HTTP, SSH, FTP y SMTP.

UDP no establece conexión, no confirma la entrega y no reordena paquetes. Es más rápido y ligero. Lo usan DNS (consultas cortas), DHCP, streaming de vídeo, VoIP y juegos online, donde la velocidad importa más que perder algún paquete.

Cómo funciona#

Vamos a seguir paso a paso lo que ocurre cuando conectas tu portátil a la WiFi y abres whoami-labs.com:

• Tu portátil no tiene IP. Envía un mensaje DHCP Discover por broadcast (a toda la red)
• El router (servidor DHCP) responde con un Offer que incluye una IP, la puerta de enlace, la máscara y los servidores DNS
• Tu portátil acepta con un Request y el router confirma con un Acknowledge
• Ahora escribes whoami-labs.com en el navegador. Tu sistema operativo envía una consulta DNS al servidor que DHCP le asignó
• El servidor DNS resuelve el nombre (consultando la cadena de servidores si no lo tiene en caché) y devuelve la IP 104.21.45.12
• Tu portátil necesita enviar el paquete al router para que salga a internet. Usa ARP para obtener la MAC del router
• Con la MAC del router, envía un paquete TCP SYN al puerto 443 de la IP del servidor web
• El servidor responde SYN-ACK, tu portátil envía ACK, y la conexión TLS comienza
• Los datos HTTP viajan cifrados dentro de esa conexión TCP

Todo eso pasa en menos de un segundo. Cada protocolo tiene su papel y funciona en una capa distinta del modelo de red.

Uso práctico paso a paso#

Paso 1: consultar registros DNS con dig#

La herramienta dig es la más completa para consultas DNS en Linux y macOS. Viene preinstalada en la mayoría de distribuciones.

# Consultar el registro A (IPv4)
dig whoami-labs.com A

# Consultar registros MX (servidores de correo)
dig whoami-labs.com MX

# Consultar registros TXT (SPF, DKIM, verificaciones)
dig whoami-labs.com TXT

# Consultar registros NS (servidores de nombres)
dig whoami-labs.com NS

# Consulta corta (solo la respuesta)
dig +short whoami-labs.com A

La salida de dig incluye varias secciones. La más importante es ANSWER SECTION, que contiene la respuesta real. También muestra el tiempo de consulta y el servidor DNS que respondió.

Paso 2: consultar DNS con nslookup#

Si estás en Windows o prefieres una herramienta más sencilla, nslookup funciona en todos los sistemas operativos:

# Consulta básica
nslookup whoami-labs.com

# Consultar un tipo de registro específico
nslookup -type=MX whoami-labs.com

# Usar un servidor DNS específico (Google)
nslookup whoami-labs.com 8.8.8.8

Paso 3: comprobar conectividad con ping#

El comando ping usa ICMP para verificar si un equipo está accesible y medir la latencia (el tiempo que tarda en responder):

# Enviar 4 pings
ping -c 4 whoami-labs.com

# Ejemplo de salida
# 64 bytes from 104.21.45.12: icmp_seq=1 ttl=57 time=12.3 ms
# 64 bytes from 104.21.45.12: icmp_seq=2 ttl=57 time=11.8 ms

El valor ttl (time to live) indica cuántos saltos (routers) puede atravesar el paquete antes de descartarse. El valor time es la latencia en milisegundos.

Paso 4: trazar la ruta con traceroute#

El comando traceroute (o tracert en Windows) muestra cada router por el que pasa tu paquete hasta llegar al destino:

# En Linux/macOS
traceroute whoami-labs.com

# En Windows
tracert whoami-labs.com

Cada línea de la salida es un salto. Si un salto muestra asteriscos, significa que ese router no respondió (tiene ICMP bloqueado). No necesariamente indica un problema.

Paso 5: ver la tabla ARP#

Puedes consultar la tabla ARP de tu equipo para ver qué direcciones MAC ha aprendido:

# En Linux
arp -a

# Ejemplo de salida
# ? (192.168.1.1) at 08:00:27:4e:66:a1 [ether] on eth0
# ? (192.168.1.50) at 0a:1b:2c:3d:4e:5f [ether] on eth0

Paso 6: ver la configuración DHCP recibida#

Para comprobar qué IP y configuración te asignó DHCP:

# En Linux (ver la IP y puerta de enlace)
ip addr show
ip route show

# En Windows
ipconfig /all

El comando ipconfig /all en Windows muestra la IP asignada, la máscara, la puerta de enlace, los servidores DNS y si la configuración viene de DHCP o es manual.

Qué puedes hacer con esto#

Buenas prácticas#

• Usa servidores DNS de confianza. Los DNS del ISP pueden ser lentos o no respetar tu privacidad. Alternativas conocidas son Cloudflare (1.1.1.1), Google (8.8.8.8) y Quad9 (9.9.9.9, que además bloquea dominios maliciosos)
• Activa DNS sobre HTTPS o DNS sobre TLS en tu sistema operativo o navegador. Sin cifrado, cualquiera en tu red puede ver qué dominios consultas
• No desactives ICMP por completo en tus servidores. Bloquear ping dificulta el diagnóstico legítimo y no aporta seguridad real contra atacantes serios
• Configura DHCP Snooping en switches gestionados para evitar que un atacante monte un servidor DHCP falso en la red
• Habilita Dynamic ARP Inspection (DAI) en entornos corporativos para prevenir ataques de ARP spoofing
• Cuando hagas reconocimiento DNS, empieza siempre con registros públicos. No necesitas enviar paquetes al objetivo para obtener información DNS

Errores comunes de principiante#

• Confundir DNS con el hosting. DNS solo traduce nombres a direcciones IP. No almacena páginas web ni correos. Si cambias los registros DNS, solo cambias a dónde apuntan las consultas, no muevas ningún archivo
• Pensar que si ping no responde, el servidor está caído. Muchos servidores y firewalls bloquean ICMP deliberadamente. Que ping no funcione no significa que el servicio HTTP no esté disponible
• Creer que ARP funciona entre redes. ARP solo resuelve direcciones dentro de la misma red local. Para llegar a otra red, envías el paquete al router (necesitas la MAC del router, no la del destino final)
• Olvidar que DNS cachea las respuestas. Si cambias un registro DNS, los clientes pueden tardar horas o días en ver el cambio por culpa de la caché. El TTL (time to live) del registro controla cuánto tiempo se guarda
• No distinguir TCP de UDP al escanear. Nmap por defecto escanea solo puertos TCP. Si no escaneas UDP también, te pierdes servicios como DNS (53), SNMP (161) y DHCP (67-68)
• Confundir un puerto con un protocolo. El puerto 80 se usa habitualmente para HTTP, pero un administrador puede poner cualquier servicio en cualquier puerto. Siempre verifica con detección de servicios

Preguntas frecuentes#

Qué pasa si el servidor DNS no responde#

Tu dispositivo no puede traducir nombres a direcciones IP. Parecerá que internet no funciona, aunque la conexión de red esté bien. Puedes comprobarlo haciendo ping directamente a una IP (por ejemplo ping 1.1.1.1): si responde, el problema es DNS, no la conexión.

Puedo usar cualquier servidor DNS#

Sí. Puedes configurar el servidor DNS que quieras en tu sistema operativo o en tu router. Los más populares son Cloudflare 1.1.1.1 (rápido y con opciones de privacidad), Google 8.8.8.8 y Quad9 9.9.9.9 (filtra dominios maliciosos). No necesitas usar el DNS de tu proveedor de internet.

Qué diferencia hay entre ping y traceroute#

Ambos usan ICMP, pero con distinto propósito. Ping comprueba si un equipo está activo y mide la latencia (cuánto tarda en responder). Traceroute muestra la ruta completa, revelando cada router intermedio entre tu equipo y el destino. Traceroute es especialmente útil para diagnosticar dónde se pierde la conexión.

Es peligroso que alguien vea mis consultas DNS#

Sí, porque revelan todos los sitios que visitas. Sin cifrado (DNS sobre HTTPS o TLS), cualquier persona en tu misma red (o tu proveedor de internet) puede ver cada dominio que consultas. Por eso es recomendable activar DNS cifrado.

Qué es un puerto well-known#

Los puertos del 0 al 1023 se llaman well-known (bien conocidos) porque están asignados a servicios estándar. Los más importantes: 22 para SSH, 25 para SMTP, 53 para DNS, 80 para HTTP, 443 para HTTPS, 445 para SMB y 3389 para RDP. Conocerlos te permite identificar servicios rápidamente al ver resultados de un escaneo.

Por qué DHCP usa UDP y no TCP#

Porque cuando un dispositivo busca una IP, todavía no tiene dirección de red ni conexión establecida. No puede hacer el saludo de tres pasos que TCP requiere. UDP permite enviar mensajes sin conexión previa, lo que encaja perfectamente con el proceso DORA de DHCP.

Resumen#

• DNS traduce nombres de dominio a direcciones IP. Sin DNS, tendrías que memorizar números para cada sitio web
• Los registros DNS (A, AAAA, CNAME, MX, TXT, NS) contienen información distinta y son una fuente clave de reconocimiento
• DHCP asigna automáticamente la IP, la puerta de enlace y los servidores DNS a cada dispositivo que se conecta a la red (proceso DORA)
• ARP resuelve direcciones IP a direcciones MAC dentro de la red local, y su falta de verificación lo hace vulnerable a spoofing
• ICMP permite diagnósticos de red con ping (comprobar actividad) y traceroute (trazar rutas)
• TCP es fiable y orientado a conexión (HTTP, SSH); UDP es rápido y sin conexión (DNS, DHCP, streaming)
• Herramientas como dig, nslookup, ping, traceroute y arp son tu punto de partida para explorar y diagnosticar cualquier red

Fuentes y lecturas recomendadas#

• RFC 1035 - Domain Names: Implementation and Specification
• RFC 2131 - Dynamic Host Configuration Protocol
• RFC 826 - Ethernet Address Resolution Protocol
• Cloudflare Learning - What is DNS?
• IANA - Service Name and Transport Protocol Port Number Registry
• OWASP - DNS Rebinding