Consulta Whois

El protocolo WHOIS (RFC 3912) fue definido en 1982 y utiliza texto plano sin estructura sobre TCP puerto 43. Sus limitaciones han motivado el desarrollo de RDAP como su sucesor: • Formato estructurado — WHOIS devuelve texto libre cuyo formato varia entre registradores (cada uno usa su propia plantilla). RDAP devuelve JSON con un esquema definido por RFC 9083, lo que permite parsing automatizado confiable. Los campos como status, events, nameservers y entities tienen estructura predecible y tipada. • Estandarización completa — RDAP está definido por cinco RFCs complementarios: RFC 7480 (transporte HTTP), RFC 7481 (seguridad y autenticación), RFC 7482 (formato de consultas), RFC 7483/9083 (formato de respuestas JSON), y RFC 7484 (bootstrap de servicios vía IANA). Esto contrasta con WHOIS, que tiene un único RFC minimalista sin especificación de formato de respuesta. • Acceso autenticado — RDAP soporta autenticación HTTP, permitiendo a registradores ofrecer acceso diferenciado (datos completos para usuarios autenticados, datos redactados para acceso anonimo). WHOIS no tiene mecanismo de autenticación nativo. • Internacionalización — RDAP soporta IDN (Internationalized Domain Names) de forma nativa, nombres de contacto en Unicode, y Content-Language en las respuestas. WHOIS esta limitado a ASCII de 7 bits. • Descubrimiento automático — RDAP utiliza el bootstrap service de IANA (RFC 7484) para determinar automáticamente que servidor RDAP es autoritativo para cada TLD. Con WHOIS, el cliente debe mantener una lista actualizada de servidores por TLD. • ICANN obligo a todos los registradores gTLD a soportar RDAP desde 2019, y el cierre del servicio WHOIS tradicional para gTLDs esta en proceso de implementación gradual. Para ccTLDs, la migración varia por país.

Los códigos de estado EPP (Extensible Provisioning Protocol, RFC 5731) definen el estado operativo de un dominio. Se dividen en códigos del cliente (client*) establecidos por el registrador a solicitud del registrante, y códigos del servidor (server*) establecidos por el registro (registry): • clientTransferProhibited / serverTransferProhibited — Impide la transferencia del dominio a otro registrador. Es la protección principal contra secuestro de dominios (domain hijacking). Todos los dominios críticos deben tener este status activo. • clientDeleteProhibited / serverDeleteProhibited — Impide la eliminación del dominio. Protege contra borrado accidental o malicioso por parte de un actor con acceso a la cuenta del registrador. • clientUpdateProhibited / serverUpdateProhibited — Impide cambios en los registros del dominio (NS, contactos, DNSSEC). Cuando está activo, no se pueden modificar los servidores de nombres ni los datos de contacto sin que el registrador lo desactive primero. • clientHold / serverHold — Instruye al registro a no incluir el dominio en la zona DNS. El dominio deja de resolver efectivamente. serverHold se aplica típicamente por falta de pago, disputas legales (UDRP), o violaciones de políticas. • Ciclo de vida completo del dominio: Registro disponible → Activo (ok/clientTransferProhibited) → Expiración → Auto-Renew Grace Period (0-45 días, varia por registrador) → Redemption Grace Period (30 días, el registrante puede recuperar el dominio pagando una tarifa elevada) → Pending Delete (5 días, irreversible) → Eliminación y disponibilidad pública. Los dominios premium o de alto valor pueden ser capturados por servicios de drop catching en milisegundos tras la eliminación. • El estado ok (también visible como active) indica que no hay restricciones especiales. Si aparece junto con otros códigos client*, los códigos restrictivos tienen precedencia. Un dominio saludable y protegido típicamente muestra: clientTransferProhibited, clientDeleteProhibited y clientUpdateProhibited.

La información de registro de dominios se ve afectada por regulaciones de privacidad y tecnologias de seguridad: • Redacción por GDPR — Desde la implementación del GDPR (mayo 2018), los registradores de gTLDs están obligados a redactar datos personales de contacto (nombre, dirección, teléfono, email del registrante) en respuestas WHOIS/RDAP públicas. Los campos redactados aparecen típicamente como "REDACTED FOR PRIVACY" o "Data Protected". El acceso a datos completos requiere solicitud formal al registrador con justificación legal (por ejemplo, vía el ICANN Registration Data Request Service). Los ccTLDs aplican sus propias regulaciones de privacidad, que pueden ser más o menos restrictivas que el GDPR. • Servicios de privacidad Whois — Antes del GDPR, los servicios de Privacy/Proxy sustituian los datos del registrante por los de una entidad intermediaria. Hoy son menos necesarios para gTLDs (la redacción es obligatoria), pero siguen siendo útiles para ccTLDs sin protección de privacidad nativa, y para ocultar la identidad del registrador ante competidores o scrapers que correlacionan dominios por registrante. • DNSSEC en el registro — La consulta RDAP muestra si el dominio tiene DNSSEC habilitado a nivel de registro (presencia de registros DS delegados al TLD). DNSSEC protege la integridad de las respuestas DNS: sin el, un atacante que controle la ruta de red puede falsificar respuestas DNS y redirigir el dominio a una IP maliciosa. La verificación de DNSSEC en RDAP confirma que el registro DS existe en la zona del TLD; para verificar la cadena completa de firmas se necesitan consultas DNS directas. • Información útil para investigación de seguridad — Incluso con redacción GDPR, los datos RDAP públicos son valiosos: las fechas de creación y actualización revelan la antiguedad del dominio (dominios recien registrados son indicadores de phishing), los servidores de nombres y registrador ayudan a correlacionar infraestructura maliciosa (threat intelligence), los códigos EPP revelan el nivel de protección del dominio, y la fecha de expiración permite identificar dominios en riesgo de expiración inminente y posible domain squatting.