¿DNS y dominio son lo mismo?

No. El dominio es el nombre que registras (misitio.com). El DNS es el sistema que publica y resuelve los datos de ese nombre, como la IP del sitio y los servidores de correo.

¿Qué puerto usa el DNS?

El puerto 53. Las consultas normales usan UDP, y se usa TCP cuando la respuesta es grande o UDP no alcanza. DNS sobre TLS usa el puerto 853 y DNS sobre HTTPS usa el 443.

Cambié el DNS y el sitio no se actualizó. ¿Por qué?

Los resolvedores guardan las respuestas en caché durante el TTL. Hasta que venza, parte de los usuarios sigue recibiendo el valor anterior. Bajar el TTL antes de un cambio planificado reduce la espera.

¿Qué diferencia hay entre 1.1.1.1 y 8.8.8.8?

Son resolvedores públicos de empresas distintas (Cloudflare y Google). Ambos responden las mismas consultas, pero varían en velocidad en tu red, política de privacidad y filtros opcionales.

Qué es DNS y para qué sirve

Los equipos se encuentran en la red por direcciones IP, como 203.0.113.10 o 2001:db8::10. Las personas recuerdan nombres. El DNS hace de puente: escribes misitio.com y, en milisegundos, un servidor responde qué IP corresponde a ese nombre.

Casi todo lo que haces en línea empieza con una consulta DNS: abrir un sitio, llamar a una API, conectar un bot al Gateway de Discord, enviar un correo. Cuando el DNS falla, el servicio parece caído aunque el servidor funcione perfectamente.

¿Qué es el DNS?#

El DNS (Domain Name System) es una base de datos distribuida y jerárquica que asocia nombres con datos, sobre todo direcciones IP. Se definió en las RFC 1034 y 1035 y sigue siendo uno de los pilares de internet.

Dos ideas explican el diseño:

Distribuido: ninguna máquina guarda todos los nombres. Cada organización mantiene los datos de su dominio, y el sistema sabe a quién preguntar.
Jerárquico: el nombre api.misitio.com se lee de derecha a izquierda: raíz (un punto final implícito), com, misitio, api. Cada nivel delega el siguiente a otros servidores.

¿Quién participa en una consulta DNS?#

Rol	Qué hace
Cliente (stub resolver)	El sistema operativo o el navegador. Pregunta al resolvedor y guarda la respuesta en caché.
Resolvedor recursivo	Hace el trabajo pesado: consulta a otros servidores hasta hallar la respuesta. Suele ser el de tu proveedor de internet, o uno público como `1.1.1.1` (Cloudflare) o `8.8.8.8` (Google).
Servidor raíz	Sabe qué servidores atienden cada TLD (`.com`, `.org`, `.mx`). Hay 13 servidores raíz con nombre, de `a.root-servers.net` a `m.root-servers.net`, cada uno con dirección IPv4 e IPv6, replicados en miles de instancias por todo el mundo (root-servers.org mantiene el mapa actualizado).
Servidor del TLD	Sabe qué servidores responden por cada dominio dentro del TLD.
Servidor autoritativo	Guarda la zona del dominio y da la respuesta final: los registros DNS.

¿Cómo encuentra el DNS una IP, paso a paso?#

Supón que tu navegador necesita www.misitio.com y no hay nada en caché:

El navegador y el sistema operativo revisan sus cachés locales. Sin respuesta, preguntan al resolvedor recursivo.
El resolvedor pregunta a un servidor raíz. La raíz no conoce la IP, pero indica los servidores de .com.
El resolvedor pregunta al servidor de .com, que indica los servidores autoritativos de misitio.com.
El servidor autoritativo responde con el registro, por ejemplo A 203.0.113.10.
El resolvedor devuelve la respuesta al cliente y la guarda en caché durante el TTL.

Cada paso es una referencia: el servidor señala quién sabe más. En la práctica la caché evita casi todo esto. Las consultas a la raíz son raras, porque los resolvedores ya recuerdan quién atiende .com.

Las consultas viajan por UDP en el puerto 53, con TCP cuando la respuesta no cabe en un paquete (la RFC 7766 exige soporte de TCP).

¿Qué son la caché y el TTL?#

Cada respuesta DNS trae un TTL (time to live): cuántos segundos puede reutilizarse sin una nueva consulta. Un TTL de 3600 significa que el resolvedor puede servir la misma respuesta hasta una hora.

La caché hace el DNS rápido y barato, pero tiene un costo: al cambiar un registro, quien ya tenía la respuesta guardada sigue viendo el valor anterior hasta que venza el TTL. Es el efecto "lo cambié y no se actualizó". Antes de una migración, baja el TTL (por ejemplo a 300) unas horas antes y súbelo de nuevo después.

¿Cómo consultar el DNS con dig?#

dig (Linux y macOS; en Windows, usa nslookup o WSL) muestra lo que responde el DNS, y @ elige el resolvedor. En orden, los cuatro comandos muestran la IP según el resolvedor de Google, solo el valor, los servidores autoritativos y el camino completo (raíz, TLD, autoritativo).

bash

dig @8.8.8.8 misitio.com A +noall +answer

dig +short misitio.com A

dig misitio.com NS +short

dig +trace www.misitio.com

La línea de respuesta tiene este formato (IP de documentación, no un registro real):

text

misitio.com.   3600   IN   A   203.0.113.10

Los campos son nombre, TTL restante, clase, tipo y valor. Si lo repites, el TTL baja: es la caché en acción. Si dig +short no devuelve nada, el nombre no existe o no tiene ese tipo de registro.

¿Es el DNS seguro y privado?#

No por defecto. El DNS clásico viaja sin cifrar, así que la red ve qué nombres consultas, y una respuesta puede falsificarse. Hay dos protecciones distintas:

DNSSEC (RFC 4033 y relacionadas) firma las respuestas de la zona. El resolvedor valida la firma y detecta manipulaciones. Protege la integridad, no oculta la consulta.
DNS sobre TLS (DoT, RFC 7858, puerto 853) y DNS sobre HTTPS (DoH, RFC 8484) cifran el tramo entre el cliente y el resolvedor. Protegen la privacidad frente a quien observa la red, pero el resolvedor sigue viendo tus consultas.

¿Qué no hace el DNS?#

No registra dominios. El registro del nombre se hace en un registrador. El DNS publica los datos después.
No transporta el tráfico. Solo informa la IP. Quien entrega la página es el servidor en esa dirección.
No cambia al instante. La caché y el TTL imponen una espera, que suele llamarse propagación.
No arregla fallas del servidor. Un DNS correcto apuntando a una aplicación caída sigue dando error.

Términos vecinos: zona (conjunto de registros de un dominio), NS (registro que indica quién es autoritativo), registrador (empresa donde compras el dominio), archivo hosts (archivo local que el sistema consulta antes del DNS).

Cómo hacerlo en Square Cloud#

Toda aplicación web en Square Cloud recibe un subdominio *.squareweb.app con HTTPS, en todos los planes, sin que toques el DNS. Para usar tu propio dominio, desde el plan Standard, creas en tu registrador los registros DNS que muestra el panel y sigues el estado de validación en tiempo real. El TLS es automático y se admiten dominios con acentos (Punycode).

El dominio sigue registrado a tu nombre, en tu registrador, y allí controlas los registros. Los pasos están en cómo apuntar un dominio a tu aplicación y cómo usar un dominio personalizado.

Los detalles del recurso están en la página de dominios personalizados.