Validador de nombres de dominio (comprobación de conformidad RFC)

Comprueba si un nombre de dominio cumple las reglas de sintaxis de RFC 1035/1123. Valida individualmente la longitud de cada etiqueta, la longitud total, los caracteres permitidos y la posición de los guiones, mostrando el motivo concreto de cualquier infracción.

Qué es el validador de nombres de dominio

El validador de nombres de dominio descompone la comprobación de si una cadena introducida cumple las reglas de sintaxis de nombres de dominio definidas en RFC 1035 (publicada en 1987) y RFC 1123 (publicada en 1989), evaluando cada regla de forma individual en lugar de devolver un único veredicto de «válido o no válido». Como muestra exactamente qué regla se ha infringido y, cuando corresponde, qué etiqueta (cada una de las partes de un dominio separadas por puntos) ha causado el fallo, resulta especialmente útil cuando ya sabes que una cadena de dominio está siendo rechazada en algún sitio pero no sabes por qué.

Es importante entender qué es lo que esta herramienta no hace: solo comprueba la sintaxis, es decir, la forma de la cadena como texto. No consulta el DNS para confirmar que el dominio esté realmente registrado, no verifica si hay un sitio web funcionando en esa dirección y no indica si el nombre está disponible para registrarse. Esto la hace muy adecuada para confirmar que un nombre candidato para un dominio nuevo, o un nombre de host que estás incorporando a un archivo de configuración, tiene una sintaxis correcta antes de dar el paso adicional de registrarlo o desplegarlo.

Cómo usar el validador de nombres de dominio

  1. Introduce un nombre de dominio Escribe en el campo de entrada el nombre de dominio que quieres comprobar (por ejemplo, example.com). Elimina primero cualquier protocolo inicial como `https://` o ruta final como `/path`, de modo que solo quede la parte del dominio.
  2. Revisa el resultado de la validación En cuanto escribes, se evalúan seis reglas en tiempo real y cada una se etiqueta como Correcto, Error o Aviso.
  3. Lee el motivo de cualquier fallo Cada fila marcada como Error incluye un motivo concreto, como la etiqueta problemática o su número de caracteres, para que veas exactamente qué parte de la cadena hay que cambiar.
  4. Prueba los botones de ejemplo para ver los casos límite Los botones Ejemplo válido y Ejemplo no válido rellenan el campo con cadenas de muestra situadas justo en los límites de las reglas, para que veas rápidamente cómo se comporta cada una.

Consejos para aprovecharla mejor

  • Esta herramienta valida según las reglas de sintaxis definidas en RFC 1035/1123; no comprueba si el dominio está realmente registrado ni si se puede resolver mediante DNS.
  • Antes de escribir tu propia expresión regular de validación para un formulario, prueba esta herramienta con los casos límite (exactamente 63 caracteres, posición de guiones, etc.) para asegurarte de que tu implementación los cubre.
  • Las entradas con caracteres no ASCII, como los nombres de dominio en japonés, solo omiten la comprobación del conjunto de caracteres. Conviértelos primero a notación `xn--` con el conversor de Punycode para una comprobación totalmente precisa.
  • Un TLD completamente numérico casi nunca ocurre en la práctica, pero se incluye deliberadamente para detectar entradas que podrían confundirse con una dirección IP durante la validación de formularios.
  • El mismo conjunto de reglas puede aplicarse a la parte de una dirección de correo electrónico posterior al símbolo `@`, por lo que también sirve como una comprobación ligera del dominio del correo.

Cuándo usar esta herramienta

Comprobar una expresión regular de validación antes de publicarla

Antes de escribir tu propia expresión regular para validar un campo de dominio, prueba aquí los casos límite —una etiqueta de exactamente 63 caracteres, un guion justo al inicio o al final— para detectar cuanto antes los huecos de tu implementación.

Comprobar de antemano un nombre candidato para un dominio nuevo

Cuando estás decidiendo el nombre de un nuevo servicio o de un subdominio, puedes confirmar que es sintácticamente correcto incluso antes de buscarlo en un registrador.

Verificar de forma puntual la parte de dominio de una dirección de correo

Como la parte de una dirección de correo electrónico posterior al símbolo @ suele seguir las mismas reglas de nombre de host, esta herramienta también sirve como comprobación secundaria ligera para tu lógica de validación de correos.

Investigar por qué se rechazó una cadena

Si un sistema marca una cadena como «nombre de dominio no válido» y no resulta evidente el motivo, pégala aquí para identificar exactamente qué regla incumple.

Glosario

Etiqueta
Cada uno de los segmentos de un nombre de dominio separados por puntos. En www.example.com hay tres etiquetas: «www», «example» y «com». RFC 1035 establece sus límites de longitud y caracteres a nivel de etiqueta, no del dominio en conjunto.
TLD (dominio de nivel superior)
La etiqueta situada más a la derecha de un nombre de dominio, como .com o .es. Se encuentra en la cima de la jerarquía del DNS, justo debajo de la raíz invisible.
FQDN (nombre de dominio totalmente cualificado)
Un nombre de dominio escrito por completo desde el nombre de host hasta el TLD, sin omitir ninguna parte. Estrictamente, un FQDN termina con un punto final que representa la raíz del DNS (por ejemplo, example.com.), aunque en el uso cotidiano ese punto final suele omitirse.
IDN (nombre de dominio internacionalizado)
Un nombre de dominio que contiene caracteres no ASCII, como japonés, chino o escritura árabe. Como el propio DNS solo puede manejar caracteres ASCII, un IDN se convierte a Punycode antes de registrarse o resolverse de verdad.
Punycode
Un sistema de codificación que convierte la parte no ASCII de un IDN en una cadena ASCII que el DNS puede manejar, con el prefijo xn--. Los navegadores suelen volver a mostrar los caracteres originales en la barra de direcciones.
Formato de transmisión
El formato binario en el que las consultas y respuestas DNS se intercambian realmente por la red. Cada etiqueta va precedida de un único byte que indica su longitud, y ese byte solo puede representar valores del 0 al 63, lo que constituye el origen técnico del límite de 63 caracteres por etiqueta.
Nombre de host
Un nombre usado para identificar un dispositivo en una red. Es un tipo concreto de nombre de dominio, y RFC 1123 restringe los caracteres que puede usar un nombre de host a letras, dígitos y guiones, exactamente el conjunto de reglas que comprueba esta herramienta.

Preguntas frecuentes

Según RFC 1035, cada etiqueta (la parte entre puntos) puede tener de 1 a 63 caracteres, y el dominio total puede tener hasta 253 caracteres (derivado del límite de 255 octetos en el formato de transmisión). Ten en cuenta que los registradores pueden imponer restricciones adicionales por encima de estos límites.

Según RFC 1035/1123, en un nombre de host solo se permiten letras, dígitos y guiones; los guiones bajos no están permitidos. Sin embargo, sí aparecen en etiquetas DNS que no son nombres de host, como los registros TXT o SRV (por ejemplo, `_dmarc.example.com`).

RFC 1123 exige que cada etiqueta empiece y termine con un carácter alfanumérico. Permitir un guion al inicio o al final haría la interpretación ambigua y podría generar problemas de compatibilidad con implementaciones de DNS antiguas.

Los nombres de dominio internacionalizados (IDN) con caracteres como el japonés deben convertirse a Punycode (notación ASCII que empieza por `xn--`) antes de registrarse en el DNS. Como esta herramienta está diseñada para validar la cadena ya convertida a Punycode, conviene convertir primero el dominio no ASCII con el conversor de Punycode y luego ejecutar aquí la comprobación de sintaxis.
Tool-kun

A propósito — Por qué la validación de nombres de dominio se reinventa una y otra vez

Comprobar la sintaxis de un nombre de dominio parece que debería resolverse con una única expresión regular sencilla, y sin embargo es un área en la que muchos desarrolladores han tropezado con sus propias implementaciones. Desde la validación de correos electrónicos en formularios, pasando por el análisis de nombres de host en archivos de configuración, hasta la validación de URL en APIs, las «cadenas parecidas a dominios» aparecen por todas partes, pero las implementaciones que reflejan con precisión las reglas oficiales de RFC 1035 (1987) y RFC 1123 (1989) son sorprendentemente escasas.

El límite de longitud en dos niveles —63 caracteres por etiqueta, 253 en total— proviene directamente del diseño del formato de transmisión del DNS (el formato binario que realmente se intercambia por la red). Cada etiqueta va precedida de un byte que indica su longitud, y ese byte está restringido a un rango de 0 a 63 (el valor máximo representable con 6 bits), lo que es la razón directa del límite de longitud de etiqueta.

La convención de que un TLD no debe ser completamente numérico tiene también una historia interesante. No es una regla exigida por ningún RFC, sino más bien una práctica de implementación ampliamente adoptada para distinguir los nombres de dominio de las direcciones IPv4 (secuencias de dígitos y puntos). Muchos resolutores de DNS y navegadores usan esta convención para decidir que una cadena como 192.168.1.1 debe tratarse como una dirección IP y no como un nombre de dominio.