← Blog

gigafile.nu はなぜ突然消えたのか — ドメインは「期限切れ」以外でも止まる

2026-07-19

Also available in English: Read in English →

2026年7月6日の朝、ファイル転送サービス「ギガファイル便」（gigafile.nu）にアクセスできなくなる障害が発生しました。Xでは「送れない」「納品できない」といった投稿が相次ぎ（「納品できない」はそのまま報道の見出しにもなっています）、運営は同日夜、暫定ドメイン gigafile.jp への切り替えを発表しました。

公式発表と報道を整理すると、経過は次のとおりです。

  • 7月6日 9:00頃 — 障害発生（公式発表）
  • 10:38 — 公式Xが障害を告知
  • 15:30 — 代替ドメインで運用環境を構築中と報告
  • 19:55 — gigafile.jp への暫定変更を発表（ITmedia）
  • 7月8日 — gigafile.nu の復旧を告知

発生から暫定対応の発表まで約11時間かかっています。この間、サービス本体にも発行済みの共有URLにもアクセスできない状態が続きました。

サーバーダウンでも証明書切れでもなく、gigafile.nu というドメインそのものが使えなくなる障害でした。この記事では、ドメインが期限切れ以外の理由で止まる仕組みと、それを外側から検知する方法を整理します。

経過から分かること

運営元は技術的な原因を公表しておらず、公式の報告では「システム障害」とだけ説明されています。ただ、復旧までの経過からいくつかのことは読み取れます。

サーバーや回線の障害であれば、ドメインを差し替えても直りません。実際には、同じサービスを gigafile.jp に切り替えることで復旧し、発行済みのURLもドメイン部分を書き換えるだけで使えました（ITmediaの報道より）。サービスの基盤は動いていて、gigafile.nu というドメインだけが使えなくなっていた、ということです。

サーバーが無事なままドメインが丸ごと使えなくなるのは、DNSの委任が機能しなくなったときです。.nu の権威ゾーンから gigafile.nu への委任情報（NSレコード）が配信されなくなると、名前解決は NXDOMAIN（そのドメインは存在しない）を返すようになり、Webサイトもメールもサブドメインもまとめて到達不能になります。

ドメインを止めるステータスがある

ドメインには、レジストリ（TLDの管理者）とレジストラ（登録事業者）が付与する EPP ステータスという状態フラグがあります。このうちいくつかは、付与された時点でドメインが止まるものです。

ステータス意味引き金の典型例
serverHoldレジストリがDNSからドメインを外した不正利用報告、コンプライアンス措置、レジストリ判断
clientHoldレジストラがDNSからドメインを外した更新費未払い、WHOIS情報の確認未完了
redemptionPeriod期限切れ後の償還期間（有料で復元可能だがサイトは停止中）更新忘れ
pendingDelete数日以内に削除され、通常の手段では復元できない償還期間も経過
inactiveNSレコードがレジストリに未登録設定不備

serverHold や clientHold が付くと、委任がゾーンから外れて先ほどのNXDOMAINの状態になります。これらのステータスは期限日と関係なく付くことがあり、ICANNのWHOIS正確性確認のメールに誰も気づかなかった、という理由で clientHold になる事例は珍しくありません。

gigafile.nu が実際にどのケースに当たったのかは、公表されていないため分かりません。ただ、どのケースであっても共通するのは、期限日ベースの監視やレジストラからのリマインダーでは事前に検知できないことです。

気づきにくい理由

この種の停止は、ユーザーからの問い合わせで発覚することが多いようです。運営側からは意外と見えません。

  • 自分のサービスのトップページを毎朝開く人はいない。社内からはDNSキャッシュが残っている間、正常に見えていることもある
  • 期限日ベースの監視やリマインダーは、期限と無関係な停止には反応しない
  • 「繋がらない」という症状からDNS、委任、レジストリステータスと切り分けていくのは、障害対応の混乱の中では時間がかかる。gigafile のケースでは暫定対応まで約11時間かかっている

外側から検知する方法は2つ

ひとつは RDAP でレジストリステータスを監視する方法です。RDAP は WHOIS の後継にあたるHTTPS APIで、ドメインのEPPステータスを機械可読で返します。serverHold が付いたことを直接検知できます。ただし .jp や .nu を含む一部のTLDはRDAPに対応していません（IANAのブートストラップレジストリに未収録。2026年7月時点で確認）。つまり gigafile.nu 自体は、この方法では監視できなかったことになります。

もうひとつは名前解決そのものの監視です。外部のリゾルバから定期的に名前を引き、それまで解決できていたドメインがNXDOMAINを返し始めたら、委任が消えたと判断できます。こちらはTLDを問わず機能します。RDAP対応TLDであれば、検知した時点でRDAPを引いて原因まで特定できます。

RDAPは原因が分かる代わりに対応TLDが限られ、名前解決の監視は全TLDで使える代わりに原因までは分からないことがある、という補完関係です。

Certly の場合

Certly では、この2層の監視をそのまま提供しています。監視対象のドメインのレジストリステータスを定期的に確認し、serverHold / clientHold / redemptionPeriod などが付いた時点で通知します。名前解決ができなくなった場合（NXDOMAIN）はその場でRDAPを照会し、「名前解決できなくなりました。レジストリ状態: serverHold — レジストラに連絡してください」という形で、原因を添えてメールやSlackに通知します。

なお、この機能で停止を防げるわけではありません。serverHold は予兆なく付くためです。できるのは、ユーザーからの問い合わせより先に、原因の見当がついた状態で対応を始められるようにすることです。gigafile のタイムラインが示すように、障害対応で時間を取られるのは原因の特定です。

登録不要の無料チェッカーで任意のドメインのレジストリステータスを確認できるので、自分のドメインを一度見てみてください。

今すぐできる備え

  • レジストラの管理画面のログイン情報と緊急連絡先を、担当者以外にも共有しておく。停止時に最初に連絡する相手はレジストラです
  • 登録情報のメールアドレスを、実際に誰かが読むアドレスにしておく。clientHold の典型的な原因は確認メールの見落としです
  • whois か certly.dev/check で、自分のドメインの現在のステータスを一度確認しておく。clientTransferProhibited などのロック系が付いているのは正常な状態です

関連記事: 証明書運用のプロでも期限切れは起こる — nii.ac.jp の事例と、これから事故が増える構造的な理由

参考リンク