Advisory: Compliance With DNS Abuse Obligations in the Registrar Accreditation Agreement and the Registry Agreement
This Advisory provides guidance on the interpretation of and compliance with the 5 April 2024 amendments to the Registrar Accreditation Agreement (RAA) and the Base Generic Top-Level Domain (gTLD) Registry Agreement (RA) regarding Domain Name System (DNS) Abuse mitigation obligations (DNS Abuse Amendments).
Unless specifically modified by the DNS Abuse Amendments, all RAA and RA obligations that were in effect prior to these Amendments remain applicable and in force.
All capitalized terms that are not defined in this Advisory have the meanings given to them in the RAA and the RA.
Registrars and registries that use the practices set forth in this Advisory would likely meet the obligations set forth in the DNS Abuse Amendments, but adherence to one or more of these practices will not automatically result in a determination that the registrar or registry operator has complied with its obligations. The examples set forth below are illustrative only and are not intended to limit the possible mitigation actions. In all cases, whenever ICANN Contractual Compliance initiates an investigation, registrars and registry operators must provide evidence demonstrating compliance with the relevant RAA and RA requirements.
Background
The ICANN organization contracts with registries to operate gTLDs through an RA. The RA specifies the responsibilities of the registry operator, which include maintaining the authoritative database of all registered domain names in the gTLD and publishing the DNS zone for the gTLD.
ICANN also enters into an RAA with each registrar, which allows the registrar to offer domain name registration services in gTLDs. The RAA outlines the responsibilities of the registrar, such as verifying registrant (or Registered Name Holder) information and maintaining accurate records. The roles and obligations of registrars and registries are distinct and are reflected in their respective agreements, the RAA and the RA.
ICANN has the authority to enforce rules related to domain name registration services and domain names as outlined in the RAA and the RA. This Advisory focuses on domain names (or Registered Names) in gTLDs that are used as vehicles or mechanisms for DNS Abuse. The requirements of the DNS Abuse Amendments in the RAA and RA are based on the actions that registrars and registry operators, respectively, can take to minimize the scope and intensity of the harm and victimization caused by DNS Abuse. These requirements also consider that registrars and registry operators represent only a portion of the DNS ecosystem, which is composed of many actors1. Depending on the specific circumstances of an instance of DNS Abuse, the most appropriate actor to detect, assess, verify, and stop the abusive activity may vary, and sometimes may be an actor other than a registrar or registry operator.
DNS Abuse
For the purposes of the RAA, the RA, and this Advisory, DNS Abuse means malware, botnets, phishing, pharming, and spam (when spam is used as a delivery mechanism for any of the other four types of DNS Abuse) as these terms are defined in Section 2.1 of the Security and Stability Advisory Committee Report on an Interoperable Approach to Addressing Abuse Handling in the DNS (SAC 1152):
Malware is malicious software, installed and/or executed on a device without the user's consent, which disrupts the device's operations, gathers sensitive information, and/or gains access to private computer systems. Malware includes viruses, spyware, ransomware, and other unwanted software.
Botnets are collections of Internet-connected computers that have been infected with malware and can be commanded to perform activities under the control of a remote attacker.
Phishing occurs when an attacker tricks a victim into revealing sensitive personal, corporate, or financial information (e.g., account numbers, login IDs, passwords), whether through sending fraudulent or look-alike emails, or luring end users to copycat websites. Some phishing campaigns aim to persuade the user to install malware.
Pharming is the redirection of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning. DNS hijacking can occur when attackers use malware to redirect victims to the perpetrator's site instead of the one initially requested. DNS poisoning causes a DNS server (or resolver) to respond with a false Internet Protocol address bearing malware. Phishing differs from pharming in that pharming involves modifying DNS entries, while phishing tricks users into entering personal information.
Spam is unsolicited bulk email, where the recipient has not granted permission for the message to be sent, and where the message is sent as part of a larger collection of messages, all having substantively identical content. Spam is only considered to be DNS Abuse when it is being used as a delivery mechanism for at least one of the other types of DNS abuse described above.
Registrar Obligations
Section 3.18 of the RAA
Prior to the enactment of the DNS Abuse Amendments, Section 3.18 required registrars to maintain and publish contact details to receive reports of abuse, including Illegal Activity. This provision also outlined requirements relating to the investigation of and response to reports of abuse involving Registered Names sponsored by a registrar, and the related records a registrar must maintain. The requirements in RAA Section 3.18 have been amended as follows:
Requirements Relating to the Publication and Maintenance of Abuse Contacts (RAA 3.18.1)
Where to Report Abuse3
To facilitate submission of reports from any party alleging abuse and/or Illegal Activity, the registrar must publish an email address or web form that is readily accessible on the homepage of the registrar's website4. Web forms must not require a login to submit abuse reports.
A registrar's homepage that clearly displays a link to a "Report Abuse'' or a "Contact Us" page (which clearly includes the abuse contact) and that allows reporters to easily submit reports from the linked page will be deemed compliant.
Confirmation of Receipt of a Report of Abuse
Additionally, the registrar must provide the abuse reporter with confirmation that the report has been received. This receipt confirmation may be sent to the abuse reporter or displayed on the screen upon completion of the submission to the registrar. This receipt confirmation must contain enough information for the reporter to be able to demonstrate that it submitted the abuse report. At a minimum, the receipt confirmation must identify the registrar, the reported Registered Name(s), and the date the report was submitted.
Contacts for Law Enforcement Agencies
The requirements related to contacts dedicated to receiving reports from Law Enforcement Agencies (LEA) and other authorities within the registrar's jurisdiction previously described in Section 3.18.2 of the RAA are now in RAA Section 3.18.3; these requirements remain unchanged.
Requirements Relating to Taking Mitigation Actions Upon Receipt of Actionable Reports of DNS Abuse (RAA 3.18.2)
Section 3.18.2 of the RAA, as modified by the DNS Abuse Amendments, now reads:
When Registrar has actionable evidence that a Registered Name sponsored by Registrar is being used for DNS Abuse, Registrar must promptly take the appropriate mitigation action(s) that are reasonably necessary to stop, or otherwise disrupt, the Registered Name from being used for DNS Abuse. Action(s) may vary depending on the circumstances, taking into account the cause and severity of the harm from the DNS Abuse and the possibility of associated collateral damage.
Actionable Evidence
The evidence must be actionable. This means that the information that is readily available to the registrar must be sufficient to enable the registrar to make a reasonable determination as to whether the Registered Name is being used for one or more forms of DNS Abuse. Registrars are encouraged to proactively monitor the Registered Names that they sponsor to identify potential DNS Abuse. A registrar's assessment of actionable evidence will vary depending on the circumstances of each case.
Obtaining Actionable Evidence From an External Party
The Contracted Parties House (CPH) published guidelines to assist with the submission of complete and actionable abuse reports to registrars (CPH Guidelines). The CPH Guidelines describe the evidence that tends to make an abuse report actionable. For example, a screenshot showing a phishing attempt with an indication of what the phish is against (a financial institution, for example); and the complete URL where the abuse is located (e.g., example[.]tld/badpage[.]html)5. Abuse reporters are encouraged to review and follow the CPH Guidelines, and to provide as much information as possible within their reports, to enable the registrar to conduct an investigation into potential DNS Abuse.
In instances where a registrar receives an abuse report that does not contain all necessary information to be considered actionable evidence of DNS Abuse, the registrar must investigate per Section 3.18 of the RAA. In some cases, the registrar may have access to information that was not provided by an abuse reporter but is necessary or helpful to determine that the Registered Name is being used for DNS Abuse. In such cases, the registrar should consider information that it can reasonably access and is relevant to the investigation (e.g., name servers, account information and activity, and contents of at least the primary webpage or specific URL in the abuse report, if provided).
After Actionable Evidence, Prompt Action Is Required
Upon obtaining actionable evidence, the registrar must promptly take appropriate mitigation action(s) that are reasonably necessary to stop, or otherwise disrupt, the Registered Name from being used for DNS Abuse. To determine the mitigation actions that are prompt and appropriate, the registrar will consider the specific circumstances of the case, which may include balancing the scope and intensity of the harm caused by the DNS Abuse against the possibility of associated collateral damage.
Collateral damage is a particularly important consideration when an otherwise legitimate or benign domain name is used as a vector for DNS Abuse without the knowledge or consent of the registrant. This is often referred to as a "compromised domain" and sometimes is a result of an exploited website content management system. In these compromise situations, direct suspension of the domain by the registrar or registry operator may not be the appropriate mitigation, as suspension will cut off access to all legitimate content as well as render any associated email and other services with the domain inaccessible6. This is also the case when the DNS Abuse is associated with a third-level or subdomain. Registrars and registries can only act at the second-level domain level. Therefore, if they suspend the second-level domain, all third-level domains would be suspended as well, not just the one associated with DNS Abuse. In these situations, a registrar might elect to provide notification to the registrant, site operator, and/or web host.
What Makes an Action Prompt
As noted above, the appropriate mitigation action to stop or disrupt an instance of DNS Abuse will vary depending on the specific circumstances. Consequently, the appropriate amount of time to investigate and take action will also vary, making it impossible to prescribe a fixed amount of time for an action to be considered "prompt." Instead, registrars must demonstrate an ongoing attentiveness to allegations of sponsored names being used for DNS Abuse. The attentiveness should be commensurate with the potential harm that DNS Abuse causes victims.
Accordingly, in response to an inquiry by ICANN Contractual Compliance, registrars will be required to explain how the actions were prompt considering the specific circumstances. ICANN Contractual Compliance will then review the explanation and the relevant circumstances to make a case-by-case determination as to whether the actions were reasonably prompt. The timelines in the examples included in this Advisory are not contractual requirements, but illustrative only. A registrar taking more time to investigate and take action against a case similar to the examples will not necessarily be indicative of noncompliance. Conversely, other circumstances may require the registrar to act more quickly, such as instances of DNS Abuse that carry the potential of causing imminent harm to end users. A registrar is expected to investigate and take action as soon as possible following the registrar's reasonable attempt to confirm an instance of DNS Abuse.
Putting It All Together – Registrar Examples of Compliance
The examples below illustrate reasonable and prompt mitigation actions taken to stop the Registered Name from being used for DNS Abuse (Scenario One) and to disrupt the course of the DNS Abuse in relation to the Registered Name (Scenario Two). These scenarios contain specific factual circumstances. Under different circumstances, individual registrars may take different actions and within a different time frame to stop, or otherwise disrupt, individual cases of DNS Abuse. In all instances, registrars must be able to demonstrate that any approach taken is compliant with the relevant requirements in Section 3.18 of the RAA.
Scenario One: A registrar receives a complete and actionable abuse report alleging that a Registered Name sponsored by the registrar is used for phishing. The report includes evidence that a URL containing the Registered Name sponsored by the registrar is being sent via email or SMS representing itself as a large bank requesting the recipients unlock their accounts. The registrar initiates an investigation considering all relevant information included in the abuse report. The registrar's investigation reveals the Registered Name has no publicly available website and only displays a direct URL with what appears to be a login screen for a large bank. The same URL is the one being sent via emails or SMS. The registrar also considers that the customer is new and the Registered Name was registered five days prior.
Appropriate Mitigation Actions: The registrar reasonably concludes the Registered Name is being used for DNS Abuse and stops the DNS Abuse by suspending the Registered Name, applying the clientHold Extensible Provisioning Protocol (EPP) status code7. The investigation and mitigation action occur within two business days of receipt of the report of abuse. The registrar may also decide to apply a transfer lock to the Registered Name to prevent the registrant from attempting to evade the mitigation action and resume using the domain name for DNS Abuse, so long as the registrar complies with the applicable requirements in ICANN's Transfer Policy.
Scenario Two: A registrar receives a complete and actionable abuse report alleging that a Registered Name sponsored by the registrar, autobrand.tld, is being used for phishing. The report of abuse includes evidence of a specific URL being used for phishing. The registrar investigates, considering all relevant information included in the abuse report as well as information readily and reasonably accessible to the registrar. The investigation confirms that the URL in the report of abuse is being used for phishing. The investigation also reveals that the URL belongs to a subdomain (city.autobrand.tld), and appears to be used by a franchisee. The registrar acknowledges that the Registered Name autobrand.tld was registered three years ago and has a robust set of content for an automobile dealership franchise. The registrar is able to confirm the Registered Name is used for Autobrand's corporate emails and subdomains for multiple franchisees.
Appropriate Mitigation Actions: The registrar reasonably concludes that the Registered Name is being used for DNS Abuse, but that it is likely the result of domain compromise and that the registrant is not knowingly using the Registered Name for DNS Abuse. The registrar assesses the potential collateral damage that suspending the domain name would have, and reasonably concludes that is not an appropriate mitigation action at this time. Instead, the registrar disrupts the DNS Abuse by notifying Autobrand, the registrant of autobrand.tld, requesting that it eliminate the phishing content by a certain date reasonably determined by the registrar. The investigation and mitigation action occur within three business days of the receipt of the abuse report.
Requirements Related to the Maintenance and Provision to ICANN of Records
The requirements related to documenting and providing records related to the receipt of and response to abuse reports previously described in Section 3.18.3 of the RAA are now in RAA Section 3.18.4; these requirements remain unchanged. These requirements also apply to the response to reports of DNS Abuse under Section 3.18.2.
Registry Operator Obligations
Section 4, Specification 6 of the RA
Specification 6, Section 4 of the RA requires the publication, and provision to ICANN, of contact details for handling inquiries related to malicious conduct in the top-level domain (TLD). It also includes requirements related to the removal of orphan glue records when used in connection with malicious conduct. The requirements in this Specification have been amended as follows:
Requirements Relating to the Publication and Maintenance of Abuse Contacts (Base RA Specification 6, Section 4.1)
Where to Report Abuse
To facilitate submission of reports from any party alleging malicious conduct in the TLD, including DNS Abuse, the registry operator must publish an email address or web form, a mailing address, and a primary contact for handling such reports.
A registry operator's homepage that clearly displays a link to a "Report Abuse'' or a "Contact Us" page (which clearly includes the abuse contact) where submission of reports is unimpeded will be deemed compliant.
Confirmation of Receipt of a Report of Abuse
Upon receipt, the registry operator shall provide the abuse reporter with confirmation that the report has been received. This receipt confirmation may be sent to the abuse reporter or displayed on the screen upon completion of the submission to the registry operator. This receipt confirmation must contain enough information for the reporter to be able to demonstrate the submission of the abuse report. At a minimum, the receipt confirmation must identify the registry operator, the reported Registered Name(s), and the date on which the report was submitted.
Requirements Relating to Taking Mitigation Actions Upon Receipt of Actionable Reports of DNS Abuse (Base RA Specification 6, Section 4.2)
Section 4.2 of Specification 6, as modified by the DNS Abuse Amendments, now reads:
Where a Registry Operator reasonably determines, based on actionable evidence, that a registered domain name in the TLD is being used for DNS Abuse, Registry Operator must promptly take the appropriate mitigation action(s) that are reasonably necessary to contribute to stopping, or otherwise disrupting, the domain name from being used for DNS Abuse. Such action(s) shall, at a minimum, include: (i) the referral of the domains being used for DNS Abuse, along with relevant evidence, to the sponsoring registrar; or (ii) the taking of direct action by the Registry Operator, where the Registry Operator deems appropriate. Action(s) may vary depending on the circumstances of each case, taking into account the severity of the harm from the DNS Abuse and the possibility of associated collateral damage.
Actionable Evidence
The evidence must be actionable. This means that the information that is readily available to the registry operator must be sufficient to enable the registry operator to make a reasonable determination as to whether the Registered Name is being used for one or more forms of DNS Abuse. Registry operators may obtain actionable evidence by reviewing information that they can reasonably and independently access, whether in conjunction with a report of abuse or as part of their own efforts under Specification 11(3)(b) of the Registry Agreement by conducting technical analysis to identify domains being used for DNS Abuse. Actionable evidence can also be presented to the registry operator by an external party such as LEA, the relevant registry operator's trusted or recognized sources, or any other party or source. Abuse reporters are encouraged to provide as much information as possible to contribute to ensuring the registry operator has sufficient information to conduct an investigation into potential DNS Abuse. For the avoidance of doubt, an abuse report considered incomplete by the registry operator may be deemed actionable if the registry operator has access to sufficient information to reasonably conduct an investigation to determine whether the reported Registered Name is used for DNS Abuse.
After Actionable Evidence, Prompt Action Is Required
Upon obtaining actionable evidence, the registry operator must promptly take appropriate mitigation action(s) that are reasonably necessary to contribute to stopping, or otherwise disrupting, the domain name from being used for DNS Abuse. To determine the appropriate actions, the registry operator will consider the specific circumstances of the case, which may include balancing the scope of the harm and victimization caused by the DNS Abuse against the possibility of associated collateral damage. The importance of collateral damage in the situation of compromised domains described above for registrars applies equally to registries.
The registry operator will also consider whether it, the sponsoring registrar, and/or another party are the best-equipped parties to review and take the appropriate, proportionate mitigation actions. For example, for a single Registered Name being used for DNS Abuse, the registrar may be best placed to review and address the DNS Abuse with its customer. Similarly, in the case of compromised systems, the Registered Name Holder or the hosting provider that maintains administrative access to affected systems may be better able to address the issues, and the registry operator should refer these to the registrar first, as suspending the domain by applying either clientHold or serverHold can cause collateral damage on benign or legitimate content. On the other hand, the registry operator may be the best party to address large-scale threats that span many Registered Name Holders or registrars, such as domain-generating algorithms used to propagate botnets.
The mitigation actions promptly taken must be reasonablynecessary to achieve one of the following outcomes: contributing to stopping or disrupting the Registered Name from being used for DNS Abuse. At a minimum, the registry operator must:
- Report the Registered Name(s) and supply the relevant evidence to the sponsoring Registrar(s); or
- Take direct action on the Registered Name(s) where the registry operator deems such direct action appropriate.
What Makes an Action Prompt
As noted above for registrars, the appropriate action to take to mitigate or disrupt an instance of DNS Abuse will vary depending on the specific circumstances. Consequently, the appropriate amount of time to investigate and take appropriate action will also vary, making it impossible to prescribe a fixed amount of time for an action to be considered "prompt." Instead, registry operators must demonstrate an ongoing attentiveness to allegations of sponsored names being used for DNS Abuse. The attentiveness should be commensurate with the potential harm DNS Abuse causes victims.
Accordingly, in response to an inquiry by ICANN Contractual Compliance, a registry operator will be required to explain how the actions were prompt considering the specific circumstances. ICANN Contractual Compliance will then review the explanation and the relevant circumstances to make a case-by-case determination as to whether the actions were prompt. The timelines in the examples included in this Advisory are not contractual requirements, but illustrative only. A registry operator taking more time on a particular case will not necessarily be indicative of noncompliance. Conversely, other circumstances may require the registry operator to act more quickly, such as instances of large-scale threats that carry the potential of causing imminent harm to a large number of end users. A registry operator is expected to investigate and take action as soon as possible following the registry operator's reasonable attempt to confirm an instance of DNS Abuse.
The examples below illustrate reasonable mitigation actions promptly taken to contribute to stopping the Registered Name from being used for DNS Abuse (Scenario Two) and to contribute to disrupting the course of the DNS Abuse in relation to the Registered Name (Scenarios One and Three). These scenarios contain specific factual circumstances. Under different circumstances, individual registry operators may take different actions with different time durations to contribute to stopping, or otherwise disrupting, individual cases of DNS Abuse. In all instances, registry operators must be able to demonstrate that any approach taken is compliant with the relevant requirements in Section 4.2 of Specification 6 of the RA.
Section 3(b), Specification 11 of the RA
This section was modified to substitute the defined term of DNS Abuse as set forth in the amendments to Specification 6, Section 4, for "security threats."
Putting It All Together – Registry Operators Examples of Compliance
Scenario One: A registry operator received a notification from a credit union (Example Credit Union) via its abuse webform that someone registered the domain <loginexamplecreditunion[.]TLD> six days ago and the credit union alleges the domain is engaged in phishing. The credit union provides a screenshot showing a webpage on the domain gathering login credentials.
Appropriate Mitigation Actions: Following its internal process, the report is processed and reviewed by the registry operator within two business days. Upon concluding its investigation, the registry operator reasonably determined that the Registered Name was being used for DNS Abuse. Therefore, the registry operator disrupts the course of the DNS Abuse by notifying and providing all pertinent information to the sponsoring registrar. The registry operator includes a time-bound request for the registrar to investigate and take the reasonably necessary mitigation actions to stop, or otherwise disrupt, the DNS Abuse. By the given deadline, the registry operator is able to confirm that the registrar suspended the Registered Name via applying the clientHold EPP status code.
Scenario Two: A registry operator is approached by LEA and provided evidence that a series of domains are, or will be, involved in a domain-generating algorithm associated with a botnet. The botnet involves some existing Registered Names, but predominantly domains that are not yet registered.
Appropriate Mitigation Actions: Within six hours of concluding its investigation and reasonably confirming the DNS Abuse, the registry operator contributes to stopping the DNS Abuse by taking actions as directed by or agreed upon with the LEA. In this case, the registry operator has agreed that for the relevant Registered Names, the registry will delegate to different name server(s) (e.g., redirect the name servers or sinkhole) at the request of LEA. The registry operator also directly creates the domains for those previously the unregistered domains associated with the botnet as requested by LEA. Noting that domain creation by the registry operator ordinarily requires permission via ICANN's Security Response Waiver (SRW)8. The registry operator also will make a timely request to obtain a contractual waiver. It is noted, however, that an SRW may also be applied for as soon as is reasonably practicable after the fact, and ICANN org may respond with a retroactive waiver if appropriate, so as to not delay the support of the LEA operation9.
Scenario Three: As part of its technical analysis looking for DNS Abuse under Specification 11(3)(b), a registry operator discovers that a subpage of a domain is being used to distribute malware while the remainder of the site on the domain appears to be legitimate or benign content. The domain name has been registered for three years.
Appropriate Mitigation Action: Within three hours of determining that the Registered Name is being used for DNS Abuse and compromised, the registry operator contributes to disrupting the course of the DNS Abuse by notifying and providing all pertinent information to the sponsoring registrar and making a time-bound request for action by the registrar to report back. The registrar then notifies the registrant directly, which resolves the issue by updating its content management system to remove the malware.
ICANN Org's Investigations Into Compliance With the New Section 3.18.2 of the RAA and Section 4.2 of Specification 6 of the RA
What Would Constitute a Complete, Well-Evidenced, and Compliant Response?
ICANN Contractual Compliance will enforce the requirements explained in this Advisory through the processing of external complaints, proactive monitoring, and audit activities.
When ICANN Contractual Compliance receives a complaint, it will review any evidence submitted by the reporter as well as any available relevant information to determine whether a compliance case must be initiated with the relevant registrar or registry operator. In the absence of sufficient evidence in support of a claim of DNS Abuse, ICANN Contractual Compliance will close the case as invalid. Among other things, this review will consider whether information readily available to the sponsoring registrar directly or through a reseller, or the registry operator, as applicable, is sufficient to reasonably determine that the Registered Name is being used for one or more forms of DNS Abuse. The review will also consider if there was any additional information provided by the reporting party in response to the registrar's or registry operator's requests for additional information or evidence.
Furthermore, where applicable and relevant to the specific case, ICANN Contractual Compliance will: (1) review relevant, publicly accessible data displayed through the Registration Data Directory Service, e.g., creation date, EPP status(es), or name servers information; and (2) perform DNS lookups to determine whether the reported Registered Names resolve in the DNS. ICANN Contractual Compliance may also conduct its own research and review additional, relevant information on a particular Registered Name alleged to be involved in DNS Abuse.
When initiating a compliance case10 with a registrar or registry operator under Section 3.18.2 of the RAA or Section 4.2 of Specification 6 of the RA, respectively, ICANN Contractual Compliance will provide an itemized list of all the information and records needed to assess compliance as it pertains to the reported Registered Names(s) and forms of the alleged DNS Abuse. In response to a compliance case, the registrar and registry operator will be expected, at a minimum, to:
- Explain how and why the registrar or registry operator reached the determination that the evidence obtained was not actionable, where applicable. For example, a registrar may explain that, after reviewing the information and records submitted by the reporting party, and through its investigation, the registrar was not able to verify that the DNS Abuse was taking place in connection with the reported Registered Name(s). ICANN Contractual Compliance may ask the registrar or registry operator to clarify any clear discrepancies between the explanation given and any information and data captured by ICANN Contractual Compliance during the complaint validation process.
- Provide a detailed explanation, supported by the relevant records, of the specific mitigating actions taken, when the actions were taken, and how the actions taken were considered prompt and reasonably necessary to stop or to disrupt or to contribute to stopping or disrupting, as it pertains to the specific circumstances of the case (including any applicable explanation relating to disproportionality of actions at the DNS level and collateral damage). The requirements for the registrar to provide this information will continue to apply in cases in which the registrar elects to delegate the investigation of the DNS Abuse report to a reseller. In such cases, the registrar retains the obligation to demonstrate compliance with Section 3.18 of the RAA11 by explaining the actions it took as well as those actions of any other delegated parties such as resellers and providing related records.
ICANN policies and contractual requirements are applied within the bounds of the laws and regulations that are applicable to each registrar and registry operator. For the avoidance of doubt, neither registrars nor registry operators will be required or expected to take any action in contravention of applicable laws and regulations.
Information About When, How, and Where to File a Complaint to ICANN Contractual Compliance is Available Here.
1 Additional information can be found in the report produced by the DNS Abuse Special Interest Group at FIRST, which also includes advice for incident response teams on the organizations that might be productively contacted at different incident response phases for different DNS abuse techniques. In addition, the Internet and Jurisdiction Policy Network (https://www.internetjurisdiction.net/) has provided further guidance on these forms of DNS Abuse in its "Operational Approaches, Norms, Criteria, and Mechanisms."
2 ICANN Security and Stability Advisory Committee's SAC 115, Section 2.1, Pages 12–13, 19 March 2021
3 For the avoidance of doubt, the requirements related to publishing the registrar's abuse contact email address and phone number through theRegistration Data Directory Service (RDDS) remain unchanged.
4 This website should be located at the same uniform resource locator (URL) that the registrar displays as the value for the "Registrar URL" field through its RDDS, provided to ICANN and to the registry operator for publishing in the registry operator's RDDS.
5 This URL is shown in a format known as a "defanged URL." A defanged URL is readable to the human eye but not clickable. Therefore, if you or the recipient of your abuse report click on the URL by mistake, it will not direct you or the recipient to a potentially malicious site.
6 More information on collateral damage and proportionality considerations when acting at the DNS level is available in the Internet and Jurisdiction Policy Network's publication "Toolkit: DNS Level Action to Address Abuses."
7 Click here for more information from ICANN about EPP Status codes.
8 Information about Security Response Waivers can be found on this page.
9 For more information on how registries can work with law enforcement and ICANN to address domain-generating algorithms, please see "Framework on Domain Generating Algorithms Associated With Malware and Botnets," published by the Government Advisory Committee Public Safety Working Group and the gTLD Registries Stakeholder Group.
10 ICANN Contractual Compliance enforces all RAA and RA obligations with its contracted parties through an established process. The DNS Abuse requirements in this Advisory will be enforced through the same process. Failure to cure a notice of breach results in RAA suspension and/or termination, or in the initiation of RA termination proceedings. Compliance with contractual obligations is also a requirement, with certain conditions, for any contracted party to renew its RAA or RA with ICANN or assign it to another entity. Relevant RAA Sections and RA Articles are below:
RAA 5.5. Termination of Agreement by ICANN.
RAA 5.7. Suspension.
RAA 5.2. Renewal.
RAA 7.3. Assignment; Change of Ownership or Management.
Base RA 4.3. Termination by ICANN.
Base RA 4.2. Renewal.
Base RA 7.5. Change of Control; Assignment and Subcontracting.