The Panix.com Domain Hijack: How a Five-Day Auto-Approval Rule Stole New York's Oldest ISP

For more than fifteen years, one of the oldest commercial internet providers in the United States lived at a single address: panix.com. Then, over a long holiday weekend in January 2005, someone took it.

Not by hacking a server. Not by guessing a password. They filled out a transfer form, paid with a stolen credit card, and waited for a brand-new ICANN rule to do the rest. Within hours the ownership of panix.com had been moved to a company in Australia, its DNS pointed at a host in the United Kingdom, and its email rerouted through Canada — all while the people who actually ran Panix slept through a Saturday night, having received no warning at all.

This is the story of how a piece of administrative paperwork, not an exploit, hijacked New York's oldest ISP — and how the cleanup helped rewrite the rules that govern who is allowed to move a domain.

A pioneering ISP whose whole business lived at one domain

Panix — Public Access Networks Corporation — was not a small story. Founded in 1989, it was, by Wikipedia's account, the third-oldest ISP in the world after The World and NetCom. It was a fixture of the early commercial internet in New York City: shell accounts, email, web hosting, the dial-up and then broadband connections that thousands of New Yorkers used to get online.

And like almost every internet business then and now, Panix's identity was its domain. Customer mailboxes ended in @panix.com. The web servers answered to www.panix.com. The whole company — its brand, its reachability, the thing that made a customer's email actually arrive — hung on the DNS records attached to one name. Lose control of that name, and you do not lose a marketing asset. You lose the business's nervous system.

That is exactly what happened.

January 2005: the fraudulent transfer

The legal account is precise about the day. As the law firm Davis Wright Tremaine summarized it at the time, on Friday, Jan. 14, 2005, a high-profile hijacking occurred when the domain name "panix.com," owned by the New York-based Internet service provider of the same name, was transferred without authorization to a third party.

By the small hours of that weekend, the consequences were live. The Register, reporting as the incident unfolded, described the redirection in one sentence that still reads like a heist diagram: the ownership of panix.com was moved to a company in Australia, the actual DNS records were moved to a company in the United Kingdom, and Panix.com's mail has been redirected to yet another company in Canada.

Slashdot, where the news broke to the wider technical community on January 16, put it bluntly: Panix, the oldest commercial Internet provider in New York, had its domain name 'panix.com' hijacked by persons unknown.

The most damning detail, from Panix's point of view, was the silence. The company established in 1989 and New York's oldest commercial ISPs, said neither it nor its registrar received any notification of the proposed changes. The transfer that took the domain away was, as far as the rightful owner could tell, completely invisible until it had already happened.

The disruption: web and email down for days

A hijacked domain is not a clean on/off switch — it is a slow, ugly fade, and the worst damage is the mail.

When you control a domain's DNS, you control where its email is delivered. By repointing panix.com's mail records, the hijackers turned themselves into the post office for an entire ISP's customer base. Inbound messages — bills, password resets, business correspondence, personal mail — stopped arriving at Panix and started flowing toward a server the attackers controlled. InfoWorld, reporting after the dust settled, noted that the hijacking deprived some Panix customers of e-mail access for two days, and that some of those customers may have lost a hundred or more messages over the weekend.

Mail that is misrouted during a hijack is not merely delayed. Much of it is gone — bounced, dropped, or silently swallowed by a server that was never supposed to receive it. For a provider whose customers measured the value of the service in "did my email arrive," days of misrouted mail was close to the worst possible outage.

And there was nothing the customers could do. The problem was not on Panix's machines, which were running fine. It was in the global routing table of the Domain Name System, which had been told — by a registrar in Australia, acting on a fraudulent request — that panix.com now belonged to someone else.

How it happened: the auto-approve transfer loophole

Here is the part that makes Panix a landmark case rather than just another bad weekend: nobody broke in. The system worked exactly as designed. The design was the vulnerability.

The mechanics ran through a chain of intermediaries. Panix's domain was registered with Dotster, a registrar in Vancouver, Washington. The fraudulent transfer was initiated through an account at Fibranet Services Ltd., a U.K.-based reseller, which submitted it up to Melbourne IT, a large registrar in Australia. As InfoWorld reported, an error by Melbourne IT Ltd. allowed fraudsters using stolen credit cards to take control of Panix.com — the account used for the transfer was fraudulent and set up with stolen credit cards.

But the credit card fraud only opened the account. What actually moved the domain was a policy. ICANN had introduced a new inter-registrar transfer process that had taken effect only weeks earlier, in November 2004, built around a principle of default approval. As The Register explained, under the new framework these rules, which came into effect last November, mean that inter-registry transfer requests are automatically approved after five days unless countermanded by the domain owner.

Read that again, because it is the whole story. Silence meant yes. If the rightful owner did nothing — because, for instance, they never received the notice — the transfer went through on its own. Davis Wright Tremaine described the same trap from the legal side: the new rules arguably make fraudulent transfers easier to accomplish because under the rules domains are automatically transferred unless the owner countermands the transfer request within five days.

Stack the failures and the picture is grim. The gaining registrar (Melbourne IT, via Fibranet) accepted a request backed by a stolen card and, by its own later admission, failed to properly verify the request. The losing registrar (Dotster) and the rightful owner (Panix) got no effective notice and so never countermanded anything. And the policy's default — approve unless someone objects — turned that absence of objection into a completed theft. No firewall was breached. The paperwork was the attack.

Recovery, and the policy reforms it triggered

Recovery, once humans got involved, was fast — and that is its own indictment, because it proved the transfer never should have been approved in the first place.

By Sunday, Panix had recovered its Panix.com domain from Australian domain hosting / registration firm Melbourne IT, where the purloined domain was parked, and pointed it back to its natural home at Dotster. The fix at the registry level was nearly instant; the global cleanup was not, because DNS does not forget on command. As The Register noted, root servers were updated quickly but the distributed nature of DNS meant it would take up to 24 hours before normality was fully restored — caches around the world had to expire before every user saw the real panix.com again.

Melbourne IT, to its credit, did not hide. Two days later The Register reported that an Australian domain registrar has admitted to its part in last weekend's domain name hijack, tracing the failure to a verification step in its transfer process that had not been performed and pledging that the loophole that allowed the error had been closed.

But the more important consequence was structural. Panix became the textbook example in the broader reckoning over transfer security that followed. ICANN's Security and Stability Advisory Committee published a 2005 report, Domain Name Hijacking: Incidents, Threats, Risks, and Remedial Actions, examining exactly this class of failure — registrars accepting transfers without confirming that the requester was actually the registrant. The lasting fixes that hardened the system trace directly back to weekends like this one:

• Registrar locks by default. A domain set to clientTransferProhibited simply refuses to transfer until the lock is removed by the rightful holder. What was once an obscure opt-in became, for many registrars, the default state — a brake the auto-approve rule could not override.
• Auth codes (EPP transfer codes). Modern gTLD transfers require a secret authorization code that the losing registrar releases only to the verified registrant, so a gaining registrar can no longer pull a domain on paperwork alone.
• A documented ICANN Transfer Policy with stricter confirmation duties and an emergency contact channel for reversing exactly this kind of fraudulent transfer fast.

The Panix hijack did not invent these mechanisms by itself, but it became the case everyone pointed to when arguing they were necessary.

What this teaches about transfer locks and verification

Strip away the dates and the registrar names, and Panix leaves a few durable lessons.

1. Default-allow is a security decision, and usually the wrong one. The single most dangerous design choice in 2005 was that silence equals consent. A transfer that completes when the owner does nothing assumes the owner is always watching and always reachable. Neither is true over a holiday weekend.
2. Identity must be verified by the party giving the asset away, not just the party taking it. The gaining registrar wanted the business and had every incentive to say yes. Real security came only when the losing registrar had to release an auth code to a verified holder — putting the verification where the asset actually lives.
3. Turn on the lock. clientTransferProhibited is the cheapest, most effective protection a domain owner has against this exact attack, and it costs nothing. A locked domain cannot be silently transferred no matter how convincing the paperwork is. Lock your important names and leave them locked.
4. Your domain is your single point of failure. Panix's servers were never compromised, yet the company was effectively offline. When one record in a registry can redirect your entire web and email presence, that record deserves more protection than your servers do.
5. Watch the notices. The five-day countermand window only protects an owner who actually receives — and reads — the transfer notice. Stale registrant email, an unmonitored admin contact, or a holiday weekend turns a safety valve into a silent failure.

The Namefi angle

The Panix hijack is, at its heart, an authority problem. The question "who is allowed to move this domain?" was answered by a chain of resellers and a default-approve timer rather than by any strong, verifiable proof of ownership. A stolen credit card and five days of silence were enough to satisfy the system that a stranger in another hemisphere spoke for an ISP in New York.

Namefi starts from the opposite premise: that control of a domain should be provable, not assumed. By representing domain ownership as a tokenized, on-chain asset that stays compatible with DNS, the act of "who holds this name" becomes cryptographically verifiable and auditable — a record that cannot be quietly overwritten by a registrar accepting bad paperwork. Transfers move when the holder's key authorizes them, not when a five-day clock runs out unattended. The default is deny, and consent has to be demonstrated, not merely un-objected-to.

None of this existed in 1989 when Panix was founded — or even in 2005, when the hijack happened. But it points at the lesson that weekend taught the whole industry: a domain is too important to be governed by silence. Ownership should be something you can prove on demand — and something a stranger cannot take simply because you weren't watching the inbox over a long weekend.

Sources and further reading

• The Register — Panix recovers from domain hijack
• The Register — Panix.com hijack: Aussie firm shoulders blame
• Davis Wright Tremaine — Guarding Against Domain Name Hijacking
• InfoWorld — Australian company takes blame for Panix domain hijack
• Slashdot — New York's Oldest ISP Gets Domain-Jacked
• Wikipedia — Panix (ISP)
• Wikipedia — Domain hijacking
• ICANN SSAC — Domain Name Hijacking: Incidents, Threats, Risks, and Remedial Actions (2005)
• ICANN — Transfer Policy
• NANOG mailing list archive — discussion of the panix.com transfer and ICANN remedies