Resumen

  • Whois 1.123 aplica NFC al Unicode descompuesto de descr: y remarks: antes de sanear caracteres de control y realizar la conversión IDNA.
  • La medida reduce diferencias binarias entre textos canónicamente equivalentes, pero no convierte la entrada, el valor canónico y la salida de cada interfaz en una sola prueba.
  • Un comprobante de normalización puede vincular las tres capas sin publicar texto libre, credenciales ni datos personales.

La letra visible no revela la secuencia

En Ondřej Caletka, el carácter ř puede llegar ya compuesto como U+0159. También puede construirse con r, U+0072, seguido del carón combinante U+030C. Un lector ve el mismo nombre. Una comparación binaria directa encuentra dos cadenas.

El repositorio público de RIPE NCC permite observar el cambio sin especular. El commit incorporado a Whois 1.123 crea una instancia NFC de ICU. La función createUtf8Attribute elimina primero los escapes Java de la entrada, normaliza el valor, recorre los puntos de código resultantes, sanea caracteres de control y, al final, ejecuta la conversión IDNA ya existente.

La prueba añadida es excepcionalmente clara. Envía U+0072 U+030C dentro de un atributo descr: y exige que la cadena resultante tenga longitud uno. Después comprueba que Ondřej Caletka, escrito con la secuencia descompuesta, salga como Ondřej Caletka, con el único punto de código precompuesto.

Las notas de la versión sitúan el despliegue en producción el 8 de julio de 2026. No anuncian una conversión universal de RPSL. Dicen que el Unicode descompuesto se normaliza en descr: o remarks:. La página vigente de codificación confirma que esos son los atributos de texto libre con soporte UTF-8 y que la forma empleada es NFC.

Por qué normalizar es la defensa correcta

Unicode define NFC como descomposición canónica seguida de composición canónica. Su propiedad útil es la unicidad: dos cadenas canónicamente equivalentes producen el mismo resultado NFC. Sin esa regla, el teclado, el editor o la plataforma de origen pueden dejar diferencias binarias permanentes en un texto que debería intercambiarse como equivalente.

Llamar manipulación a toda normalización ocultaría esa ventaja. NFC mantiene la equivalencia canónica; no es una normalización de compatibilidad que borra indiscriminadamente otras distinciones. En un registro usado por herramientas muy diferentes, reducir representaciones equivalentes es una defensa operativa sólida.

RIPE NCC también eligió un alcance prudente. La versión 1.122, puesta en producción el 30 de abril, habilitó UTF-8 solo para descr: y remarks:. La propuesta al grupo de trabajo habla de un cambio mínimo viable: permitir avisos en idiomas locales, aprender de su uso y no afectar nombres, direcciones ni datos personales. Además, recuerda que esos campos libres no deben alojar datos personales.

La exigencia proporcionada no es conservar para siempre toda secuencia descompuesta como valor principal. Es conservar la identidad de la transformación: qué se recibió, qué quedó como representación canónica y qué se entregó al consumidor.

La interfaz vuelve a transformar la prueba

La documentación de RIPE separa dos familias. Whois por el puerto 43, NRTMv3 y los ficheros diarios ordinarios usan Latin-1 por defecto. Cuando un carácter no cabe en una interfaz, se sustituye por ?. La aplicación web, la API REST de Whois, RDAP, NRTMv4, Syncupdates y los ficheros .utf8.gz usan UTF-8 por defecto. El cliente de puerto 43 puede solicitar otro juego de caracteres.

Esa convivencia es comprensible. Un servicio histórico necesita proteger la compatibilidad; los canales modernos deben conservar Unicode. Sin embargo, un objeto capturado en un flujo Latin-1 no es la misma evidencia binaria que el objeto canónico en UTF-8. Un signo de interrogación introducido al exportar tampoco demuestra que el remitente escribiera ese signo.

La diferencia llega a tareas corrientes. Un espejo calcula el hash de lo que recibió. Un operador archiva el acuse de una actualización. Un investigador compara un dump antiguo con una respuesta REST. Si el hash carece de etiqueta de representación, una diferencia de codificación puede parecer una modificación del contenido. Si solo se compara la pantalla, dos entradas distintas pueden parecer idénticas sin revelar que la base las hizo converger.

No hay evidencia pública de que un espejo concreto cometa ese error. Las fuentes tampoco dicen si todos los objetos anteriores a 1.123 se normalizaron de una vez o si cada entrada previa a NFC queda almacenada en otro sistema. La conclusión no depende de inventar esa respuesta: existe una transformación deliberada y la custodia debe indicar qué lado de ella está vinculando.

Un registro mínimo, no otra base de datos pública

El comprobante de actualización puede contener el identificador duradero del objeto y su versión, el acuse de operación, la clase de atributo, la interfaz de entrada y su codificación. Debe nombrar NFC y la versión o commit del software, señalar si cambió la secuencia de puntos de código y registrar por clase cualquier sustitución causada por saneamiento o validez de puntos de código.

La integridad no exige publicar el texto. Un hash abierto de una frase corta y previsible puede facilitar su adivinación. Es preferible un compromiso autenticado, un hash de lote bajo control de acceso o una prueba disponible solo para las partes legitimadas. Ni descr:, ni remarks:, ni las credenciales de actualización tienen que aparecer en el recibo público.

Al consultar o replicar, el registro debe añadir la interfaz, el charset solicitado, la versión de serialización y la huella de la salida exacta. Una relación de sustitución une correcciones posteriores. Así, «enviado», «canónico» y «emitido» dejan de ser sinónimos accidentales.

Nada de esto certifica la afirmación escrita en el objeto. La normalización no prueba quién opera la red, quién posee el recurso o qué ruta está activa. Prueba únicamente la regla que conecta dos representaciones. Esa modestia hace que el comprobante sea útil.

Lo que queda fuera

Las fuentes no documentan un ataque, una caída, un fallo de autorización ni un error de identidad causado por NFC. No muestran que todos los atributos RPSL admitan UTF-8, ni que person:, role:, org-name: o las direcciones se hayan internacionalizado. El commit tampoco responde por sí solo qué ocurrió con cada objeto histórico.

El incidente NRTM de agosto es otro mecanismo: saltos de línea adicionales, un objeto RPSL inválido, la detención del flujo y cambios posteriores en 1.124. No forma parte de este análisis. La continuidad de la réplica y la representación canónica requieren comprobantes distintos.

Fuentes

  1. Notas de versiones de RIPE Database
  2. Codificación de caracteres en RIPE Database
  3. Planes trimestrales archivados de RIPE Database
  4. Actualización operativa del grupo de trabajo de base de datos en RIPE 90
  5. Propuesta de UTF-8 en descr: y remarks:
  6. Mensaje de lanzamiento de Whois 1.122
  7. Análisis de impacto de UTF-8 en RIPE Labs
  8. Commit de RIPE-NCC que normaliza Unicode descompuesto
  9. Versiones publicadas de Whois
  10. Anexo 15 del estándar Unicode