INNOG 9 在 APNIC 62 讨论什么：IPv6、DNS 与链路韧性核查
简答：INNOG 9 在 APNIC 62 讨论了 IPv6-first、外部依赖、RPKI/ROA/ASPA、海底链路与 AI 工作负载，面向运维人员，核心是用可验证、可恢复的设计维持关键服务。
定义：网络韧性是指网络在链路中断、解析异常、路由错误或部分外部依赖不可用时，仍能维持关键服务并完成恢复的能力。
先看结论：会议要点与核查动作
INNOG 9 把 IPv6、DNS、路由安全和链路冗余放进同一个网络韧性框架；下面这张表可以直接用于自查。本文编译整理自 APNIC 关于 INNOG 9 的原文报道，截至 2026 年 10 月 22 日整理。
| 议题 | 原文涉及的重点 | 本地可执行的核查 | 异常时先查 |
|---|---|---|---|
| IPv6-first | 面向 AI、物联网、边缘计算和机器间通信，把 IPv6 纳入基础设施设计 | 分别查询 A、AAAA，并用 curl -4 与 curl -6 对比 HTTPS | AAAA、默认路由、出口策略、服务器监听地址 |
| 外部依赖 | 国际链路中断时，外部 DNS、云组件、远程 API、时间同步可能成为隐藏依赖 | 建立“依赖—影响—替代—验证”记录 | 解析器位置、远程接口、校时服务和单一出口 |
| 路由安全 | 关注 RPKI、ROA、ASPA 等路由来源与路径验证机制 | 核对前缀、来源 ASN、ROA 状态和上游策略 | 前缀长度、来源 ASN、最大前缀限制和 ROV 策略 |
| 链路与 AI 基础设施 | 海底光缆、数据中心、带宽、时延和 GPU 工作负载会共同影响网络设计 | 记录关键链路和服务依赖，安排故障切换演练 | 单一登陆点、单一出口、跨区域 API 和数据中心路径 |
APNIC 62 官方页面显示，会议于 2026 年 9 月 4 日至 10 日在印度孟买举行，INNOG 9 与会议同期举办；参会者包括网络运营商、基础设施提供商、安全专家和政策制定者。APNIC 62 官方会议信息可用于核对时间、地点与会议背景。
如果读者正在处理具体访问异常，建议先按站内的五层连接诊断路线定位 DNS、TCP、TLS、HTTP 或浏览器边界，再把下面的韧性检查作为长期记录，而不是一开始就重置全部网络设置。
INNOG 9 的四个实践重点
1. IPv6-first 不只是增加 AAAA 记录
APNIC 原文引用 NIXI 首席执行官 Devesh Tyagi 的观点：IPv6 不应只被视为 IPv4 地址不足时的补救措施，而应成为面向 AI、物联网、边缘计算和机器间通信的基础技术。原文进一步强调，网络、数据中心、应用和安全系统都应在设计阶段考虑 IPv6。
这意味着“有 AAAA 记录”不能等同于“业务支持 IPv6”。客户端是否拥有可用地址、出口是否有默认路由、防火墙是否允许访问、负载均衡是否监听 IPv6、应用是否能返回正确的 TLS 和 HTTP 响应，都需要分别验证。
2. 链路可达不等于业务依赖完整
APNIC 对孟加拉网络中断经验的报道指出，当国际连接消失而本地基础设施仍在运行时，部分关键服务仍可能因为依赖外部 DNS 解析器、云端应用组件、远程 API、时间同步系统或移动支付平台而失败。原文给出的方向是识别这些隐藏依赖，并在可行时加强本地解析、本地关键服务副本和本地基础设施。
这里能直接迁移到企业排障的结论是：不要只记录“出口是否通”，还要记录业务访问必须经过哪些 DNS、API、身份认证、证书校验和时间源。具体组织是否需要本地化部署、备用链路或更大规模投资，原文未说明，不能从会议报道推导统一成本或实施周期。
3. 路由安全需要同时看来源和路径
原文提到 RPKI、ROA 和 ASPA 等路由安全技术。APNIC 对 RPKI 的说明中，ROA 用于声明某个 ASN 是否被授权发布指定前缀，验证结果通常分为 Valid、Invalid 和 Not Found；ASPA则用于辅助验证 AS 路径关系。可通过 APNIC RPKI 资料核对这些定义。
对拥有地址资源的团队，检查动作应包括：在资源管理平台确认 ROA 的前缀、授权 ASN 和最大长度；再使用 RPKI 验证器或路由验证查询工具查看实际公告状态；最后确认上游是否执行 Route Origin Validation。没有 ROA 时，状态可能是 Not Found，这不等同于已经确认路由错误。
4. 海底链路和 AI 工作负载会放大单点依赖
APNIC 原文提到，海底光缆承载绝大多数国际互联网流量，印度的国际连接目前较多集中在孟买和金奈等登陆点；随着数据中心和 AI 负载增长，网络还需要面对更高带宽、更低时延、数据中心互联和推理任务靠近用户等要求。
对普通企业来说，适合先做的不是复制大型基础设施，而是把关键业务的链路依赖画出来：用户入口、DNS、出口、云接口、身份认证、时间同步、数据存储和恢复路径分别位于哪里。然后以恢复时间目标为依据，决定哪些依赖值得增加备用路径。
5 分钟基线速查：用 dig 和 curl 区分 DNS、IPv6 与 HTTPS
以下示例适用于 Linux、macOS 或 Windows 子系统。把 example.com 替换为正在排查的域名；命令只读取结果，不会自动修改网络设置。BIND 文档说明，dig 的 +dnssec 用于请求 DNSSEC 相关记录，+cd 用于请求服务器不要执行 DNSSEC 验证，因此 dig 本身不是完整的本地验证器。
dig example.com A +dnssec
dig example.com AAAA +dnssec
dig example.com A +dnssec +cd
dig example.com AAAA +dnssec +cd
curl -4 -I https://example.com
curl -6 -I https://example.com这些选项的说明可查阅 BIND 9 官方手册和 curl 官方命令手册。
| 观察结果 | 优先判断 | 下一步 |
|---|---|---|
| A 有结果，AAAA 无结果 | 业务可能只发布 IPv4 地址 | 不要直接判定 IPv6 故障，先确认业务是否计划提供 IPv6 |
| AAAA 有结果，curl -6 失败 | IPv6 路径、出口策略或服务器监听可能异常 | 检查本机地址、默认路由、防火墙和服务端监听 |
| 普通查询失败，+cd 查询有结果 | 递归解析器可能在 DNSSEC 验证阶段拒绝响应 | 查看响应状态、AD 标志、DS、DNSKEY 和 RRSIG 是否匹配 |
| curl -4 成功，curl -6 成功但 HTTPS 失败 | 问题可能位于 TLS、证书、SNI、ALPN 或 HTTP | 继续使用 verbose 输出和站内 TLS、HTTP 分层步骤 |
| curl -4 与 curl -6 都失败 | 可能是 DNS 之后的 TCP、TLS、HTTP 或本地网络问题 | 记录错误文本，再按五层路线逐层缩小范围 |
DNSSEC 提供的是 DNS 数据来源认证与完整性校验，不提供机密性，也不能替代链路可用性检查；这一点可查阅 RFC 4033。如果解析器验证失败，不要直接写成“域名被篡改”，还要排查 DS 与 DNSKEY 不匹配、签名过期、信任锚、缓存和本地时间等因素。RFC 9364 将 DNSSEC 的现行最佳实践集中说明，可参考 RFC 9364。
如果现象是“只有一个域名打不开”，可以继续查看站内的域名解析失败排查；如果是 IPv4 正常而 IPv6 失败，则使用IPv4 正常、IPv6 失败排查进行地址选择和出口路径对照。
把会议观点转成一张可维护的韧性记录
建议为每个关键业务维护以下五列，而不是只在故障结束后写一句“已恢复”。记录时保留原始命令输出、时间和修改前后的配置差异。
- 依赖：写明递归 DNS、权威 DNS、IPv4、IPv6、出口、证书、时间同步、远程 API 和存储位置。
- 影响：记录依赖不可用时会出现 DNS 超时、TLS 失败、HTTP 5xx、登录失败还是数据同步失败。
- 替代：写明是否存在备用解析、备用出口、本地缓存、静态页面或人工流程；官方资料没有说明的内容标记为“原文未说明”。
- 验证：分别测试 IPv4、IPv6、DNSSEC 验证、远程 API 超时和时间偏差，不要把多个变量同时修改。
- 恢复：记录故障开始、定位、缓解、恢复和复盘时间，并注明最终确认的故障层。
| 检查项 | 至少保存的证据 | 异常后的动作 |
|---|---|---|
| DNS | A、AAAA、DNSSEC 查询结果和递归解析器地址 | 对比普通查询与 +cd 查询，区分解析、验证和链路问题 |
| IPv6 | 本机地址、默认路由、AAAA 结果和 curl -6 输出 | 按本机、出口、服务器三段确认失败边界 |
| RPKI | 前缀、来源 ASN、ROA 状态和检查时间 | 核对前缀长度、授权 ASN 与上游 ROV 策略 |
| 链路 | 主要出口、备用出口、登陆点或上游依赖 | 按恢复目标安排切换演练，不凭会议观点估算投入 |
| 业务 | 远程 API、时间同步、认证和存储依赖 | 逐项测试超时、缓存和降级路径 |
若要保存一次基线，可以使用下面的 Linux 命令；A 和 AAAA 分开查询，避免把两个类型误写成一次只返回最后一个查询类型：
mkdir -p diagnosis-$(date +%F)
dig example.com A +dnssec > diagnosis-$(date +%F)/dns-a.txt
dig example.com AAAA +dnssec > diagnosis-$(date +%F)/dns-aaaa.txt
curl -4 -I https://example.com > diagnosis-$(date +%F)/http4.txt 2>&1
curl -6 -I https://example.com > diagnosis-$(date +%F)/http6.txt 2>&1这组命令只保存观察结果，不代表已经完成 DNSSEC、RPKI 或业务恢复验证。需要更完整地记录现象、假设、验证和回退动作时，可继续参考站内的故障基线记录。
常见问题
INNOG 9 在 APNIC 62 主要讨论什么？
主要讨论 IPv6-first 架构、国际链路中断后的外部依赖、RPKI 与路由安全、海底光缆、企业安全以及 AI 工作负载对网络基础设施的影响。它是会议议题和运营经验汇总，不是一份统一部署规范。
IPv6 地址能访问，为什么业务仍然打不开？
IPv6 地址可达只说明部分网络层路径成立，业务仍可能在 DNS、TLS、HTTP、服务器监听、出口策略或浏览器层失败。应分别测试 AAAA、curl -6、证书和 HTTP 响应。
dig +dnssec 能直接证明 DNSSEC 验证成功吗？
不能。dig 的 +dnssec 主要请求 DNSSEC 记录，是否验证成功应结合递归解析器返回的 AD 标志、响应状态，并用 +cd 对照查询。必要时还要核对 DS、DNSKEY、RRSIG、信任锚和本地时间。
如何检查自己的 RPKI 和 ROA 状态？
先记录自有前缀、授权 ASN 和最大长度，再在资源管理平台查看已发布的 ROA，并用 RPKI 验证器或路由验证查询工具检查实际公告状态。Valid、Invalid 和 Not Found 的含义不同，不能只看是否存在 ROA。
中小团队需要马上建设完整的多链路架构吗？
不一定。更稳妥的顺序是先盘点关键业务依赖，确认单一 DNS、出口、远程 API 或时间源造成的影响，再依据恢复目标安排备用路径和演练。会议原文未提供适用于所有组织的成本和实施周期。
常见问题
INNOG 9 在 APNIC 62 主要讨论什么？
主要讨论 IPv6-first 架构、国际链路中断后的外部依赖、RPKI 与路由安全、海底光缆、企业安全以及 AI 工作负载对网络基础设施的影响。它是会议议题和运营经验汇总，不是一份统一部署规范。
IPv6 地址能访问，为什么业务仍然打不开？
IPv6 地址可达只说明部分网络层路径成立，业务仍可能在 DNS、TLS、HTTP、服务器监听、出口策略或浏览器层失败。应分别测试 AAAA、curl -6、证书和 HTTP 响应。
dig +dnssec 能直接证明 DNSSEC 验证成功吗？
不能。dig 的 +dnssec 主要请求 DNSSEC 记录，是否验证成功应结合递归解析器返回的 AD 标志、响应状态，并用 +cd 对照查询。必要时还要核对 DS、DNSKEY、RRSIG、信任锚和本地时间。
如何检查自己的 RPKI 和 ROA 状态？
先记录自有前缀、授权 ASN 和最大长度，再在资源管理平台查看已发布的 ROA，并用 RPKI 验证器或路由验证查询工具检查实际公告状态。Valid、Invalid 和 Not Found 的含义不同，不能只看是否存在 ROA。
中小团队需要马上建设完整的多链路架构吗？
不一定。更稳妥的顺序是先盘点关键业务依赖，确认单一 DNS、出口、远程 API 或时间源造成的影响，再依据恢复目标安排备用路径和演练。会议原文未提供适用于所有组织的成本和实施周期。