谷歌把DNS路由藏进35.199.192.0/19

35.199.192.0/19。这组数字让某跨国企业的云架构团队在凌晨三点的bridge call里沉默了四分钟。他们刚花了72小时排查一个诡异的DNS故障——on-premises防火墙日志显示请求已放行，响应却永远消失在谷歌云的某个角落。

这不是配置错误，是谷歌云VPC的隐藏机制在起作用。Cloud DNS转发查询时，源IP会强制变成35.199.192.0/19这个特殊网段，而每个VPC都有一条不可见、不可删、不可传播的路由把它指向自己的DNS上下文。当流量跨VPC时，响应包像被扔进黑洞。

那位架构师后来把排查过程写成了技术文档。我读完后的第一反应：这设计像酒店前台——每个楼层（VPC）都有自己的总机，你让10楼前台转接9楼的房间，对方回拨时却永远打到10楼的总机上。

企业IPAM上云的两难：权威性与连通性不可兼得

这家企业的痛点很典型。他们已经在全球数据中心跑熟了Infoblox、EfficientIP或BlueCat这类企业IPAM平台，所有DNS记录——从服务器主机名到服务发现条目——都由这些平台统管。上云后，他们坚持一个原则：IPAM必须是跨混合环境的唯一权威源。

谷歌云默认的DNS架构并不买账。Compute Engine实例默认把查询发给169.254.169.254，由Cloud DNS基于VPC网络配置处理。想让Cloud DNS把查询转发给on-premises的IPAM？可以，但转发流量的源IP是35.199.192.0/19——一个被企业防火墙集体标记为"可疑公网地址"的网段。

防火墙策略与云原生DNS设计，在这里正面相撞。

架构团队试过标准方案：在Cloud DNS里建转发区域（Forwarding Zone），指向on-premises的DNS服务器。测试环境通了，生产环境挂了。安全团队拒绝为35.199.192.0/19开白名单，理由很充分——"这看起来像是谷歌的公网IP，我们为什么要让生产DNS接受来自公网的查询源？"

更深层的矛盾在于权威性。即使防火墙放行，Cloud DNS的转发区域只是"代理"查询，真正的权威记录仍在on-premises。当云原生服务需要注册自己的DNS记录时（比如Kubernetes集群动态创建的服务端点），这些记录该写进Cloud DNS还是回写IPAM？企业选择了后者：所有记录必须归集到IPAM，Cloud DNS只做查询通路。

这要求IPAM的"触角"必须延伸到GCP内部——但不是以传统的主从复制架构，而是以网格成员（Grid Member）的形式部署虚拟机，让IPAM平台把GCP视为另一个需要管理的网络区域。

三层VPC架构：SD-WAN作为脊柱，DNS作为神经中枢

最终落地的设计用了三个VPC，通过Network Connectivity Center（NCC）串成一体。这不是为了炫技，是为了把DNS流量和SD-WAN流量解耦到不同网络平面。

SD-WAN VPC是混合网络的脊柱。里面跑着一个SD-WAN虚拟机，配了三个网络接口：eth0接SD-WAN VPC本身，eth1接Infra VPC，eth2接App VPC。这个VM的角色很明确——让云资源通过企业已有的SD-WAN fabric访问on-premises，同时让on-premises通过反向路径触达云端。

NCC在这里做了两件事：一是把SD-WAN VM注册为Router Appliance Spoke，二是开启VPC间的路由交换。结果是一张自动维护的路由表——App VPC知道on-premises的子网怎么走（下一跳是SD-WAN VM），Infra VPC也知道App VPC的地址空间。

但DNS不能走这条路。SD-WAN VM的eth1和eth2只是数据平面的通道，DNS查询需要更精细的控制。于是架构团队在Infra VPC里部署了一台DNS虚拟机——文档里叫它"BIND VM"，实际对应IPAM平台的网格成员。这台VM只接eth0，活在Infra VPC的10.0.1.0/24里。

关键设计决策：DNS VM只服务Infra VPC，不直接暴露给其他VPC。

这引出了Cloud DNS的两种区域类型在架构中的分工。App VPC里建的是Peering Zone（对等区域），把gcp.example.com的查询"镜像"到Infra VPC的DNS上下文。Infra VPC里建的是Forwarding Zone（转发区域），把同样的域名查询实际转发到10.0.1.10的DNS VM。

两者都用forwarding_path = "private"，强制走VPC内部路由而非公网。但Peering和Forwarding的区别，决定了整个方案能否绕开35.199.192.0/19的陷阱。

Peering vs Forwarding：一次查询的两次上下文跳转

理解这个方案的关键，是跟踪一条DNS查询的完整路径。假设App VPC里有个VM（10.0.2.10）要查app-server.gcp.example.com：

第一步，查询到达App VPC的Cloud DNS上下文。Peering Zone匹配到gcp.example.com后缀，触发对等机制——注意，这时候没有数据包离开App VPC，只是DNS服务的元数据平面把查询"投影"到了Infra VPC的上下文。

第二步，在Infra VPC的Cloud DNS上下文中，Forwarding Zone接管。它把查询实际转发到10.0.1.10，源IP自然是35.199.192.0/19。DNS VM收到查询，查自己的权威区域，找到app-server对应的IP（碰巧也是10.0.2.10，同一台机器的自我查询）。

第三步，响应返回。这时候35.199.192.0/19的路由机制开始生效——Infra VPC有这条不可见路由，指向自己的Cloud DNS上下文，所以响应包正确回到转发路径的入口。

如果App VPC直接用Forwarding Zone指向DNS VM呢？灾难。

查询从App VPC发出，源IP是35.199.192.0/19。DNS VM在Infra VPC，响应时目的IP是35.199.192.0/19。但Infra VPC的那条特殊路由指向的是Infra VPC自己的Cloud DNS上下文，不是App VPC的。响应包在Infra VPC内部打转，永远到不了App VPC的查询发起者。

这就是为什么Peering Zone是必需的。它把跨VPC的DNS交互从数据平面提升到元数据平面，消除了35.199.192.0/19的返回路径依赖。用那位架构师的类比：Peering像是两个前台之间的内部通话系统，Forwarding则是实际拨号到房间。你必须先内部协调好，再执行实际连接。

四个管理区域的精密配合

Cloud DNS的配置最终落地为四个管理区域，没有一个是私有权威区域（Private Zone）——这是刻意为之。企业IPAM才是权威源，Cloud DNS只负责查询路由。

App VPC里的两个Peering Zone分工明确：gcp.example.com对等给Infra VPC，处理云内资源的DNS；example.com同样对等给Infra VPC，处理企业全局命名空间。这种分层让云原生服务和传统基础设施的DNS查询走同一条管道，但在IPAM侧可以应用不同的策略。

Infra VPC里的两个Forwarding Zone是实际干活的：gcp.example.com转发到DNS VM，example.com同样转发到DNS VM。两者都指向同一个10.0.1.10，但基于查询的后缀，IPAM可以返回云内地址或on-premises地址。

DNS VM本身的配置是方案中最"传统"的部分——跑BIND或IPAM厂商的网格软件，维护gcp.example.com和example.com的权威区域。当云资源需要注册DNS记录时，它们通过标准DDNS或API调用更新IPAM，IPAM再同步到这台VM。查询路径是反向的：Cloud DNS → DNS VM → IPAM数据库 → 响应。

整个架构的脆弱点只有一个：DNS VM的单点故障。

文档里没有详谈高可用设计，但提到了"IPAM grid member"的复数形式。合理的推断是生产环境会部署多台DNS VM，用Cloud DNS的多个转发目标实现负载均衡和故障切换。35.199.192.0/19的源IP机制在这里反而是优势——Cloud DNS会自动在多个目标间轮询，某台VM宕机时流量自动转移。

35.199.192.0/19：被误解的设计，被低估的影响

值得多写几句这个特殊网段。谷歌把它定义为"Special-Purpose IP Addresses for Google Cloud DNS"，RFC 6890风格的保留地址。每个VPC自动安装的路由优先级高于所有其他路由，包括你手动配置的静态路由和动态路由协议学到的条目。

这条路由不可见（gcloud compute routes list不会显示），不可修改（没有API或控制台入口），不可传播（NCC、VPC Peering、Cloud Router都不交换它）。它的唯一目的是确保Cloud DNS的响应能回到正确的查询上下文——但在跨VPC场景下，这个设计变成了陷阱。

企业防火墙的误伤是另一个维度的问题。35.199.192.0/19在WHOIS里确实注册给Google，ASN归属也是Google。防火墙规则写成"拒绝所有来自公网IP的入站DNS查询"是最佳实践，没人能预料到云厂商会用这种地址做内部服务源IP。

那位架构师的团队最终没有要求安全团队开白名单——他们选择了Peering Zone的绕行方案。这不是妥协，是更干净的架构：DNS查询的权限边界和VPC的网络边界对齐，IPAM的权威性通过部署位置而非防火墙规则来保证。

文档末尾列了六条谷歌云官方参考链接，从Cloud DNS概览到NCC路由交换详解。最常被点开的那条，标题是"DNS forwarding and routing options"——点进去的第一句话就是解释35.199.192.0/19的行为。很多工程师是在踩坑后才读到这句话。

那位架构师在文档最后放了一个查询流程的ASCII示意图，从App VM的dig命令一路画到响应返回。我注意到他特意在Cloud DNS的两个上下文切换处标了箭头——Peering的那步用虚线，Forwarding的那步用实线。虚线代表元数据平面的投影，实线代表实际的数据包流动。

这个区分救了他们的方案。如果两条都是实线，35.199.192.0/19的黑洞就会吞噬一切。

现在的问题是：当你的企业IPAM平台要求成为唯一权威源，而云厂商的DNS设计默认自己才是中心时，你会选择改造IPAM去适配云，还是像这家企业一样，在VPC之间搭建一套"翻译层"？他们的方案用了三台VPC、一个SD-WAN VM、一台DNS VM、四个管理区域——这个复杂度是合理的架构分层，还是云原生时代的企业IT在被迫偿还历史债务？