Qué significa cada comprobación y cómo arreglarla.

Zona padre y delegación

Servidores de nombres del padre

Antes de que nadie pueda llegar a tus servidores de nombres, un servidor de la zona padre — el registro de tu extensión — tiene que apuntar a ellos. Consultamos directamente a uno de esos servidores del registro, así que el resultado es la delegación tal y como la recibe internet, no una copia cacheada.

Delegación en el registro

Los registros NS almacenados en el registro. Si faltan, el dominio no resuelve en ninguna parte, por bien configurados que estén tus servidores: comprueba que el dominio esté registrado, pagado y no en estado «hold».

Número de servidores de nombres

Dos es el mínimo que exigen los estándares, tres o cuatro es cómodo. Uno significa que cualquier ventana de mantenimiento saca tu dominio de internet. Más de siete solo agranda las respuestas de referencia.

Registros glue

Si tus servidores de nombres viven dentro del dominio al que sirven (ns1.ejemplo.com sirviendo ejemplo.com), el registro debe publicar además sus direcciones IP. Sin ese glue, un resolver tendría que preguntarle a ejemplo.com dónde está ejemplo.com — un bucle irresoluble. El glue se añade en tu registrador, en la misma pantalla que los servidores de nombres.

El registro y la zona coinciden

La lista de NS del registro y los registros NS de dentro de tu zona deben ser idénticos. Cuando difieren, unos resolvers usan una lista y otros la otra, y los problemas aparecen al azar para una parte de tus visitantes.

Registro del dominio (RDAP)

El registrador, las fechas de creación y caducidad y el estado en el registro, leídos por RDAP, el sucesor estructurado de WHOIS. Los estados que contienen «hold» o «redemption» significan que el dominio ha dejado de resolver por motivos administrativos, normalmente una renovación impagada.

Servidores de nombres

Servidores que responden

Cada servidor delegado se consulta directamente, paquete a paquete, desde nuestra red. La tabla muestra las direcciones usadas, el tiempo de ida y vuelta, el número de serie que informa cada servidor y si responde de forma autoritativa.

Todos los servidores de nombres responden

Los resolvers eligen un servidor de nombres más o menos al azar. Un servidor caído no rompe tu dominio, lo vuelve intermitentemente lento: una parte de las consultas espera a que expire el tiempo de espera antes de probar con otro. Retira de la delegación los servidores que ya no existen.

Respuestas autoritativas

Una respuesta autoritativa lleva la marca AA. Un servidor delegado que responde sin ella no aloja la zona — un resto clásico tras una migración, o una zona que nunca se creó en ese servidor.

El serie SOA está sincronizado

Los servidores secundarios copian la zona cuando crece el número de serie. Series distintas significan que una transferencia está fallando y que algunos servidores responden con una versión antigua de tu zona. Revisa los registros del principal, la lista de notificaciones y las ACL de transferencia.

Los registros NS son idénticos

Todos tus servidores deberían publicar el mismo conjunto de NS. Las diferencias suelen significar que se editó a mano el fichero de zona en un solo servidor.

La recursión está desactivada

Un servidor autoritativo debe responder solo por sus propias zonas. Si además resuelve nombres arbitrarios para cualquiera, puede usarse para amplificar ataques de denegación de servicio contra terceros y acabará en listas de abuso. Desactiva la recursión o restríngela a tus propias redes.

DNS sobre TCP

El TCP no es un plan B, es obligatorio. Las respuestas grandes — firmas DNSSEC, registros TXT largos, muchas direcciones — no caben en un paquete UDP, y un cortafuegos que solo permite el puerto 53 por UDP las rompe en silencio.

Soporte de EDNS(0)

EDNS permite a un resolver anunciar que acepta respuestas más grandes y que entiende DNSSEC. Los servidores o equipos intermedios que descartan consultas EDNS provocan resoluciones lentas y son incompatibles con la validación moderna.

Los servidores de nombres no son alias

Un registro NS debe apuntar a un nombre que tenga registro de dirección. Apuntarlo a un CNAME está prohibido por los estándares y algunos resolvers lo rechazan sin más.

Direcciones públicas

Un servidor de nombres publicado con una dirección privada (10.x, 192.168.x, 172.16-31.x) es inalcanzable desde internet y filtra tu direccionamiento interno.

Diversidad de redes

Dos servidores de nombres en el mismo bastidor, en el mismo conmutador y en la misma /24 caen juntos. La redundancia real significa redes distintas, idealmente proveedores distintos y ciudades distintas.

Servidores de nombres accesibles por IPv6

Al menos un servidor de nombres debería tener registro AAAA. Las redes móviles son cada vez más solo IPv6 y llegan a los servidores solo IPv4 a través de un traductor, lo que añade latencia a cada consulta.

Tiempo de respuesta

Medido desde nuestros servidores, así que las cifras absolutas dependen de la distancia. Lo que importa es la dispersión: un servidor mucho más lento que el resto ralentizará a una parte de tus visitantes.

DNS inverso de los servidores de nombres

Informativo. Los nombres inversos ayudan a los operadores a identificar tus servidores en los registros y en los avisos de abuso.

Registro SOA

El registro Start Of Authority guarda la identidad de la zona: el servidor principal, la dirección de contacto, el número de versión y los temporizadores que obedecen los servidores secundarios y los resolvers.

Servidor principal (MNAME)

El servidor considerado la fuente de verdad de la zona. Normalmente aparece también como registro NS; un principal oculto es una excepción legítima, pero entonces hay que apuntar las actualizaciones dinámicas a otro sitio de forma explícita.

Contacto de la zona (RNAME)

La dirección de correo de quien mantiene la zona, escrita con un punto en lugar del signo @: hostmaster.ejemplo.com significa hostmaster@ejemplo.com. Debería ser una dirección que alguien lea de verdad.

Número de serie

La versión de la zona. Debe aumentar con cada cambio; si no, los secundarios nunca copian la actualización. La convención AAAAMMDDnn deja a la vista de un vistazo la fecha de la última edición.

Refresco, reintento, expiración y mínimo

Refresco: cada cuánto comprueba un secundario si hay un serie nuevo. Reintento: cuánto tarda en volver a intentarlo tras un fallo, siempre menos que el refresco. Expiración: cuánto tiempo sigue sirviendo la zona un secundario mientras el principal está inaccesible — días, no minutos, o una caída corta tumbará tu dominio. Mínimo: cuánto tiempo cachean los resolvers el hecho de que un nombre no existe.

Valores de TTL

El TTL es el tiempo durante el cual los resolvers pueden reutilizar una respuesta. Los valores muy cortos multiplican las consultas y añaden latencia; los muy largos hacen lentas las migraciones. Una hora es un buen valor por defecto, bajado a unos minutos el día antes de un cambio planificado.

Registros web y de direcciones

Dirección del dominio

Los registros A y AAAA del dominio a secas, sin www. Si faltan, escribir ejemplo.com en el navegador no lleva a ninguna parte aunque www.ejemplo.com funcione.

Sin CNAME en el ápex de la zona

Un CNAME no puede convivir con otros registros, y el ápex siempre tiene registros SOA y NS, así que un CNAME ahí es inválido y rompe las búsquedas de correo y de servidores de nombres. Los proveedores ofrecen registros ALIAS, ANAME o CNAME aplanado justo para este caso.

Subdominio www

Publica tanto el dominio a secas como www, y redirige uno al otro en el servidor web. Los visitantes y quienes enlazan usan ambas formas, prefieras la que prefieras.

IPv6 (AAAA)

Un registro AAAA hace que tu sitio sea accesible de forma nativa por IPv6. La mayoría de CDN y paneles de hosting lo activan con un interruptor.

Registro HTTPS (SVCB)

Un tipo de registro más reciente que le dice al navegador, antes de la primera conexión, que el sitio habla HTTPS y qué versiones del protocolo admite. Elimina la redirección inicial en texto plano y es imprescindible para Encrypted Client Hello.

Registro comodín

Un comodín responde por cualquier nombre que no exista. Es cómodo en instalaciones multiinquilino, pero oculta erratas, rompe el cacheo negativo y dificulta detectar un secuestro de subdominio.

El servidor web responde

Una petición HTTP al dominio, para que una configuración DNS perfecta delante de un servidor web caído no se informe como saludable. No afecta a la puntuación DNS.

Entrega de correo

Registros MX

Adónde se entrega el correo de tu dominio, por orden de prioridad: primero se prueba el número más bajo. Si un dominio nunca recibe correo, publica un MX nulo (prioridad 0, destino «.») para que los remitentes fallen de inmediato en lugar de encolar durante días.

Redundancia de servidores de correo

Un segundo MX en otro proveedor mantiene el correo en cola en vez de rebotarlo mientras tu servidor principal está caído. Ojo: un MX de respaldo también debe saber qué buzones existen, o se convierte en un relé de spam.

Los servidores MX resuelven

Un destino MX debe resolver a una dirección. Una errata aquí hace que rebote todo el correo enviado a tu dominio.

Los servidores MX no son alias

Un registro MX debe apuntar a un nombre con registro de dirección, nunca a un CNAME. Varios servidores de correo rechazan directamente esos dominios.

DNS inverso de los servidores de correo

Los servidores receptores comprueban que la IP remitente tenga registro PTR y que coincida con el nombre con el que el servidor se presenta. No tener PTR es una de las formas más rápidas de acabar en la carpeta de spam. El PTR lo crea quien posee la dirección IP: tu proveedor de hosting.

DANE / TLSA

Un registro TLSA publica el certificado que presentará tu servidor de correo, validado mediante DNSSEC. Hace imposibles los ataques de degradación sobre SMTP y exige una zona firmada.

Listas de bloqueo (DNSBL)

Tus direcciones de correo y web se comprueban contra listas públicas antispam. Aparecer en una significa que muchos receptores rechazan o filtran los mensajes; cada lista publica su propio procedimiento de retirada.

Autenticación del correo

SPF

Un registro TXT que lista los servidores autorizados a enviar correo con tu dominio en el sobre. Solo se permite un registro SPF, y evaluarlo puede costar como máximo diez consultas DNS: cuenta cada include, a, mx y redirect, incluidos los que hay dentro del registro de tu proveedor. Termina con -all (rechazar) o ~all (marcar), nunca con +all.

DKIM

Tu servidor de correo firma cada mensaje con una clave privada; la mitad pública vive en el DNS bajo selector._domainkey. A diferencia de SPF, la firma sobrevive a los reenvíos. Cada proveedor elige sus selectores, así que probamos los habituales — que aquí no aparezca nada no demuestra que DKIM esté desactivado.

DMARC

Publicado en _dmarc.ejemplo.com, indica a los receptores qué hacer cuando SPF y DKIM fallan, y adónde enviar los informes. Empieza en p=none con una dirección rua, lee los informes durante unas semanas y pasa después a cuarentena y finalmente a rechazo. Sin DMARC, cualquiera puede enviar correo como tu dominio.

MTA-STS

Un registro TXT más un fichero de política servido por HTTPS en mta-sts.example.com. Indica a los demás servidores de correo que el TLS es obligatorio para tu dominio, lo que impide que un atacante elimine el cifrado entre servidores.

TLS-RPT

La cara de informes de MTA-STS y DANE: los remitentes te envían por correo un resumen diario de las conexiones TLS fallidas, para que un certificado roto no pase inadvertido durante semanas.

BIMI

Publica tu logotipo para que los buzones compatibles lo muestren junto a los mensajes autenticados. Exige antes DMARC en cuarentena o rechazo, y algunos proveedores piden además un certificado de marca verificada.

Seguridad

DNSSEC

DNSSEC firma tu zona para que los resolvers detecten respuestas falsificadas. Necesita dos mitades: las firmas publicadas por tus servidores de nombres (DNSKEY, RRSIG) y un registro DS subido al registro. Un DS sin zona firmada es peor que no tener DNSSEC: los resolvers validadores se negarán a resolver tu dominio por completo.

CAA

Un registro CAA nombra las autoridades de certificación autorizadas a emitir certificados para tu dominio. Las autoridades están obligadas a consultarlo, así que es una forma barata de impedir que se emita un certificado en otro sitio. Añade una entrada iodef para que te avisen cuando alguien lo intente.

Transferencia de zona (AXFR)

Una transferencia de zona entrega todos los registros que tienes. Abierta al mundo es un mapa gratuito de tu infraestructura: equipos internos, servidores de pruebas, sistemas de copia de seguridad. Restringe las transferencias a tus servidores secundarios, idealmente con una clave TSIG.

Divulgación de la versión del software

Los servidores de nombres responden por defecto a una consulta especial con su versión de software. Ocultarla no arregla nada por sí sola, pero evita que tus servidores aparezcan en escaneos automáticos que buscan una versión vulnerable concreta.

Registros TXT

Los tokens de verificación se acumulan durante años. Los antiguos agrandan cada respuesta, pueden empujarlas más allá del límite de UDP y a veces mantienen autorizado sobre tu dominio a un servicio abandonado.