摘要

  • 将 Hosting SC ITNS.NET SRL 视为托管容量依赖项的公开案例是真实但有限的：ITNS 本身在其应用层服务中描述了云应用和托管托管，PeeringDB 列出了第二个名为 IPV4-HOSTING 的 SC ITNS.NET SRL 网络，RIPE 将 AS35346 和 AS202511 都关联到同一家摩尔多瓦组织。
  • 更强有力的证据是网络证据而非产品证据。AS35346 处于活跃状态，在 RIPEstat 中可见，在 PeeringDB 中出现在 MD-IX 和 KIVIX，并且在 RIPE 数据库中关联了命名的上游和对等策略。AS202511 分配给同一组织，但在 2026 年 7 月 12 日的 RIPEstat 中并未被公布。
  • 主要的运营风险并非神秘的云控制平面。而是区域托管提供商背后的普通物理堆栈：基希讷乌的设施、电力、上游多样性、IPv4 存量、路由器配置、硬件更换、支持时间、客户数据导出以及在维修窗口变成客户中断之前移动工作负载的能力。
  • 证据等级为中等。有足够的公开路由、监管和运营商信息来识别依赖关系和故障路径，但没有足够的公开设施、库存、状态页面、合同或恢复测试证据来验证多站点弹性或客户可移植性。

有用的问题不是 ITNS 是否“在云中”

托管通常作为抽象出售。客户购买虚拟服务器、私有 VLAN、托管防火墙、网络门户、备份目标或应用环境，并被鼓励以服务名称而非物理约束的视角思考。Hosting SC ITNS.NET SRL 是一个有用的提醒：区域托管容量仍然是一个普通资产的堆栈。某处服务器必须启动。某处交换机必须转发帧。某处路由必须离开摩尔多瓦。某处技术人员必须更换电源、交换光学模块、恢复配置或告诉客户迁移需要几分钟、几小时还是整个周末。

公开记录并不支持将 ITNS 解读为超大规模云平台的夸张说法。但支持一个更窄、更重要的解读：ITNS 是一家摩尔多瓦通信运营商，其公开声明覆盖到应用层和托管托管服务，并拥有可见的自治系统基础设施，这对任何依赖其托管容量的客户都至关重要。其自身的关于我们页面将 IT and Network Solution (ITNS.NET SRL) 描述为一家拥有二十多年经验的摩尔多瓦光网络和电信合作伙伴。其业务范围页面描述了从物理网络设计到互联网、电视和云系统的工作。其Layer 7 页面进一步深入应用服务，命名了云应用、托管托管、门户、DevOps 系统、视频监控、电视、电话和定制数字服务。

这很重要，因为托管容量不仅是一个产品类别，也是一个依赖类别。如果 ISP、企业、公共机构或较小的服务提供商在 ITNS 基础设施上运行服务，客户将面临与任何区域云或托管供应商相同的运营问题。是否有多个可用站点，还是仅有通往一个城市区域的多个路由？客户工作负载是否易于导出，还是与特定于提供商的地址和管理工具纠缠在一起？IPv4 供应来自自有分配、租用地址空间、客户提供的空间还是重新公布的子网？提供商是否附近有备件库存，还是故障服务器和光学模块必须等待采购？如果单个上游、路由服务器、电源、计费系统或服务台出现问题，故障会蔓延多远？

公开证据给出了部分答案。ANRCETI 电子通信网络和服务提供商公开注册处列出的 ITNS. NET S.C. S.R.L. 位于基希讷乌的 Miron Costin 3/1，授权提供公共固定地面网络和服务，包括电话、呼叫传输、租用线路、数据传输和互联网接入。RIPE 组织记录 ORG-SIS76-RIPE识别了摩尔多瓦的 SC ITNS.NET SRL，提供了注册号，标记该组织为本地互联网注册机构，并记录了 Muncesti 121A 基希讷乌地址。RIPE 自动编号记录 AS35346命名了 EUROTELECOM，将 AS 关联到该组织，并列出了上游、交换点和对等点的导入导出策略。第二个RIPE 自动编号记录 AS202511使用 AS 名称 HOSTING 和同一组织，而 PeeringDB 列出了相应的IPV4-HOSTING 网络条目在 SC ITNS.NET SRL 下。

公开记录也留下了主要空白。PeeringDB 的主要ITNS.NET 网络条目报告了两个交换连接和零个设施记录。PeeringDB 中缺少设施行并不证明 ITNS 缺乏机架、机笼或数据中心租约。仅意味着读者无法使用该公开记录验证服务器所在位置或两个客户工作负载是否可以部署在物理上独立的站点。官方网站用关于冗余、监控和服务持续性的广泛声明发言；但没有发布详细的状态页面、设施拓扑、备件政策、备份架构、恢复时间、客户导出程序或托管产品目录。因此，购买者必须将公开材料视为证据起点，而非弹性认证。

法律和本地身份：服务背后的摩尔多瓦运营商

身份痕迹比零售产品痕迹更强。ANRCETI 的公开注册处命名了 ITNS. NET S.C. S.R.L.，给出了基希讷乌地址 Miron Costin 3/1，并列出了与该运营商关联的服务类别，包括公共互联网接入、数据传输和租用线路服务。该监管记录很重要，因为它将 ITNS 锚定在摩尔多瓦电子通信市场中，而不是将其作为仅限网络的托管品牌。同时，它将公司定位为运营商，其托管服务（如果出售给客户）与传统电信职责并存：接入网络、传输、互联、支持和服务连续性。

RIPE 提供了互补的互联网号码资源视角。组织对象使用名称 SC ITNS.NET SRL，国家代码 MD，注册号 1005600004190 和本地互联网注册机构状态。地址字段指向 Muncesti 121A, MD-2002, 基希讷乌。同一记录指向 ITNS-NET-MNT 和 RIPE NCC-HM-MNT 作为维护者，ITNS-NET-MNT 维护者对象描述了具有基希讷乌地址的 ITNS 网络运营中心。这些记录并不证明哪个法律实体拥有每个机架或服务器。但确实证明本文讨论的公共路由资源并非脱离摩尔多瓦公司身份。

PeeringDB 从网络运营商视角强化了联系。SC ITNS.NET SRL 组织条目使用相同的组织名称，将 EUROTELECOM 标记为替代名称，列出网站 itns.md 和 itns.net，给出基希讷乌地址详情，并将组织连接到两个网络：ITNS.NET (AS35346) 和 IPV4-HOSTING (AS202511)。PeeringDB 由网络运营商自行维护，不应视作监管记录，但仍有用，因为它反映了运营商如何向对等方展示自己。在该论坛中，ITNS 不仅展示了一般网络，还展示了一个带托管标签的 AS。

因此，身份图片有三个层次。监管机构看到一家摩尔多瓦电子通信提供商。RIPE 看到一家摩尔多瓦本地互联网注册机构，拥有关联到 SC ITNS.NET SRL 的 AS35346 和 AS202511。PeeringDB 看到一家网络运营商，拥有 ITNS.NET 网络和第二个带托管标签的网络。这足以将 Hosting SC ITNS.NET SRL 视为真实的基础设施依赖项。但不足以推断超出这些公开记录声明的所有权联系、客户关系或设施合同。

公司自称提供什么

ITNS 的自有网站范围广泛且有些营销色彩，但提供了一些相关声明。关于我们页面将 ITNS.NET SRL 描述为拥有超过二十年增长的摩尔多瓦光网络参与者，在互联网服务提供商业务中拥有专业知识，并参与光纤网络的设计、实施和运营。语言是自我宣传的，但支持一个基本结论：ITNS 希望被理解为基础设施工程和运营公司，而不仅仅是经销商页面。

业务范围页面更为具体。它说 ITNS 提供从物理光纤设计到互联网、电视和云系统的完整电信基础设施解决方案。它划分了从 Layer 1 到 Layer 7 的堆栈。Layer 1 涵盖需求验证、现场分析、光学基础设施设计、与当局协调以及施工。Layer 2 涵盖使用 Juniper、Cisco、Huawei、Arista、Mikrotik、D-Link 和 TP-Link 等供应商的有源设备设计。Layer 3 涵盖安装、配置、互联网服务供应、上游连接、对等互连、IP 传输、监控和维护。Layer 7 命名了电视、视频监控、固定电话、门户、DevOps 系统和基于云的应用。

Layer 1 页面很有用，因为它解释了公司声明背后的物理定位。它描述了电子通信网络的设计和施工、现场勘测、路由追踪、文档、管道和电缆安装、熔接、端接和 OTDR 测试。对于托管容量，这间接相关。与光纤和网络运营商垂直接近的托管服务可能在本地接入、客户电路和私有连接方面具有优势。它也继承了现场运营的约束：许可、路由损坏、技术人员可用性以及修复或重路由物理基础设施所需的时间。

Layer 3 页面更接近托管依赖。它描述了路由、BGP、OSPF、MPLS、VLAN、网络分段、上游连接、对等互连、IP 传输、高可用性设计、监控和维护。从 ITNS 购买托管容量的客户不仅购买计算或存储。客户依赖这些 Layer 3 实践来保持工作负载可达。如果路由策略改变，如果传输合同暂停，如果错误配置传播，或者客户 IP 空间必须在中断期间移动，服务边界就变成了网络边界。

Layer 7 页面是此槽位的主要公开服务证据。它说 ITNS 交付应用层服务，并明确将云应用、托管托管、IoT 集成和企业服务编排列入定制解决方案。这不是完整的托管产品目录。它不发布服务器大小、价格、虚拟化平台、备份保留、存储层级、服务水平、接受的支付条款或数据导出承诺。尽管如此，它是一份直接的官方声明，表明托管和应用服务属于公司的商业覆盖范围。

为什么选择我们页面同时提高了标准和不确定性。它声称从光纤到云应用的端到端解决方案、24/7 支持和监控、冗余路由、主动维护和 99.99% 正常运行时间。这些声明作为面向客户的承诺是有价值的，但页面本身并未独立验证。在没有公开的事故历史、状态页面、站点地图和恢复演练的情况下，这些声明应被视为买方必须通过合同和技术尽职调查来测试的断言。

AS35346 是可见的生产网络

公开记录中最清晰的有形资产是 AS35346。RIPE 数据库自动编号对象将 AS 记录为 EUROTELECOM，关联到 ORG-SIS76-RIPE，状态为 ASSIGNED，创建日期 2005 年 7 月 20 日，最后修改日期 2026 年 6 月 24 日。同一对象命名了上游和互联政策。它列出了通过 AS174 的 Cogent、通过 AS9199 的 RENAM、通过 AS60514 的 NGN 和通过 AS50084 的 Rapid Link。它还列出了包含 Moldtelecom IXP 引用的 MD-IX、包含 TRABIA IXP 引用的 KIVIX，以及 Google Global Cache、Arax-impex 和 Rapid Link 的对等行。细节是技术性的，但战略含义很简单：AS35346 的互联面比单一传输馈线更广。

RIPEstat 证实 AS35346 不仅已分配而且可见。RIPEstat AS 概览显示持有者为 EUROTELECOM SC ITNS.NET SRL，并标记 AS 于 2026 年 7 月 12 日被公告。RIPEstat 路由状态视图报告了其 RIS 对等样本中的完整 IPv4 可见性、高 IPv6 可见性、19 个 IPv4 公告前缀、6400 个 IPv4 地址、148 个 IPv6 前缀和 13 个观察到的邻居。它还显示该 AS 的首次观察起源在 2005 年 12 月，当前观察在 2026 年 7 月。对于托管服务客户来说，这比服务手册更强。可达性被独立的路由收集器看到。

RIPEstat 公告前缀调用显示了 IPv6 面有多广。它列出了许多 /29 IPv6 公告以及 IPv4 前缀如 91.242.112.0/20、几个 91.242.x.0/24、195.138.108.0/24 和 194.114.144.0/24。确切组合应视为时间敏感，但当前快照显示 AS35346 不是休眠的空壳。它正在为区域运营商大规模主动起源地址空间。

RIPEstat AS 路由一致性视图增加了细微差别。它显示了许多同时在 BGP 和 RIPE 路由注册表中存在的前缀，但也显示了一长串在 BGP 中可见但在 whois 端未匹配的 IPv6 前缀。这并不自动意味着路由错误。但确实意味着客户或对等方不应假设每个公告都具有相同的已发布路由注册表态势。对于托管容量，特别是在涉及客户前缀或委派 IPv6 范围时，路由文档的质量会影响过滤、上游接受和故障诊断的速度。

RPKI 证据是部分的但有用。RIPEstat91.242.112.0/20 的 RPKI 验证调用返回了起源 AS35346 的有效状态。第二个195.138.108.0/24 的 RPKI 验证调用也返回了 AS35346 的有效状态，同时显示更广的 AS8474 路由对于同一确切起源问题将是无效的。对于客户，有效的 ROA 不能保证服务正常运行时间，但减少了这些特定前缀的一类路由起源风险。

带托管标签的 AS 是一个线索，而非当前活动容量的证据

AS202511 是公开记录中最明确的托管线索。RIPE 自动编号对象使用 AS 名称 HOSTING，将 AS 关联到 ORG-SIS76-RIPE，并列出与 AS41221 和 AS42881 的导入/导出策略。它创建于 2018 年，最后修改于 2025 年 3 月。PeeringDB 的IPV4-HOSTING 条目在 SC ITNS.NET SRL 下列出 AS202511，网站 itns.md 和替代名称 SC ITNS.NET SRL。

但实时路由证据较弱。AS202511 的 RIPEstat AS 概览显示持有者为 HOSTING SC ITNS.NET SRL，但标记 AS 于 2026 年 7 月 12 日未被公告。AS202511 的 RIPEstat 路由状态调用在 RIS 对等样本中未显示当前 IPv4 或 IPv6 可见性，尽管记录了历史首次和最后观察。PeeringDB 同样为 IPV4-HOSTING 条目显示零 IX 计数、零设施计数和零公共流量配置文件。

这个区别很重要。一个休眠或当前未公告的带有托管标签的 AS 可能仍然在操作上相关。它可能为未来的托管增长、私有安排、客户迁移、流量工程计划或地址管理而保留。也可能只是一个未被当前使用的旧资源。公开证据无法决定这些解释间的选择。更安全的结论是 ITNS 拥有一个带托管标签的号码资源足迹，但今天可见的活动服务依赖通过 AS35346 分析更好，除非客户合同、Looking Glass、路由收集器或服务订单另行证明。

这也影响了托管经济学。IPv4 地址稀缺且昂贵，特别是对于需要支持虚拟服务器、专用机箱、客户设备、邮件服务器、名称服务器和传统应用程序的较小区域提供商。存在名为 IPV4-HOSTING 的网络表明 IPv4 供应和分配可能是服务的核心，但当前缺乏公开 BGP 可见性使得更难确定该供应如何使用。买方应询问托管服务是否接收提供商 IPv4、客户自有的 IPv4、带端口转发的共享 IPv4、以 IPv6 为主的寻址，还是如果 IP 块更改时的迁移路径。

对等和交换存在减少了部分风险，留下了其他风险

PeeringDB 将 AS35346 报告为 ITNS.NET，网络名称 IT & Network Solutions，区域范围，大部分入站流量比例，50-100 Gbps 流量，开放对等策略，启用 IPv6，两个交换连接，无公共设施记录。PeeringDB 网络 29822 的 netixlan 视图给出了两个连接：MD-IX 和 KIVIX，均显示为 10 Gbps，均处于运营状态，均有 IPv4 和 IPv6 地址，并配置为路由服务器对等点。这意义重大。托管工作负载不仅需要上游传输。当本地和区域流量能够靠近客户、避免拥塞的长途路径并在一条传输路径受损时保持可达性时，它也有益。

MD-IX PeeringDB 条目将 MD-IX 标识为基希讷乌的摩尔多瓦互联网交换点，由 Moldtelecom SA 运营，在 PeeringDB 中有两个设施记录：COLO-54 Moldtelecom 和 Data City - Moldtelecom。KIVIX PeeringDB 条目将 KIVIX 标识为基希讷乌互联网交换点，连接到 Trabia 的基希讷乌设施上下文。这些交换记录并不证明 ITNS 客户服务器位于这些设施内。它们证明交换结构本身与基希讷乌的数据中心或运营商位置在物理上相关联，并且 ITNS 至少拥有 PeeringDB 列出的交换连接。

这里有一个微妙风险。交换存在可以改善本地路由，但也可能制造多站点弹性的假象。两个交换端口并不一定意味着两个独立的计算站点。提供商可以在多个交换点对等，同时在一个房间内运行客户服务器。反之，提供商可以在多个租赁位置运营服务器，但不在 PeeringDB 中披露任何位置。现有的记录更支持互联多样性而非站点多样性。

RIPE 自动编号对象通过列出命名的传输和对等关系拓宽了画面。Cogent 和 RENAM 在 RIPE 策略和 RIPEstat 路由一致性导入/导出部分中均在 BGP 中可见。其他列出的关系如 NGN、Rapid Link、MD-IX、KIVIX 和某些对等方在策略对象中可见，即使一致性视图未显示匹配的当前 BGP 可见性。这种混合并不罕见。路由策略记录可能滞后于现实，包含计划关系，省略实时关系或保留旧安排。对于尽职调查，重要点不是将每个关系计为保证容量。而是询问哪些上游承载当前生产托管流量，每个链路有多少容量，接受哪些路由，以及如果一条路径失效，客户前缀可以多快重路由。

设施是最大的公开盲点

与设施最相关的事实是地址和交换上下文，而非机架地图。RIPE 为组织提供 Muncesti 121A。ITNS 维护者对象为网络运营中心提供 Miron Costin 3/1。ANRCETI 的注册处也列出 Miron Costin 3/1。PeeringDB 的组织条目列出 Muncesti 121A 和 Miron Costin 3/1 两者。这些公开地址标识了基希讷乌的运营点，但并未显示客户服务器、存储系统或边缘路由器所在的位置。

办公室、运营中心、网络节点、数据大厅和租赁机架之间的区别很重要。托管容量的故障方式不同，取决于涉及哪个。如果客户服务器位于带有冗余电源、冷却、访问控制、备件和运营商会合能力的自有或租赁数据大厅，提供商可以做出更强的可靠性声明。如果服务器位于较小的办公附属设备间，提供商可能仍能胜任运营，但风险转向电源质量、访问限制、消防、冷却空间和硬件库存。如果容量从另一个数据中心运营商转售，客户需要了解事故期间谁控制动手访问。

PeeringDB 的ITNS.NET 的 netfac 视图返回零个设施行。这是本分析中最重要的负面事实之一。它不证明 ITNS 没有设施存在。许多网络选择不列出设施。但它确实意味着公共 PeeringDB 记录不允许买方验证 AS35346 存在于 Data City、Trabia、Moldtelecom、自有位置或任何其他命名站点。因此，证明责任转移到合同文件、客户参考、设施参观、提供商图表或签署的服务描述。

公司网站从另一个方向提供了物理工厂信心。Layer 1 材料描述了围绕光纤路由和文档的施工和工程实践。这支持了 ITNS 理解外部设施和物理网络部署的想法。它不直接支持关于数据中心成熟度的声明。光纤运营商可能擅长挖沟、管道、熔接和接入路由，同时依赖第三方托管服务器的租空间。托管买方应分离这些问题。光纤能力可以改善本地接入和私有回程；数据中心能力决定服务器在电源、冷却和访问事件期间的生存能力。

因此，特色的运营依赖不是“哪个云平台”，而是“哪个房间”。客户应问的具体问题是：主用机架在哪里，备用机架在哪里，它们由哪些电源馈电，哪个设施运营商控制访问，哪些运营商进入房间，远程操控需要多长时间，备有哪些磁盘和电源，以及备份如何与主故障域分离？

安装容量不等同于可用容量

公开来源显示了一个有意义的网络足迹。RIPEstat 报告 AS35346 的完整当前 IPv4 可见性和实质性 IPv6 可见性。PeeringDB 报告 50-100 Gbps 流量和两个 10 Gbps 交换端口。官方网站描述端到端基础设施和应用服务。这些事实表明已安装能力。它们并未告诉客户在考虑现有客户、超额订阅、维护储备、DDoS 余量和端口限制后，还剩下多少可用容量。

这种区别对于托管经济学尤其重要。提供商可以公告许多 IPv6 前缀，但可能仍受限于 IPv4 分配、物理服务器数量、存储性能、支持人员或上游承诺。它可以拥有 10 Gbps 交换端口，但特定托管服务可能受限于 1 Gbps 上行链路、防火墙、共享存储阵列或客户 VLAN 设计。它可以宣传 99.99% 正常运行时间，但维护窗口、恢复义务和补偿条款仍然保密。客户不应将地址空间大小与计算库存混淆，或将交换存在与备用服务器容量混淆。

AS35346 的地址画像仍有价值。6400 个地址的 IPv4 可见性如果当前且准确归属，是区域运营商的重要资源。它可以支持接入客户、基础设施、邮件、托管、NAT 池、监控和客户分配。IPv6 公告也足够广泛，使支持 IPv6 的托管设计成为可能。但业务价值取决于运营策略：客户是否可以获得路由子网，反向 DNS 是否委派，提供商防火墙是否在路径中，滥用处理是否影响托管客户，以及如果客户离开，地址分配是否可移植。

AS202511 增加了未解决的容量信号。带托管标签的 AS 可以有用，如果 ITNS 希望将托管路由与通用接入网络隔离、应用独立的上游策略、接受客户前缀或在维护期间移动工作负载。但由于该 AS 于 2026 年 7 月 12 日在 RIPEstat 中未被公告，不能在没有额外证据的情况下将其计为在线恢复容量。休眠的 AS 可以是一个选项；直到在操作中观察到它，它才是一个经过测试的故障转移路由。

故障路径是普通的，这就是为什么它们重要

面向客户的托管服务最可能的故障路径并不奇特。它们是机架、上游、硬件库存、支持、计费、迁移和提供商合同故障。

机架或房间故障是最容易理解的。如果承载客户工作负载的服务器、存储和架顶式交换机失去电源或冷却，客户经历停机，除非工作负载故障切换到物理上独立的站点。公开材料提到冗余和高可用性，但未发布多站点架构。因此正确的买方假设是谨慎的：冗余是一个需要验证的声明，而不是从多个交换连接的存在中继承的事实。

上游或路由故障更容易公开看到。AS35346 有命名的上游和交换对等点，RIPEstat 看到当前邻居。这减少了单上游风险，但并未消除路由故障。错误配置的路由过滤器、过期的路由对象、无效的 ROA、上游纠纷、路由服务器事件或 DDoS 黑洞策略仍可能影响托管工作负载。一些前缀的 RPKI 有效性有帮助，但路由一致性输出显示注册表和 BGP 视图并非对所有公告统一。具有严格可达性要求的客户应询问其服务使用哪些前缀以及这些确切前缀是否具有有效的 RPKI、完整的路由对象和经过测试的上游接受。

硬件库存故障更难观察，但经常具有决定性。当提供商手头没有备用的硬盘、电源、光学模块、内存、服务器或交换机时，托管容量变得脆弱。ITNS 的官方页面强调工程、供应商、监控和维护。它们没有披露备件政策。区域提供商如果库存常见部件并拥有强大的供应商关系，仍可能具有弹性。但公开证据不允许客户假设故障的存储控制器或服务器主板可以在当天更换。

支持故障是另一个隐藏依赖。官方网站列出支持和监控概念，PeeringDB 在主网络条目中列出公共 NOC 联系人。这是一个有用的信号。其余问题是实际的：谁在非工作时间接听，事故如何升级，服务台能否进行网络更改，远程操控是内部人员还是设施提供，计费问题能否自动暂停服务，以及客户备份在账户纠纷期间是否可访问。

迁移故障是最无声的风险。当客户需要离开时，托管容量不再抽象。磁盘镜像能否导出？DNS 更改能否协调？IP 地址能否移动？备份是否为标准格式？如果提供商网络受损，是否有带外复制路径？合同是否允许在终止或未付款后检索数据？ITNS 的公开页面不回答这些问题。这对许多提供商来说是正常的，但正是客户应在中断前解决可移植性的原因。

数据本地化是合理的；数据主权并非自动

此分配的区域是 MD，公开证据支持摩尔多瓦作为运营环境。ANRCETI 将 ITNS 列为摩尔多瓦提供商。RIPE 和 PeeringDB 列出摩尔多瓦地址。交换存在在基希讷乌。公司官方网站强调摩尔多瓦的数字未来、摩尔多瓦光纤基础设施和本地工程。这些事实使得本地托管或本地网络依赖成为可能。

合理的本地性不等同于保证的数据主权。公开记录不显示客户磁盘所在位置。不显示备份存储位置。不显示托管应用是否使用摩尔多瓦以外的第三方平台。不显示管理访问、监控、电子邮件、DNS、工单、存储复制、安全服务是否依赖外部供应商。寻求摩尔多瓦数据驻留的客户需要合同和架构图，而不仅仅是摩尔多瓦 AS。

网络记录也指向摩尔多瓦之外。Cogent 是一家全球传输提供商。RENAM 是本地学术和研究网络上下文。MD-IX 和 KIVIX 在对等方参与时保持本地流量本地化，但上游传输本质上离开本地交换结构。托管工作负载可以物理位于基希讷乌，同时依赖外部传输、外部 DNS 服务、外部支付处理器或海外备份目标。这本身不是问题。它仅仅意味着“由摩尔多瓦运营商托管”不应自动转化为“所有依赖项留在摩尔多瓦”。

因此，数据主权尽职调查应精确。询问主要数据存储在哪里，备份存储在哪里，谁可以访问环境，哪些司法管辖区涵盖分包商，哪些日志离开国家，以及站点故障后将使用哪个紧急恢复副本。公开的 ITNS 证据支持本地运营商论点。它没有为任何个别客户解决数据位置问题。

当 ITNS 托管的容量故障时谁受影响

受影响方取决于客户购买的是 ITNS 堆栈的哪一部分。对于 ISP 或较小的接入提供商购买网络集成，故障可能影响最后一英里客户、CPE 供应、电视前端、VoIP 服务或监控。对于企业购买托管托管或云应用，受影响表面是客户门户、内部系统、监控存储、远程访问、电子邮件、业务线应用或公共网站。对于公共机构，影响可能包括面向公民的门户、本地服务交付、固定电话或其他机构的数据交换。

ITNS 官方页面反复将公司定位为企业、服务提供商、社区基础设施和公共机构的合作伙伴。这个广泛的目标市场使得故障表面比单个托管页面更广。如果 ITNS 设计光纤、管理路由、运营应用平台和支持门户，同一个提供商可以在一个客户的几个依赖层中。这在正常情况下可以简化问责，因为一个运营商理解整个路径。但如果同一个运营商控制接入、路由、托管和支持，它也可以集中风险。

影响机制首先是延迟，然后是可达性，然后是数据访问，最后是客户信任。部分路由损伤可以使托管服务变慢或区域不可达。机架或存储故障可以使它们不可用。支持故障可以将短事件变成长事件。可移植性故障可以在提供商纠纷或长时间中断期间束缚客户。由于 ITNS 具有可见的路由多样性但设施和恢复证据不透明，最高优先级的尽职调查不是“AS 看起来活跃吗？”而是“客户服务能否在特定的房间、上游、服务器和支持故障中幸存？”

客户在依赖 ITNS 进行托管容量之前应验证什么

客户不需要每个私有操作细节来使用区域托管提供商。它确实需要足够的信息来理解自己的风险。第一个验证是站点独立性。要求 ITNS 识别特定服务的主要和恢复位置，解释这些位置是否共享电源、冷却、光纤入口、设施运营商、上游路由器或存储，并显示故障转移如何触发。

第二个验证是网络独立性。询问哪个 AS 和哪些前缀将承载服务，服务使用 AS35346 还是 AS202511，确切前缀是否由有效的 ROA 覆盖，哪些上游接收它们，路由对象是否存在，以及事故期间路由更改需要多长时间。公开来源显示 AS35346 是活动的，AS202511 已分配但当前未在 RIPEstat 中公告。客户不应接受关于“多个提供商”的泛泛声明而没有前缀级细节。

第三个验证是硬件和存储恢复。询问本地备有哪些组件，更换硬盘和电源的适用时间，存储是否复制，备份是否不可变，恢复如何测试，以及客户数据如何在没有提供商工具的情况下导出。公开网站谈论监控和维护，但只有客户特定证据才能显示恢复成熟度。

第四个验证是支持权限。询问谁可以重启服务器、更换光学模块、编辑 BGP 策略、释放备份、批准迁移或在办公时间外暂停计费操作。公共 NOC 联系人很有价值，但托管服务事故通常跨越网络、系统、存储和商业边界。接听电话的人必须能够联系到实际可以更改服务状态的人。

第五个验证是退出。托管容量在最不具可移植性的时候是当客户最后才考虑可移植性。在投产前，客户应知道如何导出数据、DNS 和反向 DNS 将如何移动、IP 是否可移植、取消后备份保留多长时间，以及如果客户在中断期间迁移，ITNS 是否会提供紧急帮助。这些条款在公共记录中不可见，这使它们成为合同工作。

证据等级和底线

证据等级为中等。身份证据很强：ANRCETI、RIPE 和 PeeringDB 都将主题连接到摩尔多瓦电信运营商。AS35346 的网络证据足够用于依赖分析：当前公告、广泛可见性、有效 RPKI 示例、命名的上游策略和交换存在都是公开的。服务证据为中等：ITNS 本身提到云应用和托管托管，并且名为 IPV4-HOSTING 的 PeeringDB 网络存在于同一组织下。设施和恢复证据较弱：主网络没有公共 PeeringDB 设施行，没有发布的机架图，没有公共恢复测试，没有状态历史，没有备份政策和没有客户可移植性条款。

这种混合并不使 ITNS 成为糟糕的托管依赖。它使其成为一个应该睁大眼睛购买的依赖。公开证据支持一家公司能够合理地在摩尔多瓦提供本地网络集成的托管服务。它不支持将该服务视为完全透明的多站点云。对于客户，正确的姿态既不是忽略也不是盲信。而是技术验证：确认房间，确认路由，确认备份，确认备件，确认支持升级，并确认如果依赖停止服务业务时如何离开。