Summary

  • ICANN’s published 2016–17 EBERO exercises found 44, 37 and 20 issues. Simulated DNS downtime ranged from 11 hours 55 minutes to one day 9 hours 5 minutes; the slowest registration-data directory recovery was five days 17 hours 58 minutes.
  • The SSR2 team asked for full end-to-end tests at least annually, with planned datasets, stages, deadlines, all exception paths and published results. In November 2022 the Board marked that recommendation complete using the historical tests and service contracts that permit annual exercises.
  • The January 2023 implementation document and Q2 2026 status report do not supply a dated later exercise result. The missing public comparison is specific: test scope, restoration times and closure of the issues found in the earlier runs.

The drill that left a paper trail

The emergency back-end registry operator, EBERO, is the machinery ICANN can call when a generic top-level domain operator cannot sustain a critical registry function. DNS must resolve. A shared registration system must accept the work of registrars. Registration data must be served. Escrow must hold recoverable records. The zone must remain correctly signed. ICANN declares the event and coordinates the handover. A contract naming those functions is the beginning of a rescue plan; a test tells us how many hours and days the handover actually consumes.

ICANN’s presentation at its 2017 Abu Dhabi meeting did something unusually useful: it printed the times. Three exercises began on 26 January 2016, 25 April 2017 and 21 September 2017. Each used a different EBERO provider and a gTLD whose registry agreement was being terminated. The operators agreed to the exercises before root-zone revocation. Each test domain had one registry-held name and no ordinary registrants. These were controlled live-TLD exercises with a simulated emergency threshold, not recorded outages of customer domains.

In the first exercise, ICANN reported total simulated DNS downtime of 12 hours 22 minutes. In the second it was one day 9 hours 5 minutes. In the third it was 11 hours 55 minutes. The root-zone change alone was applied eight hours 22 minutes, one day 5 hours 5 minutes and seven hours 55 minutes after the simulated threshold. That difference matters: restoring DNS on an EBERO server is one task; making the public root point to it is another. The handover depends on both.

The registration path moved on a slower clock. The escrow deposit reached ICANN after one day 7 hours 31 minutes in the first run, two days 19 hours 36 minutes in the second and one day 14 hours 22 minutes in the third. Shared registration service returned after nearly two days, nearly three days and more than four days respectively. ICANN’s measured total RDDS downtime rose from two days 5 hours 5 minutes to three days 2 hours 14 minutes and then five days 17 hours 58 minutes. The escrow function was restored at the end of the runs after five days 21 hours 53 minutes, eight days 2 hours 34 minutes and eight days 3 hours 21 minutes.

These are the presentation’s exercise measures, not a forecast for every incident.

The slide’s last row is more honest than a green dashboard: 44 issues in the first run, 37 in the second, 20 in the third. Adding those columns yields 101 issue observations; the presentation does not establish 101 unique defects. Its next slide says problems had been or were being resolved, without a dated closure register there. A test capable of finding faults is valuable. The critical next question is whether the fixes were exercised again.

How a recurring test became a finished recommendation

The SSR2 review team’s 2021 recommendation 24.1 asked ICANN to coordinate end-to-end testing of the entire EBERO process at predetermined intervals, at least once a year. It specified test plans, datasets, progression states and deadlines, coordination with contracted parties to exercise exception paths, and publication of results. The point was a repeatable performance record. One successful transfer could show that a chain worked once. Annual repetition could show whether the chain still worked after contracts, systems and people changed.

The ICANN Board approved 24.1 as fully implemented in November 2022. It cited two things: the earlier tests and provisions in EBERO service agreements allowing annual readiness exercises. It also accepted clarification that tests need not use active TLDs carrying registrants. That was a sensible choice for avoiding a rehearsal on somebody else’s live business. It did not turn a contractual exercise clause into an annual sequence of published outcomes.

ICANN’s implementation document, published in January 2023, names the three 2016–17 exercises as the prior proof. It points to the provider agreements and the ICANN60 presentation. It says a future full exercise could involve operators and providers. The document labels the implementation completion date “n/a,” gives the Board’s November 2022 decision as the final date, and lists no milestones. It contains no later annual run with a date, results or issue-closure table. ICANN’s Q2 2026 Specific Reviews report still describes 24.1 through the contractual permission for annual exercises and retains it as complete. That report also provides no dated follow-up run in its 24.1 discussion.

There is a narrow but consequential difference between those records. The historical tests are real; the Board did not approve an imaginary drill. The agreements create a continuing mechanism. Yet the public explanation of “complete” shows an old measured baseline beside a standing ability to run new tests. It does not place a later set of measurements alongside the 2017 times. A reader trying to assess present emergency readiness can inspect the contract, but cannot compare the slow RDDS recovery or the 44, 37 and 20 reported issues with a dated, equivalent outcome in these implementation records.

The ownership of the missing line

ICANN’s current EBERO page lists three contracted providers, their agreements and a transition manual. It states ICANN’s responsibility to declare and coordinate an emergency. The public resource list offers no dated annual results series. A new provider agreement is useful procurement evidence. It says little about whether the handover was rehearsed against a dirty escrow deposit, a root-zone delay or a stalled data directory, and how those branches ended.

The accountability problem is therefore located in the handoff between a review team’s requested evidence and a Board status decision. The team wanted a recurring, published stress test. The Board accepted historical tests and a contract that made repetition possible. The completion flag then stayed green in the 2026 report. The institution that declares an EBERO event also decides what record is enough to close the recommendation. A completed recommendation can become a shelf for the very measurements it was supposed to keep producing.

ICANN has already shown the format. Publish the date, the provider used, the test dataset and starting state; show when DNS worked on provider servers, when the root changed, when escrow arrived, when EPP and RDDS returned, and which exception legs were exercised. List issues found and retested. The 2017 slides prove this can be done without exposing registrants or pretending that a simulation was a real outage. A dated later series with those fields would settle the present evidentiary gap. Until that record is attached to the status, “complete” describes a Board decision more clearly than the current speed of an emergency rescue.

Sources