Memecahkan masalah Cloud DNS

Halaman ini memberikan solusi untuk masalah umum yang mungkin Anda alami saat menggunakan Cloud DNS untuk membuat zona publik, zona pribadi, zona pencarian balik, zona penerusan, dan data resource.

Zona publik

Bagian ini membahas masalah terkait zona publik.

Tidak dapat membuat zona publik

Jika Anda mendapatkan error attempted action failed, artinya Cloud DNS API tidak diaktifkan di project Anda.

Untuk mengaktifkan Cloud DNS API, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Library API.

    Buka Library API

  2. Untuk Select a recent project, pilih project Google Cloud tempat Anda ingin mengaktifkan API.

  3. Di halaman API library, gunakan kotak Search for APIs & Services untuk menelusuri Cloud DNS API. Halaman yang menjelaskan API akan muncul.

  4. Klik Enable.

Zona pribadi

Bagian ini membahas masalah terkait zona pribadi.

Masalah zona pribadi di project layanan VPC Bersama

Untuk informasi penting tentang penggunaan zona pribadi dengan jaringan VPC Bersama, lihat Zona pribadi dan VPC Bersama.

Tidak dapat membuat zona pribadi, tidak dapat mencantumkan atau membuat kebijakan

Anda harus memiliki peran Administrator DNS untuk melakukan berbagai tindakan zona pribadi, seperti mencantumkan kebijakan server Domain Name System (DNS) atau membuat zona pribadi. Peran ini dapat diberikan melalui alat Identity and Access Management (IAM).

Zona pribadi tidak me-resolve di jaringan VPC yang sama

Pastikan Anda melakukan pengujian dari instance VM yang antarmuka utamanya berada di jaringan yang sama dengan zona pribadi yang telah Anda buat

Instance virtual machine (VM) mengirim semua traffic dari antarmuka utamanya, kecuali jika traffic ditujukan untuk subnet yang terpasang ke salah satu antarmuka lain atau jika VM telah mengonfigurasi rute kebijakan. Pastikan VM pengujian Anda memiliki antarmuka utama di jaringan yang sama dengan zona pribadi yang Anda uji.

Pastikan VM Anda menggunakan:

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

Pastikan jaringan tersebut ada dalam daftar jaringan yang diberi otorisasi untuk membuat kueri zona pribadi Anda:

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

Pastikan nama DNS dalam kueri cocok dengan zona Anda

Google Cloud me-resolve data sesuai dengan urutan resolusi nama, menggunakan zona dengan akhiran terpanjang untuk menentukan zona mana yang akan dikueri untuk nama DNS tertentu. Pastikan akhiran untuk data yang Anda kueri cocok dengan minimal satu zona pribadi yang dapat diakses di jaringan VPC Anda. Misalnya, Google Cloud akan terlebih dahulu mencari myapp.dev.gcp.example.lan di zona yang menayangkan dev.gcp.example.lan, jika dapat diakses, sebelum mencarinya di zona yang menayangkan gcp.example.lan, jika dapat diakses.

Output perintah berikut menunjukkan akhiran DNS untuk zona pribadi tertentu:

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

Membuat kueri nama DNS menggunakan server metadata

Gunakan dig untuk mengirimkan kueri nama DNS langsung ke server metadata Google Cloud, 169.254.169.254:

dig DNS_NAME @169.254.169.254

Gunakan dig untuk membuat kueri server nama default VM:

dig DNS_NAME

Jika output dari dua perintah dig menghasilkan jawaban yang berbeda, periksa bagian ;; SERVER: dari perintah kedua. Server yang merespons harus berupa server metadata, 169.254.169.254. Jika tidak, berarti Anda telah mengonfigurasi sistem operasi tamu untuk menggunakan server nama DNS kustom, bukan server metadata Google Cloud default. Zona pribadi Cloud DNS mengharuskan Anda menggunakan server metadata untuk resolusi nama. Lingkungan tamu Linux dan lingkungan tamu Windows akan melakukannya untuk Anda. Jika Anda telah mengimpor image yang digunakan untuk VM, verifikasi bahwa lingkungan tamu yang sesuai telah diinstal.

Zona pribadi tidak me-resolve melalui Cloud VPN atau Cloud Interconnect

Pertama, pastikan Anda berhasil membuat kueri dan me-resolve nama DNS dari dalam jaringan VPC yang diotorisasi.

Memverifikasi konektivitas melalui Cloud VPN atau Cloud Interconnect

Pastikan konektivitas dari sistem lokal ke jaringan VPC Anda beroperasi. Secara khusus, traffic TCP dan UDP di port 53 harus dapat keluar dari jaringan lokal dan dikirim ke jaringan VPC Anda. Verifikasi konfigurasi firewall lokal untuk memastikan traffic keluar tersebut diizinkan.

Anda dapat menggunakan protokol apa pun, seperti ping (ICMP), untuk menguji konektivitas ke VM contoh di jaringan VPC dari lokal. Meskipun permintaan Cloud DNS tidak dikirim ke VM Google Cloud, menguji konektivitas ke VM contoh memungkinkan Anda memverifikasi konektivitas melalui tunnel Cloud VPN atau koneksi Cloud Interconnect. Pastikan Anda mengonfigurasi aturan firewall izin masuk yang sesuai untuk VM Google Cloud contoh karena aturan traffic masuk deny tersirat akan memblokir semua traffic masuk.

Pastikan penerusan masuk diaktifkan untuk jaringan VPC yang diizinkan

Penerusan masuk harus diaktifkan untuk setiap jaringan VPC yang diberi otorisasi untuk membuat kueri zona pribadi Cloud DNS Anda. Gunakan perintah berikut untuk mencantumkan semua kebijakan:

gcloud dns policies list

Identifikasi jaringan di tabel output, dan periksa kolom Forwarding untuk melihat apakah penerusan diaktifkan.

Pastikan jaringan yang diizinkan adalah jaringan VPC

Penerusan DNS memerlukan subnet, yang hanya tersedia untuk jaringan VPC, bukan jaringan lama.

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

Jaringan lama diidentifikasi dalam output sebagai LEGACY.

Pastikan ada alamat penerusan DNS yang valid yang dicadangkan di jaringan tersebut

Perintah berikut menampilkan semua alamat IP penerusan DNS yang dicadangkan dalam project Anda.

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

Anda dapat menambahkan klausa AND ke filter untuk membatasi output hanya ke subjaringan yang Anda minati.

Contoh:

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

Jika Anda tidak melihat alamat IP di jaringan/region yang Anda harapkan, ajukan tiket ke Dukungan Google Cloud.

Jalankan perintah dig yang mengarahkan kueri ke alamat yang Anda temukan dalam perintah sebelumnya. Lakukan dari VM di jaringan yang sama. Pengujian ini memverifikasi bahwa penerusan masuk berfungsi, dan masalahnya ada di tempat lain.

dig DNS_NAME @10.150.0.1 # address returned by previous command

Ulangi perintah dig yang sama, tetapi dari host lokal di seluruh VPN.

Data CNAME yang ditentukan di zona pribadi tidak berfungsi

Cloud DNS hanya mengejar data CNAME seperti yang dijelaskan dalam Pengejaran CNAME.

Zona pencarian balik

Bagian ini memberikan tips pemecahan masalah untuk zona pencarian balik. Beberapa masalah zona pribadi juga berlaku untuk zona pencarian balik. Untuk tips tambahan, lihat bagian pemecahan masalah Zona pribadi.

VM dengan alamat non-RFC 1918 tidak me-resolve

Menyelaraskan VM dengan alamat non-RFC 1918

Jika Anda membuat VM selama versi alfa non-RFC 1918 sebelum dukungan Cloud DNS diluncurkan, VM ini mungkin tidak me-resolve dengan benar. Untuk mengatasi masalah ini, mulai ulang VM Anda.

Zona penerusan

Bagian ini memberikan tips pemecahan masalah untuk zona penerusan. Beberapa masalah zona pribadi juga berlaku untuk zona penerusan. Untuk tips tambahan, lihat bagian pemecahan masalah Zona pribadi.

Zona penerusan (penerusan keluar) tidak berfungsi

Pertama, pastikan Anda berhasil membuat kueri dan me-resolve nama DNS dari dalam jaringan VPC yang diotorisasi.

Penerusan kueri dari VM di jaringan VPC konsumen ke jaringan VPC produsen tidak berfungsi

Jika Anda menggunakan peering DNS dan ingin meneruskan kueri dari VM di jaringan VPC konsumen ke jaringan VPC produsen, lalu ke satu atau beberapa server nama lokal, pastikan salah satu prasyarat berikut terpenuhi:

  • Jaringan VPC produsen menetapkan mode pemilihan rute dinamis ke GLOBAL

  • VM di jaringan VPC konsumen berada di region yang sama dengan tunnel VPN atau Cloud Interconnect di VPC produsen

  • (Khusus VPN Klasik) Jaringan VPC produsen memiliki rute statis yang dikonfigurasi untuk mengirim traffic yang ditujukan ke server nama lokal melalui tunnel VPN Klasik. Jaringan VPC produsen juga harus memiliki VM atau tunnel VPN di region yang sama dengan subjaringan yang digunakan oleh VM klien.

    • Misalnya, VPC1 menggunakan zona peering yang mengirim kueri untuk example.com. ke VPC2. Misalkan juga bahwa VPC2 memiliki zona penerusan pribadi untuk example.com. yang meneruskan kueri ke server nama lokal menggunakan tunnel VPN Klasik.

      Agar VM yang berada di us-east1 di VPC1 dapat membuat kueri example.com., VPC2 harus memiliki VM yang berada di us-east1. Rute statis juga harus dikonfigurasi yang mencakup rentang CIDR server nama lokal, dengan next hop yang dikonfigurasi sebagai tunnel VPN Klasik.

Memverifikasi konektivitas melalui Cloud VPN atau Cloud Interconnect

Anda dapat menggunakan protokol apa pun, seperti ping (ICMP), untuk menguji konektivitas ke VM contoh di jaringan VPC dari lokal. Anda juga harus mencoba membuat kueri server nama lokal langsung dari contoh VM Google Cloud menggunakan alat seperti dig:

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

Memeriksa aturan firewall di jaringan VPC

Aturan firewall izinkan traffic keluar yang tersirat mengizinkan koneksi keluar dan respons yang sudah ditetapkan dari VM di jaringan VPC Anda, kecuali jika Anda telah membuat aturan kustom untuk menolak traffic keluar. Jika telah membuat aturan keluar tolak kustom, Anda harus membuat aturan izinkan prioritas lebih tinggi yang mengizinkan traffic keluar ke setidaknya server nama lokal.

Memeriksa firewall lokal

Pastikan firewall lokal Anda dikonfigurasi untuk mengizinkan traffic masuk dari dan traffic keluar ke 35.199.192.0/19.

Periksa log di firewall lokal Anda, cari permintaan DNS dari 35.199.192.0/19. Untuk menggunakan ekspresi regex untuk melakukan penelusuran, gunakan hal berikut:

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

Memeriksa server nama lokal

Pastikan Anda tidak memiliki ACL yang dikonfigurasi di server nama lokal yang akan memblokir kueri dari 35.199.192.0/19.

Periksa server nama lokal Anda untuk melihat apakah server tersebut menerima paket dari 35.199.192.0/19. Jika memiliki akses shell, Anda dapat menggunakan alat seperti tcpdump untuk mencari paket masuk dari dan paket keluar ke 35.199.192.0/19:

sudo tcpdump port 53 and tcp -vv

Memverifikasi rute kembali

Jaringan lokal Anda harus memiliki rute ke tujuan 35.199.192.0/19 dengan next hop berupa tunnel VPN atau koneksi Interconnect untuk jaringan VPC yang sama yang mengirim permintaan DNS. Perilaku ini dijelaskan dalam Membuat zona penerusan.

Jika Anda menggunakan beberapa tunnel VPN untuk menghubungkan jaringan VPC yang sama ke jaringan lokal, respons tidak harus dikirim menggunakan tunnel yang sama dengan yang mengirimnya. Namun, respons harus dikirim menggunakan tunnel VPN dengan next hop di jaringan VPC yang sama tempat permintaan berasal.

Jika telah menghubungkan lebih dari satu jaringan VPC ke jaringan lokal, Anda harus memastikan bahwa balasan DNS tidak dikirim ke jaringan yang salah. Google Cloud akan menghapus respons DNS yang dikirim ke jaringan VPC yang salah. Untuk solusi yang direkomendasikan, lihat panduan Praktik terbaik kami.

Penerusan keluar ke server nama yang menggunakan alamat IP non-RFC 1918 gagal

Secara default, Cloud DNS menggunakan pemilihan rute standar, yang merutekan kueri melalui internet publik saat server nama target memiliki alamat IP non-RFC 1918. Pemilihan rute standar tidak mendukung penerusan kueri ke server nama dengan alamat non-RFC 1918 yang tidak dapat dijangkau dari internet publik.

Untuk meneruskan kueri ke server nama yang menggunakan alamat IP non-RFC 1918 melalui jaringan VPC Anda, konfigurasikan zona penerusan atau kebijakan server Cloud DNS untuk menggunakan pemilihan rute pribadi bagi server nama target.

Untuk penjelasan tentang perbedaan antara pemilihan rute standar dan pribadi, lihat target penerusan dan metode pemilihan rute.

Batasan ini berlaku meskipun ada rute VPC untuk server nama target; rute untuk alamat non-RFC 1918 tidak berpengaruh pada perilaku penerusan keluar Cloud DNS saat perutean standar dikonfigurasi.

Penerusan keluar ke NIC sekunder gagal

Pastikan Anda telah menyiapkan pengontrol antarmuka jaringan (NIC) sekunder dengan benar.

Untuk petunjuk tentang cara menyiapkan NIC tambahan, lihat Membuat instance virtual machine dengan beberapa antarmuka jaringan.

Kueri yang diteruskan keluar menerima error SERVFAIL

Jika Cloud DNS menerima error dari semua server nama target atau tidak menerima respons dari server nama target mana pun, Cloud DNS akan menampilkan error SERVFAIL.

Untuk mengatasi masalah ini, pastikan server nama lokal Anda dikonfigurasi dengan benar. Kemudian, pastikan server nama lokal Anda merespons kueri dari rentang alamat Cloud DNS yang dijelaskan dalam Membuka firewall Google Cloud dan lokal untuk mengizinkan traffic DNS dalam waktu 4 detik. Jika server nama on-premise Anda meminta bantuan ke server nama upstream (misalnya, karena dikonfigurasi sebagai resolver cache), pastikan tidak ada masalah dengan server nama upstream.

Selain itu, jika target penerusan adalah sistem lokal, perhatikan bahwa rute yang dikonfigurasi untuk jalur tersebut dapat berupa rute dinamis kustom atau rute statis kustom, dengan pengecualian penting bahwa rute statis kustom dengan tag jaringan tidak valid untuk meneruskan kueri DNS. Pastikan rute yang digunakan untuk menjangkau server nama lokal tidak menentukan tag jaringan.

Data resource

Bagian ini memberikan tips pemecahan masalah untuk data resource.

Data yang tidak terduga saat membuat kueri untuk kumpulan data resource yang ada di zona

Ada beberapa alasan mengapa Anda mungkin menerima data yang tidak terduga saat membuat kueri untuk kumpulan data resource yang ada di zona terkelola Cloud DNS:

  1. Kumpulan data resource yang dibuat menggunakan sintaksis @ yang ditentukan dalam RFC 1035 tidak didukung. Cloud DNS menafsirkan simbol @ dalam kumpulan data resource tersebut secara harfiah; oleh karena itu, di zona example.com., kumpulan data yang dibuat untuk QNAME @ ditafsirkan sebagai @.example.com., bukan example.com.. Untuk mengatasi masalah ini, pastikan Anda membuat set data tanpa simbol @; semua nama bersifat relatif terhadap puncak zona.

  2. Seperti semua data, data CNAME karakter pengganti tunduk pada aturan keberadaan yang dijelaskan dalam RFC 4592. Misalnya, misalnya Anda menentukan kumpulan data berikut di zona 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

    Kueri untuk public.srv1.images.example.com. menampilkan NOERROR dengan bagian jawaban kosong. Adanya data di antara CNAME dan QNAME mencegah CNAME ditampilkan, tetapi tidak ada data yang cocok persis dengan QNAME, sehingga Cloud DNS menampilkan jawaban kosong. Ini adalah perilaku DNS standar.

Google Cloud VM menampilkan data pointer (PTR) yang salah

Saat VM dimigrasikan selama peristiwa pemeliharaan, logika data PTR tidak menangani beberapa kasus ekstrem dengan benar dan mengembalikan data PTR DNS ke nama domain yang sepenuhnya memenuhi syarat (FQDN) googleusercontent.com. Untuk memulihkan fungsi, terapkan kembali data PTR.

Untuk mengetahui detail tentang cara menerapkan data PTR di VM, lihat Membuat data PTR untuk instance VM.

Kumpulan data resource Cloud DNS ditampilkan dalam urutan acak

Sesuai dengan praktik industri DNS, server nama Cloud DNS kini mengacak urutan kumpulan data resource dan mengabaikan urutan yang diberikan oleh server otoritatif. Ini adalah perilaku DNS normal dan berlaku untuk zona Cloud DNS pribadi dan .

Jenis resource zonal tidak didukung

Jika Anda memasukkan tanda --location ke perintah gcloud atau permintaan API untuk fitur yang menargetkan zona Cloud DNS yang berbeda, permintaan tersebut akan ditolak. Misalnya, jika Anda mengirim permintaan fitur khusus zona ke server global, atau permintaan fitur khusus global ke server zona, server akan menolak permintaan tersebut dan menampilkan error _UNSUPPORTED_ZONAL_RESOURCETYPE.

Untuk mengetahui daftar resource dan fitur yang didukung Cloud DNS zonal, lihat dukungan Cloud DNS zonal.

Langkah selanjutnya