Módulo 8 · 8.4
Errores frecuentes
Módulo 8: Seguridad y resolución de problemas · Tiempo de lectura: 10 minutos
Objetivo de aprendizaje: Después de esta lección reconocerá los diez errores de DNS más frecuentes por su síntoma y sabrá cómo solucionarlos.
Conceptos clave: punto final, nombre de dominio duplicado, modificar en el lugar equivocado, dos registros SPF, CNAME en el dominio raíz, AAAA olvidado, MX sin dirección, proxy para el correo, DS antiguo tras una transferencia, caché
Cómo usar esta lección
Los errores que se describen a continuación no proceden de un libro de texto, sino de las preguntas que reciben cada semana los proveedores de hosting. Para cada error verá: qué nota el usuario, cómo demostrarlo con una sola consulta y cuál es la solución. Ante un problema, empiece siempre con las mismas dos preguntas: qué servidores de nombres tiene el dominio (dig +short NS example.com) y qué devuelve el servidor de nombres autoritativo (dig @<nameserver> <nombre> <type>). Con eso ya resolverá la mitad de los casos.
1. Olvidar el punto final
Síntoma: un CNAME, MX o NS no funciona; un servicio indica "registro no encontrado".
Demostración: dig +short CNAME shop.example.com devuelve shops.platform.example.example.com.
Causa: en una zona, un nombre sin punto final es relativo: el panel añade su propio dominio al final (lección 2.2).
Solución: escriba el nombre de destino como nombre completo con punto (shops.platform.example.). Algunos paneles añaden el punto automáticamente; compruebe después de guardar qué queda realmente.
2. El nombre de dominio duplicado en el nombre
Síntoma: una verificación o comprobación de DKIM de un servicio no se supera, aunque el registro "está ahí".
Demostración: dig +short TXT k2._domainkey.example.com no devuelve nada, pero dig +short TXT k2._domainkey.example.com.example.com sí.
Causa: el servicio indica el nombre completo (k2._domainkey.example.com) y su panel añade el dominio otra vez al final.
Solución: en el campo de nombre, introduzca solo la parte anterior a su dominio: k2._domainkey. El panel suele mostrar debajo del campo el nombre completo: compruébelo.
3. Modificar en el lugar equivocado
Síntoma: modifica un registro, pero no cambia nada, ni siquiera al cabo de un día.
Demostración: dig +short NS example.com devuelve servidores de nombres de una entidad distinta a donde hizo la modificación (por ejemplo, de un constructor de páginas web o de Cloudflare).
Causa: solo la entidad de los servidores de nombres determina el DNS (lección 2.1). Los registros en otro lugar no tienen ningún efecto.
Solución: modifique el registro donde están los servidores de nombres, o vuelva a configurar los servidores de nombres originales. Un ejemplo real: alguien configuró los servidores de nombres hacia una plataforma de creación de páginas web para el sitio web, pero el registro A para mail no estaba allí. Resultado: enviar funcionaba, recibir no, porque el MX apuntaba a mail.example.com y ese nombre ya no existía.
4. Dos registros SPF
Síntoma: el correo acaba cada vez más en spam o es rechazado, desde que conectó un nuevo servicio.
Demostración: dig +short TXT example.com devuelve dos líneas que empiezan con v=spf1.
Causa: el nuevo servicio indicó "añada este registro SPF", y eso se hizo literalmente. Con dos registros SPF, el SPF no es válido (permerror, RFC 7208), lo cual es peor que no tener SPF en absoluto.
Solución: combínelos en un solo registro: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Tenga en cuenta el límite de diez consultas (lección 4.3).
5. Un CNAME en el dominio raíz
Síntoma: el panel rechaza el registro, o tras guardarlo su correo deja de funcionar.
Demostración: el servicio pide "cree un CNAME para @".
Causa: un CNAME no puede coexistir con otros registros, y en el dominio raíz siempre hay registros SOA y NS (y a menudo MX y TXT). Véase la lección 3.2.
Solución: use en @ el registro A (y eventualmente AAAA) que indique el servicio, y el CNAME solo para www o un subdominio. Algunos proveedores de DNS tienen una opción ALIAS o "CNAME flattening" para este caso.
6. Olvidar el AAAA en una transferencia
Síntoma: tras una transferencia, parte de los visitantes (a menudo en móvil) sigue viendo el sitio antiguo, o aparece un error de certificado.
Demostración: dig +short A example.com devuelve la nueva dirección, dig +short AAAA example.com todavía una dirección del servidor antiguo.
Causa: los dispositivos con IPv6 utilizan preferentemente el AAAA. Solo se ha modificado el A.
Solución: modifique también el AAAA, o elimínelo si el nuevo servidor no tiene IPv6. Un ejemplo real: al conectar una plataforma de tienda online, además del nuevo registro A también había que eliminar el antiguo AAAA; de lo contrario, la tienda seguía siendo inaccesible para parte de los visitantes.
7. Un MX que no apunta a nada
Síntoma: no recibe correo; los remitentes reciben un mensaje de error.
Demostración: dig +short MX example.com devuelve 10 mail.example.com., pero dig +short A mail.example.com no devuelve nada (NXDOMAIN).
Causa: un MX apunta a un nombre, y ese nombre debe tener un registro A o AAAA. A menudo el registro A de mail ha desaparecido tras una transferencia de servidores de nombres. Un MX tampoco puede apuntar a una dirección IP ni a un CNAME (RFC 2181).
Solución: cree un registro A para el nombre del servidor de correo, o haga que el MX apunte a un nombre que sí tenga una dirección.
8. El correo está en otro sitio, pero el servidor antiguo cree que debe entregarlo
Síntoma: el correo de fuera llega correctamente a su nuevo proveedor, pero el correo de su propio sitio web (formulario de contacto, tienda online) nunca llega. A veces recibe 550 Unknown user.
Demostración: el MX apunta al nuevo proveedor, pero en el servidor web la entrega local de correo sigue activada.
Causa: no se trata de un error de DNS, pero lo parece. Un servidor web que cree que tiene sus propios buzones no consulta el MX.
Solución: desactive la entrega local en el panel de su hosting (en DirectAdmin: la casilla "Usar este servidor para gestionar mis correos electrónicos"). Otros paneles tienen una opción similar, a menudo llamada "Remote mail exchanger" o "correo externo".
9. Proxy activado para el correo
Síntoma: con un proveedor de DNS con función de proxy (como la nube naranja de Cloudflare), el sitio web funciona, pero su programa de correo no puede conectar, o el certificado del sitio no se renueva.
Demostración: dig +short A mail.example.com devuelve una dirección del proxy en lugar de la de su servidor de correo.
Causa: un proxy web solo reenvía el tráfico web, no el correo.
Solución: desactive el proxy (nube gris, "DNS only") para mail y todos los nombres que use su programa de correo. Para los certificados: desactive el proxy temporalmente hasta obtener el certificado, o use el modo SSL correcto en el proxy.
10. DS antiguo tras una transferencia
Síntoma: tras una transferencia de servidores de nombres, su dominio queda inaccesible para parte del mundo; a otras personas no les afecta.
Demostración: dig example.com @1.1.1.1 devuelve SERVFAIL, dig +cd example.com @1.1.1.1 sí devuelve una respuesta. DNSViz (https://dnsviz.net/, lección 8.1) marca el DS en rojo y dibuja debajo una clave gris, punteada, que ya no está en su zona. Zonemaster y el Verisign DNSSEC Debugger informan de lo mismo con palabras.
Causa: en el registro de dominios todavía figura el DS de la entidad anterior (lección 8.1). Solo fallan los resolvers que validan, por eso no todo el mundo lo nota.
Solución: haga que se actualice el DS con la clave de la nueva entidad, o elimínelo y vuelva a activar DNSSEC después.
Y el "error" que no es un error: la caché
Muy a menudo todo está correcto, pero usted todavía ve la respuesta antigua. Lo reconocerá porque: dig @<nameserver> da la nueva respuesta, un verificador en línea en otros países también, solo su ordenador no. Solución: ventana privada, teléfono mediante 4G/5G, o vaciar su caché (lección 8.2). También una línea olvidada en el archivo hosts de su ordenador (de una prueba anterior antes de una transferencia) produce este efecto: elimine esa línea.
Una trampa relacionada: consultar un nombre nuevo antes de haberlo creado. El resolver recuerda entonces "no existe" (caché negativa) y tarda más en funcionar el nombre nuevo (lección 6.2).
En la práctica: así se ve en un panel
Muchos paneles evitan parte de estos errores. Mi WebOké, por ejemplo, avisa cuando falta el punto final y muestra debajo del campo de nombre el nombre completo; DirectAdmin rechaza los registros que no son válidos con "Error Writing Records". Cloudflare y otras entidades tienen avisos similares. Antes de hacer cambios importantes, haga una copia de seguridad o exporte su zona, así siempre podrá volver atrás.
Resumen
- Empiece siempre por: qué servidores de nombres hay y qué dice el servidor de nombres autoritativo.
- La mayoría de los errores están en el nombre (punto, dominio duplicado) o en el lugar (entidad equivocada).
- Un único registro SPF, ningún CNAME en @, transferir el AAAA junto con el A, MX hacia un nombre con dirección.
- SERVFAIL tras una transferencia suele deberse a un DS antiguo.
- Si solo usted ve la respuesta antigua, es su caché o su archivo hosts.
Cuestionario
Ejercicio
Ejercicio Z8.4: Reconocer errores. Recibirá cinco casos breves con la salida de dig correspondiente (en el entorno del curso). Elija para cada caso cuál de los diez errores es. Después, una búsqueda real: averigüe con dig o una herramienta en línea qué registro falla en dnssec-failed.org (el estado y qué resultado da +cd), y si wikipedia.org tiene exactamente un registro SPF.
Para saber más
Estos artículos describen las soluciones en los paneles de WebOké; en otras entidades los botones se llaman de otra manera.
- La página web o el correo electrónico no funciona tras una migración o un cambio de DNS: compruebe su dominio
- ¿Cuánto tarda un cambio de nameserver o DNS, y qué hacer si no lo ve?
- Manual de DirectAdmin 18.7: Mi dominio todavía no funciona tras una transferencia o modificación
- Manual de DirectAdmin 18.9: Ya no recibo correo electrónico
- Manual de DirectAdmin 5.4: Registros CNAME y el punto final
- No se puede enviar correo desde PHP: los registros MX apuntan a otro lugar
- Utilizar servidores de nombres propios o externos (como Cloudflare) para su dominio