Halaman ini memberikan solusi untuk masalah umum yang mungkin Anda alami saat menggunakan Cloud DNS untuk membuat zona publik, zona pribadi, 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:
Di konsol Google Cloud, buka halaman Library API.
Untuk Select a recent project, pilih project Google Cloud tempat Anda ingin mengaktifkan API.
Di halaman API library, gunakan kotak Search for APIs & Services untuk menelusuri
Cloud DNS API. Halaman yang menjelaskan API akan muncul.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
pertama-tama 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)"
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
GLOBALVM 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 untukexample.com.yang meneruskan kueri ke server nama lokal menggunakan tunnel VPN Klasik.Agar VM yang berada di
us-east1di VPC1 dapat membuat kueriexample.com., VPC2 harus memiliki VM yang berada dius-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 on-premise yang akan memblokir kueri dari 35.199.192.0/19.
Periksa server nama lokal 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 lokal 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:
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 zonaexample.com., kumpulan data yang dibuat untuk QNAME@ditafsirkan sebagai@.example.com., bukanexample.com.. Untuk mengatasi masalah ini, pastikan Anda membuat set data tanpa simbol@; semua nama bersifat relatif terhadap puncak zona.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.92Kueri untuk
public.srv1.images.example.com.menampilkanNOERRORdengan 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.
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 publik dan pribadi.
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
- Untuk mempelajari fitur lebih lanjut, lihat Ringkasan Cloud DNS.
- Untuk mengatasi error, lihat Pesan error.
- Untuk mendapatkan bantuan tambahan, lihat Dukungan.