Halaman ini diterjemahkan oleh Cloud Translation API.

Pemecahan Masalah Domain

Jika Google Public DNS tidak dapat menyelesaikan domain, hal ini sering kali disebabkan oleh masalah pada domain atau server nama resminya. Langkah berikut dapat membantu menentukan penyebab masalah, sehingga administrator domain dapat menyelesaikannya sendiri.

Sebelum memulai langkah-langkah ini, periksa domain di dns.google seperti yang dijelaskan di halaman pemecahan masalah umum, yang mungkin mengarahkan Anda ke langkah diagnostik tertentu di bawah. Atau, coba semua langkah berikut sampai Anda menemukan penyebabnya.

Langkah 1: Periksa masalah validasi DNSSEC

Jika pencarian web dns.google untuk domain menunjukkan "Status": 2 (SERVFAILURE) dan kueri tanpa DNSSEC berhasil, mungkin ada masalah DNSSSEC dengan server nama domain atau registry domain level teratas (TLD)-nya (yang memublikasikan data DS untuk validasi DNSSEC domain terdaftar).

Perubahan pada registrar atau layanan DNS

Masalah DNSSEC dapat terjadi setelah domain beralih dari registrar atau layanan DNS yang mendukung DNSSEC ke domain yang tidak mendukung. Jika layanan sebelumnya meninggalkan data DS usang di registry TLD, dan layanan baru tidak membuat data DNSKEY baru dengan data DS yang cocok dalam registry TLD, memvalidasi resolver seperti Google Public DNS tidak dapat menyelesaikan domain.

Jika hal ini terjadi, minta Registrar Domain untuk menghapus data DS yang sudah usang dari registry TLD.

Respons DNSSEC terlalu besar

Penyebab lain dari masalah DNSSEC dapat berupa respons DNSSEC yang terlalu besar untuk muat dalam satu paket IP, sehingga menciptakan respons terfragmentasi yang mungkin dihapus. Jika DNSViz menunjukkan "tidak ada respons yang diterima hingga ukuran payload UDP berkurang" error, kegagalan DNSSEC dapat disebabkan oleh respons yang sangat besar. Ukuran respons dapat dikurangi dengan satu atau beberapa tindakan berikut:

Konfigurasikan "respons minimal" untuk server nama otoritatif
Kurangi jumlah data DNSKEY yang aktif menjadi dua atau tiga data
Menggunakan data DNSKEY 1280 atau 2048 bit (RFC 6781, StackExchange)
Beralih dari tanda tangan RSA ke tanda tangan ECDSA yang lebih kecil (RFC 8624)

Periksa juga masalah DNSSEC lainnya yang dilaporkan oleh alat pada langkah 2. Contohnya mencakup data denial-of-existence NSEC atau NSEC3 yang buruk yang membuktikan bahwa tidak ada subdomain (PowerDNS dengan zona yang disimpan dalam database eksternal mungkin memilikinya) atau tanda tangan RRSIG yang sudah tidak berlaku (dengan proses penandatanganan yang dikonfigurasi secara manual yang rusak).

Langkah 2: Periksa server nama resmi

Jika Google Public DNS (atau resolver terbuka) mengalami masalah saat menyelesaikan domain, DNSViz akan menampilkan masalah domain dan server nama yang menyebabkannya. Buka halaman DNSViz dan masukkan nama domain yang bermasalah. Jika DNSViz tidak memiliki data historis, atau hanya memiliki data yang berusia lebih dari satu hari (seperti yang ditampilkan pada halaman di sini), klik tombol Analisis besar untuk menampilkan tombol Analisis yang lebih kecil di bawah (jika belum terlihat) dan klik juga. Saat analisis selesai, klik "Lanjutkan" untuk menampilkan hasil. Klik error merah dan peringatan kuning di sidebar kiri untuk menampilkan detail, atau tahan kursor ke objek dalam diagram untuk memunculkan info tersebut dalam konteks.

Jika diagnostik sebelumnya menunjukkan masalah DNSSEC yang mungkin terjadi pada domain, buka halaman web DNSSEC Analyzer dan masukkan nama domain. Jika penganalisis ini melaporkan error atau peringatan DNSSEC, tahan kursor di atas ikon ⊗ atau ⚠ berwarna merah untuk mendapatkan saran cara memperbaikinya.

Halaman web intoDNS melaporkan masalah non-DNSSEC dengan domain yang dimasukkan di halaman utama dan juga menampilkan saran untuk memperbaikinya.

Administrator domain harus memperbaiki sebagian besar error yang dilaporkan alat ini, karena dapat menyebabkan masalah tidak hanya untuk DNS Publik Google tetapi juga resolver lain.

Langkah 3: Periksa masalah delegasi

Google Public DNS adalah resolver "parent-Fokus" yang hanya menggunakan server nama yang ditampilkan dalam rujukan dari domain induk. Jika nama server nama dan alamat glue di TLD sudah usang atau salah, hal ini dapat menyebabkan masalah delegasi.

Jika DNSViz atau intoDNS melaporkan peringatan tentang inkonsistensi antara server nama yang didelegasikan di TLD dan server nama yang berada di domain turunan itu sendiri, server tersebut mungkin perlu ditangani sebelum Google Public DNS dapat menyelesaikan domain. Jika alat ini melaporkan bahwa domain yang terdaftar tidak ada (NXDOMAIN), periksa apakah domain tersebut masih berlaku atau sedang ditangguhkan karena alasan apa pun.

Masalah delegasi juga dapat disebabkan oleh kegagalan dalam menyelesaikan nama server nama untuk suatu domain. Periksa data A dan AAAA untuk server nama di dns.google untuk melihat apakah ada masalah dengan server nama' domain.

Langkah 4: Periksa respons besar

DNS mengandalkan UDP untuk membawa sebagian besar trafficnya. Datagram UDP yang besar tunduk pada fragmentasi dan UDP yang terfragmentasi mengalami pengiriman yang tidak dapat diandalkan. Ini adalah fokus DNS Flag Day 2020, yang merupakan upaya untuk meningkatkan keandalan DNS secara global. Google Public DNS telah berpartisipasi dalam upaya ini, dan membatasi ukuran respons UDP yang akan diterima melalui UDP. Coba kueri seperti di bawah, dengan command prompt Anda sendiri atau Google Cloud Shell:

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

Kueri untuk berbagai jenis data tersebut menentukan:

+dnssec: Aktifkan DNSSEC, terutama menampilkan data yang diperlukan untuk validasi DNSSEC saat tersedia. Hal ini dapat memperluas ukuran hasil secara signifikan. Tindakan ini mengemulasikan perilaku Google Public DNS.
+bufsize=1400: Batasi ukuran buffer UDP yang diizinkan. Tindakan ini mengemulasikan perilaku Google DNS Publik Publik, mulai dari upaya DNS Flag Day 2020.
+timeout=1: Setel waktu tunggu ke satu detik. Tindakan ini mengemulasikan perilaku Google Public DNS.
@ns1.example.com: Server resmi mana yang harus dikueri -- simpan tanda @ tetapi ganti dengan server otoritatif domain Anda sendiri, seperti yang ditunjukkan oleh perintah pertama.

Amati outputnya; apakah Anda melihat garis seperti:

;; Truncated, retrying in TCP mode.: Hal ini menunjukkan bahwa respons lebih besar dari ukuran buffer UDP yang diminta, sehingga responsnya terpotong dan sebagai respons, klien beralih ke TCP. Server otoritatif Anda harus dapat menangani traffic DNS di port TCP 53. (Lihat RFC 7766 yang mengharuskan "implementasi HARUS mendukung UDP dan transpor TCP".)
;; MSG SIZE rcvd: 2198: Untuk angka di atas 1400? Ini sekali lagi menunjukkan respons yang besar.
;; Query time: 727 msec: Untuk angka di atas 500? Respons yang lambat (terutama yang mendekati atau di atas 1 detik) dapat dihapus oleh Google Public DNS. Hal ini sangat mungkin terjadi jika suatu waktu dihabiskan untuk upaya UDP yang kemudian diikuti dengan upaya TCP. Lokasi geografis server dan klien dapat sangat memengaruhi latensi.
;; connection timed out; no servers could be reached: Terutama jika hanya untuk beberapa kueri, hal ini menunjukkan masalah sehingga server Anda tidak dapat menjawab kueri DNS secara tepat waktu.

Anda dapat mencoba variasi kueri berikut:

Menambahkan parameter +tcp.: Tindakan ini memaksa dig untuk langsung menggunakan TCP, sehingga Anda dapat memeriksa apakah server resmi Anda menangani kueri TCP secara langsung dengan cara ini.
Menghapus parameter +bufsize=1400.: Tindakan ini akan memulihkan perilaku default dig, (dengan ukuran sebesar 4096). Jika kueri Anda gagal dengan setelan ini, tetapi berfungsi tanpanya, ini adalah petunjuk bahwa server Anda tidak menangani failover TCP dengan baik. Mengandalkan UDP untuk membawa respons besar terkadang hanya berfungsi. Tindakan terbaiknya adalah mendukung transpor TCP untuk DNS.
Berulang di setiap server nama.: Contoh di atas memiliki dua server nama otoritatif (ns1 dan ns2). Beberapa masalah disebabkan oleh server yang berbeda yang menampilkan jawaban yang berbeda. Pastikan semuanya menjawab secara konsisten dengan mengulangi kueri yang sama di semua server otoritatif.

Jika semua kueri' berukuran kecil (1400 byte atau kurang), cepat (sebaiknya 500 milidetik atau lebih cepat), dan dapat diandalkan (bekerja secara konsisten melalui TCP dan UDP), ukuran respons tidak menjadi masalah Anda; baca bagian pemecahan masalah lainnya. Meskipun respons Anda cepat, kueri dari jarak yang jauh secara geografis mungkin lebih lambat.

Jika salah satu pemeriksaan ini gagal (besar? lambat? tidak dapat diandalkan?), tindakan utama yang harus dilakukan adalah A) memastikan server Anda merespons dengan pemotongan UDP, jika responsnya melebihi ukuran buffer UDP dan B yang diminta), maka server tersebut dapat menangani percobaan ulang kueri TCP yang akan mengikutinya. Beberapa alat dapat membantu Anda mendiagnosis masalah keandalan DNS:

DNSViz
Debugger DNSSEC
Penguji Kepatuhan EDNS
DNS Checker -- pastikan untuk menghapus centang kotak "CD" (nonaktifkan pemeriksaan DNSSEC)

Jika ada error atau peringatan yang ditampilkan oleh alat ini, pastikan untuk mengatasinya. Pastikan juga untuk membaca semua petunjuk pemecahan masalah lainnya di situs ini.

Langkah 5: Periksa apakah resolver publik lainnya menyelesaikan domain

Jika Anda tidak menemukan penyebab masalah setelah mengikuti langkah-langkah di atas, jalankan perintah berikut di command prompt, dengan mengganti example.test. dengan domain yang dimaksud (dan mempertahankan titik di akhir):

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS atau Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

Perintah ini menggunakan resolver DNS OpenDNS, Quad9, dan Cloudflare 1.1.1.1. Jika Anda mengalami kegagalan resolusi dari dua hal tersebut serta Google Public DNS, kemungkinan masalahnya ada pada domain atau server namanya.

Jika Anda mendapatkan hasil yang sukses dari lebih dari satu resolver publik lainnya, mungkin ada masalah dengan Google Public DNS. Jika tidak ada masalah serupa yang telah dilaporkan untuk domain (atau TLD-nya) di issue tracker, Anda harus melaporkan masalah tersebut kepada kami, termasuk output perintah dan teks halaman diagnostik atau screenshot dalam laporan Anda.