The Perl.com Domain Theft: How a 30-Year-Old Community Home Was Quietly Stolen

Some domains are infrastructure that happens to look like a name. perl.com is one of them. It is not a marketing asset or a brand someone built last year — it is a piece of internet furniture that the Perl programming community has lived around since the early days of the web, the canonical front door to documentation, articles, and the language's public face.

So when, on the morning of January 27, 2021, that front door suddenly belonged to someone else, it was not a clever brand play or a negotiated sale. It was a theft. The domain had been quietly pried out of its rightful owner's control months earlier, bounced through registrars, and pointed at an IP address with a history of distributing malware. The community's own network operators put it bluntly: "The perl.com domain was hijacked this morning, and is currently pointing to a parking site."

This is the story of EP19 in our Domain Mayday series: how a thirty-year-old community domain was stolen without anyone breaking a single server, and what it took to get it back.

A domain held since the early 90s

To understand the theft, you have to understand how ordinary the setup was — and how that ordinariness was the vulnerability.

perl.com was not held inside some hardened corporate vault. It was held the way most long-lived domains are held: by one trusted person, at a mainstream registrar, renewed year after year without drama. The site's editor, brian d foy, later described the lineage in his own account of the incident: "This domain was registered in the early 90s, Tom Christiansen was given control of it shortly after that, and basically kept paying the registration fees."

That is the entire profile of a huge fraction of the internet's most important names. A person, a registrar login, and three decades of quietly paying the bill. It works perfectly — right up until the registrar account itself becomes the target.

January 27, 2021: the front door changes locks

The first public alarm came from the people who run the Perl community's infrastructure. The Perl NOC (Network Operations Center) blog posted that the domain had been hijacked "this morning" and was now pointing somewhere it should not. Worse than a simple parking page, the operators warned that "there are some signals that it may be related to sites that have distributed malware in the past."

brian d foy raised it publicly the same day. Reporting on the incident confirmed the timing in plain terms: "On January 27th, Perl programming author and Perl.com editor brian d foy tweeted that the perl.com domain was suddenly registered under another person."

The community's response was fast and pragmatic. While recovery work began, the NOC redirected readers to a backup: "If you're looking for the content, you can visit perldotcom.perl.org." The canonical name was gone, but the content stayed reachable.

What was at risk: a malware-linked IP

A stolen domain is dangerous in proportion to the trust it carries — and perl.com carried a lot. Millions of developers, tutorials, CPAN tooling, and old links across the web all pointed at it. Whoever controlled the name controlled what all that trust resolved to.

And the new owner did not point it somewhere harmless. As BleepingComputer documented, "The domain name perl.com was stolen and now points to an IP address associated with malware campaigns."

The technical fingerprints were specific. The DNS records were rewritten so that "the IP addresses assigned to the domain were changed from 151.101.2.132 to the Google Cloud IP address 35.186.238[.]101." That destination had a past: "In 2019, the IP address 35.186.238[.]101 was tied to a domain distributing a malware executable for the now-defunct Locky ransomware."

Stack those two facts and the danger is obvious. A name that developers reflexively trust, suddenly resolving to an IP with a malware history, is a near-perfect setup for tricking exactly the kind of technical, security-aware audience that is normally hard to fool.

How it happened: the registrar account, not the server

Here is the part that makes this incident a textbook case rather than a footnote: nobody hacked perl.com's web server, and nobody guessed a DNS password. The attack happened one layer up, at the registrar — the company that holds the authoritative record of who owns the name.

In his post-mortem, brian d foy described the working theory directly: "We think that there was a social engineering attack on Network Solutions, including phony documents and so on." The press framed it the same way: the theft was "a social engineering attack that convinced registrar Network Solutions to alter the domain's records without valid authorization."

The most unsettling detail is the timeline. The community only noticed in January, but the actual compromise was far older. Forensic work surfaced by domain attorney John Berryhill pushed the real date back months; as the perl.com account records, "John Berryhill provided some forensic work in Twitter that showed the compromise actually happened in September." SecurityWeek confirmed the attacker's patience: "The attack, he explains, took place in September 2020" — roughly four months before anyone saw the effects.

Why the long wait? Because the rules of domain transfers reward patience. "ICANN prohibits the transfer of a domain for 60 days following the updating of contact info." An attacker who quietly seizes a registrar account in September cannot immediately whisk the domain away — so they sat on it, let the clock run, and made their move once the lock expired.

When they finally moved, they laundered the name through registrars and borders to make recovery harder. The Register documented the first hop: "The domain was transferred to the BizCN registrar in December, but the nameservers were not changed." BleepingComputer traced the same path geographically: the domain "was stolen in September 2020 while at Network Solutions, transferred to a registrar in China on Christmas Day" before the final hop in January, when "The domain was transferred again in January to another registrar, Key Systems, GmbH."

And then they tried to cash out. With the name freshly relocated, "the unauthorized registrant tried to sell the domain for $190,000 on domain market Afternic." A thirty-year-old community asset, stolen via paperwork, listed for sale like used furniture.

The recovery: weeks of paperwork to undo paperwork

The same machinery that let the theft happen — registrars, registries, and ownership records — was also the only path back. There was no server to re-secure and no patch to deploy. Someone had to prove, through the registrar and registry chain, that Tom Christiansen was the real owner and the new "owner" was a fraud.

That work started within days. By January 30, the Perl NOC reported that "Network Solutions is working with Tom Christiansen, the rightful registrant, on the recovery of the Perl.com domain." The push "ultimately led to the restoration of the domain to its previous owner, Tom Christiansen, in early February."

But "restored" did not mean "fixed." brian d foy's own framing captures both the relief and the unfinished work: "The Perl.com domain is back in the hands of Tom Christiansen and we're working on the various security updates so this doesn't happen again." Because the domain had pointed at a malware-linked IP, security products had blacklisted it and some DNS resolvers were sinkholing it. Even after the registry record was correct, it took additional weeks for the name to be trusted again across the internet's reputation systems — a long tail that stretched the full ordeal across roughly two months.

The headline, in foy's words, was almost understated: "For a week we lost control of the Perl.com domain." A week of active theft; months of latent compromise before it; weeks of cleanup after.

What this teaches about registrar account security and long-held domains

The perl.com theft is so instructive precisely because nothing exotic happened. Strip it down and the lessons are uncomfortably general:

1. Your registrar account is the real crown jewel. Everyone hardens their servers and their DNS host. But the domain's ownership record lives at the registrar, and that account is often protected by little more than a password and a support team that can be talked into changes. perl.com was stolen there, not at the edge.

2. Social engineering beats technical controls. No exploit, no malware on the victim's side — just "phony documents and so on" persuasive enough to move a real record. Two-factor authentication on your own login does not help if the registrar's humans can be convinced to override it.

3. Long-held domains are soft targets. A name registered in the early 90s and renewed on autopilot for thirty years tends to accumulate stale contact info, a single point of human failure, and an owner who isn't watching the WHOIS record daily. Quiet stability is exactly what lets a September compromise go unnoticed until January.

4. The transfer rules cut both ways. The 60-day post-update transfer lock that is supposed to protect owners became the attacker's waiting room. Patience plus laundering across registrars and borders turned a quick fix into a multi-party, multi-week recovery.

5. Recovery is slower than theft. Stealing the name took a forged document. Getting it back took registrars, a registry, the rightful owner's evidence, and then weeks of rebuilding reputation with blocklists and resolvers. Theft is one transaction; restitution is many.

The grim summary: for a domain like perl.com, the strength of your password matters less than whether your registrar can be tricked into ignoring it.

The Namefi angle

Every step of the perl.com theft turned on one weakness: ownership was a record in someone else's account, changeable by whoever could persuade the right support agent. The attacker never needed the owner's keys. They needed the registrar's trust — and a forged slip of paper was enough to transfer a thirty-year-old asset across the planet and list it for sale.

Namefi is built around the opposite premise: that domain ownership should be cryptographically verifiable and hard to silently rewrite. By representing domain control as a tokenized, on-chain asset that stays compatible with DNS, the authoritative answer to "who owns this name?" stops being a mutable line in a registrar's database that a convincing phone call can flip. Transfers become signed, auditable events rather than back-office paperwork — and a fraudulent "change of ownership" has no quiet door to walk through.

It would not have made perl.com un-stealable overnight; registrars and registries are still part of the chain. But it attacks the exact failure mode that defined this incident — the gap between paying for a name for thirty years and being able to prove, tamper-resistantly, that it is yours — and it shrinks the window where a stolen domain can be laundered before anyone can object.

perl.com got its front door back. The harder question this episode leaves behind is why the lock was ever something a stranger with the right paperwork could open.

Sources and further reading

• The Perl NOC — perl.com hijacked
• perl.com (brian d foy) — The Hijacking of Perl.com
• BleepingComputer — Perl.com domain stolen, now using IP address tied to malware
• The Register — Perl.com theft blamed on social engineering attack
• SecurityWeek — Hackers Controlled Perl.com Domain Months Before Hijack
• Security Affairs — Attackers took over the Perl.com domain in September 2020
• The Daily Swig (PortSwigger) — Domain for popular programming website Perl.com stolen in 'hack'
• Slashdot — Perl.com Domain Stolen, Now Using IP Address of Past Malware Campaigns
• INCIBE-CERT — The perl.com domain has been hijacked
• GIGAZINE — Perl.com editors tell the truth about the Perl.com domain hijacking case