Resumen

  • La RFC 1591 dijo que la IANA establecería el Internet DNS Names Review Board (IDNB) para resolver desacuerdos sobre quién debía gestionar un dominio de nivel superior; sus decisiones serían vinculantes.
  • En 2017 y 2024, documentos del ccNSO afirmaron que el IDNB nunca se creó. Una política distinta de revisión de ccTLD, con resultados no vinculantes, se aprobó en 2025; el informe ICANN86 de mayo de 2026 aún la situaba en fase de planificación de implementación.

Una frase de la RFC 1591 parece ofrecer la última palabra. Si dos partes que querían gestionar un dominio de nivel superior no lograban un acuerdo, el Internet DNS Names Review Board actuaría como panel de revisión. Sus decisiones serían vinculantes. Jon Postel incluyó esa previsión en marzo de 1994, dentro de un memorando sobre la estructura y la delegación del Sistema de Nombres de Dominio.

El comité llama la atención porque el documento no era únicamente una lista de requisitos técnicos. También describía una forma de resolver el desacuerdo sobre quién debía administrar un dominio. Sin embargo, documentos posteriores del ccNSO dicen que la IANA nunca estableció el IDNB y que tampoco lo creó otra entidad. El texto describía una institución prevista, no una organización que se hubiera puesto en marcha.

La RFC se identificaba como informativa y aclaraba que no establecía un estándar de Internet. Describía a la IANA como responsable de la coordinación general del DNS, mientras el Internet Registry central —entonces InterNIC— asumía buena parte de la administración cotidiana. Cada dominio debía tener un gestor designado, con servidores de nombres operativos, contacto administrativo en el país para un ccTLD y capacidad técnica para prestar el servicio.

Ese gestor era un custodio, no el dueño del dominio. La RFC decía que debía servir tanto a la comunidad nacional como a la comunidad global de Internet; los debates sobre propiedad eran inapropiados frente a las responsabilidades y el servicio. También exigía igualdad de trato: mismas reglas para las solicitudes, sin favorecer a los clientes de un proveedor de red relacionado con el gestor. Los subdominios podían operar sus propios servidores si los datos publicados eran correctos.

La participación entraba en juego al elegir al gestor. Las partes “significativamente interesadas” debían estar de acuerdo con que el candidato fuese apropiado. La IANA debía intentar que los contendientes alcanzaran un acuerdo y, en general, no cambiar una delegación establecida sin el consentimiento de todos, salvo mala conducta grave del gestor. Las partes interesadas debían tener “alguna voz”. Pero, si no había acuerdo o un solicitante no podía representar a todo el país, la IANA y el registro central podían delegar solo una parte del dominio. Para resolver el conflicto, la RFC nombraba al IDNB como panel con decisiones vinculantes.

La secuencia distinguía la voz de las partes de la autoridad para decidir. Ser escuchado no resolvía automáticamente un conflicto. El gestor tenía obligaciones operativas y la IANA conservaba la coordinación general descrita por el memorando. El IDNB debía ofrecer el paso decisorio cuando fracasaba el consenso. Por eso importa saber si llegó a existir: sin el panel, el procedimiento escrito no tenía el destino previsto.

En junio de 1996, otro texto de Postel reutilizó la idea en una propuesta para nuevos dominios internacionales, como COM, ORG y NET. El Internet-Draft ampliaba la función del IDNB a recursos técnicos contra el proceso propuesto y repartía responsabilidades entre IANA, IETF, ISOC y un grupo ad hoc. Pero el Datatracker lo clasifica como un borrador individual, no respaldado por el IETF y sin valor formal en su proceso de estándares. Expiró en diciembre de 1996. Es evidencia de que el concepto del panel reapareció en una propuesta, no de que se constituyera ni de que el texto se convirtiera en política.

La ausencia quedó documentada expresamente en 2017. Un grupo de trabajo del ccNSO afirmó que el IDNB nunca había sido establecido y observó que las decisiones sobre delegación, transferencia y revocación de ccTLD no estaban sujetas a un mecanismo de revisión o apelación. El informe final del ccNSO de septiembre de 2024 repitió que el comité nunca se creó y que entonces no existía una revisión independiente para esas decisiones. Estos documentos describen una brecha institucional; no demuestran que todos los conflictos quedaran sin respuesta ni aclaran cada caso particular.

La conclusión más reciente no es que el IDNB apareciera con retraso. El 8 de junio de 2025, la Junta de ICANN aprobó una política distinta de revisión de ccTLD desarrollada por el ccNSO. La anunció como una vía independiente para revisar determinadas decisiones del operador de la función IANA, pero aclaró que el resultado no sería vinculante. El informe de política de ICANN86 del 14 de mayo de 2026 la situaba en “planificación de implementación”. Su alcance, marco institucional y efecto difieren del panel que imaginó la RFC de 1994. No son el mismo mecanismo.

La distinción histórica es sencilla y decisiva. La RFC reconoció que las partes afectadas tenían interés en quién gestionaba un dominio, antepuso el servicio a la propiedad y contempló una instancia vinculante si fracasaba el acuerdo. Sin embargo, nombrar un comité en un documento no lo convierte en una institución operativa. Los esfuerzos posteriores tuvieron que partir de esa ausencia y recorrer otro proceso de política. La participación puede aportar conocimiento, objeciones y pruebas. Un mecanismo de revisión requiere además un órgano, un alcance, un procedimiento y una consecuencia definida.

En el registro histórico del DNS, esas piezas no llegaron juntas.

Fuentes