Login
More than five years after domain name registrars started redacting personal data from all public domain registration records, the non-profit organization overseeing the domain industry has introduced a centralized online service designed to make it easier for researchers, law enforcement and others to request the information directly from registrars.
In May 2018, the Internet Corporation for Assigned Names and Numbers (ICANN) — the nonprofit entity that manages the global domain name system — instructed all registrars to redact the customer’s name, address, phone number and email from WHOIS, the system for querying databases that store the registered users of domain names and blocks of Internet address ranges.
ICANN made the policy change in response to the General Data Protection Regulation (GDPR), a law enacted by the European Parliament that requires companies to gain affirmative consent for any personal information they collect on people within the European Union. In the meantime, registrars were to continue collecting the data but not publish it, and ICANN promised it would develop a system that facilitates access to this information.
At the end of November 2023, ICANN launched the Registration Data Request Service (RDRS), which is designed as a one-stop shop to submit registration data requests to participating registrars. This video from ICANN walks through how the system works.
Accredited registrars don’t have to participate, but ICANN is asking all registrars to join and says participants can opt out or stop using it at any time. ICANN contends that the use of a standardized request form makes it easier for the correct information and supporting documents to be provided to evaluate a request.
ICANN says the RDRS doesn’t guarantee access to requested registration data, and that all communication and data disclosure between the registrars and requestors takes place outside of the system. The service can’t be used to request WHOIS data tied to country-code top level domains (CCTLDs), such as those ending in .de (Germany) or .nz (New Zealand), for example.
The RDRS portal.
As Catalin Cimpanu writes for Risky Business News, currently investigators can file legal requests or abuse reports with each individual registrar, but the idea behind the RDRS is to create a place where requests from “verified” parties can be honored faster and with a higher degree of trust.
The registrar community generally views public WHOIS data as a nuisance issue for their domain customers and an unwelcome cost-center. Privacy advocates maintain that cybercriminals don’t provide their real information in registration records anyway, and that requiring WHOIS data to be public simply causes domain registrants to be pestered by spammers, scammers and stalkers.
Meanwhile, security experts argue that even in cases where online abusers provide intentionally misleading or false information in WHOIS records, that information is still extremely useful in mapping the extent of their malware, phishing and scamming operations. What’s more, the overwhelming majority of phishing is performed with the help of compromised domains, and the primary method for cleaning up those compromises is using WHOIS data to contact the victim and/or their hosting provider.
Anyone looking for copious examples of both need only to search this Web site for the term “WHOIS,” which yields dozens of stories and investigations that simply would not have been possible without the data available in the global WHOIS records.
KrebsOnSecurity remains doubtful that participating registrars will be any more likely to share WHOIS data with researchers just because the request comes through ICANN. But I look forward to being wrong on this one, and will certainly mention it in my reporting if the RDRS proves useful.
Regardless of whether the RDRS succeeds or fails, there is another European law that takes effect in 2024 which is likely to place additional pressure on registrars to respond to legitimate WHOIS data requests. The new Network and Information Security Directive (NIS2), which EU member states have until October 2024 to implement, requires registrars to keep much more accurate WHOIS records, and to respond within as little as 24 hours to WHOIS data requests tied everything from phishing, malware and spam to copyright and brand enforcement.
The domain name registrar Freenom, whose free domain names have long been a draw for spammers and phishers, has stopped allowing new domain name registrations. The move comes after the Dutch registrar was sued by Meta, which alleges the company ignores abuse complaints about phishing websites while monetizing traffic to those abusive domains.
Freenom’s website features a message saying it is not currently allowing new registrations.
Freenom is the domain name registry service provider for five so-called “country code top level domains” (ccTLDs), including .cf for the Central African Republic; .ga for Gabon; .gq for Equatorial Guinea; .ml for Mali; and .tk for Tokelau.
Freenom has always waived the registration fees for domains in these country-code domains, presumably as a way to encourage users to pay for related services, such as registering a .com or .net domain, for which Freenom does charge a fee.
On March 3, 2023, social media giant Meta sued Freenom in a Northern California court, alleging cybersquatting violations and trademark infringement. The lawsuit also seeks information about the identities of 20 different “John Does” — Freenom customers that Meta says have been particularly active in phishing attacks against Facebook, Instagram, and WhatsApp users.
The lawsuit points to a 2021 study (PDF) on the abuse of domains conducted by Interisle Consulting Group, which discovered that those ccTLDs operated by Freenom made up five of the Top Ten TLDs most abused by phishers.
“The five ccTLDs to which Freenom provides its services are the TLDs of choice for cybercriminals because Freenom provides free domain name registration services and shields its customers’ identity, even after being presented with evidence that the domain names are being used for illegal purposes,” the complaint charges. “Even after receiving notices of infringement or phishing by its customers, Freenom continues to license new infringing domain names to those same customers.”
Meta further alleges that “Freenom has repeatedly failed to take appropriate steps to investigate and respond appropriately to reports of abuse,” and that it monetizes the traffic from infringing domains by reselling them and by adding “parking pages” that redirect visitors to other commercial websites, websites with pornographic content, and websites used for malicious activity like phishing.
Freenom has not yet responded to requests for comment. But attempts to register a domain through the company’s website as of publication time generated an error message that reads:
“Because of technical issues the Freenom application for new registrations is temporarily out-of-order. Please accept our apologies for the inconvenience. We are working on a solution and hope to resume operations shortly. Thank you for your understanding.”
Image: Interisle Consulting Group, Phishing Landscape 2021, Sept. 2021.
Although Freenom is based in The Netherlands, some of its other sister companies named as defendants in the lawsuit are incorporated in the United States.
Meta initially filed this lawsuit in December 2022, but it asked the court to seal the case, which would have restricted public access to court documents in the dispute. That request was denied, and Meta amended and re-filed the lawsuit last week.
According to Meta, this isn’t just a case of another domain name registrar ignoring abuse complaints because it’s bad for business. The lawsuit alleges that the owners of Freenom “are part of a web of companies created to facilitate cybersquatting, all for the benefit of Freenom.”
“On information and belief, one or more of the ccTLD Service Providers, ID Shield, Yoursafe, Freedom Registry, Fintag, Cervesia, VTL, Joost Zuurbier Management Services B.V., and Doe Defendants were created to hide assets, ensure unlawful activity including cybersquatting and phishing goes undetected, and to further the goals of Freenom,” Meta charged.
It remains unclear why Freenom has stopped allowing domain registration. In June 2015, ICANN suspended Freenom’s ability to create new domain names or initiate inbound transfers of domain names for 90 days. According to Meta, the suspension was premised on ICANN’s determination that Freenom “has engaged in a pattern and practice of trafficking in or use of domain names identical or confusingly similar to a trademark or service mark of a third party in which the Registered Name Holder has no rights or legitimate interest.”
A spokesperson for ICANN said the organization has no insight as to why Freenom might have stopped registering domain names. But it said Freenom (d/b/a OpenTLD B.V.) also received formal enforcement notices from ICANN in 2017 and 2020 for violating different obligations.
A copy of the amended complaint against Freenom, et. al, is available here (PDF).
March 8, 6:11 p.m. ET: Updated story with response from ICANN. Corrected attribution of the domain abuse report.
Every few months, an important ceremony takes place. It’s not splashed all over the news, and it’s not attended by global dignitaries. It goes unnoticed by many, but its effects are felt across the globe. This ceremony helps make the internet more secure for billions of people.
This unique ceremony began in 2010 when Verisign, the Internet Corporation for Assigned Names and Numbers (ICANN), and the U.S. Department of Commerce’s National Telecommunications and Information Administration collaborated – with input from the global internet community – to deploy a technology called Domain Name System Security Extensions (DNSSEC) to the Domain Name System (DNS) root zone in a special ceremony. This wasn’t a one-off occurrence in the history of the DNS, though. Instead, these organizations developed a set of processes, procedures, and schedules that would be repeated for years to come. Today, these recurring ceremonies help ensure that the root zone is properly signed, and as a result, the DNS remains secure, stable, and resilient.
In this blog, we take the opportunity to explain these ceremonies in greater detail and describe the critical role that Verisign is honored to perform.
DNSSEC is a series of technical specifications that allow operators to build greater security into the DNS. Because the DNS was not initially designed as a secure system, DNSSEC represented an essential leap forward in securing DNS communications. Deploying DNSSEC allows operators to better protect their users, and it helps to prevent common threats such as “man-in-the-middle” attacks. DNSSEC works by using public key cryptography, which allows zone operators to cryptographically sign their zones. This allows anyone communicating with and validating a signed zone to know that their exchanges are genuine.
The root zone, like most signed zones, uses separate keys for zone signing and for key signing. The Key Signing Key (KSK) is separate from the Zone Signing Key (ZSK). However, unlike most zones, the root zone’s KSK and ZSK are operated by different organizations; ICANN serves as the KSK operator and Verisign as the ZSK operator. These separate roles for DNSSEC align naturally with ICANN as the Root Zone Manager and Verisign as the Root Zone Maintainer.
In practice, the KSK/ZSK split means that the KSK only signs the DNSSEC keys, and the ZSK signs all the other records in the zone. Signing with the KSK happens infrequently – only when the keys change. However, signing with the ZSK happens much more frequently – whenever any of the zone’s other data changes.
Something to keep in mind before we go further: remember that DNSSEC utilizes public key cryptography, in which keys have both a private and public component. The private component is used to generate signatures and must be guarded closely. The public component is used to verify signatures and can be shared openly. Good cryptographic hygiene says that these keys should be changed (or “rolled”) periodically.
In DNSSEC, changing a KSK is generally difficult, whereas changing a ZSK is relatively easy. This is especially true for the root zone where a KSK rollover requires all validating recursive name servers to update their copy of the trust anchor. Whereas the first and only KSK rollover to date happened after a period of eight years, ZSK rollovers take place every three months. Not coincidentally, this is also how often root zone key signing ceremonies take place.
The notion of holding a “ceremony” for such an esoteric technical function may seem strange, but this ceremony is very different from what most people are used to. Our common understanding of the word “ceremony” brings to mind an event with speeches and formal attire. But in this case, the meaning refers simply to the formality and ritual aspects of the event.
There are two main reasons for holding key signing ceremonies. One is to bring participants together so that everyone may transparently witness the process. Ceremony participants include ICANN staff, Verisign staff, Trusted Community Representatives (TCRs), and external auditors, plus guests on occasion.
The other important reason, of course, is to generate DNSSEC signatures. Occasionally other activities take place as well, such as generating new keys, retiring equipment, and changing TCRs. In this post, we’ll focus only on the signature generation procedures.
A month or two before each ceremony, Verisign generates a file called the Key Signing Request (KSR). This is an XML document which includes the set of public key records (both KSK and ZSK) to be signed and then used during the next calendar quarter. The KSR is securely transmitted from Verisign to the Internet Assigned Numbers Authority (IANA), which is a function of ICANN that performs root zone management. IANA securely stores the KSR until it is needed for the upcoming key signing ceremony.
Each quarter is divided into nine 10-day “slots” (for some quarters, the last slot is extended by a day or two) and the XML file contains nine key “bundles” to be signed. Each bundle, or slot, has a signature inception and expiration timestamp, such that they overlap by at least five days. The first and last slots in each quarter are used to perform ZSK rollovers. During these slots we publish two ZSKs and one KSK in the root zone.
The root zone KSK private component is held inside secure Hardware Security Modules (HSMs). These HSMs are stored inside locked safes, which in turn are kept inside locked rooms. At a key signing ceremony, the HSMs are taken out of their safes and activated for use. This all occurs according to a pre-defined script with many detailed steps, as shown in the figure below.
Also stored inside the safe is a laptop computer, its operating system on non-writable media (i.e., DVD), and a set of credentials for the TCRs, stored on smart cards and locked inside individual safe deposit boxes. Once all the necessary items are removed from the safes, the equipment can be turned on and activated.
The laptop computer is booted from its operating system DVD and the HSM is connected via Ethernet for data transfer and serial port for console logging. The TCR credentials are used to activate the HSM. Once activated, a USB thumb drive containing the KSR file is connected to the laptop and the signing program is started.
The signing program reads the KSR, validates it, and then displays information about the keys about to be signed. This includes the signature inception and expiration timestamps, and the ZSK key tag values.
FreshRSS 
Validate and Process KSR /media/KSR/KSK46/ksr-root-2022-q4-0.xml...
# Inception Expiration ZSK Tags KSK Tag(CKA_LABEL)
1 2022-10-01T00:00:00 2022-10-22T00:00:00 18733,20826
2 2022-10-11T00:00:00 2022-11-01T00:00:00 18733
3 2022-10-21T00:00:00 2022-11-11T00:00:00 18733
4 2022-10-31T00:00:00 2022-11-21T00:00:00 18733
5 2022-11-10T00:00:00 2022-12-01T00:00:00 18733
6 2022-11-20T00:00:00 2022-12-11T00:00:00 18733
7 2022-11-30T00:00:00 2022-12-21T00:00:00 18733
8 2022-12-10T00:00:00 2022-12-31T00:00:00 18733
9 2022-12-20T00:00:00 2023-01-10T00:00:00 00951,18733
...PASSED.
It also displays an SHA256 hash of the KSR file and a corresponding “PGP (Pretty Good Privacy) Word List.” The PGP Word List is a convenient and efficient way of verbally expressing hexadecimal values:
SHA256 hash of KSR:
ADCE9749F3DE4057AB680F2719B24A32B077DACA0F213AD2FB8223D5E8E7CDEC
>> ringbolt sardonic preshrunk dinosaur upset telephone crackdown Eskimo rhythm gravity artist celebrate bedlamp pioneer dogsled component ruffled inception surmount revenue artist Camelot cleanup sensation watchword Istanbul blowtorch specialist trauma truncated spindle unicorn <<
At this point, a Verisign representative comes forward to verify the KSR. The following actions then take place:
The signing program outputs a new XML document, called the Signed Key Response (SKR). This document contains signatures over the DNSKEY resource record sets in each of the nine slots. The SKR is saved to a USB thumb drive and given to a member of the Root Zone KSK Operations Security team. Usually sometime the next day, IANA securely transmits the SKR back to Verisign. Following several automatic and manual verification steps, the signature data is imported into Verisign’s root zone management system for use at the appropriate times in the next calendar quarter.
Keeping the internet’s DNS secure, stable, and resilient is a crucial aspect of Verisign’s role as the Root Zone Maintainer. We are honored to participate in the key signing ceremonies with ICANN and the TCRs and do our part to help the DNS operate as it should.
For more information on root key signing ceremonies, visit the IANA website. Visitors can watch video recordings of previous ceremonies and even sign up to witness the next ceremony live. It’s a great resource, and a unique opportunity to take part in a process that helps keep the internet safe for all.
The post Verisign’s Role in Securing the DNS Through Key Signing Ceremonies appeared first on Verisign Blog.
As we passed five years since the Internet Assigned Numbers Authority transition took place, my co-authors and I paused to look back on this pivotal moment; to take stock of what we’ve learned and to re-examine some of the key events leading up to the transition and how careful planning ensured a successful transfer of IANA responsibilities from the United States Government to the Internet Corporation for Assigned Names and Numbers. I’ve excerpted the main themes from our work, which can be found in full on the Internet Governance Project blog.
In March 2014, the National Telecommunications and Information Administration, a division of the U.S. Department of Commerce, announced its intent to “transition key Internet domain name functions to the global multi-stakeholder community” and asked ICANN to “convene global stakeholders to develop a proposal to transition the current role played by NTIA in the coordination of the Internet’s domain name system.” This transition, as announced by NTIA, was a natural progression of ICANN’s multi-stakeholder evolution, and an outcome that was envisioned by its founders.
While there was general support for a transition to the global multi-stakeholder community, many in the ICANN community raised concerns about ICANN’s accountability, transparency and organizational readiness to “stand alone” without NTIA’s legacy supervision. In response, the ICANN community began a phase of intense engagement to ensure a successful transition with all necessary accountability and transparency structures and mechanisms in place.
As a result of this meticulous planning, we believe the IANA functions have been well-served by the transition and the new accountability structures designed and developed by the ICANN community to ensure the security, stability and resiliency of the internet’s unique identifiers.
But what does the future hold? While ICANN’s multi-stakeholder processes and accountability structures are functioning, even in the face of a global pandemic that interrupted our ability to gather and engage in person, they will require ongoing care to ensure they deliver on the original vision of private-sector-led management of the DNS.
The post ICANN’s Accountability and Transparency – a Retrospective on the IANA Transition appeared first on Verisign Blog.
