Resumen

  • El acuerdo de transferencia JPNIC–JPRS del 31 de enero de 2002 otorga a JPNIC y a la Autoridad Gubernamental japonesa autoridad conjunta para decidir un sucesor si JPRS entra en quiebra o insolvencia (art. 14(6)); JPRS debe seguir operando hasta que se determine ese sucesor (art. 13(11)).
  • El escrow de datos es un mecanismo de tres partes: JPRS extrae y transmite datos cifrados a diario, un agente aprobado por JPNIC y la Autoridad Gubernamental los almacena fuera de sitio, y JPNIC audita todo el proceso; JPRS reticó el papel del agente en julio de 2023 y su identidad actual no es pública.
  • A diferencia de los acuerdos gTLD de JPRS (.jprs, .okinawa, .nagoya, .ryukyu), el Acuerdo de Patrocinio ccTLD de .jp del 27 de febrero de 2002 no contiene ningún Instrumento de Operaciones Continuas ni operador interino de emergencia designado por ICANN.

La pregunta de si un dominio de nivel superior sobrevive a su operador suele responderse con el vocabulario de ICANN: el Instrumento de Operaciones Continuas, la transición de emergencia, un operador interino. Para el .jp, ese vocabulario no existe. Lo que existe es un contrato bilateral japonés de 2002 con un mecanismo de sucesión propio.

La cadena de designación

La historia institucional es breve y está fechada con precisión. El Gobierno de Japón avaló a JPRS el 30 de enero de 2002; la IANA publicó su primer informe de redelegación el 8 de febrero; la Junta de ICANN aprobó el acuerdo —con una discrepancia documentada: la página ccTLD de ICANN data la aprobación el 8 de febrero de 2002, mientras que el segundo informe de la IANA la fecha el 12 de febrero—; el Acuerdo de Patrocinio ccTLD se firmó el 27 de febrero de 2002; la IANA publicó su segundo informe el 1 de abril; y la transferencia JPNIC–JPRS surtió efecto ese mismo día, condicionada a la conclusión del Acuerdo de Patrocinio (acuerdo de transferencia; página ccTLD de ICANN; informe IANA del 8 de febrero; segundo informe IANA).

Quién decide el sucesor

El acuerdo de transferencia no deja la sucesión al azar. Si JPRS cae en quiebra o insolvencia, o si se decide una re-transferencia, JPNIC y la Autoridad Gubernamental consultan mutuamente y deciden con rapidez el nuevo destinatario (art. 14(6)). JPRS debe seguir operando hasta que se determine ese destino (art. 13(11)) y transferir todos los datos relevantes del registro (art. 13(12)). No puede ceder su posición como administrador del registro delegado por ICANN a un tercero (art. 13(7)), ni subcontratar operaciones técnicas sin notificar a ICANN (art. 13(8)).

El escrow: la pieza que no se ve

La arquitectura de custodia es tripartita: JPRS extrae y transmite diariamente datos cifrados del registro; un agente de custodia —seleccionado por JPRS según criterios de JPNIC y JPRS, pero aprobado por JPNIC y la Autoridad Gubernamental— los almacena fuera de sitio y los entrega por instrucción del auditor; y JPNIC audita todo el proceso (página de escrow; documentos de selección; reticer en 2023). El agente debe transferir los datos al sucesor una vez decidido. La identidad del agente actual no es pública.

El hueco de DNSSEC

La Declaración de Prácticas DNSSEC del .jp responsabiliza al registro del reemplazo de emergencia de claves y la recuperación predefinida, y establece que al cierre organizativo la información necesaria para el servicio DNSSEC se deposita con el agente de custodia (JP DPS en japonés; en inglés). Pero el mismo documento declara que no se realiza escrow de claves privadas: el material de clave existe como copias múltiples en módulos de hardware guardados en cajas fuertes con almacenamiento fuera de sitio. Un sucesor tendría que generar claves nuevas y hacer reemplazar el registro DS en la zona raíz.

El contraste con los gTLD

Los acuerdos de registro gTLD de JPRS sí contienen la maquinaria que el .jp no tiene. El acuerdo del .jprs y el de Ryukyu incluyen cláusulas de Instrumento de Operaciones Continuas y de Transición de Emergencia (acuerdo .jprs; acuerdo Ryukyu). La investigación de JPRS sobre DNS de desastre usó el string .jprs, no el .jp. La maquinaria que parece «ICANN mantiene vivo el TLD» pertenece a los strings gTLD de JPRS, no a su dominio nacional.

Sin plan de continuidad publicado

No se localizó un plan de contingencia o de continuidad de negocio independiente para el registro .jp en el corpus recuperado; las obligaciones de continuidad aparecen dentro del acuerdo de transferencia, el JP DPS, los documentos de escrow y una presentación de preparación ante desastres de JPRS de 2019 alojada por ICANN (presentación ICANN de 2019). El índice de documentos de JPRS enumera el acuerdo de transferencia, los memorandos de 2013 y 2021, el Acuerdo de Patrocinio, las traducciones de la IANA, los documentos del agente de escrow y el informe del registro — ningún documento de BCP (índice de documentos; informe del registro 2024).

Fuentes

  1. JPNIC–JPRS Transfer Agreement
  2. JPNIC–JPRS Memorandum, December 2021
  3. JPNIC–JPRS Memorandum
  4. Sponsorship Annex 3
  5. JPRS Document Index
  6. JPRS Registry Report 2024
  7. JP Domain Data Handling Rules
  8. JPRS Technical Documents (English)
  9. JPRS Technical Index
  10. JPRS Topics, 29 November 2022
  11. JPRS Press Release, 31 October 2017
  12. JPRS Escrow-Agent Re-tender Notice, 3 July 2023
  13. JPRS Topics, 20 June 2024
  14. JP DNSSEC Practice Statement (English, v1.6)
  15. JP DNSSEC Practice Statement (Japanese, v1.6)
  16. JP DNSSEC Practice Statement (Japanese, v1.4)
  17. IANA Redelegation Report, 8 February 2002
  18. IANA Second Report, 1 April 2002
  19. ICANN ccTLD Page for .jp
  20. .jp ccTLD Sponsorship Agreement, 27 February 2002
  21. ICANN Announcement of the .jp Sponsorship Agreement
  22. JP Data Escrow Overview (JPNIC)
  23. Escrow-Agent RFP Overview, 2008
  24. JPNIC Escrow-Agent Re-tender Notice, 3 July 2023
  25. JPRS Disaster-Preparedness Presentation (ICANN, 2019)
  26. .jprs Registry Agreement
  27. .ryukyu Registry Agreement
  28. Perfil de JPRS en el directorio BTW