Dominios y DNS para el propietario de un servidor
El servidor se puede cambiar en una tarde, pero el dominio acompaña al proyecto durante años. Mediante DNS, el dominio apunta al servidor, al correo y a servicios externos, y un solo registro erróneo deja la web sin servicio o envía los correos a spam. Veamos qué registros necesita el propietario de un VPS, cómo funciona la caché, dónde alojar la zona y cómo pasar a un servidor nuevo sin que los visitantes lo noten.
Un dominio tiene tres partes independientes, y conviene distinguirlas. El registrador vende y renueva el propio dominio. Los servidores DNS indicados en el registrador mediante los registros NS guardan la zona, es decir, la lista de registros del dominio. El proveedor de hosting ofrece el servidor con la dirección IP a la que apuntan esos registros. Las tres funciones pueden estar en una sola empresa o en tres distintas, y de ello depende qué habrá que cambiar en una migración.
Registros DNS principales
- A: la dirección IPv4 del servidor para un nombre (RFC 1035). Una web suele necesitar dos: para
example.comy parawww.example.com. - AAAA: lo mismo para IPv6 (RFC 3596). Añádalo solo si el servidor responde de verdad por IPv6: los navegadores prueban primero esa dirección, y un IPv6 que no funciona provoca retrasos a parte de los visitantes. Más detalles en el artículo IPv4 e IPv6 en un servidor.
- CNAME: un alias; el nombre apunta a otro nombre, por ejemplo
wwwaexample.como un subdominio a la dirección de una CDN. Según el RFC 2181, un nombre con CNAME no puede tener otros registros, por lo que no se pone un CNAME en el dominio raíz: ahí ya están los registros NS y SOA. Algunos proveedores de DNS lo resuelven con tipos propios como ALIAS o ANAME, pero es una extensión de cada servicio, no un estándar. - MX: los servidores que reciben el correo del dominio, con una prioridad: el número menor es el principal. Un MX debe apuntar a un nombre con registro A o AAAA, no a una dirección IP ni a un CNAME.
- TXT: texto libre. En él se guardan SPF, DKIM y DMARC para el correo y los códigos de verificación del dominio para buscadores y otros servicios. Cómo redactar los registros de correo se explica en el artículo Servidor de correo en un VPS: SPF, DKIM y DMARC.
- CAA: qué autoridades de certificación pueden emitir certificados para el dominio (RFC 8659). Es opcional, pero si existe, una autoridad que no figure en él se negará a emitir. Sobre certificados, vea el artículo Certificados SSL: gratuitos y de pago.
La zona típica de una web en un VPS con el correo en un servicio externo es así: registros A y AAAA para el dominio y para www, el MX del servicio de correo, TXT con SPF y DMARC, CNAME o TXT para DKIM y varios TXT con verificaciones de servicios.
TTL: por qué los cambios no se ven al instante
El TTL es el tiempo en segundos durante el cual los servidores DNS de los operadores y los dispositivos de los visitantes recuerdan una respuesta (RFC 2181, sección 8). Mientras no venza, no vuelven a consultar la zona, así que un registro nuevo no llega a todos antes de que pase el TTL del antiguo. De ahí la idea extendida de que «el DNS tarda hasta 72 horas en actualizarse»: en realidad todo depende del TTL que usted mismo haya fijado.
- 3600 segundos (una hora): un valor razonable para el funcionamiento normal;
- 300 segundos: durante una migración o una configuración, cuando quizá haya que cambiar la dirección rápido;
- un día o más: para registros que no cambian en años, como el MX.
La ausencia de un registro también se guarda en caché. Si se consulta un subdominio antes de crearlo, la respuesta negativa se recuerda durante el plazo indicado en el registro SOA de la zona (RFC 2308), a menudo una hora. Por eso, primero cree el registro y después compruébelo.
Un caso aparte son los registros NS en el registrador. Su TTL no lo fija el titular del dominio, sino la zona de nivel superior. Una consulta a los servidores de las zonas el 6 de noviembre de 2026 mostró que, para los dominios .com, los registros NS se guardan en caché 172 800 segundos, es decir, dos días, y para .ru, 345 600 segundos, cuatro días. Por eso cambiar los servidores DNS de un dominio siempre tarda más que cambiar un registro A.
PTR: el registro inverso para el correo
Los registros normales traducen un nombre en una dirección, y el PTR, una dirección en un nombre: 203.0.113.10 → mail.example.com. No está en la zona de su dominio, sino en la zona de direcciones in-addr.arpa o ip6.arpa, que gestiona el titular de la dirección IP, es decir, el proveedor de hosting. Se configura en el panel del proveedor o a través del soporte.
Una web no necesita PTR, pero el correo sí: Google exige a los remitentes que la IP del servidor tenga PTR y que el nombre que contiene apunte de vuelta a la misma dirección. Antes de comprar un VPS para correo, compruebe si el proveedor permite cambiar el PTR y si el puerto 25 de salida está abierto; hay una selección de estos servidores en VPS para servidor de correo.
Dónde alojar la zona: registrador, proveedor de hosting o servicio DNS aparte
- En el registrador. Es gratis y no depende del proveedor de hosting: al cambiar de servidor, cambia un registro A. Inconvenientes: pocos tipos de registro, sin API o con una API limitada, y la velocidad de respuesta depende de la infraestructura del registrador.
- En el proveedor de hosting. Es cómodo tenerlo todo en un panel, y algunos proveedores rellenan la zona ellos mismos. Pero al cambiar de proveedor también habrá que trasladar la zona, y si la cuenta se bloquea o hay una disputa, junto con el servidor deja de estar disponible el DNS, es decir, el correo y todos los subdominios.
- Un servicio DNS aparte. Servidores en varios países con anycast, respuestas rápidas, API para automatizar y emitir certificados wildcard, historial de cambios. Muchos tienen planes básicos gratuitos. Encaja con proyectos que tienen varios servidores o que usan una CDN.
Una regla para cualquier opción: el registrador y la cuenta del dominio deben pertenecer al titular del proyecto, no a un contratista ni al proveedor de hosting. Según el catálogo de accsly.io (noviembre de 2026), 494 planes de hosting compartido de 153 de los 1655 proveedores mencionan un dominio gratuito, normalmente con pago anual. Ante una oferta así, averigüe a nombre de quién se registra el dominio y cuánto cuesta renovarlo el segundo año. Los planes de hosting están reunidos en la sección Hosting para webs.
Proteja el dominio como si fuera dinero: acceso en dos pasos en el registrador, renovación automática con una tarjeta en vigor y un correo del titular actualizado. Según las normas vigentes de ICANN, un dominio de las zonas genéricas como .com no se puede transferir a otro registrador durante 60 días tras su registro o transferencia, así que conviene elegir bien el registrador desde el principio.
Cómo migrar una web sin tiempo de inactividad
- Uno o dos días antes, baje el TTL de los registros A y AAAA a 300 segundos y espere a que venza el TTL anterior.
- Prepare el servidor nuevo y pruebe la web en él antes de cambiar el DNS:
curl --resolve example.com:443:203.0.113.10 https://example.com/o una entrada en el archivohostsde su ordenador. - Cambie los registros A y AAAA a la nueva dirección. En pocos minutos, la mayoría de los visitantes estará en el servidor nuevo.
- No apague el servidor antiguo durante al menos un día: los dispositivos con la dirección en caché seguirán accediendo a él. Si la web recibe datos, durante la migración ponga la copia antigua en solo lectura para que los pedidos y comentarios no se repartan entre dos bases de datos.
- Restablezca el TTL a su valor habitual cuando todo funcione.
El procedimiento completo para trasladar archivos, base de datos y correo se describe en el artículo Cómo migrar una web del hosting compartido a un VPS.
Si además del servidor cambia los servidores DNS del dominio, hágalo en un paso aparte. Primero traslade todos los registros a la zona nueva y compare las respuestas de los servidores antiguos y nuevos: dig @nuevo-ns example.com MX, y así con cada tipo. Solo entonces cambie los NS en el registrador y mantenga operativa la zona antigua al menos durante el TTL de la delegación: dos días para .com y cuatro para .ru. Si el dominio tiene DNSSEC activado, antes de cambiar los NS retire el registro DS en el registrador o traslade las claves según el esquema del RFC 6781: de lo contrario, los resolutores que validan DNSSEC dejarán de abrir el dominio.
Cómo comprobarlo
El comando dig example.com A +short muestra la respuesta actual, y dig example.com A +trace, el recorrido desde los servidores raíz hasta los suyos, lo que ayuda a ver qué servidor devuelve el registro antiguo. dig -x 203.0.113.10 comprueba el PTR. Para ver el TTL que le queda en la caché a un resolutor concreto, consúltelo directamente sin +short. Si la web está detrás de una CDN, el registro A apuntará a la CDN y no a su servidor; cómo funciona esto se explica en el artículo CDN: cuándo la necesita una web.