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 的帮助文件和条款，来区分每一层证据能说明什么、不能说明什么。

这个区分对非技术管理者很重要。“网络编号仍在公告”“服务器有响应”“首页能打开”和“客户已经完成付款”是四个不同结论。若把它们合成一个绿色状态，团队就可能在业务尚未恢复时过早关闭事故。

配图是为 BTW Media 生成的写实编辑图片：一名无法识别身份的操作人员在普通办公桌旁查看恢复清单，玻璃隔断后是无品牌网络机柜。它不是 DreamHost、New Dream Network、员工、设施、设备、客户、事故、性能或认可的真实画面。

登记系统保存身份，不负责网站结果

ARIN 的 RDAP 响应把 AS26347 命名为 DREAMHOST-AS，并把状态标记为 active。ASN 是自治系统编号，是网络与其他网络交换路由信息时使用的唯一数字。对于不了解 BGP 的读者，可以把它理解为互联网道路图上的运营主体编号。

记录把 New Dream Network, LLC 列为登记主体，把 Dreamhost NetOPs 列入技术和网络运营联系角色，另设滥用联系角色。快照显示登记事件发生在 2002 年 8 月 28 日，最近变更事件发生在 2015 年 8 月 31 日。

这类记录的价值在于唯一性、准确性和可联系性。其他网络遇到路由问题或需要提交滥用报告时，可以针对一个明确对象协调。公司也可以把今天的名称、状态和联系方式与过去的记录对照，检查是否发生了未经预期的变化。

但登记表不是正在运行的网络。它不会展示每台路由器、每条光纤、每座机房、每个客户或每个应用，也不衡量时延、容量、工单响应速度或交易是否成功。记录正确，并不等于网站正常。

合理做法是对账：登记身份、联系角色、观察到的路由、客户账户配置和用户侧测试应当相互兼容。出现差异时先调查原因，不应仅凭一次自动观测就公开指控。

这符合 Heng.lu 的现实层原则。登记机构是账本和记录者，不是运行系统的主权控制器。数字资源需要保持唯一、准确、可追踪，并服务于运营连续性；真正的网络状态仍要由运行中的路由和实际服务证据确认。

路由观测补充了有时间边界的现实证据

在本次快照中，RIPEstat 把资源 26347 与 DREAMHOST-AS、New Dream Network, LLC 联系起来，并标记该自治系统处于公告状态。通俗地说，当时的路由收集器可以看到 AS26347 参与全球互联网路由。

公告前缀接口覆盖 2026 年 7 月 22 日至 8 月 5 日的观测窗口，共返回 27 条记录，其中 24 条是 IPv4，3 条是 IPv6。前缀是一组互联网地址的简写。这说明两种地址体系都出现在捕获的路由表面中。

“27”不是客户数量、服务器数量、产品数量或机房数量，也不是完整的法律资源清单。路由收集器从特定位置观察网络，一条路由可能在某些地点可见，在另一些地点被过滤或走不同路径。这个接口也不测试带宽、丢包、页面速度和数据库健康。

因此，登记数据和路由数据不能互相冒充。ARIN 回答“账本里记录了谁”，RIPEstat 回答“观测点看到了什么公告”，客户监控回答“应用完成了什么”。这些证据结合起来才有助于诊断。

普通企业不必自己运营 BGP，也可以利用这一层。它可以列出关键域名和地址，在必要时记录预期网络来源，并明确谁负责验证明显变化。告警是调查起点，不是最终结论。

PeeringDB 是运营商维护的地图，不是容量审计

PeeringDB 快照把该网络命名为 DreamHost，另列 New Dream Network, LLC，关联 AS26347 和 dreamhost.com，并把类型标为 Content、范围标为 Global、一般对等策略标为 Open。资料中还估计有 25 个 IPv4 前缀和 1 个 IPv6 前缀。

这些估计不必与 RIPEstat 的 24 条 IPv4、3 条 IPv6 观测完全一致。PeeringDB 是运营商自行维护的目录，字段范围和更新时间与路由观测不同。把两组数字当成同一种统计，会制造虚假的矛盾。

互联接口返回 1 条状态为 operational 的交换网络记录，对应 1 个交换点标识；设施接口没有返回记录。空列表只说明当时该接口中没有公开行，不能推断 DreamHost 没有设施、私有互联、上游连接或地理冗余。

PeeringDB 适合做运营沟通和规划的起点。它不能独立证明实时流量、剩余容量、物理路径隔离或客户 SLA。即使一条连接标记为正常，也不能证明某个网站的流量一定经过那里。

重要决策仍需当前合同、实际路径测试、客户遥测和必要的服务商确认。地图有用，但不能成为系统本身。

同一品牌下的产品有不同控制边界

DreamHost 概览列出共享主机、VPS、独立服务器、DreamPress、邮件、域名、DreamObjects 和 DreamCompute。客户可以组合购买，但每个产品把不同程度的运维工作留给服务商或客户。

共享主机由服务商管理较多公共平台，客户仍负责内容、账户、应用选择和部分配置。VPS 或独立服务器可能提供更多控制或隔离，同时也会带来更多补丁、安全、监控和容量管理工作。对象存储还有自己的服务定义。

常见错误是把一个产品的承诺套在另一个产品上。网站文件恢复不等于 MySQL 恢复；DreamObjects 的月度可用性条款不等于一般主机的计算方式；某一平台的状态通知也不能解释客户自己的 DNS 或第三方支付故障。

企业应按产品保留清单：账户、套餐、域名、文件、数据库、邮件、证书、外部服务、技术负责人和业务负责人。小网站用一页表格即可，关键是准确和可更新。

“网站托管在 DreamHost”只能说明采购关系，不能指导恢复。真正有用的信息是：域名在哪里注册，谁控制权威 DNS，哪些记录指向主机，文件与哪套数据库对应，独立副本在哪里，以及哪些人能操作。

DNS 是多层权力链，不是一只开关

DreamHost 的 DNS 概览区分域名注册商、托管公司、名称服务器和具体记录。注册商负责域名登记；名称服务器决定整套 DNS 记录由谁管理；A、AAAA、CNAME、MX 等记录再把网站、邮件和其他服务指向目的地。

这些职能可以都在 DreamHost，也可以分布在多家公司。灵活性有利于迁移和混合部署，但会增加交接边界。新主机完全正常时，公开域名仍可能指向旧地址。更换名称服务器会移动整个区域的控制权，如果漏掉邮件或验证记录，影响可能远超网页。

客户应保存 DNS 清单和最近的区域导出，包括注册商、权威服务器、重要记录、预期值、管理员和变更历史。注册商与 DNS 账户需要强身份验证，恢复邮箱要由组织控制，而不是依赖已离职人员的私人地址。

DNS 变更应按生产变更管理。明确新值、旧值、影响范围、验证方法和回退条件。更换名称服务器前最好由第二个人复核，因为它可能同时影响网站、邮件、证书验证和其他服务。

行政账本保证域名和号码的唯一性，实际委派和响应决定当下行为。二者都需要，但不能混为一个结论。

DNS 传播意味着用户可能暂时看到不同答案

DreamHost 的传播指南说明，递归解析器会在 TTL 到期前缓存记录。互联网服务商和其他解析器有自己的缓存节奏。文件称通常需要几小时，也可能在部分情况下达到 72 小时。

DreamHost 名称服务器的默认 TTL 被描述为 5 分钟，但这不是全球 5 分钟保证。旧记录可能使用不同 TTL，设备或应用还可能有本地缓存，域名委派变更也有自己的过程。

迁移期间，一部分用户可能访问新站，另一部分仍访问旧站。如果两边都接受写入，就可能形成两套不同数据。只从办公室的一台电脑测试，然后立刻关闭旧站，风险很高。

合理计划要允许短期共存：在适当情况下提前降低相关 TTL，安全保留旧环境，直接查询权威响应，再通过多个解析器和不同网络测试，同时观察两边是否仍有交易。不能因为一个位置看到新地址就宣布完成。

“DNS 传播”也不应成为所有问题的万能解释。错误记录、缺失区域、域名过期、证书不匹配和应用错误需要不同修复。应记录受影响地点真正得到的答案，再与预期值比较。

状态页与支持工单是两条不同证据通道

DreamHost 的当前状态说明把用户引向官方状态页查看当前和未来更新，也提供历史状态入口；如果网站出现问题，则建议联系技术支持。

公开状态页适合说明大范围事件，工单适合携带账户级证据。两者都看不到所有故障。状态页全绿时，某个客户仍可能有错误 DNS、过期证书、资源耗尽或应用缺陷；反过来，某个地点能打开网页，也不能否定更广泛的事故。

有效工单应包含受影响域名或服务、开始时间、用户看到的症状、位置、最近变更和多个网络的检查结果。不要在公开内容中放入密码、个人数据或可被滥用的安全细节。

支持权限要在事故前准备。至少两名授权人员应能登录，账单和恢复联系人要有效，团队要知道从哪里查看工单和如何升级。若账户只属于一位已离职员工，服务商有支持能力，客户也可能无法使用。

服务商标记“已解决”只是一个里程碑。客户仍需检查 DNS、页面、登录、写入、邮件或结账。只有业务动作成功，客户侧事故才真正结束。

可用性承诺有计时起点、排除项和有限补偿

DreamHost 的一般条款写有主机可用性承诺，同时排除预先公告的维护以及客户代码或配置错误等情况。条款还说明，DreamHost 对停机的评估从客户提交支持工单时开始。

这个工单时钟非常实际。团队可能在 02:00 发现问题，却到 03:00 才联系支持。业务影响已经发生一小时，而合同定义的计时后来才开始。监控、值班和升级速度会同时影响恢复和索赔证据。

条款描述的补偿是：每个符合条件的停机小时或不足一小时，给予相当于当前一天主机成本的信用额，上限为下一次预付续费的 10%。账单信用不能自动覆盖丢失订单、员工时间、紧急顾问、客户赔付和声誉损失。

DreamObjects 另有按月 99.9% 的定义和计算方式。把它当作所有主机服务的指标是不准确的。SLA 只有在保留产品、测量对象、周期、排除项、申请方法和补偿边界时才有意义。

企业还要设自己的端到端目标：哪个用户动作必须成功，可以中断多久。服务商可用性与业务可用性可以同时汇报，但不能相互替代。

“不限量”仍运行在共享资源边界内

DreamHost 的 Unlimited Policy 说明，共享服务器上的存储或流量“不限量”，并不意味着 CPU、内存和磁盘输入输出没有限制。若网站优化不佳并影响其他用户，客户可能被要求迁移到私有服务器。

这不是说任何具体客户违反了政策，而是共享平台必须有资源治理。多个客户能以较低成本使用公共基础设施，前提是单个工作负载不能无限占用所有计算资源。

真正成为瓶颈的未必是文件容量。低效数据库查询、异常插件、定时任务、合法流量高峰或账户遭滥用，都可能消耗 CPU 和磁盘。客户需要在应用层观察响应时间、超时、失败任务和数据库错误。

升级 VPS 或其他产品可能增加资源，也会增加管理工作。决策应基于测量、团队能力和业务后果。计划中的迁移通常比旺季中的紧急搬家便宜。

网站文件和 MySQL 是两个恢复对象

DreamHost 的网站恢复指南称，通常会保留约两周的网站文件副本，但不保证可用，并建议客户保留本地备份。该面板流程只恢复文件，不恢复数据库；根据数据量，操作大约可能需要 5 至 15 分钟。

数据库恢复指南描述了每日 MySQL 备份，并称通常约有 5 天可选。文件同样明确说这些副本不作保证，强烈建议客户自己维护站外数据库备份。

对内容管理系统而言，文件中可能有主题、插件、上传资料和配置，数据库中则有文章、用户、订单和设置。把周二的文件与周五的数据库拼在一起，网站可能能打开，却处于不一致状态。一次软件升级还可能同时改变代码和数据库结构。

企业需要的是一套一致的恢复集合：文件、数据库、配置、密钥、证书、DNS 和外部依赖。具体方法因应用而异，但负责人必须知道哪些部分属于同一个恢复时间点。

独立副本用于应对账户锁定、误删、攻击或常规层不可用。副本仍需加密、限制访问、规定保留期和安全删除。“独立控制”不是随意复制敏感数据，而是避免所有恢复能力都受同一账户和故障域控制。

只有实际恢复过的备份才是可靠证据

备份任务显示成功，只能证明某个程序报告写入完成。它不能证明内容齐全、解密密钥可用、现有员工知道步骤，或恢复时间满足业务要求。

有代表性的演练应在隔离环境恢复文件与数据库，应用必要配置，使用安全测试域名，然后执行接近真实用户的动作。测试不能向真实客户发送邮件或付款，也要遵守隐私和安全要求。

恢复点目标回答“最多能丢多少近期数据”，恢复时间目标回答“最多能停多久”。每日数据库副本对低频更新的展示站可能足够，对活跃商城可能完全不够。文件操作需要十分钟，不等于整个业务十分钟恢复。

演练记录应包括日期、副本标识、步骤、耗时、结果、意外和责任人。失败但促成修复的演练很有价值；从未测试的绿色图标没有同样的证明力。

监控必须看到用户真正做的事

服务商状态页回答是否公布了广泛事件，主机指标显示资源，外部探针显示某个网络能否访问，应用监控显示错误，而业务监控确认预约、购买、捐款、登录或表单是否完成。

这些信号不能合成一个绿灯。首页返回正常时，支付仍可能失败；服务器在线时，DNS 可能指向别处；网络路由存在时，证书可能已过期。

每条告警都要有接收人、严重级别和动作。无人查看的邮箱不算监控。告警也不能过多，否则真正重要的信号会被忽略。

时间线应保留用户影响开始、首次发现、工单提交、基础设施恢复和第一笔成功业务动作。这样才能区分发现延迟、服务商修复和业务恢复。

组织权限本身也是可靠性的一部分

许多网站由一个人开始：员工或外包人员注册域名、开通主机、保存密码。项目成功后，权限结构却没有随之成熟。若这个人离开，基础设施可能仍健康，公司却失去改变它的权力。

每个关键服务都应有业务负责人和技术操作人。注册商、主机和备份的恢复邮箱应由组织控制。至少两名授权人员应能在不共享个人账号的情况下执行恢复流程。

权限要最小化。并非所有人都需要更换名称服务器或删除数据库。独立账号、强身份验证、定期权限审查和有日志的紧急访问可以降低风险。

续费日期、支付卡和账单通知也属于运营。域名或套餐可能因为行政信息失效而中断，并不需要物理设备发生故障。

月费之外还有监督、集成和失败成本

共享主机月费购买了有价值的平台能力。监督成本包括账户、更新、DNS、证书和监控；集成成本包括邮件、支付、身份和外部接口；恢复成本包括独立存储、说明文档和演练。

故障成本包括丢失交易、停工、客户支持、紧急顾问和声誉；退出成本包括迁移数据、改变 DNS、验证和并行运行。这些成本不否定共享主机的经济性，而是让企业做完整比较。

个人作品站可能容忍数小时甚至数天，活跃商城或预约系统可能几分钟就产生损失。控制应与价值相称。不是每个系统都需要最高冗余，但域名、数据和行动权限不应只依赖一个没有记录的人。

小型组织可以采用的控制清单

第一，做一页资产清单：账户、套餐、域名、注册商、DNS、文件、数据库、邮件、证书、集成、备份、续费和负责人。

第二，定义最关键的用户动作并从外部监控。明确谁收告警，谁能提交工单、对外沟通或启动替代方案。

第三，分别保存文件与 MySQL 的独立副本，加密并按可接受数据损失设保留期。恢复说明不要只放在生产账户里。

第四，在隔离环境执行恢复，完成业务动作，测量时间并修复缺失步骤。重大应用变更后应重新演练。

第五，计划 DNS 变更：导出区域、理解委派、准备回退、从多个网络验证，并在确认缓存影响消失前保留旧目的地。

最后，在正确层级关闭事故。控制面板、服务器或 DNS 恢复只是阶段。用户动作成功、数据完成对账、后续任务明确，才是业务闭环。

实际结论

公开证据支持一个有限而清楚的结论。ARIN 将 AS26347 登记为活跃的 DREAMHOST-AS，登记主体为 New Dream Network, LLC。RIPEstat 看到该 ASN 正在公告，并在捕获窗口返回 27 条前缀记录。PeeringDB 提供运营商维护的网络档案，而不是容量审计。

DreamHost 的文件让责任边界更具体。域名、名称服务器和 DNS 记录可能由不同主体控制；缓存会造成暂时不一致；状态页与工单用于不同证据；一般主机和 DreamObjects 有不同测量对象。

文件与 MySQL 采用不同恢复流程和常规保留窗口，而且服务商不保证这些副本一定存在，并建议客户保留本地或站外副本。共享平台上的 CPU、内存和磁盘也仍受资源政策约束。

小企业不需要自己运营全球互联网，却必须保留自己独有的控制：组织拥有的账号、可核对的 DNS、独立的数据副本、用户侧监控和经过测试的决策能力。DreamHost 提供平台；客户的监督、集成管理和恢复证据，决定平台能否成为连续的业务服务。

Sources

图片说明

BTW Media 原创生成的写实编辑图片：一名无法识别身份的操作人员在普通办公桌旁查看恢复清单，邻近区域可见无品牌网络机柜。图片由内置图片生成工具创建并转换为 1600 × 900 JPEG，没有使用第三方照片、标志、商标、真实控制台或专有系统。画面不代表 DreamHost、New Dream Network、其员工、设施、客户、设备、架构、事故、性能或认可。