European Commission Study on DNS Abuse

Revision as of 17:26, 3 May 2023 by Jessica (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The EC conducted a study on DNS abuse, which generated the following recommendations for all actors in the DNS ecosystem.[1]

A. Better DNS Metadata for identifying resources and their attribution to intermediaries B. Contact Information and Abuse Reporting C. Improved Prevention, Detection, and Mitigation of DNS Abuse via maliciously registered domain names D. Improved Detection and Mitigation of (compromised) domain names distributing malicious content E. Better Protection of the DNS Operation and Preventing Abuse of the DNS F. DNS Abuse Awareness, Knowledge Building, and Mitigation Collaboration
1. ccTLDs registries should provide a scalable, unified way of accessing complete registration data in compliance with data protection laws, using RDAP 3. Registrants' and domain name administrators' email addresses that are not visible in the public WHOIS should be displayed as anonymized email addresses 8. TLD registries, registrars, and resellers should verify domain registration data accuracy; implement harmonized Know Your Business Customer procedures or eID authentication in accordance with the eIDAS Regulation, using cross-checks in other publicly available and reputed databases 15. the abuse rates of hosting providers should always be monitored by independent researchers with institutions and regulatory bodies; abuse rates should not exceed predetermined thresholds; incentive structures should be studied to induce hosting providers 17. ccTLDs should be required to sign TLD zone files with DNSSEC and facilitate its deployment according to good practices 24. EU ccTLDs should harmonize practices and adopt good practices
2. ccTLDs registries should publish DNS zone file data through DNS zone transfer or a system similar to the Centralized Zone Data Service 4. domain name administrators should maintain RFC 2142 specific email aliases for domain names (e.g., abuse, hostmaster, webmaster) and an email in the DNS SOA record 9. registries should develop/improve search tools or surveillance services to enable third parties to identify names that could potentially infringe their rights 16. operators of free services should employ advanced prevention and remediation solutions to curb abuses of subdomain names and hosting infrastructure; should proactively detect suspicious domain names containing keywords of the most frequently targeted brands and names; and work with heavily attacked companies and develop Trusted Notifier programs 18. registrants should have easy access to DNSSEC signing within the TLD; registries should require their registrars to support DNSSEC signing for registrants 25. DNS service providers should collaborate with EU and Member States’ institutions, law enforcement authorities, and Trusted Notifiers or trusted flaggers; formalize informal collaborations
5. A standardized (and potentially centralized) system for access to registration data (WHOIS data) should be set up, identifying the minimum information necessary to process disclosure requests. The reaction time to such requests shall be clearly defined 10. registries should offer, directly or through the registrars/resellers, services allowing intellectual property rights holders to block infringing domain name registrations 19. registries could offer discounts for DNSSEC-signed domain names 26. consumers and IPR holders should be made aware of measures to tackle DNS abuse.
6. The study also recommends setting up a standardized (and potentially centralized) system for abuse reporting, identifying the minimum information necessary to process such reports. The receipt of abuse reports is to be acknowledged. The reaction time to such reports shall be clearly defined and the abuse reporter should be provided with information on the actions taken. The DNS service providers shall provide for an appeal proceeding against their decisions to a third neutral party 11. registries and registrars should use predictive algorithms to prevent abusive registrations 20. Internet Service Providers operating DNS resolvers should configure DNSSEC validation to protect end users from cache poisoning attacks 27. all intermediaries and stakeholders should share knowledge and do capacity building in the fight against DNS abuse
7. We encourage the exchange of information on threats between parties involved (e.g., CERTs, security organizations) using collaborative platforms such as Malware Information Sharing Platform (MISP) to report and mitigate abuse in a more effective and timely way. 12. Registries' and registrars' abuse rates should always be monitored by independent researchers with institutions and regulatory bodies; their abuse rates should not exceed predetermined thresholds; if they exceed the thresholds and do not improve, accreditation could be revoked 21. National CERT teams should subscribe to data sources that identify open DNS resolvers; should intensify notification efforts to reduce the number of open DNS resolvers, the root cause of distributed reflective (DR)DoS Attacks
13. registries and registrars with lower abuse rates could be financially rewarded, through a reduction in domain registration fees 22. The Cybersecurity community should continuously measure the adoption of SPF and DMARC protocols, especially for high-risk domain names; raise awareness of domain spoofing among domain owners and email service providers; and correct and toughen SPF and DMARC rules to mitigate email spoofing/Business Email Compromise scams
14. registries should maintain access to RBLs, identify their registrars with the highest and lowest concentrations and rates of DNS abuse, propose incentive structures to encourage their registrars to prevent and mitigate malicious registrations 23. Network operators should deploy IP Source Address Validation for all traffic at the edge of a network to protect closed DNS resolvers from different external attacks against DNS infrastructure, including possible zero-day vulnerabilities within the DNS server software

References[edit | edit source]