Como funcionan los verificadores de disponibilidad de dominios

Buscas un dominio en dos herramientas diferentes. Una dice "disponible". La otra dice "ocupado". Ambas tienen razón, están consultando fuentes de datos distintas con frecuencias de actualización diferentes. Esto ocurre más de lo que la mayoría de la gente imagina, y entender por qué ayuda a elegir la herramienta correcta para cada situación. Este artículo explica los tres mecanismos principales de verificación de disponibilidad, por qué divergen los resultados, y qué garantiza realmente "disponible" (menos de lo que podrías pensar).

Los tres mecanismos de verificación de disponibilidad

Mecanismo 1: la caché propietaria del registrador

Los grandes registradores como GoDaddy y Arsys mantienen sus propias bases de datos de dominios registrados, sincronizadas periódicamente con el registro oficial. Cuando buscas en su sitio, estás consultando su caché, no el registro directamente.

La ventaja es la velocidad: su caché es local, las respuestas son casi instantáneas. La desventaja es la frescura. Un dominio registrado hace diez minutos podría aparecer como "disponible" en la caché de un registrador si su sincronización todavía no ha corrido. A la inversa, un dominio que venció hace dos horas podría todavía aparecer como "ocupado".

Las cachés de registradores también sirven a un propósito comercial: a menudo muestran dominios como "disponibles a este precio" cuando en realidad son premium o reservados, lo que no es lo mismo que registrable libremente al precio estándar.

Mecanismo 2: WHOIS

WHOIS (RFC 3912) consulta el servidor WHOIS del registro o registrador directamente, sin pasar por una caché local. Los datos son más frescos que una caché propietaria, pero el protocolo tiene problemas significativos.

El más práctico: WHOIS no tiene ningún formato de respuesta estandarizado. La salida WHOIS de Verisign para .com se ve completamente diferente a la de Red.es para .es, que se ve diferente a la de DENIC para .de. Cada parser que procesa respuestas WHOIS tiene que manejar docenas de formatos distintos, y frecuentemente falla en los casos límite.

Los registros también limitan las consultas WHOIS. Para verificaciones masivas, alcanzarás los límites rápidamente.

Mecanismo 3: RDAP

RDAP (Registration Data Access Protocol, RFC 7480/7483) es el sucesor moderno de WHOIS. Es una API REST que devuelve respuestas JSON con estructura estandarizada, eso resuelve completamente el problema del parsing.

La señal de disponibilidad es simple: si un dominio existe en el registro, RDAP devuelve HTTP 200 con los datos del dominio. Si el dominio no existe (lo que significa que está disponible para registrar) RDAP devuelve HTTP 404. No se requiere parsing. Sin ambigüedad.

Los datos RDAP provienen directamente del registro autoritativo. Para .com, es Verisign. Para .es, es Red.es. Sin capa intermedia entre la consulta y la fuente canónica de verdad.

La limitación: RDAP no es universal. La mayoría de los gTLDs (.com, .net, .org, .io, .app, .dev, y la mayoría de los nuevos gTLDs) lo soportan. Pero una gran parte de los ccTLDs (especialmente en Asia, África y Europa del Este) todavía solo ofrecen WHOIS.

Por qué diferentes herramientas dan resultados distintos

La divergencia en los resultados proviene de cuatro fuentes:

• Fuentes de datos diferentes: una herramienta que consulta RDAP y una que consulta una caché de registrador verán cosas distintas en tiempo real. Ninguna está equivocada, leen bases de datos diferentes.
• Retraso de propagación: después de registrar un dominio, el registro necesita unos minutos para actualizar sus datos. Durante esa ventana, algunos verificadores pueden seguir mostrando "disponible".
• Diferencias de interpretación: algunas herramientas definen "disponible" de forma distinta. Un dominio en redemptionPeriod está técnicamente registrado pero no puede transferirse ni usarse, algunos verificadores dicen "ocupado", otros dicen "venciendo".
• Dominios premium y reservados: muchos verificadores no distinguen entre un dominio libremente disponible, un dominio premium (disponible a precio más alto), y un dominio reservado (no disponible para registro estándar).

Qué significa realmente "disponible"

Un verificador que muestra "disponible" no garantiza que el dominio sea registrable cuando hagas clic en "comprar".

Entre la verificación y el intento de registro:

• Alguien más podría registrarlo en los segundos entre tu búsqueda y tu compra.
• El dominio podría estar en un periodo de gracia que un verificador particular no muestra.
• Podría ser un dominio premium a un precio significativamente más alto.
• El registro podría haberlo colocado en una lista reservada.

Para dominios verdaderamente disponibles (HTTP 404 de RDAP sin estado especial), la ventana suele ser corta, segundos a pocos minutos. Para dominios en transición (redención, pending delete), la brecha entre "aparece como disponible" y "registrable ahora mismo" puede ser significativa.

Cómo Domain Sentinel realiza las verificaciones de disponibilidad

Domain Sentinel consulta RDAP primero para todos los TLDs que lo soportan. La consulta va directamente al registro, sin caché intermedia. Para ccTLDs sin RDAP, recurre a WHOIS.

Para la interfaz de búsqueda, esto significa que el resultado mostrado es tan fresco como sea posible, dada la latencia de actualización del propio registro (típicamente segundos a pocos minutos después de un registro o evento de eliminación).

Para el monitoreo de watchlist, Domain Sentinel sondea cada dominio a intervalos regulares y rastrea las transiciones de estado. Cuando un dominio pasa de pendingDelete a 404 (eliminado y disponible), se dispara una alerta.

Límites del enfoque RDAP

Algunos registros limitan las consultas RDAP, lo que puede ralentizar las verificaciones para portfolios muy grandes. Los ccTLDs sin RDAP tienen tiempos de respuesta ligeramente más largos a través de WHOIS, y el parsing de WHOIS ocasionalmente produce fechas de vencimiento incorrectas para formatos de registrador inusuales.

Construir tu propio verificador: las APIs públicas

Para desarrolladores que quieren consultar disponibilidad directamente:

# Proxy universal via rdap.org (enruta automáticamente al registro correcto)
curl -s https://rdap.org/domain/example.com
# HTTP 200 = el dominio existe (registrado)
# HTTP 404 = el dominio no existe (disponible)

# Solo obtener los códigos de estado
curl -s https://rdap.org/domain/example.com | jq '.status'

# Endpoint directo de Verisign para .com (más rápido, sin proxy)
curl -s "https://rdap.verisign.com/com/v1/domain/example.com"

# Red.es para .es
curl -s "https://rdap.nic.es/domain/example.es"

El archivo bootstrap de IANA en https://data.iana.org/rdap/dns.json mapea cada TLD a su endpoint RDAP. Es la lista autoritativa de qué TLDs tienen RDAP y dónde están sus servidores.

Ningún verificador garantiza que un dominio estará disponible en 30 segundos. El enfoque práctico: consultar RDAP directamente (o usar una herramienta que lo haga), actuar rápido cuando encuentres algo que quieres, y añadir a la watchlist todo lo que no puedas registrar de inmediato.