The APAC Space web conference to discuss DNS Abuse was held on 13 February 2020. 17 remote participants from various backgrounds including registries and registrars, end-users, and civil societies attended the web conference.
In summary, Donna Austin (Chair, Registries Stakeholder Group) and Raymond Zylstra (Neustar) gave the registries’ perspective of defining DNS Abuse according to the Registry Agreement (RA) Specification 11(3)(b), and the steps that registries take to mitigate DNS security threats. Holly Raiche (At-Large Advisory Committee member) spoke on the ALAC’s perspective of DNS Abuse and the ALAC recommendations to the Board on this matter. Satish Babu facilitated the community discussion as the APAC Space Community Facilitator.
During AOB, Joyce Chen (ICANN) informed community members that the next APAC Space will take place during the ICANN67 Community Forum in Cancún, Mexico.
Details of the session are as follows:
For background, the APAC Space web conference followed from the community discussions that took place during the Plenary on DNS Abuse in ICANN66 Montreal. In his opening remarks, Jia-Rong Low (ICANN) said that ICANN Org does not have a view on the topic of DNS Abuse and sought guidance from the community based on their discussions. Hence, the web conference served to inform APAC community members about the ongoing discussions and to relate the issues back to the APAC region.
Perspectives on DNS Abuse
Registries Stakeholder Group (RySG)
Donna stated that there was no agreed definition of DNS Abuse within the ICANN community. However, the ICANN community agreed that DNS Abuse was an important topic for the community to discuss. The RySG preferred to use the term “security threats” to refer to threats within the RA scope. To find out more about RySG’s perspective on DNS Abuse, read the RySG Open Letter to the Community.
According to the RA Specification 11(3)(b), registry operators are required to do technical analysis to identify potential security threats such as pharming, phishing, malware, and botnets. They are also required to maintain records of the identified threats and actions that were taken.
In response to advice from the Governmental Advisory Committee (GAC), a voluntary Framework for Registry Operator to Respond to Security Threats was developed by Registries and the Public Safety Working Group (PSWG).
Raymond explained that registries had limited options to take action. This was because any action taken by the registry operator will affect the domain name as a whole, i.e., taking action would mean removing the entire domain name from the Domain Name System (DNS). Additionally, certain actions such as transferring a domain may require a court order. As registrars had a direct relationship with the registrants, registrars were usually the first line of action in the instance of abuse.
Donna highlighted that a group of registries and registrars cooperated to create and sign a Framework to Address DNS Abuse. The framework acts as a best practice guide for contracted parties.
At-Large Advisory Committee
Holly highlighted that the European Union General Data Protection Regulation (EU GDPR) has had an impact on what data is collected and made available in the WHOIS. This was a concern for stakeholders tackling DNS Abuse, such as law enforcement.
Of note, the ALAC Consolidated Policy Working Group meets weekly to discuss issues such as DNS Abuse. A result of those discussions was the ALAC Advice to ICANN Board on DNS Abuse which outlined ALAC’s concerns and recommendations to the Board. Some of the key concerns raised were:
- DNS Abuse remains a key factor eroding confidence in the Internet.
- Bulk registrations are a problem as they are largely undertaken by bad actors.
- There should be no further round of new gTLDs without a thorough reform to mitigate DNS Abuse.
- Rather than keep the status quo, ICANN had a role to play to take action on these issues, identifying the operators with high concentrations of abuse against whom onward action ought to be contemplated.
Holly also raised the recommendations to address DNS Abuse that were made in the Competition, Consumer Trust, Consumer Choice (CCT) Review under ‘Chapter 9 – Safeguards’. Of note were three recommendations:
- To provide incentives for registries to adopt proactive anti-abuse measures.
- The use of initiatives such as Domain Abuse Activity Reporting (DAAR) to identify systemic abuse and bad actors.
- More comprehensive reporting by ICANN Contractual Compliance.
Discussion highlights are as follows:
- In response to Satish’s question on what the APAC landscape for DNS Abuse was like, Donna said that RySG was working with the ICANN Office of the CTO (OCTO) to improve DAAR data. Holly responded that as there were countries in the region with fewer resources to tackle DNS Abuse, some registries and registrars in those areas may need help implementing systems to tackle abuse.
- With reference to the data that ALAC used as a basis for its recommendations, a community member asked if there was data to compare abuse cases pre-2013 (i.e., prior to the obligations of the current RA and Registrar Accreditation Agreement) and the current situation. She further asked how improvements or success could be measured with the current DNS Abuse mechanisms and best practices in place. Donna acknowledged that it was challenging for community to agree on definitions to measure abuse. Holly replied that more research was needed to find out how to identify areas of abuse, where they were coming from, and how to stop it.
- Satish asked if the Framework to Address Abuse would be an effective solution to mitigate DNS Abuse. Donna responded that the Framework was useful to reference as it provided context on what would be considered DNS Abuse, and what would not be addressed, such as content abuse. There were also other initiatives outside the scope of the RA where contracted parties will take action on, such as dealing with child exploitation. Another example was that spam was not typically included in DNS Abuse definitions and there were other legal mechanisms to deal with issues like spam. In the Framework, spam was considered only where it functioned as a delivery mechanism for other forms of DNS Abuse such as phishing and botnets.