Resumen

  • ARIN consulta hasta el 14 de septiembre de 2026 sobre retirar Whois-RWS, RWhois y Whois sobre el puerto 43 en favor de RDAP; las fechas siguen siendo propuestas, no decisiones de cierre.
  • Cada servicio tiene una dependencia distinta: paridad de API y web para Whois-RWS, herramientas de conversión para RWhois y una ventana propuesta de retirada de dos años, acompañada de divulgación, para el servicio del puerto 43, de uso intenso.
  • El control duradero debería ser tres puertas de salida basadas en evidencias, no una declaración agregada de que RDAP está listo.

Una migración de directorio puede parecer completa desde el servidor y seguir rota en el recorrido que importa. Un punto final de reemplazo puede devolver el registro correcto, mientras un script de respuesta a incidentes nunca llega a descubrirlo. Un servicio local de reasignación puede carecer de una ruta de conversión probada. Un dispositivo de seguridad puede seguir esperando texto plano por el puerto 43 y fallar silenciosamente cuando desaparece esa suposición.

Por eso, la consulta de ARIN sobre el futuro de sus servicios de directorio se entiende mejor como tres migraciones con un destino común. ARIN abrió la consulta el 14 de agosto y solicita comentarios hasta las 17:00 ET del 14 de septiembre. En el cierre informativo del 4 de septiembre, la consulta seguía abierta. Ninguna fecha propuesta de retiro era un cierre adoptado o completado.

Un estándar, tres mapas de dependencias

La norma STD 95 del IETF define para RDAP el transporte HTTP, los servicios de seguridad, formatos uniformes de consulta, respuestas JSON estructuradas y el descubrimiento del servicio autoritativo. ARIN sostiene que la consolidación puede reducir la superficie de ataque y la carga administrativa, además de mejorar la estandarización y la automatización. ARIN espera también que los clientes RDAP sean más habituales en las distribuciones de sistemas operativos.

Esas ventajas no hacen intercambiables a los servicios heredados. Whois-RWS ofrece una API y una interfaz web. ARIN propone un programa de divulgación de 180 días y retirar la API no antes del 1 de julio de 2027. La URL web permanecería hasta que la paridad de funciones respaldada por RDAP permita un cambio transparente.

RWhois se sitúa en el lado de la publicación. Algunas organizaciones lo usan para exponer información de reasignación desde sus propios servidores. ARIN afirma que recomendaría un servidor RDAP de código abierto y proporcionaría una herramienta para convertir los datos de RWhois. Solo después de que esa herramienta esté disponible comenzaría un cierre gradual propuesto de 365 días, con retiro no antes del 1 de enero de 2028.

El puerto 43 plantea el problema de descubrimiento más amplio. ARIN dice que todavía transporta un volumen elevado de consultas y que lo utilizan profesionales de ciberseguridad, investigadores y fuerzas del orden. La fecha propuesta es no antes del 1 de enero de 2029, tras dos años de transición y divulgación.

Una fecha no es una prueba de salida

Los tres servicios requieren evidencias distintas: equivalencia de API para Whois-RWS, herramientas de publicación y migración para RWhois, y descubrimiento de clientes y migración de automatización para el puerto 43. Una fecha del calendario no demuestra por sí sola que los usuarios dependientes hayan encontrado y probado el reemplazo.

Para Whois-RWS, la prueba debe abarcar consultas comunes, referencias, errores, límites de tasa y automatización. Para RWhois, debe demostrar que los operadores pueden trasladar datos y autoridad, con resultados reproducibles, una vía de reversión y tiempo suficiente para probar el servidor recomendado.

En el puerto 43, clientes no autenticados, scripts, productos de seguridad y flujos de investigación pueden no aparecer en ningún inventario. Los avisos y la divulgación ayudan, pero la preparación también exige observar la caída del uso, publicar ejemplos de migración y distinguir el tráfico abandonado de los clientes esenciales que aún no se han trasladado.

Según el análisis de BTW, el intercambio económico es asimétrico: mantener servicios redundantes indefinidamente consume capacidad de seguridad y mantenimiento, pero retirarlos demasiado pronto puede trasladar costes mucho mayores a los flujos de trabajo dependientes. El calendario aún puede corregirse; eliminar la última vía de respaldo es el paso difícilmente reversible.

Siguen sin conocerse el resultado de la consulta, las fechas finales, la política de excepciones, las bases de uso, los presupuestos de error, los criterios de paridad y los activadores de reversión. También se desconoce cuántos scripts y dispositivos no se identifican o no pueden adoptar RDAP sin cambios del proveedor.

Fuentes