摘要

  • 孟加拉国电信监管委员会和孟加拉国互联网服务提供商协会都把 Planet Information Technology Solution Limited 识别为位于达卡的 ISP。[8][9] APNIC 另将该组织与活跃的 AS136903、IPv4 分配 103.98.106.0/23 和 IPv6 分配 2001:df1:1780::/48 关联起来。[10][11][13][14] 这些记录证明身份和责任边界，不是性能评分。
  • 在冻结观测窗口内，RIPE NCC 看到 AS136903 宣告 103.98.107.0/24 与 2001:df1:1780::/48。[15][16] 这是有限的 BGP 收集器视角，不是可用率、容量、时延或全部客户体验测量。
  • 查询结果只显示一个相邻 ASN，即 AS137491。[17] 这并不表示 Planet 只有一家供应商、一条物理线路，或不存在私有、非首选及备用连接。它只意味着多样性必须通过合同、物理路径和切换测试另行证明。
  • RIPE NCC 的 RPKI 验证器把两条观测路由都标为 valid。[18][19] 这说明当时的起源 ASN 和前缀长度与可用 ROA 相容，不代表整条路径安全、所有网络都执行过滤，也不保证服务在线、性能或合同结果。
  • 公司网站描述住宅和企业接入、光纤、专用带宽、静态 IP、VPN 支持、BDIX 或 CDN 以及若干服务目标。[1]-[7] 这些是公开能力与承诺。冻结证据中没有独立的吞吐、丢包、时延、可用率、恢复时间或客户生产结果序列。
  • 当前域名 planet-itsolutions.com 在观测时可解析；目录保留的历史域名返回 NXDOMAIN。这反映公共身份同步和迁移成本，不能被表述为服务中断，也不能推断持续时间、原因和客户影响。
  • 长期成本来自资源与路由监督、ROA 变更、IPv4/IPv6 对等维护、DNS 和邮件、滥用联系人、供应商协调、例外管理、证据保存以及可移植性演练。

先把文章固定到准确的公司对象

BTW 目录中的完整对象名称是 Md. Abdus Salam T/A Planet Information Technology Solution Ltd.，而企业公开页面更常使用 Planet Information Technology Solution Ltd. 或 Planet Information Technology Solution Limited。研究不能为了叙事方便把不同写法直接抹平，也不能因为拼写差异就建立多个公司。正确做法是用许可证、地址、组织代码和网络编号建立可复核的对应关系。

ISPAB 记录提供了第一座桥梁：Planet 的会员号为 G-351，条目列出 divisional ISP 许可证、达卡地址和当前网站。[8] BTRC 在 2024 年 12 月 23 日的名单第 127 行列出 Planet，许可证号为 14.32.0000.702.45.591.24.292。[9] APNIC 则把 AS136903 命名为 PITSL-AS-AP，并关联到 ORG-PITS1-AP。[10][11] 三组独立记录都指向目录中的同一公司。

这种汇合并不等于全面认证。BTRC 文件只说明一个有明确日期的监管记录；ISPAB 条目说明协会关系；APNIC 记录编号资源与联络角色。它们都不测量每条接入电路，不核验每份客户合同，也不替公司网站的每项承诺背书。每条结论都必须保留来源的功能、日期和边界。

Planet 的公共控制面包括 ASN、IPv4 与 IPv6 资源、BGP 宣告、ROA、行政、技术和滥用联系人、域名、权威 DNS、邮件、网站、产品页面和支持入口。这些层可以同时存在却彼此漂移：路由可能可见，而角色邮箱已经无人管理；新网站可能运行，而行业目录仍指向旧域名。连续性不是某一个对象显示绿色状态，而是这些控制面被持续对账。

公开材料没有描述 Planet 自研的人工智能模型，也没有训练方法、基准测试、私有架构或客户部署证据。这里可观察的能力是网络运营能力。产品可靠性需要持续测量；客户生产结果需要可归属的客户证据。把三者混在一起，会把“具备资源”误写成“产品可靠”，再误写成“客户已经获得结果”。

APNIC 是责任账本，不是网络主权或运行保证

AS136903 的 APNIC RDAP 对象处于 active 状态，并把该编号与 Planet 联系起来。[10] ORG-PITS1-AP 保存组织名称和公开关系。[11] IRT-PITSL-BD 则提供滥用报告路径及角色邮箱的验证日期。[12] 这种角色分离具有运营意义：管理账户的人不一定是配置路由的人，处理投诉的人也不一定有权批准紧急变更。

active 不能被翻译成“一切正常”。邮箱曾通过验证也不代表当前响应速度和处置权限。注册系统作为账本，维持编号唯一性、委派关系、责任角色和历史记录；它不转发数据包，也看不到客户应用。因此，公开角色需要定期测试，并配置能跨越人员离职、设备故障和主域名问题的恢复路径。

APNIC 把 103.98.106.0/23 记录为活跃的 IPv4 分配。[13] 这个范围包含两个 /24。BGP 观测显示其中的 103.98.107.0/24 由 AS136903 宣告。[15] 登记与运行状态相互兼容，但回答不同问题：前者说明登记的资源责任，后者说明收集器当时看到的传播。不能据此推断每个地址的用途，也不能断言另一个 /24 是否部署、保留或由何种策略控制。

IPv6 分配 2001:df1:1780::/48 也处于 active 状态。[14] 相同前缀在 BGP 中可见。[15][16] 这是双栈运营的积极技术信号，但不证明每个客户都获得 IPv6，不证明每个应用实现功能对等，也不证明支持、监控和故障恢复已经覆盖两种协议。

编号资源的成本主要发生在生命周期中。APNIC 账户、授权人员、账户恢复、角色联系人、前缀清单、路由过滤、ROA、反向 DNS 和客户依赖必须保持一致。只有当这些项目能按已知顺序改变、验证并回滚时，可移植性才不是纸面概念。

滥用联系人也有完整的工作链。公开邮箱只是入口；团队还要验证报告，依据地址和时间定位相关服务，在限制风险的同时保护无关客户，协调修复，保存事实记录并关闭事件。登记信息帮助归属，但不会自动完成调查。

BGP 观测说明了什么，又没有说明什么

RIPE NCC 的 announced-prefixes 数据在冻结窗口内列出 103.98.107.0/24 和 2001:df1:1780::/48。[15] routing-status 数据显示，查询到的 RIS peers 对 IPv4 和 IPv6 各看见一条路由。[16] 这证明登记资源存在可观察的运行状态，而不只是数据库中的静态条目。

这不是完整的全球路由表，也不是在线率报告。路由可见时，服务仍可能拥塞、丢包或应用不可用；不同收集器之间的差异，也可能不会影响最终用户。事件调查必须分开检查 BGP 可见性、数据包可达性、DNS、接入电路和应用健康度。

查询所见的唯一邻接 ASN 是 AS137491。[17] 把它直接写成 Planet 的“唯一上游”会超过证据范围。私有互联、交换中心、非首选备用链路、路由服务器和合同关系不会由一个公共收集视角完整展示。严谨结论只能是：采购方若依赖多样性，就必须要求直接证据。

真正的多样性检查需要看光纤路径、管道、楼宇、电力、设备、供应商、路由策略和切换程序。两份商业合同可能共用同一机房、同一光缆或同一电源；相反，某个时刻只看见一条关系，也可能隐藏未激活的备份。测量范围必须和客户购买的服务范围一致。

在 /23 之内宣告更具体的 IPv4 /24 会带来集成要求。前缀过滤、ROA 的 maxLength、安全系统、监控和变更文档都必须接受相同计划。只允许聚合前缀的过滤规则可能拒绝计划中的 /24；过宽的规则又可能接受未计划的更具体路由。

双栈意味着两条控制链。IPv4 和 IPv6 可以在路由、防火墙、DNS、客户设备和应用层分别失败。IPv4 测试成功不能关闭 IPv6 事件。仪表板、值班手册和恢复验证都应明确协议族，并执行端到端检查。

RPKI 有效只说明起源授权

RIPE NCC 验证器把 AS136903 与 103.98.107.0/24 的组合判断为 valid。[18] 覆盖 103.98.106.0/23 的 ROA 允许最大长度 /24。AS136903 与 2001:df1:1780::/48 的组合也有效。[19] 这些结果降低了对“这个起源是否被资源持有人授权”的不确定性。

它的范围仍然很窄。RPKI 起源验证不认证整个 AS_PATH，不检查所有网络是否执行无效路由过滤，也不测量加密、丢包、时延或吞吐。有效路由仍可能指向不可用服务；路由泄漏也可能保留正确起源，却形成不符合意图的传播。

主要成本集中在变更。新增起源、宣告更具体前缀或启用备用 ASN，都必须与 ROA 同步。若路由先上线，可能短暂变成 invalid；若 maxLength 长期放得过宽，则扩大未必需要的授权空间。一次完整变更要记录意图、顺序、检查点、回滚方式和最终关闭责任人。

紧急时仍能访问 RPKI 管理面同样重要。如果没有人能调整授权，备用网络就没有真正准备好。账户、角色、恢复和批准流程需要定期演练。验证结果应保留时间、前缀、起源和相关 ROA，便于后来解释不同验证器或不同时刻之间的差异。

区分能力、产品可靠性和客户生产结果

Planet 的网站展示住宅和企业接入、光纤、专用带宽、静态 IP 选项以及与 VPN 相关的支持。[1][2][3] 套餐页面列出不同档位，并提到 BDIX、CDN 或 contention ratio 等属性。[4] 服务与联系页面还出现恢复、响应、安装或服务水平目标。[3][5][7]

这些页面说明企业宣称可以提供什么。APNIC 资源和可见路由使网络能力具备可观察基础，但并没有验证每一款产品的质量。若要证明可靠性，需要在明确的服务范围和时间窗内，持续收集可用率、丢包、时延、抖动、吞吐、拥塞、恢复时长和支持响应数据。

冻结来源没有提供这样的独立序列。公司页面上的数字仍是目标、承诺或商业陈述。要把它变成研究结论，就要知道测量点、排除项、统计窗口、数据所有者、故障分布和合同补救。一项月度平均值可能掩盖每天关键时段反复发生的问题。

客户生产结果更是另一层。某客户可能希望保持分支机构、语音、支付、云端系统或备份的运行，但本证据包没有可以归属到具体客户的案例。这种缺失不证明成功，也不证明失败；它只是禁止文章虚构客户证言或业务收益。

服务上线前应定义验收：IPv4 与 IPv6、DNS、应用路径、约定时段吞吐、故障切换、安全边界、联系人和证据格式。本文没有执行私有测试，也没有做供应商基准比较。它只说明从“公共能力可见”走向“产品可靠”还缺哪些证据。

公共域名变化带来的维护成本

当前网站和 ISPAB 条目使用 planet-itsolutions.com。[1][8] 观测时，该域名发布了 Web、NS、MX 和 SPF 信息。目录保存的旧域名则返回 NXDOMAIN。NXDOMAIN 只表示查询时该名称不存在，不能说明它何时停止、为何停止以及是否影响客户。

域名迁移会触及注册商、DNS 委派、网站、邮件、证书、账户、合同、账单、行业目录、APNIC 联系人、支持和监控。新网站上线不会自动修复旧的角色邮箱；Web 重定向也不会转发邮件。迁移关闭条件应包括完整清单、明确责任人和外部验证。

旧域名失效可能拖慢使用历史联系信息的滥用报告、供应商沟通或客户支持。如果放弃的名称后来重新可注册，还可能产生身份风险。迁移策略需要决定哪些服务继续保留、通知哪些相对方、如何扫描残留链接以及何时安全退役。

当前域名自身也不是单一部件，而是注册商账户、委派、权威区、Web 源站、MX 与 SPF 多个边界。注册商账户失去恢复能力时，网站可能仍能运行，却无法处理下一次变更。DNS 故障可以同时影响网站和邮件，而 AS136903 的 BGP 路由毫无变化。监控必须分层。

监督、集成、维护和异常处理

监督成本

监督从受控清单开始：ASN、前缀、预期宣告、ROA、过滤、联系人、DNS、邮件、许可证、供应商、商业承诺和客户验收。不同对象需要不同频率。路由变化可能要求分钟级告警；联系人和监管文档适合周期复核。一盏统一状态灯不能准确表示所有对象。

证据质量本身也要监督。RIPE RIS 是某时刻的收集视图，APNIC 是登记权限，First-party 页面是企业声明，BTRC 名单是有日期的文档。团队应记录来源、采集时间、值和它回答的问题，避免后来把历史快照当作当前事实。

集成成本

集成把清单连接到路由器、ROA、过滤器、安全控制、反向 DNS、监控、工单和合同。供应商带来账户、升级路径、账单和退出条件；客户带来静态地址、VPN、防火墙、设备和应用依赖。一侧“正确”的改变可能破坏另一侧未记录的假设。

交界处的责任必须明确：谁测量，谁能改路由器，谁控制 DNS，谁批准紧急宣告，谁通知客户？没有这张责任图，多支团队可能都报告自己的任务完成，而整体服务仍未恢复。

维护成本

路由、过滤、ROA、联系人、账户、证书、DNS、产品和监控都在变化。IPv4 与 IPv6 让部分控制成双。当前品牌和历史域名还需要在外部记录中持续对账。每个变更与例外都应保留足够证据，以还原意图、批准、效果和回到可接受状态的过程。

异常处理成本

紧急起源可能等待 RPKI 访问；滥用报告可能缺字段；域名迁移时 DNS 账户可能锁定；IPv4 可能先于 IPv6 恢复。每个例外都需要分类、授权人、到期时间、回滚和关闭证据。没有结束日期的临时办法，会变成无人承认的长期依赖。

应当主动测试的故障模式

  1. 联系人失效： APNIC 对象仍 active，但邮箱或角色无人响应。应定期测试，并保留不同故障域中的恢复方式。
  2. 路由与 ROA 漂移： 新起源或新长度变为无效。变更前后都应对照意图、BGP 和 ROA。
  3. 路由撤回： 收集器看不到 IPv4、IPv6 或二者。应联合多个视图和客户服务测量后再分类原因。
  4. 隐藏集中： 公共数据只见一个邻接。需要核查供应商、物理线路、电力和实际切换。
  5. 协议族分裂： 一种协议正常而另一种失败。路由、DNS、防火墙和应用必须分开测。
  6. DNS 权限丢失： 当前记录仍正确，但账户无法恢复。应演练角色、认证和区域导出。
  7. 历史域名残留： 合作方仍使用 NXDOMAIN 名称。要建立残留引用清单和替代路径。
  8. 支持升级无权处置： 一线联系人回复却不能批准修复。需要验证升级角色、可达性和替代人。
  9. 承诺缺少测量： 某个目标被当作普遍可靠性。必须要求方法、范围、时间窗和排除项。
  10. 临时例外永久化： 手工路由、宽 ROA 或替代联系人无人负责。每项例外都要有到期日和关闭证据。

采购、治理与退出

采购方可以把公共记录作为起点，而不是最终判决。尽调问题应覆盖公司和许可证身份、预期前缀、起源、RPKI、IPv4/IPv6 支持、供应商与物理路径多样性、DNS 和邮件责任、监控、事件处理、服务测量、升级和退出。

合同应把能力与实测服务分开。静态 IP、VPN 支持、BDIX/CDN 和恢复目标都需要定义：由谁、从哪里、在什么时间窗测量，哪些情况排除，达不到时如何补救？没有边界的可用率数字把解释成本转嫁给客户。

退出应在采购时设计。客户地址、配置、DNS、邮件、证书、账户和证据要能转移。绑定供应商的地址可能要求重新编号。域名迁移需要并行期和经过验证的退役。备用路径必须在授权、路由、DNS、安全和应用一起通过时才算真实可用。

可辩护的结论既不是赞美，也不是故障指控。Planet 具备真实、可核验的网络控制面：AS136903 和编号资源处于活跃登记状态，IPv4 与 IPv6 在观测时可见，两组起源验证有效；有日期的机构文件和公司页面增加了责任与能力线索。这些事实不证明长期可靠，也不证明客户成功。质量取决于登记权限、运行状态、商业责任和恢复能力能否持续保持一致。

来源

  1. Planet 官方首页。
  2. Planet 公司介绍页。
  3. Planet 服务页。
  4. Planet 套餐页。
  5. Planet 联系页。
  6. Planet 董事长页面。
  7. Planet 发布的 BTRC 资费文件。
  8. ISPAB 的 Planet 条目。
  9. BTRC 2024 年 12 月 23 日 divisional ISP 许可证名单。
  10. AS136903 的 APNIC RDAP。
  11. ORG-PITS1-AP 的 APNIC RDAP。
  12. IRT-PITSL-BD 的 APNIC RDAP。
  13. 103.98.106.0/23 的 APNIC RDAP。
  14. 2001:df1:1780::/48 的 APNIC RDAP。
  15. RIPE NCC announced-prefixes 数据。
  16. RIPE NCC routing-status 数据。
  17. RIPE NCC ASN 邻接观测。
  18. 103.98.107.0/24 的 RPKI 验证。
  19. 2001:df1:1780::/48 的 RPKI 验证。

图片说明：文章使用的卷绕光纤和管道照片由 Rubin Observatory / NSF / AURA 提供，通过 Wikimedia Commons 以 CC BY 4.0 许可发布。图片仅提供通用基础设施语境，不代表 Planet、其网络、设施、人员、客户、事件、可靠性或生产结果。