Descubre cómo Paul Mockapetris creó DNS, reemplazando las pesadas listas de hosts por un sistema de nombres escalable. Aprende cómo funciona DNS, por qué importa la caché y conceptos básicos de seguridad.
Cada vez que escribes una dirección web, haces clic en un enlace o envías un correo, confías en una idea simple: las personas deberían poder usar nombres memorables, mientras que las máquinas encuentran la máquina correcta.
DNS resuelve un problema cotidiano: las computadoras se comunican usando direcciones numéricas (direcciones IP) como 203.0.113.42, pero las personas no quieren memorizar cadenas de números. Quieres recordar example.com, no la dirección numérica que ese sitio use hoy.
El Sistema de Nombres de Dominio (DNS) es la “agenda” de Internet que traduce nombres de dominio legibles por humanos a las direcciones IP que las máquinas usan para conectar.
Esa traducción parece pequeña, pero es la diferencia entre una Internet usable y otra que se siente como una guía telefónica escrita totalmente en dígitos.
Este es un recorrido no técnico—no necesitas conocimientos de redes. Veremos:
En el camino conocerás a Paul Mockapetris, el ingeniero que diseñó DNS a principios de los años 80. Su trabajo fue decisivo porque no solo creó un nuevo formato de nombres: diseñó un sistema que podía escalar cuando Internet pasó de ser una pequeña red de investigación a algo usado por miles de millones de personas.
Si alguna vez un sitio “se cayó”, esperaste a que un cambio de dominio “se propagara” o te preguntaste por qué las configuraciones de correo incluyen entradas DNS extrañas, ya conoces DNS desde fuera. El resto de este artículo explica qué ocurre tras bambalinas—con claridad y sin jerga.
Mucho antes de que alguien escribiera una dirección web familiar, las redes tempranas tenían un problema más simple: ¿cómo alcanzas una máquina específica? Las computadoras podían hablar entre sí usando direcciones IP (números como 10.0.0.5), pero las personas preferían nombres de host—etiquetas cortas como MIT-MC o SRI-NIC que eran más fáciles de recordar y compartir.
Para el primer ARPANET, la solución fue un único archivo compartido llamado HOSTS.TXT. Era esencialmente una tabla de búsqueda: una lista de hostnames emparejados con sus direcciones IP.
Cada computadora mantenía una copia local de ese archivo. Si querías conectar a una máquina por nombre, tu sistema comprobaba HOSTS.TXT y encontraba la IP correspondiente.
Esto funcionó al principio porque la red era pequeña, los cambios eran relativamente raros y había un lugar claro para obtener las actualizaciones.
A medida que se unieron más organizaciones, el enfoque empezó a ceder bajo el crecimiento normal:
El problema central era la coordinación. HOSTS.TXT era como una libreta de direcciones compartida para todo el mundo. Si todos dependen del mismo libro, cada corrección requiere una edición global y todos tienen que descargar la versión más reciente rápidamente. Cuando la red alcanzó cierto tamaño, ese modelo de “un archivo para todo” se volvió demasiado lento, demasiado centralizado y demasiado propenso a errores.
DNS no reemplazó la idea de mapear nombres a números; reemplazó la forma frágil en que ese mapeo se mantenía y distribuía.
A principios de los años 80, Internet estaba pasando de ser una pequeña red de investigación a algo más grande, desordenado y compartido. Entraban más máquinas, las organizaciones querían autonomía y la gente necesitaba una forma más fácil de alcanzar servicios que memorizar direcciones numéricas.
Paul Mockapetris, trabajando en ese entorno, es ampliamente reconocido como el diseñador de DNS. Su contribución no fue un producto llamativo: fue una respuesta de ingeniería a una pregunta muy práctica: ¿cómo mantienes los nombres usables cuando la red sigue creciendo?
Un sistema de nombres suena simple hasta que imaginas lo que “simple” significaba entonces: una lista compartida de nombres que todos tenían que descargar y mantener actualizada. Ese enfoque se rompe tan pronto como el cambio se vuelve constante. Cada nuevo host, renombrado o corrección se convierte en trabajo de coordinación para todos.
La idea clave de Mockapetris fue que los nombres no son solo datos; son acuerdos compartidos. Si la red se expande, el sistema para crear y distribuir esos acuerdos debe expandirse también—sin exigir a cada computadora que recupere constantemente una lista maestra.
DNS reemplazó la idea de “un archivo autoritativo” por un diseño distribuido:
Esa es la brillantez silenciosa: DNS no fue diseñado para ser ingenioso; fue diseñado para seguir funcionando bajo restricciones reales—ancho de banda limitado, cambios frecuentes, muchos administradores independientes y una red que no paraba de crecer.
DNS no se inventó como un atajo ingenioso: se diseñó para resolver problemas específicos y muy prácticos que surgieron cuando Internet crecía. El enfoque de Mockapetris fue fijar metas claras primero y luego construir un sistema de nombres capaz de mantenerse durante décadas.
El concepto clave es la delegación: diferentes grupos administran distintas partes del árbol de nombres.
Por ejemplo, una organización gestiona lo que está bajo .com, un registrador te ayuda a reclamar example.com, y luego tú (o tu proveedor DNS) controlas los registros para www.example.com, mail.example.com, etc. Esto divide la responsabilidad de forma clara, de modo que el crecimiento no crea un cuello de botella.
DNS asume que ocurrirán problemas—servidores se caen, redes se particionan, las rutas cambian. Por eso depende de múltiples servidores autoritativos para un dominio y del caché en los resolutores, de modo que una caída temporal no rompa inmediatamente cada consulta.
DNS traduce nombres amigables para las personas en datos técnicos, más famosamente direcciones IP. No es “Internet en sí”—es un servicio de nombres y búsqueda que ayuda a tus dispositivos a encontrar dónde conectar.
DNS hace manejables los nombres organizándolos como un árbol. En lugar de una lista gigante donde cada nombre debe ser único globalmente (y alguien tiene que supervisarlo), DNS divide el nombre en niveles y delega la responsabilidad.
Un nombre DNS se lee de derecha a izquierda:
www.example.com. técnicamente termina con un ..com, .org, .net, códigos de país como .ukexample en example.comwww en www.example.comAsí www.example.com puede desglosarse en:
com (el TLD)example (el dominio registrado bajo .com)www (una etiqueta que el propietario del dominio crea y controla)Esta estructura reduce conflictos porque los nombres solo necesitan ser únicos dentro de su padre. Muchas organizaciones pueden tener un www, porque www.example.com y www.otro-ejemplo.com no colisionan.
También reparte la carga. Los operadores de .com no necesitan gestionar los registros de cada sitio; solo apuntan a quién es responsable de example.com, y luego el propietario de example.com gestiona los detalles.
Una zona es simplemente una porción manejable de ese árbol—datos DNS que alguien se encarga de publicar. Para muchos equipos, “nuestra zona” significa “los registros DNS para example.com y los subdominios que alojamos”, almacenados en su proveedor autoritativo.
Cuando escribes un nombre en un navegador, no le preguntas a “Internet” directamente. Algunos ayudantes especializados reparten el trabajo para que la respuesta se encuentre rápidamente y con fiabilidad.
Tú (tu dispositivo y navegador) empiezas con una pregunta simple: “¿Qué dirección IP coincide con example.com?” Tu dispositivo normalmente no sabe la respuesta todavía y no quiere preguntar a docenas de servidores para averiguarlo.
Un resolutor recursivo hace la búsqueda en tu nombre. Suele ser provisto por tu ISP, la IT de tu empresa/escuela o un resolutor público. El beneficio clave: puede reutilizar respuestas en caché de búsquedas previas, acelerando las cosas para todos los que lo usan.
Servidores DNS autoritativos son la fuente de verdad para un dominio. No “buscan” en Internet; tienen los registros oficiales que indican qué IPs, servidores de correo o tokens de verificación pertenecen a ese dominio.
example.com.Piensa en el resolutor recursivo como un bibliotecario que puede buscar por ti (y recuerda respuestas populares), mientras que un servidor autoritativo es el catálogo oficial del editor: no consulta otros catálogos—simplemente indica qué es cierto para sus libros.
Cuando escribes example.com en tu navegador, en realidad tu navegador no busca un nombre: necesita una dirección IP (un número como 93.184.216.34) para saber dónde conectar. DNS es el sistema de “encuéntrame el número de este nombre”.
Tu navegador primero pregunta al sistema operativo de tu equipo: “¿Ya conocemos la IP de example.com?” El SO comprueba su memoria a corto plazo (caché). Si encuentra una respuesta fresca, la búsqueda termina aquí.
Si el SO no la tiene, reenvía la pregunta a un resolutor DNS—normalmente operado por tu ISP, tu empresa o un proveedor público. Piensa en el resolutor como tu “conserje DNS”: hace el trabajo para que tu dispositivo no tenga que hacerlo.
Si el resolutor no tiene la respuesta en caché, inicia una búsqueda guiada:
.com). El servidor raíz no da la IP final—da referencias, básicamente direcciones: “Pregunta a estos servidores .com a continuación.”.com): el resolutor pregunta a los servidores de .com dónde se gestiona example.com. De nuevo, no es la IP final—más bien direcciones: “Pregunta a este servidor autoritativo por example.com.”A o AAAA) que contiene la dirección IP.El resolutor envía la IP de vuelta a tu SO y luego a tu navegador, que finalmente puede conectar. La mayoría de búsquedas parecen instantáneas porque los resolutores y los dispositivos cachean respuestas durante un periodo definido por el propietario del dominio (TTL).
Un flujo fácil de recordar es: Navegador → caché del SO → caché del resolutor → Root (referencia) → TLD (referencia) → Autorizado (respuesta) → de regreso al Navegador.
DNS sería terriblemente lento si cada visita a un sitio iniciara una búsqueda desde cero y preguntara a varios servidores por la misma respuesta. En su lugar, DNS se apoya en la caché—una “memoria” temporal de búsquedas recientes—para que la mayoría de usuarios obtengan respuestas en milisegundos.
Cuando tu dispositivo pregunta a un resolutor DNS por example.com, ese resolutor puede necesitar trabajar la primera vez. Después de aprender la respuesta, la guarda en caché. La siguiente persona que pida el mismo nombre puede obtener la respuesta de inmediato.
La caché existe por dos razones:
Cada registro DNS se sirve con un valor TTL (Time To Live). Piensa en TTL como una instrucción que dice: mantén esta respuesta durante X segundos, luego deséchala y pregunta de nuevo.
Si un registro tiene TTL de 300, los resolutores pueden reutilizarlo hasta 5 minutos antes de volver a comprobar.
TTL es un acto de equilibrio:
Si vas a mover un sitio a un nuevo host, cambiar un CDN o hacer un corte de correo (cambiar registros MX), el TTL determina qué tan rápido los usuarios dejan de ir al lugar antiguo.
Una práctica común es bajar los TTLs con antelación de un cambio planificado, hacer el cambio y luego volver a subir los TTLs cuando todo esté estable. Por eso DNS puede ser rápido en el día a día—y a la vez parecer “terco” justo después de una actualización.
Cuando inicias sesión en un panel DNS, normalmente editarás un puñado de tipos de registro. Cada registro es una pequeña instrucción que dice a la red dónde enviar a la gente (web), dónde entregar correo o cómo verificar la propiedad.
| Registro | Qué hace | Ejemplo sencillo |
|---|---|---|
| A | Apunta un nombre a una dirección IPv4 | example.com → 203.0.113.10 (tu servidor web) |
| AAAA | Apunta un nombre a una dirección IPv6 | example.com → 2001:db8::10 (misma idea, direccionamiento más reciente) |
| CNAME | Hace que un nombre sea un alias de otro nombre | www.example.com → example.com (para que ambos vayan al mismo lugar) |
| MX | Indica dónde debe ir el correo del dominio | example.com → mail.provider.com (prioridad 10) |
| TXT | Almacena “notas” que las máquinas pueden leer (verificación, políticas de correo) | example.com tiene un SPF como v=spf1 include:mailgun.org ~all |
| NS | Indica qué servidores autoritativos alojan el DNS de un dominio/zona | example.com → ns1.dns-host.com |
| SOA | El “encabezado” de la zona: NS primario, contacto admin y valores de temporización | El SOA de example.com incluye ns1.dns-host.com y tiempos de retry/expire |
Algunos fallos comunes son:
example.com). Muchos proveedores DNS no lo permiten porque el nombre raíz también debe llevar registros como NS y SOA. Si necesitas “raíz a un hostname”, usa un registro A/AAAA o una función “ALIAS/ANAME” si tu proveedor la soporta.www). Elige un enfoque.mail.provider.com puede romper el correo; puntos faltantes/extra y copiar el campo de host equivocado (p. ej. @ vs www) son causas comunes de fallos.Si compartes orientación DNS con un equipo, una pequeña tabla como la anterior en tus docs (o una página de runbook) acelera las revisiones y la resolución de problemas.
DNS funciona porque la responsabilidad se reparte entre muchas organizaciones. Esa división es también la razón por la que puedes cambiar de proveedor, modificar ajustes y mantener tu nombre online sin pedir permiso a “Internet”.
Registrar un dominio es comprar el derecho a usar un nombre (como example.com) por un periodo. Piénsalo como reservar una etiqueta para que nadie más la reclame.
Alojar DNS es ejecutar las configuraciones que dicen al mundo a dónde debe apuntar ese nombre—tu web, proveedor de correo, registros de verificación, etc. Puedes registrar un dominio con una empresa y alojar el DNS con otra.
.com, .org o .uk. Mantiene la base de datos oficial de quién posee cada nombre bajo ese TLD y qué servidores de nombres son responsables.Los servidores raíz están en la cima de DNS. No conocen la IP de tu sitio y no almacenan los registros de tu dominio. Su trabajo es más limitado: decirles a los resolutores dónde encontrar los servidores autoritativos de cada TLD (como dónde se maneja .com).
Cuando configuras los “name servers” para tu dominio en el registrador, estás creando una delegación. El registry de .com (a través de sus servidores autoritativos) entonces apuntará las consultas de example.com a los name servers que elegiste.
A partir de ese momento, esos name servers controlan las respuestas que el resto de Internet recibe—hasta que cambies la delegación de nuevo.
DNS se basa en la confianza: cuando escribes un nombre, asumes que la respuesta apunta al servicio real. La mayoría de las veces es así—pero DNS también es un objetivo habitual para ataques, porque un pequeño cambio en “a dónde apunta este nombre” puede redirigir a mucha gente.
Un problema clásico es el spoofing o envenenamiento de caché. Si un atacante engaña a un resolutor para que almacene una respuesta falsa, los usuarios pueden ser enviados a la IP equivocada aunque escribieran el dominio correcto. El resultado puede ser páginas de phishing, descargas de malware o tráfico interceptado.
Otro problema es el secuestro de dominio a nivel de registrador. Si alguien accede a tu cuenta del registrador, puede cambiar name servers o registros DNS y “tomar” tu dominio sin tocar tu hosting.
Luego está el peligro cotidiano: mala configuración. Un CNAME erróneo, un TXT antiguo o un MX incorrecto pueden romper flujos de inicio de sesión, la entrega de correo o comprobaciones de verificación. Estos fallos a menudo parecen “Internet caído”, pero la causa raíz es una pequeña edición DNS.
DNSSEC añade firmas criptográficas a los datos DNS. En términos sencillos: la respuesta DNS puede validarse para confirmar que no ha sido alterada en tránsito y que realmente proviene del servidor autoritativo del dominio. DNSSEC no cifra las consultas ni oculta lo que buscas, pero puede impedir que muchas respuestas forjadas sean aceptadas.
Las consultas DNS tradicionales son fáciles de observar para las redes. DNS-over-HTTPS (DoH) y DNS-over-TLS (DoT) cifran la conexión entre tu dispositivo y un resolutor, reduciendo el escrutinio y cierta manipulación en el trayecto. No hacen a DNS “anónimo”, pero cambian quién puede ver y manipular las consultas.
Usa MFA en tu registrador, habilita bloqueos de dominio/transferencia y restringe quién puede editar el DNS. Trata los cambios DNS como despliegues de producción: exige revisión, lleva un registro de cambios y configura monitorización/alertas para cambios en registros o en name servers para que te enteres rápido de sorpresas.
DNS puede sentirse como “configúralo y olvídalo”, hasta que un pequeño cambio deja tu web o correo fuera de servicio. La buena noticia: unos hábitos sencillos hacen que la gestión de DNS sea predecible, incluso para equipos pequeños.
Empieza con un proceso ligero y repetible:
La mayoría de problemas DNS no son complicados—solo difíciles de notar con rapidez.
Si despliegas apps con frecuencia, DNS entra en tu proceso de lanzamientos. Por ejemplo, equipos que publican apps desde plataformas como Koder.ai (donde puedes construir y desplegar apps vía chat y luego asociar dominios personalizados) siguen dependiendo de los mismos fundamentos: objetivos A/AAAA/CNAME correctos, TTLs sensatos para cortes y un camino claro de rollback si algo apunta al lugar equivocado.
Si envías correo desde tu dominio, DNS afecta directamente si los mensajes llegan a la bandeja de entrada.
Los nombres amigables hicieron que Internet escalara más allá de una pequeña comunidad de investigación. Trata DNS como infraestructura compartida—un poco de cuidado inicial mantiene tu sitio accesible y tu correo de confianza a medida que creces.
DNS (Sistema de Nombres de Dominio) traduce nombres amigables para las personas como example.com en direcciones IP como 93.184.216.34 para que tu dispositivo sepa a dónde conectarse.
Sin DNS, tendrías que recordar direcciones numéricas para cada sitio y servicio que usas.
Las primeras redes usaban un único archivo compartido (HOSTS.TXT) que mapeaba nombres a direcciones IP.
A medida que la red creció, resultó inmanejable: actualizaciones constantes, nombres en conflicto y fallos por copias desactualizadas. DNS reemplazó el enfoque de “un archivo global” por un sistema distribuido.
Paul Mockapetris diseñó DNS a principios de los años 80 para resolver el problema de escala de los nombres en una red en rápido crecimiento.
La idea clave fue la delegación: dividir la responsabilidad entre muchas organizaciones para que no hubiera una lista maestra (o un administrador) que se convirtiera en cuello de botella.
Los nombres DNS son jerárquicos y se leen de derecha a izquierda:
www.example.com..comexample.comwww.example.comEsta jerarquía facilita la delegación y la gestión a escala global.
Un resolutor recursivo busca respuestas por ti y las almacena en caché (a menudo lo ofrece tu ISP, la IT de tu empresa o un proveedor público).
Un servidor DNS autoritativo es la fuente de verdad para los registros de un dominio; no busca en otros sitios, simplemente responde por su zona.
Una búsqueda típica sigue estos pasos:
.com) → servidores autoritativos del dominio.TTL (Time To Live) indica cuánto tiempo pueden cachear los resolutores una respuesta DNS antes de verificar de nuevo.
La “propagación” es principalmente que las distintas cachés expiren en momentos distintos.
Los registros más comunes que gestionarás son:
Un registrar es donde registras/renuevas el dominio (tu derecho a usar example.com).
Un proveedor de DNS/host ejecuta los servidores autoritativos y almacena tus registros DNS.
Puedes registrar con una empresa y hospedar DNS en otra cambiando los NS del dominio en el registrar.
Los fallos comunes en DNS incluyen:
Medidas prácticas:
AAAAAAAAAACNAME: convierte un nombre en alias de otro (habitual para www).MX: dónde se debe entregar el correo del dominio.TXT: verificación y autenticación de correo (SPF, DKIM, DMARC).NS: qué servidores son autoritativos para el dominio.Una regla práctica: no pongas CNAME y A en el mismo nombre.