Why gigafile.nu suddenly vanished — domains can stop working without expiring

On the morning of July 6, 2026, GigaFile (gigafile.nu), one of the most widely used file-transfer services in Japan, became unreachable. Posts from freelancers who suddenly couldn’t deliver files to clients spread quickly (“can’t deliver my work” ended up in news headlines), and that evening the operator switched the whole service to a temporary domain, gigafile.jp.

Based on the official announcements and press coverage, the timeline was (all times JST):

July 6, ~9:00 — outage begins (official notice)
10:38 — the official X account acknowledges the outage
15:30 — the operator reports it is setting up an environment on an alternative domain
19:55 — the temporary switch to gigafile.jp is announced (ITmedia)
July 8 — gigafile.nu is restored

Getting from the start of the outage to a workaround took about eleven hours, and for that whole window the service and every previously issued sharing URL were unreachable.

The cause wasn’t a server crash or an expired certificate. The domain itself had stopped working. This post goes through how that can happen to a domain that hasn’t expired, and how to detect it from the outside.

What the recovery path tells us

The operator hasn’t published a technical root cause; its official report describes the event only as a “system failure”. The way the service recovered still says a lot.

A server or network failure isn’t fixed by changing domains. GigaFile recovered by pointing the same service at gigafile.jp, and previously issued sharing URLs worked once the domain part was rewritten (per ITmedia’s coverage). The infrastructure was running; only the gigafile.nu domain had stopped working.

A domain failing outright while the servers behind it stay healthy points to broken DNS delegation. When the NS records for a domain stop being served from the .nu zone, resolvers everywhere return NXDOMAIN (“this domain does not exist”), and the website, email, and every subdomain become unreachable together.

The statuses that stop a domain

Every domain carries EPP status flags assigned by the registry (the TLD operator) and the registrar. Several of them stop the domain outright:

Status	Meaning	Typical trigger
`serverHold`	The registry removed the domain from DNS	Abuse reports, compliance action, registry decision
`clientHold`	The registrar removed the domain from DNS	Unpaid renewal, incomplete WHOIS verification
`redemptionPeriod`	Post-expiry grace period (restorable for a fee, but offline)	Missed renewal
`pendingDelete`	Deletion within days; no ordinary recovery	Redemption period also missed
`inactive`	No nameservers registered at the registry	Misconfiguration

When serverHold or clientHold is applied, the delegation is removed from the zone, producing exactly the NXDOMAIN failure mode described above. These statuses can appear at any point in a domain’s life, independent of the expiry date. Domains end up on clientHold every day for reasons as mundane as a WHOIS verification email that nobody read.

The operator hasn’t disclosed which of these, if any, applied to gigafile.nu. None of them, though, would show up in date-based monitoring or a registrar’s reminder emails.

Why operators find out last

Suspensions like this tend to be discovered through user reports rather than by the operator, for a few reasons:

Nobody opens their own site every morning, and DNS caches can keep it working from inside the office for a while
Date-based monitoring has nothing to react to, because nothing expired
Getting from “the site is down” to “the registry pulled our delegation” takes time in the middle of an incident. In GigaFile’s case, the gap between onset and a workaround was around eleven hours

Detecting it from the outside

There are two practical approaches.

The first is watching the registry status over RDAP. RDAP is the HTTPS successor to WHOIS and returns a domain’s EPP statuses in machine-readable form, so a monitor can catch serverHold when it appears. The limitation is TLD coverage: some TLDs, including .jp and .nu, are absent from the IANA RDAP bootstrap registry as of July 2026. gigafile.nu itself couldn’t have been monitored this way.

The second is watching name resolution. Query the domain periodically from external resolvers; if a domain that used to resolve starts returning NXDOMAIN, the delegation is gone. This works on every TLD, and on RDAP-supported TLDs the monitor can query RDAP at detection time to find out why.

The two approaches complement each other: RDAP explains the cause but has coverage gaps, while NXDOMAIN detection works on every TLD but doesn’t tell you why.

Where Certly fits

Certly does both. It checks the registry status of every monitored domain periodically and alerts when a dangerous status (serverHold, clientHold, redemptionPeriod, and so on) appears. When a domain stops resolving, it queries RDAP on the spot and includes the result, so the alert reads: “example.com is no longer resolving. Registry status: serverHold — contact your registrar.”

One caveat: this is detection, not prevention. A serverHold can land without warning, and no monitoring will stop that. The difference is starting the incident already knowing what happened, rather than spending the first hours working it out.

The free checker shows the registry status of any domain without signup, if you want to see what yours looks like.

A few precautions worth taking

Make sure someone besides “the domain person” can log into the registrar account and knows the emergency contact. The registrar is the first call when a suspension happens
Keep the registration contact email pointed at an inbox somebody actually reads. An unanswered verification email is the classic path to clientHold
Check your domain’s statuses once, with whois or certly.dev/check. Lock statuses like clientTransferProhibited are a good sign. If yours has none at all, turning on the registrar’s transfer lock is an easy fix

Sources

GigaFile official: outage notice / recovery notice / incident report (Japanese)
ITmedia: outage coverage / “can’t deliver my work” coverage (Japanese)
RFC 8056 (EPP/RDAP status mapping), IANA RDAP Bootstrap Registry