排解 Cloud DNS 問題

本頁面提供解決方案，協助您解決使用 Cloud DNS 建立 公開區域、 私人區域、反向查詢區域、 轉送區域和資源記錄時，可能會遇到的常見問題。

公開區域

本節說明公開區域的問題。

無法建立公開區域

如果您收到 attempted action failed 錯誤，表示您的專案未啟用 Cloud DNS API。

如要啟用 Cloud DNS API，請按照下列步驟操作：

1. 前往 Google Cloud 控制台的「API Library」(API 資料庫) 頁面。

   前往「API Library」(API 程式庫)

2. 針對「選取近期專案」，請選取要啟用 API 的 Google Cloud 專案。

3. 在「API 程式庫」頁面中，使用「搜尋 API 和服務」方塊搜尋 Cloud DNS API。畫面隨即顯示說明 API 的頁面。

4. 按一下「啟用」。

不公開區域

本節說明不公開區域的問題。

共用虛擬私有雲服務專案中的不公開區域問題

如需將不公開區域與共用虛擬私人雲端網路搭配使用的重要資訊，請參閱「不公開區域與共用虛擬私人雲端」。

無法建立不公開區域、無法列出或建立政策

您必須具備 DNS 管理員角色才能執行各種私人區域操作，例如列出網域名稱系統 (DNS) 伺服器政策或建立私人區域。這個角色可以透過 Identity and Access Management (IAM) 工具授予。

不公開區域無法在同一個虛擬私有雲網路中解析

請確認您執行測試的 VM 執行個體主要介面與您已建立的不公開區域位於同一個網路上

虛擬機器 (VM) 執行個體會將所有流量從主要介面傳送出去，除非流量的目的地是連線到其他介面之一的子網路，或者 VM 已設定政策轉送。請確認您測試的 VM 主要介面與您正在測試的不公開區域位於同一個網路上。

確認 VM 正在使用：

gcloud compute instances describe VM_NAME \
    --zone=GCE_ZONE \
    --format="csv[no-heading](networkInterfaces['network'])"

確保該網路位於獲授權查詢您不公開區域的網路清單中：

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv(privateVisibilityConfig['networks'])"

確認查詢中的 DNS 名稱是否與您的區域相符

Google Cloud 會根據名稱解析順序解析記錄，使用具有最長字尾的區域，決定要查詢特定 DNS 名稱的區域。請確認您要查詢的記錄尾碼與您虛擬私有雲端網路中至少有一個可存取的不公開區域相符。舉例來說， Google Cloud會先在提供 dev.gcp.example.lan 的區域中尋找 myapp.dev.gcp.example.lan (如可存取)，然後才在提供 gcp.example.lan 的區域中尋找 (如可存取)。

下列指令的輸出顯示特定不公開區域的 DNS 尾碼：

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv[no-heading](dnsName)"

使用中繼資料伺服器查詢 DNS 名稱

使用 dig 將 DNS 名稱查詢直接提交到 Google Cloud中繼資料伺服器 169.254.169.254：

dig DNS_NAME @169.254.169.254

使用 dig 查詢 VM 的預設名稱伺服器：

dig DNS_NAME

如果兩個 dig 指令的輸出產生不同的答案，請檢查第二個指令的 ;; SERVER: 區段。回應伺服器必須是中繼資料伺服器 169.254.169.254。如果不是的話，則表示您已將客體作業系統設定為使用自訂的 DNS 名稱伺服器，而不是預設的Google Cloud 中繼資料伺服器。Cloud DNS 不公開區域會要求您使用中繼資料伺服器進行名稱解析。Linux 客體環境和 Windows 客體環境都會為您進行這項作業。如果您已匯入用於 VM 的映像檔，請確認是否已安裝適當的客體環境。

不公開區域無法透過 Cloud VPN 或 Cloud Interconnect 解析

首先，請確認您可以從已授權的虛擬私人雲端網路內成功查詢和解析 DNS 名稱。

驗證通過 Cloud VPN 或 Cloud Interconnect 的連線能力

確保從內部部署系統到虛擬私人雲端網路的連線能力可以正常運作。具體而言，通訊埠 53 上的 TCP 和 UDP 流量必須能夠離開您的內部部署網路並傳送到虛擬私人雲端網路。請確認內部部署防火牆的設定，以確保允許這類輸出流量。

您可以使用任何通訊協定 (例如 ping (ICMP)) 來測試從內部部署到您虛擬私有雲網路中範例 VM 的連線能力。雖然系統不會將 Cloud DNS 要求傳送到 VM，但測試與範例 VM 之間的連線能力可讓您確認通過 Cloud VPN 通道或 Cloud Interconnect 的連線能力。 Google Cloud 請確保為範例Google Cloud VM 設定適當的允許輸入防火牆規則，否則默示拒絕輸入規則會封鎖所有傳入流量。

確保為已授權的虛擬私人雲端網路啟用傳入轉送功能

您必須為獲授權查詢您 Cloud DNS 不公開區域的每個虛擬私人雲端網路啟用傳入轉送功能。請使用下列指令列出所有政策：

gcloud dns policies list

識別輸出資料表中的網路並檢查「Forwarding」(轉送) 欄位，查看是否已啟用轉送功能。

確保已授權的網路是虛擬私人雲端網路

DNS 轉送需要子網路，只有虛擬私人雲端網路才有子網路，不是 舊版網路。

gcloud compute networks list \
    --format="csv[no-heading](name, SUBNET_MODE)"

舊版網路在輸出中會識別為 LEGACY。

確保該網路中保留了有效的 DNS 轉送位址

下列指令會顯示專案中所有保留的 DNS 轉送 IP 位址。

gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER" \
    --format='csv[no-heading](address, subnetwork)'

您可以在篩選器中加入 AND 子句，將輸出限制為只包含您關注的子網路。

範例：

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"

如果您未在預期的網路/地區中看到 IP 位址，請向 Google Cloud 支援團隊提交票證。

執行 dig 指令，將查詢指向您在先前指令中找到的位址。請從同一個網路中的 VM 執行此操作。這項測試可驗證傳入轉寄站是否正常運作，問題是否出於其他地方。

dig DNS_NAME @10.150.0.1 # address returned by previous command

重複相同的 dig 指令，但從 VPN 另一端的內部部署主機執行。

在不公開區域中定義的 CNAME 記錄無法運作

Cloud DNS 只會追蹤 CNAME 記錄，如CNAME 追蹤一文所述。

反向查詢區

本節提供反向查詢區域的疑難排解提示。某些不公開區域的問題也適用於逆向查詢區域。如需其他提示，請參閱「不公開區域」疑難排解一節。

非 RFC 1918 位址的 VM 無法解析

將 VM 與非 RFC 1918 位址進行調和

如果您在非 RFC 1918 的 Alpha 版推出前建立 VM，且未啟用 Cloud DNS 支援功能，這些 VM 可能無法正確解析。如要解決這個問題，請重新啟動虛擬機。

轉送區域

本節提供轉送區域的疑難排解提示。某些不公開區域的問題也適用於轉送區域。如需其他提示，請參閱「不公開區域」疑難排解一節。

轉送區域 (傳出轉送) 無法運作

首先，請確認您可以從已授權的虛擬私人雲端網路內成功查詢和解析 DNS 名稱。

無法將來自用戶虛擬私有雲網路的 VM 查詢轉送至供應商虛擬私有雲網路

如果您使用 DNS 對等互連功能，且想將來自消費者虛擬私有雲網路的 VM 查詢轉送至供應商虛擬私有雲網路，再轉送至一或多個內部部署名稱伺服器，請務必符合下列其中一項必要條件：

• 供應者虛擬私有雲網路的動態轉送模式已設為 GLOBAL

• 用戶虛擬私有雲網路中的 VM 與供應商虛擬私有雲中的 VPN 通道或 Cloud Interconnect 位於相同區域

• (僅限 Classic VPN) 產生者虛擬私有雲網路已設定靜態路徑，可透過 Classic VPN 通道傳送傳送至內部名稱伺服器的流量。供應者虛擬私有雲網路也必須在用戶端 VM 使用的子網路所在的區域中，設有 VM 或 VPN 通道。

  • 舉例來說，假設 VPC1 使用對等互連區域，將 example.com. 的查詢傳送至 VPC2。假設 VPC2 有 example.com. 的私人轉送區域，該區域會使用傳統 VPN 通道將查詢轉送至內部部署名稱伺服器。

    如要讓位於 VPC1 中的 us-east1 的 VM 能夠查詢 example.com.，VPC2 必須有位於 us-east1 中的 VM。您也必須設定靜態路徑，涵蓋內部部署名稱伺服器的 CIDR 範圍，並將下一個躍點設為 Classic VPN 通道。

驗證通過 Cloud VPN 或 Cloud Interconnect 的連線能力

您可以使用任何通訊協定 (例如 ping (ICMP)) 來測試從內部部署到您虛擬私有雲網路中範例 VM 的連線能力。您也必須嘗試使用 dig 之類的工具，直接從範例Google Cloud VM 查詢內部部署名稱伺服器：

dig DNS_NAME @192.168.x.x # address of the onprem DNS server

檢查虛擬私人雲端網路中的防火牆規則

默示允許輸出防火牆規則允許來自虛擬私人雲端網路中的 VM 傳出連線和已建立的回應，除非您已建立自訂規則以拒絕輸出。如果您已建立自訂拒絕輸出規則，則將需要建立優先順序更高的允許規則，以允許至少輸出到內部部署名稱伺服器。

檢查內部部署防火牆

確保您的內部部署防火牆已設為允許 35.199.192.0/19 的傳入流量和外送流量。

檢查內部部署防火牆中的記錄，尋找來自 35.199.192.0/19 的 DNS 要求。如要使用 regex 運算式進行搜尋，請使用以下運算式：

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

檢查內部部署名稱伺服器

確認您的內部部署名稱伺服器中未設定任何會封鎖來自 35.199.192.0/19 的查詢的 ACL。

檢查您的內部部署名稱伺服器，瞭解是否正在接收來自 35.199.192.0/19 的封包。如果您擁有殼層存取權，則可以使用 tcpdump 等工具來尋找與 35.199.192.0/19 的傳入封包和外送封包：

sudo tcpdump port 53 and tcp -vv

確認傳回路徑

您的內部部署網路必須具有連到 35.199.192.0/19 目的地的路徑，而且下一個躍點是傳送 DNS 要求的同一個虛擬私人雲端網路的 VPN 通道或互連網路連線。如需瞭解這項行為，請參閱「建立轉送區域」一文。

如果您使用多個 VPN 通道將同一個虛擬私人雲端網路連線到內部部署網路，則不必使用與傳送回應相同的通道來傳遞回應，但必須使用在產生要求的同一個虛擬私有雲網路中具有下一個躍點的 VPN 通道來傳遞回應。

如果您已將多個虛擬私有雲網路連線到內部部署網路，則必須確保不會將 DNS 回覆傳送到錯誤的網路。 Google Cloud 會捨棄傳送到錯誤虛擬私有雲網路的 DNS 回應。如需建議的解決方案，請參閱最佳做法指南。

傳出轉送至使用非 RFC 1918 IP 位址的名稱伺服器失敗

根據預設，Cloud DNS 會使用標準路由，在目標名稱伺服器具有非 RFC 1918 IP 位址時，透過公用網際網路轉送查詢。標準路由不支援將查詢轉送至非 RFC 1918 位址的名稱伺服器，因為這些位址無法透過公開網際網路存取。

如要透過 VPC 網路將查詢轉送至使用非 RFC 1918 IP 位址的名稱伺服器，請將 Cloud DNS 轉送區域或伺服器政策設定為使用目標名稱伺服器的私人路由。

如要瞭解標準和私人轉送服務的差異，請參閱轉送目標和轉送方法。

即使目標名稱伺服器有 VPC 路徑，這項限制仍會套用；在設定標準轉送功能時，非 RFC 1918 位址的路徑不會影響 Cloud DNS 的傳出轉送行為。

傳出轉送至次要 NIC 失敗

確認已正確設定次要網路介面控制器 (NIC)。

如要瞭解如何設定其他網路介面卡，請參閱「建立內含多個網路介面的虛擬機器執行個體」。

傳出轉送的查詢收到 SERVFAIL 錯誤

如果 Cloud DNS 從所有目標名稱伺服器收到錯誤，或未收到任何目標名稱伺服器的回應，就會傳回 SERVFAIL 錯誤。

如要解決這個問題，請確認內部部署名稱伺服器已正確設定。接著，請驗證內部部署的名稱伺服器是否在 4 秒內回應來自 Open Google Cloud和內部部署防火牆的 Cloud DNS 位址範圍的查詢，以便允許 DNS 流量。如果內部部署名稱伺服器查詢上游名稱伺服器 (例如，因為已設定為快取解析器)，請確認上游名稱伺服器沒有問題。

此外，如果轉送目標是內部系統，請注意，為該路徑設定的路徑可以是自訂動態路徑或自訂靜態路徑，但含有網路標記的自訂靜態路徑無法用於轉送 DNS 查詢。請確認用於連線至內部部署名稱伺服器的路徑未指定網路標記。

資源記錄

本節提供資源記錄的疑難排解提示。

查詢可用區內的資源記錄集時，出現非預期的資料

在 Cloud DNS 代管可用區中查詢資源記錄集時，可能會收到非預期資料，原因如下：

1. 系統不支援使用 RFC 1035 中指定的 @ 語法建立的資源記錄集。Cloud DNS 會逐字解讀這類資源記錄集中的 @ 符號，因此在 example.com. 區域中，為 QNAME @ 建立的記錄集會解讀為 @.example.com.，而非 example.com.。如要解決這個問題，請務必在建立記錄集時不使用 @ 符號，所有名稱都應相對於區域的頂層。

2. 如同所有記錄，萬用字元 CNAME 記錄也必須遵守 RFC 4592 所述的存在規則。舉例來說，假設您在 example.com. 區域中定義下列記錄集：

   *.images.example.com. IN CNAME _static.example.com.

   srv1.images.example.com. IN A 192.0.2.91

   _static.example.com. IN A 192.0.2.92

   針對 public.srv1.images.example.com. 的查詢會傳回 NOERROR，其中的答案部分為空白。在 CNAME 和 QNAME 之間存在記錄會導致系統無法傳回 CNAME，但沒有任何記錄與 QNAME 完全相符，因此 Cloud DNS 會傳回空白答案。這是標準的 DNS 行為。

Google Cloud VM 顯示錯誤的指標 (PTR) 記錄

在維護事件期間遷移 VM 時，PTR 記錄邏輯無法正確處理某些邊緣案例，並將 DNS PTR 記錄還原為 googleusercontent.com 完整網域名稱 (FQDN)。如要恢復功能，請再次套用 PTR 記錄。

如要進一步瞭解如何在 VM 上套用 PTR 記錄，請參閱「建立 VM 執行個體的 PTR 記錄」一文。

以隨機順序傳回的 Cloud DNS 資源記錄集

為了符合 DNS 業界慣例，Cloud DNS 名稱伺服器現在會隨機排列資源記錄集的順序，並忽略權威伺服器指定的順序。這是正常的 DNS 行為，適用於 公開 和 私人 Cloud DNS 區域。

不支援的區域資源類型

如果您針對指定不同 Cloud DNS 區域的功能，在 gcloud 指令或 API 要求中輸入 --location 標記，系統會拒絕要求。舉例來說，如果您將僅限區域的功能要求傳送至全球伺服器，或是將僅限全球的功能要求傳送至區域伺服器，伺服器會拒絕要求，並顯示 _UNSUPPORTED_ZONAL_RESOURCETYPE 錯誤。

如需區域 Cloud DNS 支援的資源和功能清單，請參閱區域 Cloud DNS 支援。

後續步驟

• 如要進一步瞭解功能，請參閱 Cloud DNS 總覽。
• 如要解決錯誤，請參閱「錯誤訊息」。
• 如需進一步協助，請參閱「支援」頁面。