DreamHostとAS26347：共有ホスティングの継続性を左右するDNS、バックアップ、顧客側の管理

要約

ARINはAS26347をアクティブなDREAMHOST-ASとして登録し、登録主体をNew Dream Network, LLCとしている。取得したRIPEstatの観測ではASNはアナウンス中で、27件のプレフィックスが確認された。これは目に見えるネットワーク識別情報だが、特定サイトやデータベース、購入処理の可用性を保証するものではない。
DreamHostの資料は、ドメイン登録、ネームサーバー、DNSレコード、キャッシュ、ウェブファイル、MySQL、ステータス通知、サポートチケットを別々の層として説明する。通常のバックアップは保証されず、顧客自身のローカルまたは外部コピーが推奨されている。したがって継続性には、顧客側の資産台帳、監視、復旧可能な権限、実際のリストア試験が必要になる。

DreamHost, LLCはBTWディレクトリに公開済みの企業エンティティとして登録されている。同社の概要資料には、ウェブホスティング、マネージドVPS、専用サーバー、マネージドWordPress、メール、ドメイン登録、オブジェクトストレージ、クラウドコンピューティングが並ぶ。同じブランドやアカウントから購入できても、これらは同じ技術対象ではなく、責任分担も同じではない。

小規模事業者にとってウェブサイトは、ドメインと数ページと月額料金だけに見えるかもしれない。実際には長い連鎖がある。ドメインは更新され、正しいネームサーバーへ委任されなければならない。DNSレコードは意図した宛先を示し、インターネット経路は通信を運び、ファイルとデータベースは整合し、証明書、メール、外部サービスも動かなければならない。さらに、障害を検知して判断できる権限者が必要だ。

本稿はDreamHostで特定の障害が起きたと主張するものではなく、非公開の構成を推測するものでもない。公開レジストリとルーティング観測、運用者が管理する相互接続情報、DreamHostのヘルプ資料と規約を使い、それぞれの証拠が何を支え、どこから先を支えないかを整理する。

この区別は技術者以外にも重要だ。「ASNが見える」「サーバーが応答する」「トップページが開く」「顧客が注文を完了できる」は別々の結論である。一つの緑色ランプにまとめると、事業が復旧していないのにインシデントを閉じる危険がある。

掲載画像はBTW Media向けに生成したフォトリアルな編集用シーンで、身元を特定できない作業者が一般的な机で復旧チェックリストを確認し、背後に無印のネットワークラックが見える。DreamHost、New Dream Network、従業員、施設、顧客、機器、事故、性能、推奨を表す実写ではない。

レジストリは識別情報を保つが、サイトの結果は保証しない

ARINのRDAP応答はAS26347をDREAMHOST-ASとし、状態をactiveとしている。ASN、すなわち自律システム番号は、あるネットワークが他のネットワークと経路情報を交換するときに使う一意の番号だ。専門外の読者には、インターネットの道路地図にある運用主体の標識と考えると分かりやすい。

記録は登録主体をNew Dream Network, LLCとし、技術およびネットワーク運用の連絡役としてDreamhost NetOPs、別にabuse連絡先を掲載している。取得した記録には2002年8月28日の登録イベントと、2015年8月31日の最終変更イベントがある。

この情報は運用調整に役立つ。他のネットワークは経路上の問い合わせやabuse報告を、曖昧なブランド名ではなく一意のオブジェクトへ結び付けられる。組織は名称、状態、連絡先の変化を以前の記録と比較できる。

ただしレジストリは、稼働中のネットワークを遠隔操作する装置ではない。すべてのルーター、光回線、施設、顧客、アプリケーションを示さず、遅延、容量、サポートの速さ、取引成功も測らない。正しい登録と正常なウェブサイトは同じ意味ではない。

適切な使い方は照合である。行政的な識別、連絡先、観測された経路、顧客の設定、ユーザー側の試験が互いに矛盾していないかを確認する。差異は調査のきっかけであり、自動的な非難の根拠ではない。

これはHeng.luの現実層とも整合する。レジストリは帳簿と記録係であって、稼働するコードやネットワークを支配する主権者ではない。番号資源の一意性、正確性、移転記録、セキュリティ上の連絡情報は重要だが、運用継続は実際の挙動で確かめる必要がある。

RIPEstatは時間を限定した稼働状況を加える

取得したRIPEstatのAS概要は、resource 26347をDREAMHOST-ASおよびNew Dream Network, LLCと関連付け、当該自律システムをannouncedと表示した。平易に言えば、その時点で経路収集器がAS26347のBGP参加を観測していた。

アナウンス済みプレフィックスの応答は、2026年7月22日から8月5日の観測窓で27件を返した。内訳はIPv4が24件、IPv6が3件だった。プレフィックスはインターネットアドレスの範囲を表す表記であり、両方のアドレス体系が見えていたことになる。

27という数字は顧客数、サーバー数、商品数、施設数ではない。法的な全資源一覧でもない。収集器は特定地点から観測し、ある経路が地域によって見えなかったり、別経路になったりする。帯域、損失、ページ速度、データベースの健全性も測らない。

そのためARINとRIPEstatは互いを置き換えない。ARINは「何が記録されているか」、RIPEstatは「観測点が何を見たか」、顧客監視は「アプリケーションが何を完了したか」に答える。

一般企業がBGPを運用する必要はない。重要なドメインとアドレスを把握し、必要なら想定する起点を記録し、明らかな変化を誰が検証するか決めればよい。アラートは調査の開始であって、公開結論ではない。

PeeringDBは案内図であり、容量監査ではない

取得したPeeringDBプロフィールはネットワーク名をDreamHost、別名をNew Dream Network, LLCとし、AS26347とdreamhost.comを関連付ける。分類はContent、範囲はGlobal、一般ポリシーはOpenで、IPv4プレフィックス25、IPv6プレフィックス1という運用者側の推定値も掲載する。

この25と1は、RIPEstatの24と3に機械的に合わせる数字ではない。PeeringDBは運用者が保守するディレクトリであり、字段の範囲や更新方法が異なる。RIPEstatは一定期間の観測集合だ。同じ測定とみなせば誤った矛盾をつくる。

相互接続APIは、一つの交換所IDに関係するoperationalの行を1件返した。施設APIは0件だった。0件という結果は、DreamHostに施設、私設接続、上流回線、地理的分散がないことを証明しない。その公開プロフィールの当該欄に行がなかったというだけである。

PeeringDBは連絡や計画の入口として有用だが、リアルタイムのトラフィック、余裕容量、物理的分離、顧客SLAを監査する資料ではない。運用中と記された接続を特定顧客の通信が使うとも限らない。

重要な判断では、現在の契約、経路試験、顧客テレメトリ、必要に応じたプロバイダー確認を加えるべきだ。地図と地図の限界を同時に保存することが重要である。

一つのブランドの下に異なる責任分担がある

DreamHostの概要は、ウェブホスティング、VPS、専用、DreamPress、メール、ドメイン、DreamObjects、DreamComputeを分けている。顧客は組み合わせて使えるが、各製品は運用作業を異なる割合でプロバイダーと顧客へ配分する。

共有ホスティングでは共通基盤の多くをプロバイダーが管理する。一方、顧客はコンテンツ、アカウント、アプリ選定、各種設定を持つ。VPSや専用サーバーはより多くの制御や分離を得られる一方、パッチ、セキュリティ、監視の責任も増え得る。

ある製品の説明を別製品へ流用してはいけない。ウェブファイルの復元はMySQLの復元ではない。DreamObjects向けの可用性条件は一般ホスティングの測定ではない。一つのプラットフォームのステータスは、顧客のDNSや外部決済の状態を説明しない。

最低限の対策は製品単位の台帳である。アカウント、プラン、ドメイン、ファイル、データベース、メール、証明書、外部依存、技術担当、事業担当を記す。小規模サイトなら一枚でよいが、現状と一致していなければならない。

「DreamHostで運用している」だけでは復旧手順にならない。「ドメインはここ、DNSの権威はここ、ファイルとDBの組み合わせはこれ、独立コピーはここ、変更権限者はこの人」と分かって初めて行動できる。

DNSは一つのスイッチではなく権限の連鎖である

DreamHostのDNS概要は、レジストラ、ホスティング会社、ネームサーバー、個別DNSレコードを区別する。レジストラはドメイン登録を扱い、ネームサーバーはゾーンをどこで管理するか決める。A、AAAA、CNAME、MXなどのレコードがウェブやメールを具体的な宛先へ向ける。

すべてをDreamHostに置くことも、複数事業者へ分けることもできる。柔軟性は移行や複合構成に役立つが、引き継ぎ点を増やす。新しいホストが正常でもドメインが古いIPを示すことがある。ネームサーバーを変える際にメール用レコードを移さなければ、ウェブ以外も止まる。

顧客はレジストラ、権威ネームサーバー、主要レコード、想定値、管理者、変更履歴を一覧化し、最新のゾーン書き出しを持つべきだ。アカウントには強い認証を使い、退職した個人のメールではなく組織が復旧連絡先を管理する。

DNS変更は本番変更として扱う。新旧の値、影響範囲、検証方法、戻す条件を決める。ネームサーバー移行はウェブ、メール、証明書確認などへ広がるため、二人目の確認が特に有効だ。

行政上の帳簿は一意性と権限連鎖を支える。しかし今この瞬間の挙動は、実際の委任と応答が決める。両方を照合するのが現実的な運用である。

DNS伝播では利用者ごとに違う答えが見える

DreamHostの伝播ガイドは、再帰リゾルバーがTTLの期限まで応答をキャッシュすると説明する。ISPなどの運用者はそれぞれの更新周期を持ち、通常は数時間、場合によって72時間程度かかるとしている。

DreamHostのデフォルトTTLは5分と記されている。ただし世界中が5分で切り替わる保証ではない。変更前のレコードが別のTTLを持ち、端末やアプリが追加キャッシュを使い、委任変更には別の処理がある場合もある。

移行中は新サイトへ来る利用者と旧サイトへ来る利用者が共存し得る。両方で注文などの書き込みを受け付けると、データが分岐する。社内の一台だけで確認し、すぐ旧環境を止めるのは危険だ。

計画では共存期間を設ける。適切なら事前にTTLを下げ、旧環境を安全に保ち、権威応答を直接確認したうえで複数のリゾルバーとネットワークから試す。両方の取引も監視する。

変更後の問題を何でも「伝播」と呼んではいけない。誤った値、欠落したゾーン、期限切れドメイン、証明書不整合、アプリ障害には別の修理が必要だ。影響地点の実際の応答を保存し、想定値と比較する。

ステータスページとサポートチケットの役割は異なる

DreamHostの通知案内は、現在および今後の情報を公式ステータスページで確認し、過去については履歴を見て、個別サイトの問題は技術サポートへ連絡するよう案内する。

公開ページは広範な障害を効率よく伝える。チケットはアカウント固有の証拠を運ぶ。どちらも全障害を自動的に把握するわけではない。全システム正常でも、顧客側のDNS誤り、証明書期限、容量不足、アプリ不具合は起こり得る。

有用な報告には、対象ドメイン、開始時刻、利用者の症状、場所、直近の変更、複数ネットワークでの結果を含める。パスワードや個人情報、悪用可能な詳細を公開欄へ置いてはいけない。

少なくとも二人が正規の方法でアカウントに入り、チケットを追えるようにする。請求先と復旧連絡先を最新にし、緊急時のエスカレーション方法を知っておく。一人の元担当者だけが所有するアカウントは、それ自体が障害点になる。

プロバイダー側の解決表示は中間点である。顧客はDNS、ページ、ログイン、書き込み、メール、購入などを再確認し、事業機能が戻ってから閉じる。

稼働率の約束には開始時計、除外、上限付き救済がある

一般規約にはホスティングの稼働率保証があり、事前通知された保守や顧客のコード・設定ミスなどを除外する。また、DreamHostが停止時間を評価する時計は、顧客が問題報告チケットを開いた時から始まるとしている。

例えば02:00に検知して03:00に連絡すれば、事業影響はすでに1時間続いているが、契約上の測定開始は後になる。監視、担当者、エスカレーション速度は復旧だけでなく証拠にも影響する。

規約のクレジットは、対象となる1時間またはその端数ごとに現在のホスティング1日分の費用を付与し、次回前払い更新料の10％を上限とする。これは請求上の救済であり、失注、人件費、緊急支援、顧客補償、信用低下を全面的に埋めるものではない。

DreamObjectsには月間99.9％という別の定義がある。これを一般ホスティングの測定として扱うのは誤りだ。SLAは、対象製品、測定物、期間、除外、申請方法、救済を正確に保持して初めて役立つ。

企業は別に事業目標を置く必要がある。どのユーザー操作が成功すべきか、何分止まれるか。プロバイダー稼働率と事業可用性は並べて報告できるが、同じ数字ではない。

「無制限」でも共有資源には運用上の境界がある

DreamHostのUnlimited Policyは、ストレージや転送量が無制限とされても、共有サーバーのCPU、メモリ、ディスクI/Oまで無制限ではないと説明する。他の利用者へ影響するほど最適化されていないサイトは、プライベートサーバーへの移行を求められる場合がある。

これは特定顧客が違反したという証拠ではなく、共有基盤の資源管理方針である。多くの顧客が安価に共通基盤を使うには、一つの処理が全資源を無制限に消費しない仕組みが必要になる。

容量だけが問題とは限らない。重いDBクエリ、壊れたプラグイン、定期処理、正当な急増、アカウント悪用がCPUやI/Oを使う。顧客は応答時間、タイムアウト、ジョブ失敗、DBエラーをアプリ側で見るべきだ。

VPSなどへの移行は資源を変える一方、管理作業も増やす。測定、技能、事業影響に基づき計画する方が、繁忙期の緊急移転より安全で安い。

ウェブファイルとMySQLは別々の復旧対象である

DreamHostのウェブサイト復元ガイドは、通常約2週間分のファイルバックアップを保持するとしつつ、利用可能性を保証せず、ローカルバックアップを推奨する。パネル手順はファイルだけを復元し、データベースは対象外で、量によりおよそ5〜15分かかるとしている。

MySQL復元ガイドは、毎日のバックアップと通常およそ5日分の候補を説明する。こちらも利用可能性を保証せず、顧客自身の外部バックアップを強く推奨する。

CMSでは、ファイルにテーマ、プラグイン、画像、設定があり、DBに記事、利用者、注文、状態がある。火曜日のファイルと金曜日のDBを組み合わせれば、画面は出ても整合しないことがある。更新がコードとDBスキーマを同時に変えることもある。

必要なのは一貫した復旧セットだ。ファイル、DB、設定、秘密情報、証明書、DNS、外部依存のどれが同じ時点に属するか把握する。方法はアプリごとに異なるが、所有者と対応関係は明確でなければならない。

独立コピーは、アカウント停止、誤削除、侵害、通常復旧層の停止に備える。暗号化、限定アクセス、保持期間、安全な削除が必要であり、「独立」は無秩序な複製を意味しない。

バックアップは実際に復元して初めて証拠になる

バックアップジョブの成功は、処理が成功を報告した証拠でしかない。すべてが含まれるか、復号鍵が使えるか、現在の担当者が手順を知るか、事業期限に間に合うかは別だ。

代表的な試験では、隔離環境へファイルとDBを復元し、必要な設定を入れ、安全な試験用名でアクセスする。そして利用者に近い操作を実行する。実決済や顧客メールを誤送信せず、個人データも保護する。

復旧時点目標は「どれだけ直近データを失えるか」、復旧時間目標は「どれだけ停止できるか」を表す。毎日1回のコピーは更新の少ない案内サイトには十分でも、活発な店舗には足りないかもしれない。

記録には日付、コピーID、手順、時間、結果、例外、次の担当を残す。失敗して改善につながる試験には価値がある。試していない緑色アイコンには同じ証明力がない。

監視は利用者の行動まで見る

プロバイダーの状態は広域状況を示す。ホスティング指標は資源を見る。外部監視はあるネットワークからの到達を確認する。アプリ監視はエラーを示す。事業監視は予約、購入、寄付、ログイン、フォーム送信が完了したかを見る。

一つの緑にまとめてはいけない。トップページが開いても決済は失敗し得る。サーバーが動いてもDNSは別を向き得る。経路が見えても証明書は期限切れになり得る。

各アラートに受信者、重大度、行動を割り当てる。誰も見ないメールボックスは監視ではない。不要な警報を減らし、本当に重要な信号が埋もれないようにする。

影響開始、検知、チケット、技術復旧、最初の成功取引という時刻を残すと、検知遅延、修理、事業復旧を分離できる。

組織が操作権限を失うことも障害である

多くのサイトは一人の担当者から始まる。社員や外注がドメインを登録し、アカウントを作り、個人の保管庫に資格情報を置く。退職すると、インフラが正常でも組織が変更権限を失う。

重要サービスには事業責任者と技術担当を置く。レジストラ、ホスティング、バックアップの復旧先は組織が管理する。少なくとも二人が個人アカウントを共有せず正規に復旧できるようにする。

権限は最小化する。全員がネームサーバー変更やDB削除をできる必要はない。個別アカウント、強い認証、定期レビュー、記録される緊急アクセスで危険を減らす。

更新日、支払いカード、請求通知も運用である。物理障害がなくても、行政情報が古ければドメインやプランが止まり得る。

月額料金の外側にある費用を数える

月額料金は利用しやすいプラットフォームを買う。監督費用にはアカウント、更新、DNS、証明書、監視がある。統合費用にはメール、決済、認証、APIがある。復旧費用には独立保管、手順、演習がある。

障害費用には失注、停止した社員、顧客対応、緊急コンサル、信用がある。退出費用にはデータ移動、DNS変更、検証、並行稼働がある。これらは共有ホスティングの価値を否定せず、総費用を正直にする。

個人作品集なら長い復旧を許容できる。店舗や予約システムは数分で損失を出すことがある。制御は価値に比例させるべきだ。すべてに最大冗長性は不要だが、ドメイン、データ、行動権限を記録のない一人だけに依存させてはいけない。

小規模組織向けの実行可能な手順

第一に、アカウント、プラン、ドメイン、レジストラ、DNS、ファイル、DB、メール、証明書、外部依存、コピー、更新日、責任者を一枚にまとめる。

第二に、最重要のユーザー操作を決め、外部から安全に試す。アラート受信者と、チケット、広報、代替手段を決定できる人を明示する。

第三に、ファイルとMySQLの独立コピーを暗号化して保持する。許容データ損失から保持期間を決め、復旧説明を本番アカウントだけに置かない。

第四に、隔離先へ復元し、事業操作を実行し、時間を測り、欠けた手順を直す。大きな変更後は再試験する。

第五に、DNS変更前にゾーンを保存し、委任を理解し、戻し方を用意し、複数ネットワークで確認してから旧環境を退役させる。

最後に、正しい層で閉じる。管理画面、サーバー、DNSの復旧は途中経過である。利用者の操作成功、データ照合、後続課題の担当がそろって完了となる。

実務上の結論

公開証拠から言える範囲は明確だ。ARINはAS26347をアクティブなDREAMHOST-ASとして登録し、登録主体をNew Dream Network, LLCとしている。RIPEstatはASNをアナウンス中と観測し、取得窓で27プレフィックスを返した。PeeringDBは運用者保守のプロフィールを示すが、容量監査ではない。

DreamHostの資料は重要な境界を具体化する。ドメイン、ネームサーバー、DNSレコードの権限は分かれ得る。キャッシュにより切替は同時ではない。状態ページとチケットは別の役割を持ち、一般ホスティングとDreamObjectsは別の測定を持つ。

ウェブファイルとMySQLには別々の復旧経路と通常保持期間がある。いずれも利用可能性は保証されず、顧客のローカルまたは外部コピーが推奨される。共有環境のCPU、メモリ、ディスクI/Oにも運用上の境界がある。

小規模企業が世界のルーティングを運用する必要はない。自分にしか守れないものを守ればよい。組織所有のアカウント、照合可能なDNS、独立したデータ、ユーザー側の監視、試験済みの判断能力である。DreamHostは基盤を提供し、顧客の監督と復旧証拠がその基盤を事業継続へ変える。

Sources

画像クレジット

BTW Media向けに生成したオリジナルのフォトリアル編集画像。身元を特定できない作業者が一般的な机で復旧チェックリストを読み、近くに無印のネットワークラックがある。内蔵画像生成ツールで作成し、1600×900のJPEGへ変換した。第三者写真、ロゴ、商標、実在の管理画面、専有システムは使っていない。DreamHost、New Dream Network、その従業員、施設、顧客、機器、構成、事故、性能、推奨を表さない。