July 2026 - Gnso-dnsabuse-pdp

when ADC leads to bulk suspension and sweeps in innocent registrants-A real case
by farzaneh badii July 4, 2026

July 4, 2026

Dear all, I am providing a real-world example with false positives, bulk suspension, sweeping in innocent registrants and the account was suspended as “high risk” following ADC-related action. We are not asking this PDP to develop a fully fledged complaint mechanisms. However, registrars should at least be required to provide a means for a Registered Name Holder to submit a complaint regarding an account suspension or other actions. It can just be a form. It can be just one sentence in the recommendation. *Summary:* A registrant using [will provide the name of the registrar upon request] received a single form notice disabling 73 domains across their account and locking the account entirely. This is some part of the communication they received: "Following a thorough *review of your domain portfolio *and the associated abuse reports, we have assessed that your account poses a high risk." The notice cited one internal reference number and stated the domains "appear to have been recently registered for the purpose of abuse," with no domain-specific evidence, no explanation of the alleged abuse type, and no appeal path, the email explicitly stated the decision was "final and will not be reversed." I'm not including the domain list here but can share it, along with the original notice, upon request. Here we are dealing with a case that we are actually making policy about: - No individualized evidence. All 73 domains were suspended under one blanket determination, with no indication of what conduct, content, or signal triggered the assessment for any specific domain. - False positives. At least 4 of the suspended domains were reportedly not owned by the account holder and had never been part of their account activity, evidence of an error somewhere in the automated attribution/matching pipeline, not merely a disputed abuse judgment. - No appeal mechanism. Even with a clear factual error (domains that didn't belong to the account holder), the notice foreclosed any correction process. - Legitimate domains swept in. A substantial portion of the suspended names were short/brandable/dictionary-style domains consistent with ordinary domain investment and resale activity, not abuse indicators by any recognized definition. Honestly, I don't think a specific example should be necessary to establish that this is a problem because the incentive structure alone makes the outcome predictable. Registrars bear real compliance and reputational costs for under-responding abuse reports, and essentially no cost for over-suspending. (I have mentioned this before in numerous DNS abuse meetings we had, at least since 2019) Bulk, automated, low-specificity suspension is simply the cheapest way to comply. Absent a requirement for individualized evidence and a mandatory appeal/correction path, this outcome, broad account-level action, misattributed domains, no recourse is the rational result of the incentives registrars face. Happy to provide further documentation on request. Farzaneh

5 9

Update on IPC Can't Live With re Recommendation 3
by trachtenbergm＠gtlaw.com July 3, 2026

July 3, 2026

All, I just wanted to provide a quick update of where we are on negotiations between the IPC and the registrars on this issue. It looks like we have agreed on language but still have not aligned on whether the language should go in the recommendation itself or the Implementation Guidance. The agreed on language is as follows: “Reasonably Accessible Data” means Registration Data or other information searchable and available to the registrar through its own existing systems and processes in the normal course of business. The availability of data beyond Registration Data may vary based on the registrar’s business model, operational structure, and data architecture. Registrars are not required to obtain, compile, create, or access data that is not ordinarily available to them, would require disproportionate effort to obtain, or where doing so would violate applicable law or contractual obligations. For the purposes of this policy, “reasonably accessible data” may include, but is not limited to: · Registration Data required to be collected or maintained under applicable ICANN agreements and consensus policies · Data otherwise held by the registrar and reasonably accessible through systems and processes used in the registrar's normal course of operations and · Information received by the registrar in connection with an abuse report or investigation. Where a registrar operates through a reseller or similar business model: · A registrar may rely on a reseller to conduct ADC investigation steps using data reasonably available to the reseller. · Registrars will remain responsible for all relevant contractual obligations, as required by 3.12 of the RAA. This means the registrar is fully responsible for complying with all RAA requirements (including 3.18) even when it uses a reseller. IPC continues to strongly believe that it is important to have some clear baseline requirements for the ADC and that there is no reasonable argument that Registration Data (i.e., registrant and basic domain information like nameserver) that registrars are required to collect for every registration is not reasonably accessible to that registrar. With this language there are ample protections for registrars against scope creep based on change in law or from other information that they are required to collect under the RAA like audit records, etc., as the langue is limited to just the registration data they must already collect. There are also ample protections for registrars in Recommendation 3 and other Recommendations that make crystal clear that registrars do not have to use all reasonably accessible data in their ADC checks and have discretion to choose which elements to use (see e.g., Rec 4 “the specific elements considered in any given ADC, even within a single registrar, may vary depending upon the particular circumstances.”). There is also no risk that we are giving bad actors a roadmap of what to avoid as it will be obvious to any bad actor that the ADC required by this policy (just like the ADC already conducted by some registrars) includes basic domain information like registrant, registration date and nameservers. At the end of the day, if the ADC does not by default include basic domain information that already must be collected by registrars in the policy, then the policy is meaningless. This is basic table stakes folks, and should be part of the policy and not subject to potentially different interpretations by the IRT or anyone else. There is plenty of flexibility in the recommendations for the policy and registrars to adapt later as DNS Abuse tactics change. Finally, we understand that the BC is on board with this so it is not accurate to say that the IPC is alone here. We are hopeful that the registrars can get on board with this as well. We can discuss further on Monday. Have a great weekend everyone and for those in the US, Happy 4th! Best regards, Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP Aspen Chicago 411 E. Main Street 360 North Green Street Suite 207 | Aspen, CO 81611 Suite 1300 | Chicago, IL 60607 T +1.970.300.5313 T +1.312.456.1020 M +1.773.677.3305 M +1.773.677.3305 trac(a)gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig Logo] [Greenberg Traurig Logo] ---------------------------------------------------------------------- If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster(a)gtlaw.com, and do not use or disseminate the information.

2 1

Proposed Agenda and important documents for DNSAM PDP1 6 July 12:30 UTC
by Feodora Hamza July 2, 2026

July 2, 2026

Dear DNSAM PDP1, Please find below the proposed agenda for our call on 6 July at 12:30 UTC. 1. Welcome (5min) 2. PDP Updates (5min) 3. Resolving last two “CANNOT LIVE WITH” items (30min) 4. Review comments received on Initial Report (30min) 5. Update and next steps on Impact Assessments (15min) 6. AOB Please find below the pending WG Action Item: * WG to review draft initial report and provide comments into the document: https://docs.google.com/document/d/12dBqHclkSlqBUAUO51L1LDSQEuyCTnfT/edit?u… In addition, please find below the slides covering proposed language and discussion items for the next WG meeting, as well as the first draft of the comprehensive set of Impact Assessments. Leadership took a first cut on the Impact Assessment and will provide an update and next steps to the WG. Please note the Impact Assessment Document will be introduced and explained to the WG on Monday and sufficient time for review and follow-up discussion will be granted. * DNSAM PDP1 6 July Meeting Slides: https://docs.google.com/presentation/d/1H4SwXNqQgWHrWk2LnTa7l3vmyAs8_lxXytO… * DNSAM PDP1 Draft comprehensive Impact Assessment: https://docs.google.com/spreadsheets/d/1LnLxqpJMqa_plGPfdXHobDr00aAgtkeYnT5… Kind regards, Feodora on behalf of Support Staff

1 0

REMINDER | Meeting Invitation | DNS Abuse Mitigation PDP1 WG | Monday, 06 July 2026
by Terri Agnew July 2, 2026

July 2, 2026

Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Monday, 06 July 2026 at 12:30 UTC for 90 minutes. Zoom Webinar: https://icann.zoom.us/j/91807711636?pwd=q6XCt8cWQU9m3fGgSojQ5X07pbnX6a.1 Passcode:+X8RaawVrW Phone one-tap: +13126266799,,91807711636#,,,,*0006343077# US (Chicago) +13462487799,,91807711636#,,,,*0006343077# US (Houston) Webinar ID: 918 0771 1636 Passcode: 0006343077 International numbers available: https://icann.zoom.us/u/a9jfXWLB8 * 2026 Meetings wiki: https://icann-community.atlassian.net/wiki/x/B4CWLQ ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only (members: please include if an alternate is joining on your behalf) * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…>, the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…>, and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Staff will promote members, participants, and alternates to panelist once joined. OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0