谷歌把DNS路由藏進(jìn)35.199.192.0/19

35.199.192.0/19。這組數(shù)字讓某跨國企業(yè)的云架構(gòu)團(tuán)隊(duì)在凌晨三點(diǎn)的bridge call里沉默了四分鐘。他們剛花了72小時(shí)排查一個(gè)詭異的DNS故障——on-premises防火墻日志顯示請(qǐng)求已放行，響應(yīng)卻永遠(yuǎn)消失在谷歌云的某個(gè)角落。

這不是配置錯(cuò)誤，是谷歌云VPC的隱藏機(jī)制在起作用。Cloud DNS轉(zhuǎn)發(fā)查詢時(shí)，源IP會(huì)強(qiáng)制變成35.199.192.0/19這個(gè)特殊網(wǎng)段，而每個(gè)VPC都有一條不可見、不可刪、不可傳播的路由把它指向自己的DNS上下文。當(dāng)流量跨VPC時(shí)，響應(yīng)包像被扔進(jìn)黑洞。

那位架構(gòu)師后來把排查過程寫成了技術(shù)文檔。我讀完后的第一反應(yīng)：這設(shè)計(jì)像酒店前臺(tái)——每個(gè)樓層（VPC）都有自己的總機(jī)，你讓10樓前臺(tái)轉(zhuǎn)接9樓的房間，對(duì)方回?fù)軙r(shí)卻永遠(yuǎn)打到10樓的總機(jī)上。

企業(yè)IPAM上云的兩難：權(quán)威性與連通性不可兼得

這家企業(yè)的痛點(diǎn)很典型。他們已經(jīng)在全球數(shù)據(jù)中心跑熟了Infoblox、EfficientIP或BlueCat這類企業(yè)IPAM平臺(tái)，所有DNS記錄——從服務(wù)器主機(jī)名到服務(wù)發(fā)現(xiàn)條目——都由這些平臺(tái)統(tǒng)管。上云后，他們堅(jiān)持一個(gè)原則：IPAM必須是跨混合環(huán)境的唯一權(quán)威源。

谷歌云默認(rèn)的DNS架構(gòu)并不買賬。Compute Engine實(shí)例默認(rèn)把查詢發(fā)給169.254.169.254，由Cloud DNS基于VPC網(wǎng)絡(luò)配置處理。想讓Cloud DNS把查詢轉(zhuǎn)發(fā)給on-premises的IPAM？可以，但轉(zhuǎn)發(fā)流量的源IP是35.199.192.0/19——一個(gè)被企業(yè)防火墻集體標(biāo)記為"可疑公網(wǎng)地址"的網(wǎng)段。

防火墻策略與云原生DNS設(shè)計(jì)，在這里正面相撞。

架構(gòu)團(tuán)隊(duì)試過標(biāo)準(zhǔn)方案：在Cloud DNS里建轉(zhuǎn)發(fā)區(qū)域（Forwarding Zone），指向on-premises的DNS服務(wù)器。測試環(huán)境通了，生產(chǎn)環(huán)境掛了。安全團(tuán)隊(duì)拒絕為35.199.192.0/19開白名單，理由很充分——"這看起來像是谷歌的公網(wǎng)IP，我們?yōu)槭裁匆屔a(chǎn)DNS接受來自公網(wǎng)的查詢?cè)矗?

更深層的矛盾在于權(quán)威性。即使防火墻放行，Cloud DNS的轉(zhuǎn)發(fā)區(qū)域只是"代理"查詢，真正的權(quán)威記錄仍在on-premises。當(dāng)云原生服務(wù)需要注冊(cè)自己的DNS記錄時(shí)（比如Kubernetes集群動(dòng)態(tài)創(chuàng)建的服務(wù)端點(diǎn)），這些記錄該寫進(jìn)Cloud DNS還是回寫IPAM？企業(yè)選擇了后者：所有記錄必須歸集到IPAM，Cloud DNS只做查詢通路。

這要求IPAM的"觸角"必須延伸到GCP內(nèi)部——但不是以傳統(tǒng)的主從復(fù)制架構(gòu)，而是以網(wǎng)格成員（Grid Member）的形式部署虛擬機(jī)，讓IPAM平臺(tái)把GCP視為另一個(gè)需要管理的網(wǎng)絡(luò)區(qū)域。

三層VPC架構(gòu)：SD-WAN作為脊柱，DNS作為神經(jīng)中樞

最終落地的設(shè)計(jì)用了三個(gè)VPC，通過Network Connectivity Center（NCC）串成一體。這不是為了炫技，是為了把DNS流量和SD-WAN流量解耦到不同網(wǎng)絡(luò)平面。

SD-WAN VPC是混合網(wǎng)絡(luò)的脊柱。里面跑著一個(gè)SD-WAN虛擬機(jī)，配了三個(gè)網(wǎng)絡(luò)接口：eth0接SD-WAN VPC本身，eth1接Infra VPC，eth2接App VPC。這個(gè)VM的角色很明確——讓云資源通過企業(yè)已有的SD-WAN fabric訪問on-premises，同時(shí)讓on-premises通過反向路徑觸達(dá)云端。

NCC在這里做了兩件事：一是把SD-WAN VM注冊(cè)為Router Appliance Spoke，二是開啟VPC間的路由交換。結(jié)果是一張自動(dòng)維護(hù)的路由表——App VPC知道on-premises的子網(wǎng)怎么走（下一跳是SD-WAN VM），Infra VPC也知道App VPC的地址空間。

但DNS不能走這條路。SD-WAN VM的eth1和eth2只是數(shù)據(jù)平面的通道，DNS查詢需要更精細(xì)的控制。于是架構(gòu)團(tuán)隊(duì)在Infra VPC里部署了一臺(tái)DNS虛擬機(jī)——文檔里叫它"BIND VM"，實(shí)際對(duì)應(yīng)IPAM平臺(tái)的網(wǎng)格成員。這臺(tái)VM只接eth0，活在Infra VPC的10.0.1.0/24里。

關(guān)鍵設(shè)計(jì)決策：DNS VM只服務(wù)Infra VPC，不直接暴露給其他VPC。

這引出了Cloud DNS的兩種區(qū)域類型在架構(gòu)中的分工。App VPC里建的是Peering Zone（對(duì)等區(qū)域），把gcp.example.com的查詢"鏡像"到Infra VPC的DNS上下文。Infra VPC里建的是Forwarding Zone（轉(zhuǎn)發(fā)區(qū)域），把同樣的域名查詢實(shí)際轉(zhuǎn)發(fā)到10.0.1.10的DNS VM。

兩者都用forwarding_path = "private"，強(qiáng)制走VPC內(nèi)部路由而非公網(wǎng)。但Peering和Forwarding的區(qū)別，決定了整個(gè)方案能否繞開35.199.192.0/19的陷阱。

Peering vs Forwarding：一次查詢的兩次上下文跳轉(zhuǎn)

理解這個(gè)方案的關(guān)鍵，是跟蹤一條DNS查詢的完整路徑。假設(shè)App VPC里有個(gè)VM（10.0.2.10）要查app-server.gcp.example.com：

第一步，查詢到達(dá)App VPC的Cloud DNS上下文。Peering Zone匹配到gcp.example.com后綴，觸發(fā)對(duì)等機(jī)制——注意，這時(shí)候沒有數(shù)據(jù)包離開App VPC，只是DNS服務(wù)的元數(shù)據(jù)平面把查詢"投影"到了Infra VPC的上下文。

第二步，在Infra VPC的Cloud DNS上下文中，F(xiàn)orwarding Zone接管。它把查詢實(shí)際轉(zhuǎn)發(fā)到10.0.1.10，源IP自然是35.199.192.0/19。DNS VM收到查詢，查自己的權(quán)威區(qū)域，找到app-server對(duì)應(yīng)的IP（碰巧也是10.0.2.10，同一臺(tái)機(jī)器的自我查詢）。

第三步，響應(yīng)返回。這時(shí)候35.199.192.0/19的路由機(jī)制開始生效——Infra VPC有這條不可見路由，指向自己的Cloud DNS上下文，所以響應(yīng)包正確回到轉(zhuǎn)發(fā)路徑的入口。

如果App VPC直接用Forwarding Zone指向DNS VM呢？災(zāi)難。

查詢從App VPC發(fā)出，源IP是35.199.192.0/19。DNS VM在Infra VPC，響應(yīng)時(shí)目的IP是35.199.192.0/19。但I(xiàn)nfra VPC的那條特殊路由指向的是Infra VPC自己的Cloud DNS上下文，不是App VPC的。響應(yīng)包在Infra VPC內(nèi)部打轉(zhuǎn)，永遠(yuǎn)到不了App VPC的查詢發(fā)起者。

這就是為什么Peering Zone是必需的。它把跨VPC的DNS交互從數(shù)據(jù)平面提升到元數(shù)據(jù)平面，消除了35.199.192.0/19的返回路徑依賴。用那位架構(gòu)師的類比：Peering像是兩個(gè)前臺(tái)之間的內(nèi)部通話系統(tǒng)，F(xiàn)orwarding則是實(shí)際撥號(hào)到房間。你必須先內(nèi)部協(xié)調(diào)好，再執(zhí)行實(shí)際連接。

四個(gè)管理區(qū)域的精密配合

Cloud DNS的配置最終落地為四個(gè)管理區(qū)域，沒有一個(gè)是私有權(quán)威區(qū)域（Private Zone）——這是刻意為之。企業(yè)IPAM才是權(quán)威源，Cloud DNS只負(fù)責(zé)查詢路由。

App VPC里的兩個(gè)Peering Zone分工明確：gcp.example.com對(duì)等給Infra VPC，處理云內(nèi)資源的DNS；example.com同樣對(duì)等給Infra VPC，處理企業(yè)全局命名空間。這種分層讓云原生服務(wù)和傳統(tǒng)基礎(chǔ)設(shè)施的DNS查詢走同一條管道，但在IPAM側(cè)可以應(yīng)用不同的策略。

Infra VPC里的兩個(gè)Forwarding Zone是實(shí)際干活的：gcp.example.com轉(zhuǎn)發(fā)到DNS VM，example.com同樣轉(zhuǎn)發(fā)到DNS VM。兩者都指向同一個(gè)10.0.1.10，但基于查詢的后綴，IPAM可以返回云內(nèi)地址或on-premises地址。

DNS VM本身的配置是方案中最"傳統(tǒng)"的部分——跑BIND或IPAM廠商的網(wǎng)格軟件，維護(hù)gcp.example.com和example.com的權(quán)威區(qū)域。當(dāng)云資源需要注冊(cè)DNS記錄時(shí)，它們通過標(biāo)準(zhǔn)DDNS或API調(diào)用更新IPAM，IPAM再同步到這臺(tái)VM。查詢路徑是反向的：Cloud DNS → DNS VM → IPAM數(shù)據(jù)庫 → 響應(yīng)。

整個(gè)架構(gòu)的脆弱點(diǎn)只有一個(gè)：DNS VM的單點(diǎn)故障。

文檔里沒有詳談高可用設(shè)計(jì)，但提到了"IPAM grid member"的復(fù)數(shù)形式。合理的推斷是生產(chǎn)環(huán)境會(huì)部署多臺(tái)DNS VM，用Cloud DNS的多個(gè)轉(zhuǎn)發(fā)目標(biāo)實(shí)現(xiàn)負(fù)載均衡和故障切換。35.199.192.0/19的源IP機(jī)制在這里反而是優(yōu)勢——Cloud DNS會(huì)自動(dòng)在多個(gè)目標(biāo)間輪詢，某臺(tái)VM宕機(jī)時(shí)流量自動(dòng)轉(zhuǎn)移。

35.199.192.0/19：被誤解的設(shè)計(jì)，被低估的影響

值得多寫幾句這個(gè)特殊網(wǎng)段。谷歌把它定義為"Special-Purpose IP Addresses for Google Cloud DNS"，RFC 6890風(fēng)格的保留地址。每個(gè)VPC自動(dòng)安裝的路由優(yōu)先級(jí)高于所有其他路由，包括你手動(dòng)配置的靜態(tài)路由和動(dòng)態(tài)路由協(xié)議學(xué)到的條目。

這條路由不可見（gcloud compute routes list不會(huì)顯示），不可修改（沒有API或控制臺(tái)入口），不可傳播（NCC、VPC Peering、Cloud Router都不交換它）。它的唯一目的是確保Cloud DNS的響應(yīng)能回到正確的查詢上下文——但在跨VPC場景下，這個(gè)設(shè)計(jì)變成了陷阱。

企業(yè)防火墻的誤傷是另一個(gè)維度的問題。35.199.192.0/19在WHOIS里確實(shí)注冊(cè)給Google，ASN歸屬也是Google。防火墻規(guī)則寫成"拒絕所有來自公網(wǎng)IP的入站DNS查詢"是最佳實(shí)踐，沒人能預(yù)料到云廠商會(huì)用這種地址做內(nèi)部服務(wù)源IP。

那位架構(gòu)師的團(tuán)隊(duì)最終沒有要求安全團(tuán)隊(duì)開白名單——他們選擇了Peering Zone的繞行方案。這不是妥協(xié)，是更干凈的架構(gòu)：DNS查詢的權(quán)限邊界和VPC的網(wǎng)絡(luò)邊界對(duì)齊，IPAM的權(quán)威性通過部署位置而非防火墻規(guī)則來保證。

文檔末尾列了六條谷歌云官方參考鏈接，從Cloud DNS概覽到NCC路由交換詳解。最常被點(diǎn)開的那條，標(biāo)題是"DNS forwarding and routing options"——點(diǎn)進(jìn)去的第一句話就是解釋35.199.192.0/19的行為。很多工程師是在踩坑后才讀到這句話。

那位架構(gòu)師在文檔最后放了一個(gè)查詢流程的ASCII示意圖，從App VM的dig命令一路畫到響應(yīng)返回。我注意到他特意在Cloud DNS的兩個(gè)上下文切換處標(biāo)了箭頭——Peering的那步用虛線，F(xiàn)orwarding的那步用實(shí)線。虛線代表元數(shù)據(jù)平面的投影，實(shí)線代表實(shí)際的數(shù)據(jù)包流動(dòng)。

這個(gè)區(qū)分救了他們的方案。如果兩條都是實(shí)線，35.199.192.0/19的黑洞就會(huì)吞噬一切。

現(xiàn)在的問題是：當(dāng)你的企業(yè)IPAM平臺(tái)要求成為唯一權(quán)威源，而云廠商的DNS設(shè)計(jì)默認(rèn)自己才是中心時(shí)，你會(huì)選擇改造IPAM去適配云，還是像這家企業(yè)一樣，在VPC之間搭建一套"翻譯層"？他們的方案用了三臺(tái)VPC、一個(gè)SD-WAN VM、一臺(tái)DNS VM、四個(gè)管理區(qū)域——這個(gè)復(fù)雜度是合理的架構(gòu)分層，還是云原生時(shí)代的企業(yè)IT在被迫償還歷史債務(wù)？