Qué es DNS: guía para propietarios de servidores

Qué es DNS y por qué tu dominio todavía no llega a tu VPS

DNS (sistema de nombres de dominio) convierte un nombre como example.com en una dirección IP (protocolo de Internet) como 203.0.113.10. Un navegador no puede conectarse a un nombre. Se conecta a una dirección, por lo que cada carga de página comienza con una consulta DNS y una respuesta. Si acabas de comprar un dominio y un VPS propio, y no se carga nada, una de estas dos situaciones es la correcta: todavía no hay ningún registro que conecte el nombre con la dirección de tu servidor, o sí existe un registro, pero algo en la ruta sigue entregando una respuesta anterior.

Ambas situaciones son normales y ninguna significa que haya algo averiado. Las secciones siguientes presentan las partes en el orden en que las encontrarás, empezando por la que más tiempo hace perder: qué panel de control contiene realmente tus registros.

Todas las comprobaciones de esta guía usan dig, que no está instalado de forma predeterminada en una máquina Ubuntu o Debian recién instalada.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrador, servidores de nombres y proveedor DNS: cuál debe editar

Estos tres términos describen funciones diferentes. Confundirlos es la razón más habitual por la que un cambio no produce ningún efecto.

• El registrador es la empresa donde compró el dominio. Su función crítica es la delegación: informa al registro que administra su TLD (dominio de nivel superior, la parte .com) de cuáles son los servidores de nombres autoritativos para su dominio.
• Los servidores de nombres autoritativos contienen los registros reales de su zona. Una zona es su dominio y los nombres que contiene.
• El proveedor DNS es quien opera esos servidores de nombres. Puede ser el registrador, otro proveedor o bind9 ejecutándose en un servidor que usted administra.

El dominio se compra en el registrador. Los cambios se hacen en el proveedor DNS. Si trasladó su dominio a los servidores de nombres de otro proveedor, el panel DNS del registrador todavía muestra una zona, guarda los cambios y ningún sistema de Internet consulta esa zona. Los registros existen. Simplemente nunca se consultan.

Compruebe dónde se están realizando las consultas:

dig example.com NS +short
dig +trace example.com

El primer comando muestra los servidores de nombres que responden actualmente para el dominio. El segundo recorre la cadena desde los servidores raíz y muestra la referencia que entregan los servidores del TLD. Esa referencia es la delegación que controla el registrador. Si esos nombres pertenecen a un proveedor que no reconoce, ese proveedor administra el panel que debe utilizar.

Cómo se realiza una consulta individual

Intervienen cuatro partes. Cada una conserva una copia de la información que obtiene.

1. El stub resolver de su equipo. No realiza búsquedas. Consulta un único servidor configurado y confía en la respuesta. En Ubuntu, /etc/resolv.conf suele ser un enlace simbólico a /run/systemd/resolve/stub-resolv.conf y designa 127.0.0.53, que es systemd-resolved ejecutándose localmente con su propia caché.
2. El resolver recursivo. Es el resolver que ejecuta su ISP (proveedor de servicios de Internet), uno público como 1.1.1.1 o uno que usted administra. Realiza el trabajo necesario para encontrar la respuesta.
3. Los servidores raíz y de TLD. El resolver recursivo consulta un servidor raíz. Este no conoce su dirección, pero responde con una referencia a los servidores de .com. Estos responden con una referencia a sus servidores de nombres.
4. El servidor de nombres autoritativo. No consulta a ningún otro servidor. Responde a partir de su zona y marca la respuesta como autoritativa.

dig +trace example.com muestra este proceso porque empieza en la raíz y muestra cada referencia en lugar de consultar una caché. Es la forma más rápida de comprobar si la delegación y la zona coinciden.

Registros DNS relevantes al ejecutar un servidor

• A: asigna un nombre a una dirección IPv4. example.com. A 203.0.113.10. Este es el registro que apunta el dominio al VPS.
• AAAA: asigna un nombre a una dirección IPv6, como 2001:db8::10. Publíquelo sólo cuando el servicio realmente escuche en esa dirección. Los clientes de redes IPv6 prueban primero la respuesta AAAA, por lo que una dirección que no tiene ningún servicio escuchando añade una espera a cada visita.
• CNAME: crea un alias de un nombre a otro. www.example.com. CNAME example.com. envía a los visitantes de www al resultado de resolver el dominio raíz. Un CNAME no puede existir en el apex (el example.com raíz), porque el apex debe contener sus propios registros SOA (start of authority) y NS, y un CNAME no puede compartir nombre con ningún otro registro. Los proveedores ofrecen soluciones alternativas con nombres como ALIAS, ANAME o CNAME flattening.
• MX: indica dónde se entrega el correo del dominio. Contiene un nombre de host y un número de prioridad; se prueba primero el número más bajo. Un MX debe apuntar a un nombre que tenga un registro de dirección. Apuntarlo a un CNAME no es válido y algunos servidores de envío lo rechazan.
• TXT: texto libre que se usa para validaciones y políticas. Aquí se encuentran los registros de autenticación del correo (SPF, DKIM y DMARC), así como el token de ACME (automatic certificate management environment) que permite emitir un certificado comodín.
• NS: indica qué servidores de nombres sirven la zona. La copia que determina dónde consulta el resto de Internet se encuentra en la zona padre y procede de la delegación del registrador, no de la copia dentro de su propia zona.

Dos detalles causan más confusión que los propios tipos de registro. Un nombre que termina en un punto es absoluto, por lo que www.example.com. significa exactamente eso y nada más. La mayoría de los paneles esperan un nombre relativo y añaden el dominio automáticamente. Por tanto, escribir www.example.com en el campo del nombre produce www.example.com.example.com, que no resuelve para nadie. El otro detalle es @, que en casi todos los paneles significa el apex: el dominio por sí solo, sin subdominio.

Apunte un registro A a su VPS

Primero obtenga la dirección que Internet ve para su servidor:

curl -4 https://ifconfig.me
ip -brief -4 address show

Después cree un registro en su proveedor de DNS: tipo A, nombre @, valor igual a esa dirección y TTL (tiempo de vida) 300. Añada un segundo registro para www: puede ser otro registro A con la misma dirección o un registro CNAME que apunte al dominio raíz.

Ahora compruebe que resuelve, preferiblemente desde su portátil y no desde el propio servidor:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

El primero usa la ruta normal de su equipo, incluidas las cachés. El segundo omite la caché local y consulta un resolvedor recursivo público. El tercero consulta directamente su servidor de nombres autoritativo, por lo que su respuesta refleja el estado actual y no hay ninguna caché en la ruta. Si el tercer comando devuelve su dirección y el primero no, el DNS está configurado correctamente y sólo está esperando a que caduque una copia almacenada en caché de la respuesta anterior.

La resolución de nombres no funciona

Una resolución de nombres correcta demuestra que DNS funciona. No demuestra nada sobre el servidor web. Cuando dig devuelve la dirección correcta, pruebe la conexión:

curl -I http://example.com

curl: (6) Could not resolve host: example.com es un problema de DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused no es un problema de DNS: el nombre se resolvió y el paquete llegó, por lo que el problema es que no había ningún proceso escuchando en ese puerto. Una solicitud que queda bloqueada y termina agotando el tiempo de espera suele indicar que un firewall descartó el paquete silenciosamente en lugar de rechazarlo. En ese punto, DNS deja de ser el tema, y los puertos y sockets en escucha junto con las reglas del firewall ufw en su VPS pasan a ser relevantes. Una vez completada la conexión, el resto de la carga de la página corresponde a HTTP en funcionamiento.

Por qué el navegador sigue mostrando el host antiguo

Nada se propaga. Ningún servidor envía el cambio a otros sistemas. El servidor de nombres autoritativo conserva el valor nuevo en cuanto lo guarda, y cada copia en caché de la respuesta anterior sigue siendo válida hasta que vence su propio temporizador. Ese temporizador es el TTL, expresado en segundos, que llevaba el registro cuando se entregó.

Las copias se almacenan en más lugares de los que se suele pensar: la caché breve del propio navegador, el resolvedor stub del equipo, el resolvedor recursivo que usa esa red y cualquier resolvedor que una VPN haya instalado en el cliente. Cada uno conserva su copia durante un máximo igual al TTL recibido. Dos personas en dos redes pueden ver respuestas distintas durante horas, y ambos equipos funcionan correctamente.

Observe la cuenta atrás en un resolvedor con caché:

dig @1.1.1.1 example.com +noall +answer

Ejecútelo dos veces, con unos segundos de diferencia. El TTL de la respuesta disminuye. Cuando llega a cero, el resolvedor descarta el registro y vuelve a consultar su servidor de nombres.

Existe otra caché que casi nadie tiene en cuenta: las respuestas negativas. Cuando se informa a un resolvedor de que un nombre no existe, también almacena ese NXDOMAIN durante el tiempo establecido por el último campo del registro SOA de la zona.

dig example.com SOA +short

El último número de esa línea es el TTL negativo, a menudo 3600. Por tanto, consultar staging.example.com antes de crearlo puede ocultarle el registro durante una hora completa después de crearlo. Cree primero el registro y consúltelo después.

Cambiar los servidores de nombres es más lento que cambiar un registro. El motivo es mecánico. Los registros de delegación de la zona .com se sirven con un TTL de 172800 segundos, es decir, dos días. Por tanto, un resolvedor que haya almacenado en caché los servidores de nombres antiguos puede seguir consultándolos durante ese tiempo. De ahí procede el consejo de «esperar hasta 48 horas». Se aplica a los cambios de servidores de nombres, no a las modificaciones normales de registros.

Planifique la migración según el TTL en lugar de intentar evitarlo:

1. Reduzca el TTL del registro a 300 y guarde el cambio.
2. Espere más tiempo que el TTL antiguo para que caduque toda copia en caché que contenga el valor anterior.
3. Cambie la dirección.
4. Cuando el tráfico se haya trasladado, vuelva a aumentar el TTL a 3600 o más, porque un TTL bajo hace que cada resolvedor consulte los servidores de nombres con mucha más frecuencia.

Para borrar lo que conserva el propio equipo:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics muestra una sección de caché con contadores de aciertos y fallos. Por tanto, justo después de vaciarla, la siguiente consulta aparece como un fallo. Los navegadores mantienen una caché independiente, lo que significa que Chrome todavía puede usar una respuesta antigua después de vaciar la caché del sistema. Borre esa caché en chrome://net-internals/#dns. Compruebe también /etc/hosts, porque una línea antigua allí tiene prioridad sobre DNS en ese equipo y sólo en ese equipo. getent hosts example.com muestra la respuesta que realmente usará el sistema, incluido /etc/hosts.

Los certificados comodín se validan mediante un registro TXT

Una CA (autoridad certificadora) comprueba el control sobre un nombre antes de emitir un certificado. El desafío HTTP-01 sirve un archivo a través del puerto 80 en ese nombre de host exacto, lo que funciona bien para un solo nombre. Un certificado comodín cubre *.example.com, un conjunto abierto de nombres de host desde los que la CA no puede obtener un archivo. Por eso, Let's Encrypt emite certificados comodín únicamente mediante el desafío DNS-01. Debe publicar un registro TXT en _acme-challenge.example.com que contenga un token proporcionado por la CA. El control de la zona es la prueba.

Esto convierte al proveedor DNS en parte de la renovación del certificado. Certbot debe crear y eliminar ese registro TXT en cada renovación sin intervención manual. Por tanto, necesita una API y un plugin compatible con su proveedor. Cuando la validación falla, el mensaje habitual es DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Esto significa que la CA consultó antes de que el registro fuera visible: o bien nunca se guardó, o bien una respuesta negativa seguía en la caché. El procedimiento completo está en la guía sobre certificados comodín con el desafío DNS-01.

Cuando una VPN sustituye el resolvedor

Un cliente VPN (red privada virtual) normalmente sustituye el resolvedor del sistema mientras está conectado, porque enviar las consultas a la red local permitiría a esa red conocer el nombre de cada sitio que visita. Ese es el comportamiento correcto, pero puede fallar en dos sentidos.

Si el túnel se establece y los nombres dejan de resolverse mientras las direcciones siguen funcionando, no se puede acceder al resolvedor instalado por el cliente desde dentro del túnel. ping 1.1.1.1 funciona correctamente y curl https://example.com devuelve curl: (6) Could not resolve host: example.com. Si, por el contrario, el túnel se establece y las consultas siguen dirigiéndose a la red a la que está conectado, el tráfico pasa por el túnel, pero el resolvedor local sigue viendo cada nombre que consulta.

resolvectl status

Esto muestra el resolvedor que usa cada enlace, para que pueda comprobar cuál instaló el túnel y si es el que esperaba. Un túnel WireGuard establece este valor mediante la línea DNS = del archivo de configuración del cliente, y cómo corregir el DNS cuando WireGuard sustituye al resolvedor explica en detalle los casos de systemd-resolved y resolvconf.

Los códigos de respuesta y lo que indica cada uno

• NXDOMAIN: un servidor autoritativo indica que el nombre no existe. Compruebe la ortografía, compruebe que no haya un sufijo de dominio duplicado y compruebe que haya editado la zona a la que apunta la delegación.
• NOERROR con un ANSWER SECTION vacío: el nombre existe, pero no tiene ningún registro del tipo solicitado. Solicitar AAAA cuando sólo existe un A produce exactamente este resultado.
• SERVFAIL: el resolver lo intentó, pero no pudo generar una respuesta. Las dos causas habituales son que los servidores autoritativos no respondan y que falle la validación de DNSSEC (extensiones de seguridad del sistema de nombres de dominio). Pruebe con dig @1.1.1.1 example.com A +cd, que desactiva la validación. Una respuesta con +cd y SERVFAIL sin esa opción indica que el problema está en las firmas. Esto ocurre después de trasladar un nameserver cuando el servidor padre todavía publica el registro DS (firmante de delegación) antiguo.
• REFUSED: el servidor consultado no responderá a esa pregunta. Normalmente, esto ocurre porque apuntó dig a un servidor autoritativo de un dominio que no sirve.
• ;; connection timed out; no servers could be reached: dig nunca llegó a un resolver. Es un problema de red o del resolver en su lado, por lo que el dominio no es la causa.

ping: example.com: Temporary failure in name resolution es la misma clase de fallo notificada por glibc en lugar de por dig.

¿Debe ejecutar servidores de nombres en su propio VPS?

Puede hacerlo. bind9, knot o nsd servirán su zona desde el servidor, y aprenderá más sobre DNS que con cualquier panel. Las objeciones son prácticas. Un dominio debe tener al menos dos servidores de nombres en redes independientes, por lo que un único VPS se convierte en un punto único de fallo para todos los servicios del dominio, incluido el correo. Los servidores de nombres cuyo nombre pertenece al dominio que sirven necesitan registros glue en el registrador. Estos registros contienen la dirección de ns1.example.com almacenada en la zona principal, porque, de lo contrario, la consulta no tiene forma de comenzar. Cuando un resolver no puede alcanzar su servidor de nombres, no recurre a su sitio web: para ese usuario, el dominio completo deja de estar disponible. Para la mayoría de los usuarios, el DNS alojado con una API es la opción de menor riesgo. Ejecutar un resolver de caché en su VPS para sus propios equipos es una tarea distinta y supone un compromiso mucho menor.

FAQ

¿Por qué todavía no se ha propagado mi cambio de DNS?

Nada se propaga. Tus servidores de nombres autoritativos mantienen el nuevo valor en cuanto lo guardas, y cada resolvedor que ya lo consultó conserva su copia en caché hasta que vence el TTL recibido. Consulta directamente el servidor autoritativo con dig @ns1.your-dns-host.net example.com A +short. Si devuelve la nueva dirección, el cambio está activo y lo único pendiente es la caché. Si cambiaste los servidores de nombres en lugar de los registros, espera mucho más tiempo, porque las delegaciones de los TLD se distribuyen con un TTL de dos días.

¿Cómo puedo saber qué servidores de nombres usa realmente mi dominio?

dig example.com NS +short muestra los servidores de nombres que responden actualmente para el dominio, y dig +trace example.com muestra la cadena de referencias desde la raíz, incluida la delegación que entregan los servidores del TLD. Si esos nombres no corresponden al proveedor cuyo panel has estado editando, ese es el problema. Edita los registros en el proveedor indicado en la delegación o cambia la delegación en tu registrador para que apunte al lugar que quieras.

Mi dominio resuelve, pero el sitio todavía no carga. ¿Qué hago ahora?

El DNS queda resuelto en cuanto dig example.com A +short devuelve la dirección de tu servidor. Después de eso, el problema está en la conexión. Si curl -I http://example.com devuelve Connection refused, significa que no hay ningún proceso escuchando en ese puerto. Una petición que queda bloqueada hasta que vence el tiempo de espera indica que un firewall descartó el paquete. Comprueba que el servidor web esté en ejecución y asociado a la dirección pública. Después, comprueba el firewall del servidor y el firewall de red independiente del panel de control de tu proveedor.

¿Por qué no puedo poner un CNAME en el dominio raíz?

Un CNAME indica que un nombre es un alias de otro nombre, y un nombre que tiene un CNAME no puede contener ningún otro registro. El dominio raíz debe contener registros SOA y NS para existir como zona, por lo que no puede ser también un CNAME. Usa un registro A que contenga la dirección en la raíz o utiliza la función del proveedor comercializada como ALIAS, ANAME o aplanamiento de CNAME. Esta función almacena un nombre y responde a las consultas con la dirección a la que ese nombre resuelve actualmente.