Summary

  • ICANN's GNSO working group proposes that a registrar must perform an Associated Domain Check after it has actionable evidence that one non-compromised name is being used for defined DNS Abuse. The Initial Report is open for comment; it is not adopted policy.
  • Recommendation 8 requires demonstrable compliance but makes its six evidence elements optional and forbids a prescribed documentation format. A small protected case schema, paired with privacy-safe aggregates, would preserve local investigative discretion while making later enforcement and effectiveness review comparable.

A registrar receives credible evidence that one domain was registered for phishing. Under today's contract, it must address that evidenced name. Under the Initial Report opened for Public Comment on 18 August, a second question would become mandatory if the recommendations are eventually adopted: what other names linked to the same account, registrant or campaign should be investigated?

That pivot is the important policy change. It moves the response from one reported name toward a bounded search for a possible portfolio. It does not authorize a global hunt across registrars, and it does not turn a shared nameserver or account attribute into proof of common malicious control.

The report handles that distinction carefully. Its first recommendation would trigger an Associated Domain Check, or ADC, only after actionable evidence shows that a registered name is being used for the forms of DNS Abuse defined in the Registrar Accreditation Agreement. It expressly excludes compromised domains—legitimate registrations later exploited without the registrant's knowledge or participation—from this trigger.

The next recommendations preserve judgment. A registrar would review information reasonably accessible in the normal course of its operations. It could consider account data, registrant information, naming patterns, shared infrastructure, coordinated registration activity and signals from external reports. The list is not exhaustive. No one element controls every case. A reseller may perform steps with its information, but the registrar keeps the contractual responsibility.

That flexibility is not a loophole by definition. It recognizes that registrars have different systems, that abuse evidence changes by case, and that excessive association can harm legitimate holders. A fixed algorithm could mistake shared hosting, privacy services or reseller records for one actor. A universal clock could be too slow for an urgent phishing campaign and too short for a complex case with a high collateral risk.

The governance defect appears one step later, in the record rather than the investigation.

A mandatory duty with optional evidence semantics

Preliminary Recommendation 8 says registrars must be able to demonstrate compliance through records and documentation kept in the ordinary course of business. It identifies six kinds of information that may be sufficient:

  • the trigger and its time;
  • whether and when the ADC occurred;
  • the information reviewed;
  • whether and how many associated names were identified;
  • what action followed, if any; and
  • why the process was reasonable and proportionate.

Then it draws a hard boundary: the policy must not prescribe a documentation format. Each registrar must maintain an internal process description and make it available to ICANN upon request.

Those clauses can coexist. An auditor can read a registrar's native file, ask questions and determine whether a particular case complied. The report is therefore not proposing evidence-free discretion, and the absence of a template does not make enforcement impossible.

But case auditability and cross-case comparability are not the same property. If “trigger time” means intake time in one system and analyst-confirmation time in another, the records cannot support a shared timeliness measure. If zero associated domains, no recorded result and a check stopped for unavailable lawful data all collapse into one blank field, the later review cannot distinguish them. If a mitigation decision overwrites the association finding, it becomes difficult to tell whether investigation and remedy were separately reasoned.

This matters because Recommendation 7 proposes a review two years after implementation. It asks ICANN org and a future Implementation Review Team to define a limited aggregate dataset and a baseline. It also correctly warns that overall abuse volume cannot by itself prove what this policy caused. The review will need comparable states before it can produce comparable aggregates.

Standardize the receipt, not the search

The smallest workable answer is not a common scanning engine. It is a minimum evidence interface.

A protected case receipt could carry a pseudonymous case identity, policy version, trigger class and time; the exclusion or treatment of a compromised domain; investigation start and close times; the registrar-reseller responsibility boundary; signal classes examined, unavailable or excluded; counts of names examined and association outcomes; mitigation or no-action disposition; privacy and collateral-risk safeguards; an evidence-set fingerprint; accountable role; review state; and correction or closure identity.

Those fields do not require ICANN to receive a domain portfolio, personal data or detection logic in public. They do not prescribe which signals a registrar must weigh or how much weight to give them. They describe the state transition in a common vocabulary: a trigger existed, a bounded check opened, particular classes of information were lawfully available or not, a result was reached, a separate action followed or did not, and a later correction preserved rather than erased the original record.

The public layer should be thinner still. It could aggregate how many actionable triggers led to ADCs, how many checks were closed under defined disposition classes, what share involved unavailable data, how long stages took within broad bands, and how often decisions were corrected. Small cells would need suppression. No public table should identify domains, registrants, reporters or investigative methods. No registrar ranking should travel without a denominator and case-mix warning.

That two-layer design fits the report's privacy and proportionality logic. The protected receipt supports Contractual Compliance. The aggregate layer supports the two-year policy review. Neither becomes a public accusation database.

The existing baseline is narrower

ICANN's 2024 global amendments already require registrars and registry operators to take prompt, appropriate action against well-evidenced DNS Abuse within their contractual roles. ICANN's advisory says Contractual Compliance can request an itemized set of records when it opens a case. Current monthly dashboards aggregate complaints, notices and resolution reasons by abuse type.

PDP 1 adds a different object: the associated-name investigation after one triggering domain. The June 2026 dashboard predates that obligation and does not measure ADC performance. It is useful only to show that ICANN already has a public aggregate reporting surface to which carefully defined future metrics might be added.

The Initial Report itself remains preliminary. Public Comment closes on 28 September. The working group must review responses, prepare a Final Report and send it to the GNSO Council. Council approval, Board adoption and implementation would still be required before registrars acquire the proposed duty. The Chair's Full Consensus designation for Recommendation 8 is a working-group process fact, not policy adoption or evidence that every stakeholder agrees on every implementation detail.

That process boundary makes the present comment period the right time to settle the evidence interface. Once registrars have built incompatible logs, mapping them later will cost more and may never recover the missing distinctions.

Comparable does not mean centralized

The report is right to resist one investigative script for a global registrar market. Local systems and lawful access must remain local. The same principle does not require every institution to invent its own meaning for the states that an ICANN policy will later count.

Thin coordination works by standardizing the joins, not the whole operation. It defines how one trigger connects to one investigation, how one investigation connects to an outcome, how an outcome connects to action, and how a correction connects to the prior record. Everything else—tools, staff, signals, internal thresholds and lawful case handling—can remain distributed.

An Associated Domain Check can therefore be mandatory without becoming a centralized surveillance system. It can remain proportional without becoming incomparable. The missing piece is not a bigger database. It is a small, portable grammar for proving the sequence of state changes.

Sources

  1. ICANN Public Comment proceeding
  2. ICANN announcement
  3. GNSO DNSAM PDP 1 Initial Report, 18 August 2026
  4. GNSO DNS Abuse Mitigation PDP 1 project page
  5. DNS Abuse Mitigation PDP 1 Charter
  6. ICANN 2024 Global Amendments page
  7. ICANN Advisory on DNS Abuse Obligations
  8. ICANN June 2026 DNS Abuse enforcement dashboard
  9. ICANN DNS Abuse Mitigation Program
  10. GNSO Policy Development Process overview
  11. GNSO Council current procedures