Los DNS son una de esas cosas que utilizamos constantemente al gestionar una web, pero que muchas personas empiezan a entender solamente cuando algo deja de funcionar.
Compramos un dominio.
Contratamos un hosting.
El proveedor nos dice:
“Cambia los DNS.”
Después aparecen términos como:
nameservers
registro A
CNAME
MX
TXT
propagación DNS
Y si nunca hemos configurado un dominio, puede parecer bastante más complicado de lo que realmente es.
En esta guía vamos a ver qué son los DNS, cómo funcionan y qué registros encontraremos habitualmente al gestionar una página web.
¿Qué significa DNS?
DNS significa Domain Name System.
Simplificando mucho, es el sistema que permite relacionar nombres de dominio fáciles de recordar con la información técnica necesaria para localizar servicios en Internet.
Nosotros escribimos:
dsforo.com
pero los servidores trabajan con direcciones y configuraciones técnicas.
El DNS ayuda a traducir ese nombre en la información necesaria para llegar al servicio correcto.
Una comparación bastante utilizada es pensar en los DNS como una especie de agenda de contactos de Internet.
Nosotros sabemos el nombre.
El sistema averigua dónde debe dirigirnos.
¿Por qué necesitamos DNS?
Imaginemos que cada vez que quisiéramos entrar en una web tuviéramos que memorizar una dirección IP.
Sería bastante poco práctico.
Es mucho más fácil recordar:
midominio.com
que una secuencia numérica.
Además, la infraestructura puede cambiar sin que necesariamente tengamos que cambiar el nombre que utilizan los usuarios.
Podemos mover una web de un servidor a otro y modificar la configuración DNS para dirigir el dominio hacia la nueva infraestructura.
Dominio, hosting y DNS no son lo mismo
Esta distinción es fundamental.
Dominio
Es el nombre que registramos.
Por ejemplo:
ejemplo.com
Hosting
Es el servicio donde alojamos nuestra web o aplicación.
DNS
Es el sistema que permite indicar hacia dónde debe dirigirse el dominio para diferentes servicios.
Podemos comprar el dominio en una empresa y contratar el hosting en otra.
No tienen que estar necesariamente en el mismo proveedor.
De hecho, en Hosting y Dominios tenemos separadas precisamente estas áreas porque son conceptos relacionados pero diferentes.
¿Qué ocurre cuando escribimos una web en el navegador?
Simplificando muchísimo el proceso:
1. Escribimos un dominio.
2. El sistema necesita saber dónde está alojado.
3. Se consulta información DNS.
4. Se obtiene la dirección correspondiente.
5. El navegador se conecta con el servidor.
6. El servidor responde con la web.
Todo esto ocurre normalmente de forma tan rápida que el usuario ni siquiera piensa en ello.
¿Qué son los nameservers?
Los nameservers o servidores de nombres indican qué servidores DNS son responsables de gestionar la zona DNS de un dominio.
Por ejemplo, cuando contratamos un hosting podemos recibir algo parecido a:
ns1.ejemplo.com
ns2.ejemplo.com
El proveedor puede pedirnos que configuremos esos nameservers en el registrador del dominio.
Una vez realizado el cambio, ese proveedor pasa a gestionar la información DNS correspondiente.
¿Tengo que cambiar siempre los nameservers?
No necesariamente.
Existen varias formas de configurar un dominio.
Podemos:
- Cambiar los nameservers completos.
- Mantener los DNS actuales y modificar registros individuales.
- Utilizar un proveedor externo de DNS.
- Utilizar servicios como CDN o proxy que gestionan también DNS.
Dependerá de nuestra infraestructura.
No cambiaría los nameservers automáticamente sin saber qué otros servicios dependen de la configuración actual.
Cuidado al cambiar DNS si tienes correo
Este es uno de los errores más frecuentes.
Tenemos una empresa con:
web + correo
Contratamos un hosting nuevo.
Cambiamos los nameservers.
La web empieza a funcionar.
Pero el correo deja de recibir mensajes.
¿Por qué?
Porque la configuración anterior incluía registros relacionados con el email y no los hemos replicado.
Antes de cambiar una zona DNS completa comprobaría siempre qué registros existen.
Especialmente:
- MX.
- TXT.
- SPF.
- DKIM.
- CNAME relacionados.
- Verificaciones de servicios.
Mover una web no significa necesariamente mover el correo.
¿Qué es un registro A?
El registro A permite relacionar un nombre con una dirección IPv4.
Por ejemplo, conceptualmente:
ejemplo.com → 192.0.2.10
Esto permite indicar que el dominio debe dirigirse hacia determinado servidor.
Es uno de los registros más habituales cuando configuramos una web.
¿Qué es un registro AAAA?
El registro AAAA cumple una función parecida al registro A, pero para direcciones IPv6.
Podemos encontrarnos con sitios que utilizan tanto IPv4 como IPv6.
Si nuestra infraestructura no utiliza IPv6 correctamente, no añadiría un AAAA simplemente porque aparece como opción.
Los registros DNS deben representar la infraestructura real.
¿Qué es un CNAME?
Un registro CNAME permite crear un alias hacia otro nombre.
Por ejemplo:
www.ejemplo.com
podría apuntar hacia:
ejemplo.com
Conceptualmente estamos diciendo:
Para este nombre, utiliza el destino asociado a este otro nombre.
Los CNAME aparecen muchísimo en servicios externos.
Por ejemplo, una plataforma puede pedirnos crear:
app.ejemplo.com
apuntando hacia un dominio proporcionado por ellos.
¿Registro A o CNAME?
Depende de lo que necesitemos configurar.
Un registro A apunta normalmente hacia una dirección IP.
Un CNAME apunta hacia otro nombre.
No los trataría como opciones intercambiables en cualquier situación.
Seguiría las instrucciones concretas del proveedor que estemos integrando.
¿Qué son los registros MX?
Los registros MX están relacionados con la recepción de correo electrónico.
Indican qué servidores deben gestionar el email de nuestro dominio.
Por ejemplo:
usuario@ejemplo.com
necesita que exista una configuración adecuada para saber dónde debe entregarse ese correo.
Si cambiamos incorrectamente los registros MX podemos dejar de recibir emails aunque la página web siga funcionando perfectamente.
Por eso web y correo deben revisarse por separado.
¿Qué son los registros TXT?
Los registros TXT permiten almacenar determinada información de texto asociada al dominio.
Se utilizan para muchísimas cosas.
Por ejemplo:
- Verificaciones de propiedad.
- Configuraciones de correo.
- SPF.
- DKIM.
- DMARC.
- Validaciones de servicios.
- Diferentes integraciones.
Cuando una herramienta nos dice:
Añade este registro TXT para verificar el dominio
normalmente nos está pidiendo demostrar que tenemos control sobre la configuración DNS.
SPF, DKIM y DMARC
Si gestionamos correo profesional probablemente encontraremos estas siglas.
De forma muy resumida:
SPF
Ayuda a indicar qué servidores están autorizados para enviar correo en nombre de nuestro dominio.
DKIM
Permite utilizar firmas criptográficas para ayudar a verificar la autenticidad de los mensajes.
DMARC
Permite establecer políticas y obtener información relacionada con la autenticación del correo.
No configuraría estos registros copiando valores aleatorios de Internet.
Debemos utilizar la información correspondiente a nuestro proveedor de correo.
¿Qué es un subdominio?
Un subdominio es una parte añadida delante del dominio principal.
Por ejemplo:
blog.ejemplo.com
tienda.ejemplo.com
app.ejemplo.com
foro.ejemplo.com
Podemos dirigir cada subdominio hacia servicios diferentes mediante DNS.
Por ejemplo:
www.ejemplo.com → hosting principal
app.ejemplo.com → servidor de aplicación
status.ejemplo.com → servicio externo
Esto permite separar infraestructuras sin necesidad de registrar dominios diferentes.
¿Qué es la propagación DNS?
Cuando cambiamos un registro DNS no siempre vemos el resultado inmediatamente en todos los lugares.
Aquí aparece el término propagación DNS.
En realidad intervienen diferentes sistemas de caché y tiempos de vida de los registros.
Por eso puede ocurrir que:
Desde nuestro móvil ya vemos la web nueva.
pero:
Desde otro ordenador todavía aparece la antigua.
Esto puede ser completamente normal durante un periodo después del cambio.
¿Cuánto tarda en propagarse un DNS?
No daría una cifra universal.
Puede depender de:
- TTL.
- Proveedor DNS.
- Cachés.
- Resolutores.
- Tipo de cambio.
- Configuración anterior.
Algunos cambios pueden verse bastante rápido.
Otros pueden tardar más en reflejarse desde diferentes ubicaciones.
Por eso evitaría afirmar:
Todos los DNS tardan exactamente 24 horas.
No funciona así.
¿Qué es el TTL?
TTL significa Time To Live.
Indica durante cuánto tiempo puede almacenarse en caché determinada información DNS antes de volver a consultarla.
Por ejemplo, un TTL elevado puede reducir consultas pero también hacer que determinados cambios tarden más en reflejarse para sistemas que todavía conservan la información anterior.
Cuando planificamos una migración importante puede tener sentido estudiar el TTL con antelación.
Error típico: cambiar el DNS y seguir viendo la web vieja
Puede ocurrir.
Algunas causas posibles:
- Caché DNS local.
- Caché del proveedor de Internet.
- Caché del navegador.
- CDN.
- Proxy.
- Registro todavía no actualizado en todos los resolutores.
Antes de concluir que el cambio ha fallado, comprobaría la resolución DNS desde diferentes herramientas y ubicaciones.
Error típico: el dominio funciona con www pero sin www
También puede ocurrir al configurar únicamente uno de los nombres.
Tenemos que comprobar:
ejemplo.com
y
www.ejemplo.com
No asumiría que configurar uno hace funcionar automáticamente el otro.
Dependiendo de la arquitectura necesitaremos los registros y redirecciones correspondientes.
DNS y redirección no son exactamente lo mismo
Este concepto también genera confusión.
DNS puede hacer que:
www.ejemplo.com
apunte hacia determinado servidor.
Pero una redirección HTTP como:
www.ejemplo.com → ejemplo.com
se produce a otro nivel.
No deberíamos pensar que un registro DNS sustituye automáticamente una redirección web 301.
Son mecanismos diferentes.
¿Puedo apuntar el dominio a un servidor nuevo sin cambiar de registrador?
Sí.
No necesitamos transferir necesariamente el dominio a la empresa de hosting.
Podemos mantener el dominio donde está registrado y modificar:
- Nameservers.
- Registro A.
- CNAME.
- Otros registros necesarios.
Esto permite separar registrador e infraestructura.
Personalmente me parece útil entender esta diferencia porque evita pensar que tenemos que mover todo el dominio cada vez que cambiamos de hosting.
Si todavía estás comparando alojamientos, tenemos también la guía sobre cómo elegir un buen hosting para una página web.
¿Qué ocurre si cambio de hosting?
Imaginemos que nuestra web está alojada en el servidor A.
Contratamos el servidor B.
Una migración simplificada sería:
1. Copiar la web al servidor B.
2. Comprobar que funciona correctamente.
3. Actualizar la configuración DNS.
4. El dominio empieza a resolver hacia el servidor B.
5. Mantener temporalmente el servidor anterior si es necesario.
La planificación es importante para reducir interrupciones.
No cancelaría el hosting anterior antes de comprobar que la migración está funcionando.
¿Qué es Cloudflare y qué tiene que ver con DNS?
Servicios como Cloudflare pueden actuar como proveedor DNS y ofrecer funciones adicionales relacionadas con seguridad, rendimiento y proxy.
En una configuración de este tipo los nameservers del dominio pueden apuntar hacia Cloudflare y desde allí gestionamos los registros.
Después Cloudflare dirige el tráfico según nuestra configuración.
Esto añade posibilidades interesantes, pero también significa que debemos entender dónde estamos modificando realmente los DNS.
“He cambiado el registro en el hosting y no pasa nada”
Puede ocurrir porque el hosting no es quien gestiona actualmente los DNS autoritativos del dominio.
Imaginemos:
El dominio usa nameservers de Cloudflare.
Entramos en cPanel y modificamos un registro.
Pero la zona activa se gestiona desde Cloudflare.
El cambio de cPanel podría no tener efecto sobre las consultas DNS públicas.
Por eso, antes de modificar nada, comprobaría qué nameservers utiliza realmente el dominio.
¿Cómo saber qué DNS utiliza un dominio?
Podemos consultar los nameservers actuales mediante herramientas de DNS o comandos del sistema.
Lo importante es determinar quién es responsable de la zona.
Después sabremos dónde debemos realizar los cambios.
No editaría registros en tres paneles diferentes esperando que alguno funcione.
DNS y SSL
Otro problema típico:
Cambiamos el dominio hacia un nuevo servidor.
La web empieza a cargar.
Pero aparece:
“La conexión no es privada.”
Aquí probablemente tenemos un problema relacionado con el certificado SSL del nuevo destino.
DNS y SSL están relacionados en la puesta en marcha, pero no son lo mismo.
Que el dominio apunte correctamente hacia un servidor no garantiza que ese servidor tenga un certificado válido para ese nombre.
DNS y HTTPS
Una configuración típica puede necesitar:
DNS correcto
servidor configurado para el dominio
certificado SSL
redirecciones adecuadas
Si falla cualquiera de estas partes, el usuario puede tener problemas.
Por eso al migrar una web no comprobaría únicamente que “responde la IP”.
Abriría el dominio real mediante HTTPS.
DNS y SEO
Normalmente no pensamos en DNS como una técnica para subir posiciones.
Pero una configuración incorrecta puede provocar problemas importantes para SEO.
Por ejemplo:
- Web inaccesible.
- Subdominio equivocado.
- Caídas durante una migración.
- Errores de certificado.
- URLs que dejan de responder.
- Servidor antiguo todavía visible.
Si Google no puede acceder correctamente a nuestra web durante un periodo prolongado, podemos terminar teniendo problemas de rastreo e indexación.
Por eso la parte técnica también importa.
En la sección de SEO técnico tratamos precisamente problemas relacionados con accesibilidad, rastreo, indexación y configuración técnica.
Cambiar DNS no mejora el SEO por sí mismo
También conviene aclarar esto.
Cambiar:
Proveedor DNS A
por:
Proveedor DNS B
no significa automáticamente que vayamos a subir posiciones.
Podemos obtener mejoras de:
- Fiabilidad.
- Resolución.
- Seguridad.
- Infraestructura.
Pero no vendería un cambio de nameservers como un truco SEO.
Lo importante es que la web sea accesible y estable.
¿Qué ocurre si el DNS falla?
Si el sistema DNS que resuelve nuestro dominio tiene problemas, los usuarios pueden no conseguir localizar nuestros servicios.
Podemos tener:
- Hosting funcionando.
- Base de datos funcionando.
- WordPress funcionando.
Pero si el dominio no resuelve correctamente, el usuario no llegará a la web.
Por eso el DNS es una pieza crítica.
¿Debo utilizar los DNS del registrador o del hosting?
No existe una respuesta universal.
Podemos utilizar:
- DNS del registrador.
- DNS del hosting.
- Proveedor especializado.
- CDN/proxy con DNS integrado.
La elección dependerá de:
- Fiabilidad.
- Facilidad de gestión.
- Rendimiento.
- Funciones.
- Seguridad.
- Infraestructura.
Para una web pequeña, utilizar los DNS del proveedor puede ser perfectamente suficiente.
En proyectos más complejos quizá necesitemos mayor control.
Cuidado al borrar registros
Cuando vemos veinte registros dentro de una zona DNS podemos pensar:
No sé para qué sirve esto, lo borro.
No lo haría.
Un registro aparentemente extraño puede estar verificando:
- Correo.
- Google.
- Microsoft.
- Una CDN.
- Un servicio externo.
- Una plataforma SaaS.
Antes de eliminar algo intentaría identificar para qué se utiliza.
Y guardaría una copia de la configuración original.
Haz una captura o exporta la zona antes de modificarla
Este hábito puede salvar bastante tiempo.
Antes de realizar cambios importantes guardaría:
- Nameservers actuales.
- Registros.
- Valores.
- TTL.
- MX.
- TXT.
- CNAME.
- A/AAAA.
Así, si algo deja de funcionar, tenemos una referencia de la configuración previa.
Especialmente en dominios empresariales con muchos servicios.
No publiques información sensible innecesariamente
La mayoría de los registros DNS son públicos por naturaleza.
Pero cuando pedimos ayuda debemos tener cuidado con la información adicional que compartimos.
No publicaría:
- Contraseñas.
- Tokens.
- Credenciales.
- Claves API.
- Accesos al panel.
Para diagnosticar un DNS normalmente no necesitamos compartir la contraseña del hosting ni del registrador.
¿Qué herramientas utilizar para comprobar DNS?
Existen muchas herramientas web y comandos que permiten consultar registros.
Por ejemplo, conceptualmente podemos revisar:
- Nameservers.
- Registro A.
- MX.
- TXT.
- CNAME.
En sistemas Unix podemos encontrarnos comandos como:
dig
o:
nslookup
según el entorno.
No hace falta dominar herramientas avanzadas para empezar, pero saber consultar qué está devolviendo públicamente el DNS ayuda muchísimo a diagnosticar problemas.
Ejemplo de diagnóstico
Imaginemos:
Mi dominio no carga después de cambiar de hosting.
Yo comprobaría en este orden:
1. ¿Qué nameservers utiliza el dominio?
2. ¿Qué registro A devuelve?
3. ¿Apunta a la IP correcta?
4. ¿El servidor responde?
5. ¿El dominio está configurado en ese servidor?
6. ¿Existe SSL válido?
7. ¿www y sin www funcionan?
8. ¿Hay una CDN o proxy intermedio?
9. ¿El problema ocurre desde todas las conexiones?
Así reducimos muchísimo las posibilidades.
Error: “DNS_PROBE_FINISHED_NXDOMAIN”
Este tipo de error suele indicar que existe un problema para resolver el nombre solicitado.
Puede aparecer, por ejemplo, cuando:
- El dominio no existe.
- Los DNS no están configurados correctamente.
- Falta un registro.
- Existe un problema con los nameservers.
- Hay una incidencia temporal de resolución.
No asumiría inmediatamente que el hosting está caído.
Primero comprobaría DNS.
Error: el dominio apunta a una IP antigua
Muy habitual después de una migración.
Podemos haber cambiado el servidor pero mantener todavía:
A → IP antigua
La web seguirá intentando llegar al servidor anterior.
La solución es revisar qué dirección debe utilizar realmente el dominio y modificar el registro correspondiente donde se gestiona la zona autoritativa.
Error: correo roto después de cambiar nameservers
Otro clásico.
La solución no suele ser “esperar más”.
Tenemos que comprobar si los nuevos DNS incluyen correctamente los registros de correo que utilizábamos.
Si hemos perdido:
- MX.
- SPF.
- DKIM.
- Otros TXT.
podemos tener problemas de recepción o envío.
Por eso insisto tanto en guardar la configuración anterior.
¿Cuándo tocaría yo los DNS?
Principalmente cuando necesito:
- Conectar un dominio con un hosting.
- Migrar servidores.
- Configurar correo.
- Añadir un subdominio.
- Verificar un servicio.
- Configurar una CDN.
- Conectar un SaaS.
- Modificar infraestructura.
Si todo funciona correctamente, no realizaría cambios aleatorios buscando “optimizar los DNS”.
Checklist antes de cambiar DNS
Antes de tocar un dominio importante comprobaría:
1. Quién gestiona los DNS actualmente.
2. Qué registros existen.
3. Qué servicios dependen del dominio.
4. Dónde está alojada la web.
5. Dónde está alojado el correo.
6. Qué registros me pide el nuevo proveedor.
7. Si necesito mantener configuraciones antiguas.
8. SSL.
9. www y dominio raíz.
10. Copia de la configuración original.
Después realizaría el cambio.
Hosting, dominios y DNS deberían entenderse juntos
Cuando empiezas a administrar webs, entender estos tres conceptos evita muchísimos problemas.
Dominio: el nombre.
DNS: las instrucciones para localizar servicios.
Hosting: la infraestructura que sirve la web.
Podemos contratar cada parte con empresas diferentes y conectarlas entre sí.
Por eso, si estás empezando a montar tus propios proyectos, merece la pena familiarizarse con la categoría de Hosting y Dominios, donde podemos agrupar dudas sobre DNS, hosting, servidores, VPS y dominios.
Y si gestionas sitios web habitualmente, en DSForo, foro para webmasters puedes compartir configuraciones, problemas técnicos, SEO, desarrollo y experiencias con distintos proveedores.
Conclusión
Los DNS permiten relacionar un dominio con los diferentes servicios que necesita utilizar.
Entre los registros que más veremos están:
- A.
- AAAA.
- CNAME.
- MX.
- TXT.
Y alrededor de ellos encontraremos conceptos como:
- Nameservers.
- TTL.
- Propagación.
- SPF.
- DKIM.
- DMARC.
No necesitamos convertirnos en administradores de sistemas para gestionar una web pequeña.
Pero sí merece la pena entender qué estamos cambiando.
Especialmente antes de modificar nameservers en un dominio que ya tiene web, correo y servicios funcionando.
Mi regla sería sencilla:
antes de tocar DNS, guarda la configuración actual y entiende qué servicio depende de cada registro importante.
Eso evita una gran cantidad de problemas.
¿Cuál ha sido vuestro peor problema con DNS?
¿Una web que no resolvía, correo que dejó de funcionar después de una migración, problemas con Cloudflare o una propagación que parecía no terminar nunca?
