Alibaba Cloud DNS：FAQ resolusi DNS cerdas

P: Masalah dengan penjadwalan penguraian cerdas yang tidak akurat

J: Metode ini hanya berlaku untuk nama domain yang menggunakan Alibaba Cloud DNS. Jika nama domain Anda dihosting di server DNS penyedia lain, hubungi penyedia server DNS Anda untuk mendapatkan bantuan. Untuk nama domain yang menggunakan server DNS Alibaba Cloud, jika jalur penguraian cerdas yang Anda atur menunjukkan penjadwalan yang tidak akurat, lihat Pemecahan masalah penjadwalan penguraian cerdas yang tidak akurat.

P: Bagaimana fitur penguraian cerdas ditagih?

J: Fitur penguraian pintar tidak ditagih secara terpisah. Biaya ini termasuk dalam biaya versi Cloud DNS. Selain itu, versi Cloud DNS yang berbeda mendukung rentang jalur penguraian yang berbeda. Untuk informasi lebih lanjut, lihat dokumen Harga dan Perbandingan versi.

P: Bagaimana cara penguraian cerdas menentukan lokasi geografis pengunjung?

J: Cloud DNS menentukan lokasi geografis pengunjung melalui IP keluar dari LocalDNS yang digunakan oleh pengunjung.

P: Dapatkah jalur penguraian diatur berdasarkan wilayah Tiongkok?

J: Ya, jalur penguraian dapat diatur berdasarkan wilayah Tiongkok. Mereka mendukung Tiongkok Timur, Tiongkok Utara, Tiongkok Tengah, Tiongkok Selatan, Tiongkok Barat Daya, Tiongkok Barat Laut, dan Tiongkok Timur Laut. Untuk informasi lebih lanjut, lihat Enumerasi jalur penguraian. Jalur regional Tiongkok hanya didukung di Edisi Perusahaan Cloud DNS.

P: Bagaimana cara saya menggunakan DNS cerdas untuk mengalihkan lalu lintas permintaan pengguna ke server normal ketika server gagal?

J: Penguraian cerdas tidak mendukung penghapusan otomatis IP yang rusak atau pengalihan otomatis. Untuk mencapai efek ini, kami sarankan Anda merujuk ke Apa itu Global Traffic Manager 3.0.

P: Saya memiliki dua server pada jalur China Mobile dan China Unicom masing-masing. Apakah penguraian cerdas Cloud DNS mendukung pengguna mengakses server terdekat?

J: Ya, kebijakan penguraian DNS adalah sebagai berikut:

Berdasarkan Carrier dari permintaan pengguna, sistem mengembalikan alamat IP server operator yang sesuai, mencapai tanggapan berbasis kedekatan. Untuk permintaan dari operator selain China Mobile atau China Unicom, sistem mengembalikan alamat IP jalur China Mobile sebagai fallback default.

P: Dapatkah jalur penguraian cerdas dikonfigurasi dengan lokasi geografis yang tumpang tindih? Jika didukung, bagaimana Cloud DNS menanggapi permintaan DNS?

J: Untuk sumber penguraian berdasarkan Region, tingkat prioritas berikut berlaku.

Anda dapat mengonfigurasi catatan DNS dengan lokasi geografis yang tumpang tindih (misalnya, menetapkan jalur penguraian ke luar Tiongkok, Asia, Singapura). Jika pengguna akhir berasal dari Singapura, sistem mengembalikan alamat penguraian yang ditentukan oleh jalur Singapura. Jika lokasi geografis pengguna akhir bukan di Singapura tetapi di Asia, sistem mengembalikan alamat penguraian yang ditentukan oleh jalur Asia. Jika lokasi geografis pengguna akhir bukan di Asia tetapi di benua lain, sistem mengembalikan alamat penguraian yang ditentukan oleh jalur luar Tiongkok.

P: Apakah mungkin untuk memberikan layanan hanya kepada pengguna di Tiongkok?

J: Ya, kebijakan penguraian DNS adalah sebagai berikut:

Dalam kebijakan penguraian DNS, untuk permintaan dari sumber permintaan di Daratan Tiongkok, sistem mengembalikan alamat IP server aktual Anda atau node aktif. Untuk kelompok Outside Mainland China, yang mencakup Hong Kong (Tiongkok), Makau (Tiongkok), Taiwan (Tiongkok), dan wilayah lainnya, Anda dapat mengembalikan alamat IP tidak valid, seperti 127.0.0.1 atau 0.0.0.0, untuk memblokir resolusi dari lokasi-lokasi tersebut.

Kegagalan resolusi Rekaman A ketika jalur default adalah rekaman CNAME

Deskripsi masalah

Sebuah catatan host di Alibaba Cloud DNS dikonfigurasi dengan dua rekaman DNS: rekaman CNAME untuk jalur default dan rekaman A untuk jalur Daratan Tiongkok. Namun, ketika klien di Daratan Tiongkok meminta rekaman A, justru rekaman CNAME untuk jalur default yang dikembalikan.

Penyebab

Ketika pengguna akhir pada jalur non-default meminta tipe rekaman selain rekaman A, server DNS otoritatif mengembalikan rekaman CNAME. Server DNS lokal kemudian menyimpan cache rekaman CNAME tersebut. Karena rekaman CNAME memiliki prioritas tertinggi, jika klien kemudian meminta rekaman A, permintaan tersebut mengenai rekaman CNAME yang telah di-cache di server DNS lokal. Akibatnya, server DNS lokal mengembalikan rekaman CNAME yang telah di-cache tersebut, bukan mengirim permintaan resolusi baru ke server DNS otoritatif. Perilaku ini ditentukan oleh protokol DNS.

Solusi

Jika Anda telah mengonfigurasi jalur resolusi spesifik lainnya, jangan atur jalur default ke rekaman CNAME. Hapus rekaman CNAME dari jalur default. Setelah TTL cache DNS lokal di sisi carrier berakhir, rekaman DNS akan diselesaikan dengan benar.