Resumen

  • En su laboratorio, Autonomica no encontró comportamientos inesperados al añadir etiquetas IDN de nivel superior a una raíz simulada y consultarlas con determinados programas DNS.
  • ICANN aclaró que el ensayo no usó una raíz en producción ni estudió la experiencia de los usuarios: servía para informar sobre compatibilidad, no para aprobar un nombre o decidir quién debía usarlo.

Una etiqueta de nivel superior es breve, pero añadirla a la raíz modifica los destinos a los que puede remitir el DNS público. En 2006, el plan de pruebas de ICANN separó dos cuestiones que suelen mezclarse: si el software DNS podía transportar etiquetas internacionalizadas en un entorno semejante a la raíz y si las aplicaciones harían que esas etiquetas fueran utilizables para las personas. La primera cuestión se llevó al laboratorio. La segunda se planteó como una fase distinta, no como algo que el primer resultado pudiera certificar.

Tina Dam estuvo cerca del programa, pero no fue autora del experimento. La biografía de archivo de ICANN la identifica como directora sénior de IDN, responsable de desarrollar y gestionar proyectos relacionados con nombres internacionalizados, incluido el Fast Track para dominios de país. El anuncio de 2007 la señala como contacto del ensayo; el informe lo firma Lars-Johan Liman, de Autonomica AB. Cuando ICANN presentó el Fast Track en 2009, Dam habló de años de borradores, pruebas y trabajo voluntario. Es evidencia de su papel de dirección, no de que diseñara o ejecutara personalmente cada ensayo. (Biografía de ICANN; anuncio de la prueba de 2007; anuncio del lanzamiento de 2009)

El montaje fue concreto. Tras contratar a Autonomica en octubre de 2006, ICANN publicó un borrador para comentarios. En Estocolmo, Autonomica conectó dos servidores raíz, un servidor de dominio de nivel superior, resolutores iterativos y un generador de consultas. La zona raíz partió de una copia de la zona activa a la que se añadieron delegaciones de prueba. Los servidores raíz ejecutaban BIND 9.3.2 y NSD 2.3.5; el conjunto de resolutores incluía varias versiones de BIND y Microsoft DNS de Windows 2000 y 2003. El equipo siguió consultas DNS ordinarias y buscó respuestas erróneas o demoras inesperadas. En los casos probados, el informe registra resultados previstos y ninguna demora inusual. (Plan de pruebas de diciembre de 2006; informe de Autonomica)

El resultado redujo una incertidumbre precisa: el software seleccionado manejó las delegaciones añadidas en ese entorno simulado. No demostró nada sobre todos los resolutores, dispositivos, navegadores, tablas lingüísticas o procesos de registro. El informe limita expresamente su alcance a las implementaciones que pudo probar. En marzo de 2007, ICANN trazó otra frontera: el ensayo no se hizo con una raíz en producción y no incorporó la perspectiva del usuario final. El plan anterior había previsto una fase aparte para aplicaciones e interfaces. Por tanto, una respuesta correcta del servidor no mostraba qué vería alguien al escribir o seguir un nombre internacionalizado. (Anuncio de la prueba de ICANN)

El laboratorio tampoco podía elegir un nombre. El Fast Track de 2009 exigía más que compatibilidad técnica: el anuncio mencionó el apoyo del gobierno y la comunidad, además de una evaluación de estabilidad. El proceso actual sigue separando la evaluación de la cadena —si representa a un país o territorio que cumple los requisitos— de su delegación, la solicitud posterior para operar la cadena aprobada y añadirla a la raíz. Una prueba puede aportar evidencia a una etapa sin convertirse en la decisión. (Sistema de solicitudes Fast Track)

El protocolo establece otra frontera. IDNA distingue la etiqueta Unicode U-label de su forma ASCII compatible A-label; esa relación no garantiza que todas las interfaces la muestren o acepten igual. Los documentos posteriores de IDNA2008 especifican el registro y la búsqueda, pero dejan fuera de su alcance algunos procesos previos de los registradores. El registro público de Dam también la sitúa entre el personal de ICANN que apoyó en 2010 la revisión de las pautas IDN en un grupo con varios sectores. Por eso “la prueba de la raíz salió bien” no basta: compatibilidad técnica, cadenas admisibles, delegación y experiencia real de usuario requieren comprobaciones distintas. (RFC 5890; RFC 5891; borrador de las pautas IDN de 2010)

Fuentes