Memecahkan masalah Cloud DNS

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

Zona publik

Bagian ini membahas berbagai 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 API Library.

    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 berbagai masalah terkait zona pribadi.

Masalah zona pribadi di project layanan VPC Bersama

Untuk mengetahui 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 membuat daftar kebijakan server Domain Name System (DNS) atau membuat zona pribadi. Peran ini dapat diberikan melalui alat Identity and Access Management (IAM).

Zona pribadi yang 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) mengirimkan semua traffic dari antarmuka utamanya kecuali jika traffic tersebut ditujukan untuk subnet yang terpasang ke salah satu antarmuka lain atau jika VM telah mengonfigurasi perutean kebijakan. Pastikan VM pengujian Anda memiliki antarmuka utamanya di jaringan yang sama dengan zona pribadi yang diuji.

Pastikan VM Anda menggunakan:

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

Pastikan jaringan berada dalam daftar jaringan yang diizinkan untuk mengkueri 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 setidaknya satu zona pribadi yang dapat diakses di jaringan VPC Anda. Misalnya, Google Cloud terlebih dahulu akan 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)"

Mengkueri 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 mengkueri server nama default VM:

dig DNS_NAME

Jika output kedua perintah dig menghasilkan jawaban yang berbeda, periksa bagian ;; SERVER: pada perintah kedua. Server respons 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 sudah mengimpor image yang digunakan untuk VM, pastikan lingkungan tamu yang sesuai telah diinstal.

Zona pribadi tidak dapat diselesaikan melalui Cloud VPN atau Cloud Interconnect

Pertama-tama, pastikan Anda berhasil mengkueri dan me-resolve nama DNS dari dalam jaringan VPC yang diizinkan.

Memverifikasi konektivitas melalui Cloud VPN atau Cloud Interconnect

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

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

Pastikan penerusan masuk diaktifkan untuk jaringan VPC yang diberi otorisasi

Penerusan masuk harus diaktifkan untuk setiap jaringan VPC yang diberi otorisasi untuk mengkueri zona pribadi Cloud DNS Anda. Gunakan perintah berikut untuk menampilkan daftar semua kebijakan:

gcloud dns policies list

Identifikasi jaringan di tabel output, dan periksa kolom Penerusan 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 valid yang dicadangkan di jaringan tersebut

Perintah berikut menampilkan semua alamat IP penerusan DNS yang dicadangkan di 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 diinginkan.

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 dengan mengarahkan kueri ke alamat yang Anda temukan dalam perintah sebelumnya. Lakukan hal tersebut dari VM dalam 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 terbalik. Beberapa masalah zona pribadi juga berlaku untuk zona pencarian terbalik. Untuk tips tambahan, lihat bagian pemecahan masalah Zona pribadi.

VM dengan alamat non-RFC 1918 tidak terselesaikan

Rekonsiliasi 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 di-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-tama, pastikan Anda berhasil mengkueri dan me-resolve nama DNS dari dalam jaringan VPC yang diizinkan.

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

Jika 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, Anda harus memastikan bahwa jaringan VPC produsen memiliki tunnel VM atau VPN di region yang sama dengan subnetwork yang digunakan oleh VM klien.

Misalnya, VPC1 menggunakan zona peering yang mengirimkan kueri untuk example.com. ke VPC2. Misalkan VPC2 memiliki zona penerusan pribadi untuk example.com. yang meneruskan kueri ke server nama lokal menggunakan tunnel Cloud VPN atau Cloud Interconnect. Agar VM yang terletak di us-east1 di VPC1 dapat membuat kueri example.com., VPC2 juga harus memiliki tunnel VM atau VPN yang terletak di us-east1.

Dalam beberapa kasus, penerusan menggunakan peering DNS mungkin dapat berfungsi meskipun tidak ada resource di suatu region.

Memverifikasi konektivitas melalui Cloud VPN atau Cloud Interconnect

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

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

Periksa aturan firewall di jaringan VPC Anda

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

Periksa firewall lokal

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

Periksa log di firewall lokal dengan mencari permintaan DNS dari 35.199.192.0/19. Untuk menggunakan ekspresi regex guna 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 menerima paket dari 35.199.192.0/19. Jika memiliki akses shell, Anda dapat menggunakan alat seperti tcpdump untuk mencari paket masuk dan paket keluar ke 35.199.192.0/19:

sudo tcpdump port 53 and tcp -vv

Verifikasi rute pulang pergi

Jaringan lokal Anda harus memiliki rute ke tujuan 35.199.192.0/19 dengan hop berikutnya 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 mengirimkannya. Namun, respons harus dikirimkan 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 yang salah. Google Cloud 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 perutean standar, yang merutekan kueri melalui internet publik saat server nama target memiliki alamat IP non-RFC 1918. Perutean 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 Cloud DNS atau kebijakan server agar menggunakan perutean pribadi untuk server nama target.

Untuk mengetahui penjelasan mengenai perbedaan antara perutean standar dan pribadi, lihat target penerusan dan metode perutean.

Batasan ini berlaku meskipun ada rute VPC untuk server nama target; rute untuk alamat non-RFC 1918 tidak akan 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 mengetahui petunjuk cara menyiapkan NIC tambahan, lihat Membuat instance mesin virtual 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 salah satu server nama target, error SERVFAIL akan ditampilkan.

Untuk mengatasi masalah ini, pastikan server nama lokal Anda sudah dikonfigurasi dengan benar. Kemudian, pastikan server nama lokal Anda merespons kueri dari rentang alamat IP Cloud DNS yang dijelaskan dalam Membuka firewall lokal dan Google Cloud untuk mengizinkan traffic DNS dalam waktu 4 detik. Jika server nama lokal Anda menggunakan server nama upstream (misalnya, karena dikonfigurasi sebagai resolver caching), 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 melakukan 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 Cloud DNS terkelola:

  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 @ akan ditafsirkan sebagai @.example.com., bukan example.com.. Untuk mengatasi masalah ini, pastikan Anda membuat kumpulan data tanpa simbol @; semua nama relatif terhadap apeks zona.

  2. Seperti semua data, data CNAME karakter pengganti tunduk pada aturan keberadaan yang dijelaskan dalam RFC 4592. Misalnya, anggaplah 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. akan menampilkan NOERROR dengan bagian jawaban kosong. Keberadaan data antara CNAME dan QNAME mencegah CNAME ditampilkan, namun tidak ada data yang sama persis dengan QNAME, sehingga Cloud DNS menampilkan jawaban kosong. Ini adalah perilaku DNS standar.

VM Google Cloud 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 data PTR lagi.

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

Kumpulan data resource Cloud DNS yang ditampilkan dalam urutan acak

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

Jenis resource zona tidak didukung

Saat Anda memasukkan flag --location ke perintah gcloud atau permintaan API untuk fitur yang menargetkan zona Cloud DNS lain, 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 memberikan error _UNSUPPORTED_ZONAL_RESOURCETYPE.

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

Langkah selanjutnya