本頁面中的部分或全部資訊可能不適用於 Trusted Cloud by S3NS。

本頁面由 Cloud Translation API 翻譯而成。

排解 Cloud DNS 問題

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

不公開區域

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

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

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

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

您必須擁有 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 名稱是否與您的區域相符

Trusted Cloud 會根據名稱解析順序解析記錄，並使用最長尾碼的區域，決定要查詢特定 DNS 名稱的區域。請確保您要查詢的記錄尾碼與您虛擬私有雲端網路中至少有一個可存取的不公開區域相符。舉例來說， Trusted 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 名稱查詢直接提交到中繼資料伺服器 169.254.169.254： Trusted Cloud

dig DNS_NAME @169.254.169.254

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

dig DNS_NAME

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

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

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

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

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

您可以使用任何通訊協定 (例如 ping (ICMP)) 來測試從內部部署到您虛擬私有雲網路中範例 VM 的連線能力。雖然系統不會將 Cloud DNS 要求傳送到 Trusted Cloud VM，但測試與範例 VM 之間的連線能力可讓您確認通過 Cloud VPN 通道或 Cloud Interconnect 連線的連線能力。請確保為範例Trusted 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 位址，請向Trusted 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

如果您有非 RFC 1918 位址，請調解 VM。

使用非 RFC 1918 位址調解 VM

如果您在 Cloud DNS 支援功能推出前，於非 RFC 1918 Alpha 期間建立 VM，這些 VM 可能無法正確解析。如要解決這個問題，請重新啟動 VM。

轉送區域

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

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

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

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

如果您使用 DNS 對等互連，並想將用戶虛擬私有雲網路中 VM 的查詢轉送至供應商虛擬私有雲網路，然後再轉送至一或多個內部部署名稱伺服器，請確認符合下列其中一項必要條件：

供應商 VPC 網路的動態轉送模式設為 GLOBAL
用戶虛擬私有雲網路中的 VM 與供應商虛擬私有雲中的 VPN 通道或 Cloud Interconnect 位於相同區域
(僅限 Classic VPN) 生產者 VPC 網路已設定靜態路徑，可透過 Classic VPN 通道傳送目的地為內部部署名稱伺服器的流量。供應商虛擬私有雲網路也必須有 VM 或 VPN 通道，且位於與用戶端 VM 所用子網路相同的區域。
- 舉例來說，假設 VPC1 使用對等互連區域，將 example.com. 的查詢傳送至 VPC2。假設 VPC2 也有 example.com. 的私人轉送區域，並使用 Classic VPN 通道將查詢轉送至內部部署名稱伺服器。
  
  如要讓位於 VPC1 中 us-east1 的 VM 查詢 example.com.，VPC2 必須有位於 us-east1 的 VM。您也必須設定靜態路徑，涵蓋內部部署名稱伺服器的 CIDR 範圍，並將下一個躍點設為 Classic VPN 通道。
  
  驗證通過 Cloud VPN 或 Cloud Interconnect 的連線能力

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

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

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

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

檢查內部部署防火牆

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

檢查內部部署防火牆中的記錄，尋找來自 177.222.82.0/25 的 DNS 要求。如要使用 regex 運算式搜尋，請使用下列項目：

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

檢查內部部署名稱伺服器

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

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

sudo tcpdump port 53 and tcp -vv

確認傳回路徑

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

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

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

傳出查詢轉送至次要 NIC 失敗

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

如需如何設定額外 NIC 的操作說明，請參閱「建立內含多個網路介面的虛擬機器執行個體」。

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

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

如要解決這個問題，請確認您的內部部署名稱伺服器已正確設定。然後，請驗證內部部署名稱伺服器是否會在 4 秒內，回應開啟內部部署防火牆，允許 DNS 流量一節中說明的 Cloud DNS 位址範圍查詢。 Trusted Cloud如果您的內部部署名稱伺服器會查詢上游名稱伺服器 (例如，因為設定為快取解析器)，請檢查上游名稱伺服器是否沒有問題。

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

資源記錄

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

查詢區域中的資源記錄集時，出現非預期的資料

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

系統不支援使用 RFC 1035 中指定的 @ 語法建立的資源記錄集。Cloud DNS 會直接解讀這類資源記錄集中的 @ 符號；因此，在 example.com. 區域中，為 QNAME @ 建立的記錄集會解讀為 @.example.com.，而不是 example.com.。如要解決這個問題，請確保建立的記錄集不含 @ 符號，且所有名稱都與區域的頂點相關。
與所有記錄一樣，萬用字元 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 行為。

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

為配合 DNS 產業慣例，Cloud DNS 名稱伺服器現在會隨機排序資源記錄集，並忽略授權伺服器提供的排序。這是正常的 DNS 行為，適用於公開不公開的 Cloud DNS 區域。

不支援的區域資源類型

如果您在 gcloud 指令或 API 要求中輸入 --location 旗標，但該功能指定的是其他 Cloud DNS 區域，系統就會拒絕要求。舉例來說，如果您將僅限區域的功能要求傳送至全域伺服器，或是將僅限全域的功能要求傳送至區域伺服器，伺服器會拒絕該要求，並提供 _UNSUPPORTED_ZONAL_RESOURCETYPE 錯誤。

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

後續步驟

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