我們的客戶的網路需求中，有不少和 DNS 的概念相關，尤其是當客戶有多個 VPC 需要連線至本地端時。正如我們在前幾篇部落格文章中所提到的，我們一般建議客戶使用 hub-and-spoke 模型；它能解決因 Google DNS 代理伺服器所造成的反向路由問題。
但在某些設定中，該方法可能在 hub network 中造成單點故障 (single point of failure, SPOF)，如果您的部署中，存在連線問題，這恐怕會導致所有 VPC 網路中斷。在這篇文章中，我們就來討論一些冗餘機制，以確保 Cloud DNS 能夠正常處理 DNS 請求。
替 hub-and-spoke 模型增加冗餘機制
如果您需要冗餘的 hub-and-spoke 模型，請參考以下模型與圖 2：
DNS-forwarding VPC 橫跨多個 Google Cloud 區域，且每個區域都有連到本地網路的單獨路徑（透過 interconnect 互連或其它方式）。在下圖中，VPC 網路 H 跨 us-west1 和 us-east1，且每個區域都有一個專用的網路，可與客戶的本地網路連接，其它 VPC 網路則和 hub network 對接。
這個方法增加了 DNS 的可用性；它允許 VPC 從任一互連路徑中移出查詢，並允許透過任一互連路徑返回查詢。移出請求的路徑，通常是透過最近的網路位置離開 Google Cloud（除非發生故障才會使用其它路徑）。
請注意，儘管 Cloud DNS 會透過最接近的區域的網路，將請求路由回本地，從本地網路返回到 Google Cloud 則取決於您的 WAN 路由。在使用相同價位的路由器情況下，您可能會在返回要求上看到不對稱的行為，因為它使用不同的路徑回應，在某些情況下可能會導致延遲的情況發生。
DNS 備援設定
不過，高可用性的 hub-and-spoke 模型，不見得適合所有的公司。
一些公司的 IP 是由多個位址混合而成，這種情況通常發生在合併或收購的公司，並可能導致難以設定一個乾淨的 geo-based DNS。讓我們來看看不同 DNS 設定，以及客戶如何面對一連串 DNS 的故障。
要了解此問題，請參考以下的 Google Cloud 客戶案例：
該客戶正在透過美國東岸的 VPC 管理美國東岸的 DNS 解析器，並透過美國西岸的 VPC 管理美國西岸的 DNS 解析器，來降低 DNS 查詢的延遲。當需要建立冗餘系統時，問題出現了。
具體來說，客戶希望有第 3 套分解器，以防有任何一個分解器故障時，它能為東岸和西岸的分解器提供備份支援。不幸的是，如圖 3 所示，這樣的設定可能會導致故障的情況。
在這個設定中，假設西岸的 DNS 故障時，流量會被轉到美國中部的備援伺服器，這些 DNS 請求的 IP 位址對應到 Google Cloud DNS 代理伺服器位址為 35.199.192.0/19。
但是，由於有兩條 VPC，WAN 會看到兩條不同的路由器返回到 Google Cloud DNS 代理伺服器，因此通常會透過最近的 Google Cloud DNS 代理伺服器 IP 位址的路由器返回。這種情況下會被視為東岸網路相互連線。由於東岸所連接的 VPC 和原來的 VPC 不同，因此返回的封包會被 Google Cloud DNS 代理伺服器丟棄（因返回封包中的 Virtual Network ID (VNID) 和東岸 VPC 的 VNID 不同）。
這裡的問題是因路由器和子網路封包引起，而不是 DNS 層本身。
因此問題就變成，如何在地端提供 HA DNS 解析器的同時，支援多 VPC 和 DNS 解析器的網路拓樸？一種方法是代理 DNS 請求，如下圖 4 所示。將所有 DNS 請求轉發到 VPC 內的一個代理伺服器（或經過設定的特定子網中）後，您的 VPC 會得到一個特定的 IP 位址，讓本地端的設備能正確地將回應送往正確的 VPC。這也簡化了本地端防火牆的設定，因為您不必再為 Google 的 DNS 代理 IP 而開啟防火牆。由於您可以替 DNS 轉發 (forwarding) 指定多個 IP 地址，因此您可以執行多個代理 VM，以實作額外的代理冗餘，並增強可用性。
高可用性的 DNS：魔鬼藏在細節裡
DNS 對每個企業來說都十分重要，但建立高可用性的 DNS 架構較複雜。建立高度冗餘 DNS 較容易，它能夠處理較多故障的情況，但會忽略路由設定，直到出現 DNS 查詢無法解決的問題為止。在替混合雲環境設計 DNS 架構時，請深入了解您所建置的環境，並仔細思考什麼樣的情況會影響 DNS 的查詢結果。
（本文翻譯改編自 Google Cloud。）
