The Internet Corporation for Assigned Names and Numbers (ICANN) is tackling the security issues related to the domain name system (DNS) with the release of a new set of disclosure guidelines.
DNS allows easily remembered domain names like Google.com to be associated with the less-memorable IP addresses of the servers hosting web pages and other services, such as 18.104.22.168.
While there are many individually named servers that internet service providers (ISPs) or web hosts implement themselves using software such as BIND, ICANN manages the handful of root domain name servers that the name servers refer to.
At the moment, if a security researcher does discover a weakness in DNS protocols, there is no guidance on who they should contact. This increases the chances that they might, even if they are well intentioned, release potentially dangerous information into the public arena before ICANN is able to respond to the issue and take action.
Under a new set of guidelines released on Monday, called Coordinated Vulnerability Disclosure Reporting at ICANN, ICANN has set out how it believes security researchers should report vulnerabilities relating to DNS, whether it or another vendor is affected.
Public disclosure is typically not recommended, unless the vendor or affected party has been notified, acknowledges the issue, and it has been resolved.
ICANN's guidelines state that should a vendor be unresponsive, the issue will instead be turned over to a coordinator, which could include a national Computer Emergency Response Team (CERT) or ICANN itself.
What security researchers deem as responsible disclosure is commonly subjective, with some opting to publicly disclose their findings if the affected vendor is unresponsive for a certain period of time or a number of contact attempts.
The guidelines contain sections specific to ICANN, such as if a flaw is discovered that affects the root domain name servers.
In these cases, ICANN has made a commitment to respond to issue notifications by email within one business day, provide an initial assessment or estimate for when the issue will be resolved within two weeks, and supply ongoing updates to the reporter as needed.
The guidelines additionally set an example for any would-be reporters by committing ICANN to less subjective disclosure timeframes if it is the party that has discovered flaws. If ICANN is reporting vulnerabilities, it will attempt to contact the affected party via their domain name registration records; another coordinator, such as the respective CERT; or even through social media contacts.
"In these cases, ICANN will notify the affected party, but will wait for (secure) handling instructions from the affected party before submitting a detailed vulnerability report," it wrote.
As for the timeframes it has set, ICANN will wait up to 10 days for a response to its notification, depending on the issue's severity, after which it will escalate the issue to a coordinator to determine how the issue should be disclosed.
There have been several issues identified in the DNS in the past, one of the most notable being the 2008 Kaminsky Bug, named after its discoverer Dan Kaminsky. In simplified terms, it allowed an attacker to hijack a domain name server's database and provide incorrect IP addresses to victims.
At the time, the US CERT published an advisory highlighting the flaw, but not completely disclosing how it worked. Later, the coordinator responsible for ensuring that vendors were adequately informed, Paul Vixie, highlighted that due to the severity of the flaw, not everyone was trusted in case it went prematurely public. The Kaminsky Bug affected at least 37 vendors.