Funcionamiento de las DNS

El DNS (Domain Name System) es el sistema que traduce los nombres que escribimos en el navegador —como www.ejemplo.com— en las direcciones IP que realmente usan los ordenadores para comunicarse entre sí. Sin él, tendríamos que memorizar números en lugar de nombres para acceder a cualquier sitio web.

Para qué se usa el DNS

  • Resolución de nombres: dado el nombre completo de un host (por ejemplo, www.ejemplo.com), obtener su dirección IP.
  • Resolución inversa: el mecanismo contrario — dada una IP, obtener el nombre asociado a ella.
  • Resolución de servidores de correo: dado un dominio (por ejemplo, gmail.com), obtener el servidor encargado de recibir el correo destinado a ese dominio.

Al ser un sistema muy flexible, también se usa para otras funciones: publicar claves públicas de cifrado, validar el origen de correos electrónicos mediante mecanismos como SPF, o incluso demostrar la propiedad de un dominio ante servicios externos.

Terminología básica

  • Host name: una sola palabra que identifica a un equipo dentro de un dominio (por ejemplo, www o blog).
  • FQDN (Fully Qualified Domain Name): el nombre completo de un host, formado por el hostname seguido de su dominio. Por ejemplo, blog.ejemplo.com.
  • Nombre de dominio: una sucesión de nombres unidos por puntos, como ejemplo.com.
  • TLD (dominio de nivel superior): la parte final de un dominio, la que no depende de ningún otro dominio. En google.com, el TLD es.com; otros ejemplos son.org,.es o.gov.

ICANN tiene autoridad sobre todos los TLD que se usan en internet y delega su gestión en distintas organizaciones (por ejemplo, Verisign gestiona los dominios.com y.net). Cada TLD también ayuda a clasificar el propósito de un dominio:.com nació para uso comercial,.gov está reservado a entidades del gobierno de EE. UU.,.edu a instituciones educativas, y así con cada uno.

Arquitectura del sistema DNS

El DNS funciona principalmente sobre el protocolo UDP, a través del puerto 53 (también usa TCP para respuestas grandes o transferencias de zona). El sistema está organizado en forma de árbol: cada nodo agrupa un conjunto de servidores con autoridad sobre una «zona» de dominios, y un servidor puede delegar en otros la autoridad sobre alguna de sus subzonas.

Por ejemplo, blog.ejemplo.com es un subdominio de ejemplo.com, que a su vez depende del TLD.com. Los servidores con autoridad sobre los TLD se llaman root servers (servidores raíz): son 13 nombres fijos (de a.root-servers.net a m.root-servers.net), aunque en la práctica cada uno se reparte entre cientos de máquinas distribuidas por el mundo mediante anycast, no en un único servidor físico.

Cuando un usuario escribe un dominio como ejemplo.com en el navegador, el resolutor DNS contacta primero con el servidor del TLD correspondiente (.com en este caso), que le indica a qué servidor debe dirigirse para obtener la IP final.

El proceso de resolución de nombres

Cuando una aplicación necesita resolver un nombre, envía la petición al servidor de nombres configurado en el sistema (normalmente, el de tu proveedor de internet). A partir de ahí:

  1. El servidor de nombres consulta a uno de los root servers, cuya dirección ya conoce de antemano.
  2. El root server le indica qué servidor tiene autoridad sobre el TLD correspondiente.
  3. El servidor inicial pregunta a ese nuevo servidor.
  4. El proceso se repite si hay más subzonas delegadas de por medio.
  5. Al llegar al servidor con autoridad final sobre el dominio, este resuelve el nombre.
  6. El servidor inicial devuelve el resultado a la aplicación que hizo la consulta.

En la práctica, casi ninguna consulta recorre esta cadena completa: la mayoría se responde desde caché, en el propio dispositivo, en el router o en el resolutor del proveedor.

Caché y tiempo de propagación

Cada respuesta DNS incluye un TTL (tiempo de vida), que indica durante cuánto tiempo puede reutilizarse esa información sin volver a consultarla. Gracias a esto, la inmensa mayoría de las consultas se resuelven desde caché en lugar de recorrer toda la cadena de servidores.

Esta es también la razón por la que los cambios en el DNS —por ejemplo, al mover un dominio a otro hosting— no se aplican de forma instantánea en todo internet: la propagación puede tardar desde minutos hasta uno o dos días, según el TTL configurado y la caché de cada servidor intermedio.

DNS y correo electrónico

Cuando se envía un correo, el servidor del remitente consulta al DNS el registro MX (mail exchanger) del dominio destino, que indica qué servidor (o servidores) está autorizado a recibir el correo de ese dominio. El DNS devuelve el nombre y la IP de ese servidor, y el emisor se conecta a él por SMTP para entregar el mensaje. Si el receptor no es el destino final, puede reenviarlo a través de otros servidores que actúan como gateways de correo.

Tipos de registro más comunes

  • A: traduce un nombre de host a una dirección IPv4.
  • AAAA: igual que el A, pero para direcciones IPv6.
  • CNAME: define un alias para otro nombre de host; no apunta a una IP, sino a otro nombre.
  • NS: indica qué servidores tienen autoridad sobre un dominio.
  • MX: define el servidor encargado de recibir el correo de un dominio.
  • PTR: el inverso del registro A, traduce una IP a un nombre.
  • TXT: añade información adicional a un dominio, muy usado para claves de verificación, DKIM o SPF.

Privacidad y seguridad: DNSSEC, DoH y DoT

El DNS original no verifica la autenticidad de las respuestas ni las cifra, lo que históricamente ha permitido ataques de suplantación (DNS spoofing/cache poisoning) y ha dejado las consultas visibles para cualquiera que intercepte el tráfico. Dos desarrollos han cambiado esto:

  • DNSSEC: añade firmas criptográficas a las respuestas DNS para que el resolutor pueda verificar que no han sido manipuladas por el camino.
  • DoH y DoT (DNS sobre HTTPS y DNS sobre TLS): cifran la consulta en sí, para que un tercero en la misma red no pueda ver qué dominios estás resolviendo. Navegadores como Chrome y Firefox, y sistemas como Windows y Android, ya lo soportan de forma nativa.

Ninguno de los dos sustituye al otro: DNSSEC garantiza que la respuesta es auténtica, DoH/DoT garantiza que nadie ve la pregunta.

Software de servidores DNS

Durante años, BIND (Berkeley Internet Name Domain) fue prácticamente el único software usado en los servidores de nombres de internet, lo que llegó a considerarse un riesgo: un fallo de seguridad grave en BIND podía afectar a buena parte del DNS mundial. Hoy la situación es distinta: los operadores de los root servers usan deliberadamente software diverso —BIND, NSD, Knot DNS, entre otros— precisamente para evitar depender de un único punto de fallo. Para resolutores locales también son muy habituales alternativas como Unbound o PowerDNS.

DNS en una red local

En redes de cierto tamaño (a partir de unos pocos equipos) tiene sentido montar un servidor DNS propio, algo independiente del DNS de internet aunque puede estar conectado a él. Las razones principales:

  • Agilizar el acceso a internet: al mantener en caché los nombres consultados recientemente, se reduce el tráfico hacia el DNS del proveedor y se acelera la navegación.
  • Simplificar la administración: permite asignar nombres internos a cada equipo de la red (por ejemplo, impresora.mired.local en vez de 192.168.1.20), de forma que si cambia el esquema de IPs no hay que tocar la configuración de cada aplicación.

Limitaciones del DNS

Al basarse originalmente en UDP —un protocolo que no garantiza la entrega—, tanto las consultas como las respuestas pueden perderse, por ejemplo por saturación de tráfico. En servidores o redes mal configurados, esto se nota especialmente ante cualquier anomalía. A esto se suma la lentitud propia de la propagación de cambios, inherente a cómo funciona la caché del sistema. Muchas veces el problema real no está en el diseño del DNS, sino en proveedores con servidores de nombres mal dimensionados o mal mantenidos.

Herramientas para investigar el DNS

En sistemas Linux y macOS, el comando dig permite hacer consultas manuales muy detalladas:

dig ejemplo.com

En Windows, el equivalente más directo es nslookup:

nslookup ejemplo.com

Windows también incorpora PowerShell con Resolve-DnsName, más cómodo de leer que nslookup. Para comprobar cómo ha propagado un cambio de DNS en distintos puntos del mundo, herramientas web como DNS Checker o whatsmydns.net son un buen complemento a estos comandos.