Who keeps .jp running if JPRS fails? The contract answer

Summary

The authority to decide a successor for .jp if JPRS becomes bankrupt or insolvent rests jointly with JPNIC and the Japanese Governmental Authority under Article 14(6) of the 31 January 2002 JP Domain Name Management and Administration Transfer Agreement — not with ICANN (transfer agreement).
JPRS must keep operating .jp until a successor is determined and then transfer all relevant registry data (Articles 13(11) and 13(12) of the same agreement) (transfer agreement).
Data escrow is a three-party structure: JPRS transmits encrypted registry data daily to an escrow agent approved by JPNIC and the Governmental Authority, and JPNIC audits the process; the agent must hand over the data on instruction (escrow overview).
The .jp ccTLD Sponsorship Agreement between ICANN and JPRS contains no Continued Operations Instrument and no designated emergency interim operator; ICANN's role in a failure is the technical root function, not operator replacement (Sponsorship Agreement; ICANN .jp page).
By contrast, JPRS's gTLD registry agreements — .jprs and the Ryukyu string — do contain Continued Operations Instrument and Emergency Transition machinery (.jprs agreement; Ryukyu agreement).
The JP DNSSEC Practice Statement creates a successor's hardest problem: service information is escrowed, but private signing keys are not; a successor must generate new keys and have the .jp DS record replaced in the root zone (JP DPS).

A question the gTLD answer gets wrong

Ask any operator steeped in the gTLD system what happens when a registry fails, and the answer comes readily: the Continued Operations Instrument (COI) in the ICANN registry agreement, the Emergency Transition process, ICANN stepping in with an emergency back-end operator. That machinery exists, is contractually specified, and has occasionally been discussed in public. It is the expected answer for the strings JPRS holds as a gTLD registry operator.

For .jp, the expected answer is simply wrong. The .jp ccTLD Sponsorship Agreement, signed 27 February 2002 between ICANN and JPRS and posted on ICANN's own document archive, does not contain a Continued Operations Instrument, nor does it designate any emergency interim operator (Sponsorship Agreement). What it does contain is the standard ccTLD framework: ICANN recognizes JPRS as the Sponsoring Organization for .jp, maintains the root database entry and administrative contacts, and publishes the .jp delegation in the root zone (ICANN .jp page). If JPRS failed tomorrow, ICANN's instruments would not tell anyone who takes over the registry's operational work. They would only tell ICANN what to do with the root.

The real answer lives elsewhere — in a domestic contract most non-Japanese observers have never read, and in documents JPRS itself publishes precisely so that the successor machinery is visible in advance.

The transfer agreement: JPNIC and the Governmental Authority hold the trigger

The JP Domain Name Management and Administration Transfer Agreement, concluded between JPNIC and JPRS on 31 January 2002 and effective 1 April 2002, is the core continuity instrument for .jp. JPRS publishes it on its document index (document index). It is a bilateral contract: JPNIC is party A (甲), JPRS is party B (乙), and the Governmental Authority (政府当局) appears throughout as the third authority whose concurrence JPNIC must seek.

Article 14 is where the succession power sits. Under Article 14(6), if JPRS enters bankruptcy or becomes unable to pay, or if a re-transfer has been decided under the preceding paragraph, JPNIC and the Governmental Authority consult with each other and promptly decide the new transferee (transfer agreement). The preceding paragraphs of Article 14 give that pair a graduated process: JPNIC issues improvement recommendations for serious violations of JPRS's stated responsibilities; if JPRS fails to correct them without legitimate reason, JPNIC and the Governmental Authority consult and give JPRS written advance notice of re-transfer; and they then decide the re-transfer jointly (transfer agreement).

Article 13 defines what JPRS owes in the meantime. Article 13(11) obliges JPRS to continue the management and administration of .JP until a re-transfer destination is determined; Article 13(12) requires it to transfer all relevant registry data to that destination (transfer agreement). Two further clauses bound the operator's freedom in ways that matter for continuity: JPRS may not assign its position as the ICANN-delegated JP registry administrator to a third party (Article 13(7)), and it may not subcontract all or part of its technical ccTLD registry operations without notifying ICANN (Article 13(8)) (transfer agreement).

Article 15 ties the domestic instrument to the international one: the transfer agreement takes effect only when, among other conditions, the ccTLD Sponsorship Agreement has been concluded (transfer agreement). The redelegation record matches that sequence. The Government of Japan endorsed JPRS as the .jp manager on 30 January 2002; the IANA redelegation report followed on 8 February 2002; ICANN's ccTLD page records Board approval dated 8 February 2002, while the IANA second report dates the Board authorization to 12 February 2002 — a small documented discrepancy worth noting, not resolving (ICANN .jp page; IANA report; IANA second report). The Sponsorship Agreement was signed 27 February 2002, and the JPNIC–JPRS transfer became effective 1 April 2002. The national contract conditioned on, and outlasts in function, the ICANN one.

The 2021 memorandum of understanding between JPNIC and JPRS updates the framework's working terms, and the 2013 memorandum stands in the same published series (2021 memorandum). The succession clause that matters for failure scenarios is unchanged in structure: JPNIC and the Governmental Authority jointly hold it.

Escrow: the data path a successor would use

If JPNIC and the Governmental Authority decide a successor, the successor needs the registry data. That is what the escrow architecture provides, and it is deliberately a three-party arrangement rather than a bilateral deposit.

The published description of the .jp data escrow system sets out the roles: JPRS, as registry operator, performs the daily extraction and transmission of encrypted escrow data; an escrow agent provides secure offsite storage and holds the deposited data; and JPNIC acts as the auditor, controlling and auditing the whole process, with the agent required to hand over the data on the auditor's instruction (escrow overview). The escrow agent is selected by JPRS against criteria set by JPNIC and JPRS, but must be approved by JPNIC and the Governmental Authority under the transfer agreement — the same pair that holds the succession power (escrow overview).

Two facts sharpen the picture. First, the selection details and results of the escrow arrangement are deliberately not published; the identity of the current agent is not public in the record examined. Second, the role is periodically re-tendered: JPRS announced a recruitment of escrow-agent candidates in July 2023 (JPRS notice; see the document index listing the RFP documents). A 2008 RFP overview document for the escrow-agent business remains available in JPNIC's published materials (RFP overview).

The design intent is legible from the contract text alone: Article 14(8) of the transfer agreement requires the escrow agent to transfer the registry data promptly to the successor once a re-transfer destination is decided (transfer agreement). The escrow is the successor's supply chain. Its audit is the successor's quality assurance. And its governance — agent chosen by JPRS, approved by the succession authorities, audited by JPNIC — keeps every party in the loop without giving any one of them unilateral control of the data.

DNSSEC: the continuity gap that data escrow does not close

The JP DNSSEC Practice Statement (JP DPS), published by JPRS, is the document that reveals where a successor's job gets hard.

The JP DPS makes the registry responsible for emergency key rollover, for pre-defined recovery procedures, for resumption from a remote backup site, and for conducting emergency key ceremonies (JP DPS). It also states that on organizational closure — dissolution or discontinuation — the information necessary for the JP DNSSEC Service is deposited with the escrow agent.

But the same document states that private-key escrow is not performed. Key material exists as multiple copies in hardware security modules held in locked safes at critical facilities, with copies stored offsite (JP DPS). Read together, the two provisions mean a successor operator would not inherit signing keys as such. It would generate new keys, publish new DNSKEY records, and then require the .jp DS record in the root zone to be replaced — an action that depends on the IANA root-zone change process, and therefore on coordination between the successor selected domestically and ICANN/IANA's root function (JP DPS).

This is the point at which the two institutional tracks necessarily meet. The domestic chain decides who the successor is; the international chain makes the successor's signature authoritative for resolvers worldwide. Neither alone suffices, and the published record does not spell out the interaction in a single document.

What JPRS's gTLD strings have that .jp does not

The contrast with JPRS's own gTLD business makes the .jp design choice visible rather than accidental.

JPRS's registry agreement for .jprs, filed with ICANN, contains the standard gTLD continuity machinery: a Continued Operations Instrument and Emergency Transition clauses that specify how ICANN can move the registry function to an emergency operator (.jprs agreement). The same is true of the agreement for .ryukyu (Ryukyu agreement). For those strings, ICANN contractually holds a replacement lever.

For .jp, no such clause exists. The machinery that keeps the TLD alive is domestic, contractual, and was written into a bilateral agreement predating the ICANN instrument by four weeks. Notably, even JPRS's own research into disaster-resilient DNS used the .jprs string rather than .jp — a further sign that the two tracks are operated as distinct regimes, not as one company with one failure mode.

A 2019 ICANN-hosted presentation by JPRS on disaster preparedness describes the operational hardening JPRS has built: redundant facilities, disaster DNS arrangements, and drill programs (disaster presentation). It is the closest public document to a contingency plan, and it describes resilience of the operator, not succession of the operator. No stand-alone published business-continuity plan for the .jp registry was located in the record examined; continuity obligations appear inside the transfer agreement, the JP DPS and the escrow documents.

What the record shows, and what it leaves open

The published record supports a two-layer answer to the failure question. Nationally, JPNIC and the Governmental Authority jointly decide the successor on insolvency; JPRS must keep operating until then and transfer the registry data; the escrow agent delivers the data on JPNIC's instruction. Internationally, ICANN maintains the root entry and the delegation and would process the successor's root-zone changes, including the DS replacement a new DNSSEC operator would need.

What the record leaves open is equally important. The current escrow agent's identity is not public, so the completeness of the data path cannot be externally verified. The exact process by which the Governmental Authority (the ministry-level authority under the transfer agreement) would act in a real insolvency has never been exercised, so the timeline in Articles 14(6) is a promise, not a precedent. And the DS-record replacement step — the hinge between domestic succession and global resolution — is governed by root-zone change procedures that neither the transfer agreement nor the JP DPS cites.

For an infrastructure observer, the lesson is about reading the right instrument. The .jp answer to "who keeps the domain running" is not in ICANN's contract. It is in a 2002 bilateral agreement that JPRS publishes, in an escrow system audited by JPNIC, and in a DNSSEC practice statement that candidly discloses what is escrowed and what is not. The machinery exists, in public, for anyone who reads Japanese and knows where to look. This report exists to read it in English.

Sources

If JPRS Fails, Who Keeps .jp Running? Reading the Successor Machinery in the .jp Record

Why it matters

Summary

A question the gTLD answer gets wrong

The transfer agreement: JPNIC and the Governmental Authority hold the trigger

Escrow: the data path a successor would use

DNSSEC: the continuity gap that data escrow does not close

What JPRS's gTLD strings have that .jp does not

What the record shows, and what it leaves open

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing