Good security practice for domain registrars

Abuse notifications/takedown

Aim: To tackle DNS abuse by investigating and responding promptly to reported abuse to minimise the time that malicious sites are reachable.

Registrars should aim to provide automated responses with unique identifiers that make it easier for reporters to track progress on abuse requests. Responses should cover confirmation when a report is received, as well as updates on the request status (accepted or rejected), with reasons for rejection where applicable.

If abusive domains are removed promptly, it has a significant effect on the harm they can cause. The best practice is for registrars to investigate and respond to abuse reports as quickly as is practical and to aim to resolve the majority of cases of abuse within 48 hours.

Registrars should consider signing up to, and publicising the use of, abuse reporting tools and aggregators, such as the NetBeacon Reporter, as they help improve the quality of abuse reports by standardising the format and enriching the content before it reaches a registrar. Better quality reporting should reduce false positives and overall response times.

Abuse detection

Aim: To reduce the number of active abusive domains and domain lifetime, as registrars proactively look for and respond to potentially abusive customer behaviours.

As well as responding to specific abuse reports, registrars should carry out proactive detection of abusive behaviours. This helps abusive domains and registrants to be investigated early and removed where necessary. Proactive monitoring may involve manual checks or automated processes, depending on the scale of the registrar and the patterns of abuse being investigated.

The aim is to identify and respond to patterns of abuse, whether the information to help detect comes from information shared by other organisations, formal abuse reports or your own monitoring. 

Common features that could indicate abusive behaviour could include:

• changes in registrant behaviour which might indicate a compromised account
• multiple registrations or customer accounts that share common features such as contact information, source IP addresses or payment details that have a previous history of abuse

Sharing threat data with other registrars

Aim: to have a platform where registrars can share information about customers and domains that have been blocked, taken down, or refused service.

If as a registrar, you detect abusive behaviour, sharing this information more widely with peer organisations brings considerable benefits. Sharing threat information and raising awareness prevents a malicious actor simply moving to another provider. Work towards building a platform among the registrar community is strongly encouraged. Privacy and data protection policies would need to be agreed to enable this in a safe and compliant manner.

Registrars should define what information they can share about instances of abuse, and collaborate with other registrars in suitable forums, such as those ran by ICANN and Nominet. Identifying common factors in abuse reports and registrations, and sharing approaches of how best to detect and investigate these cases, would reduce cases of abuse across industry.

As referred to in the ‘know your customer checks’ section above, the trends and patterns used to detect abuse are a good example of data sharing that reduces malicious sign-ups for registrars without the need to share personal data.

Vulnerability notification mechanisms

Aim: To provide a suitable contact mechanism for security issues.

It is important that cyber security organisations have the right security contacts for a domain owner, if they need to make contact to disclose a vulnerability responsibly, notify the owning organisation of a suspected compromise, or report other suspected malicious activity for investigation. 

To support this, you should encourage users to use existing security contact methods. If publicly available contacts are not available, or if you are providing privacy services, you should provide a mechanism to pass vulnerability notifications on to your customers.

Existing mechanisms to publish security contact and policy information, such as a ‘security.txt’ or the DNS based equivalent proposed in 'DNS Security TXT', require organisations to opt in to publish their contact information. Currently only a small percentage of organisations implement security.txt and vulnerability disclosure processes. 

As UK GDPR legislation has significantly affected the data publicly available in the WHOIS service, the abuse contact at a registrar may be the only available contact for a domain. Note that they are not intended to be a general purpose security and incident reporting mechanism.