Summary

  • ICANN’s new Time to Mitigation value is estimated DNS uptime between the first and last observed active resolution of an eligible RBL-reported domain; it is not the exact interval from report to intervention.
  • Before planned registrar, registry or API comparisons, Domain Metrica should display report time, monitoring start, last active observation and classification confirmation separately, with status reasons, exclusions and no-attribution language.

A domain stops answering with an ordinary address. When, exactly, was it mitigated? ICANN’s 3 September release gives Domain Metrica users a new number called Time to Mitigation, or TTM. The name invites a simple reading: start a clock when abuse is reported, stop it when somebody acts.

That is not the published method. TTM is a useful observation interval with narrower semantics. It estimates DNS uptime between a reported domain’s first and last observed active resolution. The difference matters before the value becomes a comparative score.

The clock begins after the report

Domain Metrica relies on supported reputation block lists. A listing is a signal, not an independently verified ICANN finding that an incident occurred. For an eligible second-level domain, the platform aims to retrieve a new report and begin monitoring within five minutes in at least 95 percent of cases. It then normally queries DNS every five minutes.

Neither the RBL report time nor the monitoring-start time automatically starts TTM. According to ICANN’s detailed FAQ, the starting point is the first observation in which the name returns an A record, or an AAAA record when no A record is returned, and the address is not recognized as a known sinkhole.

This is DNS visibility, not full service availability. A successful resolution does not show that a website, mail system, phishing page or command-and-control service worked. A change that occurs and reverses between five-minute checks may not be seen. Resolver location, caching, filtering, rate limits and failures can also affect the observation.

The start can therefore sit later than the report. It may also be unavailable: if the domain never produces an active observation, the platform cannot estimate uptime. “Unknown” is not zero.

The last active answer is not the intervention time

The endpoint is equally specific. For DNS removal, Domain Metrica requires three consecutive NXDOMAIN responses. At the standard cadence, the first and third answers normally span about ten minutes. Those responses support the later classification, but TTM ends at the preceding last active resolution.

For sinkholing, a name can continue resolving and still be classified as mitigated when the returned address matches known sinkhole infrastructure. The last resolution to an address not recognized as a sinkhole ends the uptime estimate; the first qualifying sinkhole observation is kept separately.

ICANN also exposes “Mitigated: Unknown” when available evidence supports a mitigated classification but does not establish DNS removal or sinkholing as the method. None of these states identifies who changed what. A registrar, registry, registrant, hosting or DNS provider, security operator, public authority, expiration process or another cause may sit behind the observed transition. TTM does not decide among them and does not prove every associated abuse channel ended.

The other important outcome is not mitigation at all. Monitoring can end after two months without a qualifying result. That name becomes “Unmonitored: Aged out.” It may still have an uptime estimate based on observed answers, but it must not be counted as a successfully mitigated case.

One number can hide four clocks

ICANN has done something valuable by publishing these qualifications. The platform description also cautions that an RBL presence is not itself an abuse incident. The governance risk begins when a well-documented case metric leaves Domain Search and enters a headline comparison.

The release says later work may add landing-page visualizations, dedicated registrar and registry views, and API access. Such tools could help identify patterns. They could also make a shorter TTM look like proof that one contracted party reacted faster than another, even when report feeds, eligibility, first observation, outcome mix or missing cases differ.

Every comparison row should therefore preserve four timestamps rather than compress them into one duration:

  1. when the supported RBL report entered the evidence chain;
  2. when Domain Metrica began monitoring;
  3. when it last observed an active non-sinkhole resolution; and
  4. when the qualifying sequence or other evidence confirmed the displayed classification.

The row should also carry the method version, measurement cadence, status and reason, address-family treatment, source feed, eligible-name rule, unknown-estimate count and aged-out count. If results are aggregated by registrar or registry, the denominator must include enough of these states to show what was omitted. Comparability is a property to demonstrate, not a consequence of placing two durations side by side.

This proposal does not require ICANN to publish licensed blocklist contents or expose investigative data. It asks the public output to retain the distinctions already present in ICANN’s own FAQ.

Sources

  1. ICANN announcement of uptime measurement capabilities
  2. Domain Metrica FAQ and measurement definitions
  3. ICANN Domain Metrica platform page
  4. ICANN’s 2024 description of the measurement project
  5. Heng Lu, Note 72: The Bill of Rights of Uniqueness Coordination