Panduan cek DNS: record, TTL, dan pemecahan masalah
ToolMellow ·
Pencarian DNS meminta satu jenis record untuk satu nama tertentu kepada resolver. Gunakan pemeriksa DNS ToolMellow untuk melihat alamat, alias, rute email, atau teks yang dikembalikan, membandingkan penyedia yang dipilih, dan menyimpan pengamatan beserta waktunya. Mulailah dengan nama DNS yang tepat dan jenis record yang sesuai dengan tugas Anda.
Alat ini mengirim kueri ke Cloudflare dan Google Public DNS melalui lokasi kueri ToolMellow yang tersedia. Hasilnya menjelaskan permintaan tersebut; hasil itu tidak membuktikan apa yang dilihat setiap pengguna, perangkat, atau resolver. Panduan ini menjelaskan kontrol, cara membaca hasil, dan langkah penyelidikan ketika record berbeda dari nilai yang diharapkan. Semua nama, alamat, dan nilai contoh di bawah bersifat ilustratif, bukan pengukuran langsung.
Cara menjalankan pencarian DNS
Buka pemeriksa DNS dan tunggu konfigurasi koneksi dimuat. Masukkan nama seperti www.example.com, pilih jenis record, pilih satu atau kedua penyedia, lalu pilih lokasi kueri yang tersedia. Tekan Periksa DNS untuk mengirim permintaan. Membuka halaman atau mengedit nama tidak otomatis mencari recordnya.
Sebelum menafsirkan nilai, baca penyedia, lokasi, status, dan waktunya. Jika nilai yang diperlukan sudah diketahui, masukkan ke kolom opsional nilai yang diharapkan lalu pilih Sama persis atau Mengandung. Unduh laporan DNS menyimpan pengamatan saat ini sebagai dns-results.json; simpan file untuk membandingkan sebelum dan sesudah perubahan.
- Setiap pemeriksaan menggunakan satu nama DNS dan satu jenis record. Jalankan kueri A dan AAAA secara terpisah untuk menyelidiki kedua keluarga alamat.
- Pilihan awal adalah A, kedua penyedia, dan lokasi utama ToolMellow. Lokasi yang tersedia berasal dari konfigurasi layanan saat ini.
- Mengubah nama, jenis, penyedia, atau lokasi menghapus hasil sebelumnya. Mengedit nilai yang diharapkan atau mode hanya membandingkan ulang hasil saat ini secara lokal.
Pilih jenis record DNS sesuai tugas
Record DNS menjawab pertanyaan yang berbeda. Kueri A bukan permintaan semua record domain, dan kueri MX tidak mengirim email uji. Pilihan jenis mendukung sembilan jenis. Pencocokan nilai yang diharapkan mendukung delapan jenis kueri maju di bawah; hasil PTR dapat diperiksa dan diunduh, tetapi perbandingan nilai yang diharapkan tidak tersedia.
| Jenis | Isi | Makna praktis |
|---|---|---|
| A | Data alamat IPv4 | Periksa IPv4 yang dikembalikan untuk nama yang diminta; ini tidak menguji situs di alamat tersebut. |
| AAAA | Data alamat IPv6 | Periksa IPv6 terpisah dari A; tujuan IPv4 yang berfungsi tidak membuktikan IPv6 berfungsi. |
| CNAME | Nama tujuan alias | Periksa alias dan penulisan yang dikembalikan. Alias DNS tidak membuat pengalihan HTTP dengan sendirinya. |
| MX | Preferensi penukar email dan nama tujuan | Baca preferensi serta nama host. Keberadaan record tidak membuktikan email berhasil terkirim. |
| TXT | Teks yang dibawa DNS | Periksa data verifikasi atau email pada nama record persis yang diberikan penyedia. |
| NS | Nama server nama | Periksa nama server yang dikembalikan; nama tersebut berbeda dari penyedia rekursif yang dipilih untuk kueri. |
| SOA | Metadata otoritas zona | Periksa metadata zona dan konteks jawaban negatif; waktu kueri bukan waktu perubahan record. |
| CAA | Data otorisasi otoritas sertifikat | Periksa otorisasi yang dipublikasikan; ini bukan uji validitas sertifikat atau HTTPS. |
| PTR | Penunjuk nama DNS balik | Masukkan nama record DNS balik lengkap. IP literal dan pencocokan nilai yang diharapkan tidak didukung di sini. |
RFC 1035: implementasi DNS dan format recordRFC 3596: ekstensi DNS untuk IPv6RFC 8659: otorisasi otoritas sertifikat
Masukkan nama DNS yang tepat, termasuk nama TXT dan IDN
Gunakan nama tempat record DNS berada, tanpa skema URL, jalur, alamat email, atau port. Domain utama dan nama www merupakan masukan berbeda. Instruksi verifikasi penyedia dapat meminta subdomain atau nama berawalan garis bawah; mencari TXT pada domain utama tidak otomatis menemukan TXT pada nama lainnya.
Pemeriksa menghapus spasi di kedua ujung, mengenali variasi titik Unicode yang didukung, menghapus titik akar terakhir, mengubah nama internasional yang didukung menjadi ASCII dengan domainToASCII milik Node, lalu mengubah nama menjadi huruf kecil. Diperlukan setidaknya dua label, masing-masing paling banyak 63 karakter ASCII setelah konversi dan total paling banyak 253. Label biasa menerima huruf, angka, dan tanda hubung di tengah. Label layanan yang didukung dengan awalan garis bawah diterima, tetapi garis bawah sembarang di tengah label tidak diterima.
| Masukan ilustratif | Kegunaan | Detail masukan |
|---|---|---|
example.com | Record domain utama | Pilih jenis yang diperlukan; ini tidak mencantumkan semua jenis atau subdomain. |
www.example.com. | Record nama www | Titik akar terakhir diterima lalu dihapus dari nama kueri yang dinormalisasi. |
_dmarc.example.com | Pengamatan TXT terkait DMARC | Pilih TXT. Kueri ini tidak mengevaluasi seluruh penemuan kebijakan DMARC atau penyelarasan pengenal pesan. |
selector._domainkey.example.com | Pengamatan TXT terkait DKIM | Ganti selector dengan pemilih yang diberikan layanan email Anda. |
bücher.example | Masukan nama internasional | IDN yang didukung diubah menjadi nama kompatibel ASCII; periksa nama yang dinormalisasi dalam hasil. |
10.113.0.203.in-addr.arpa | Masukan nama record PTR | Oktet IPv4 dibalik dalam contoh nama DNS balik ini; perbandingan nilai yang diharapkan tidak tersedia. |
https://example.com/path, 203.0.113.10, *.example.com | Bentuk masukan yang ditolak | Gunakan nama DNS. Untuk IP literal, gunakan alat pencarian IP atau DNS balik yang terpisah. |
RFC 5891: nama domain internasionalNode.js: konversi URL domainToASCIIRFC 1035: implementasi DNS dan format recordRFC 6376: tanda tangan DKIM dan pencarian kunci berdasarkan pemilihRFC 9989: penemuan kebijakan dan penyelarasan DMARC
Penyedia rekursif dan server nama otoritatif memiliki peran berbeda
Server nama otoritatif memublikasikan data zona DNS. Resolver rekursif memperoleh jawaban untuk klien dan dapat memakai kembali informasi cache. Memilih Google Public DNS atau Cloudflare memilih layanan rekursif untuk pengamatan ini; bukan berarti layanan itu menghosting zona Anda atau merupakan server nama otoritatif domain Anda.
ToolMellow mengirim permintaan dari servernya atau probe yang dikonfigurasi ke endpoint HTTPS tetap milik penyedia, lalu membaca respons JSON. Format JSON yang ditentukan penyedia berbeda dari pesan biner DNS yang distandardisasi untuk DNS melalui HTTPS. Pencarian ini tidak mengubah setelan DNS perangkat, tidak menanyakan server nama sembarang yang Anda masukkan, dan tidak menelusuri setiap delegasi mulai dari akar.
RFC 1034: nama domain, resolusi, dan cacheRFC 8484: kueri DNS melalui HTTPSGoogle Public DNS: API JSON untuk DNS melalui HTTPSCloudflare 1.1.1.1: permintaan DNS melalui HTTPS dengan JSON
Baca nama record, TTL, dan detail pengamatan bersama-sama
Setiap baris jawaban memuat nama record, jenis, TTL yang dikembalikan dalam detik, dan data tekstual. Baca nama bersama nilainya: respons rekursif dapat memuat rangkaian alias dan alamat tujuan alias. CNAME pendukung atau jenis lain tidak menggantikan jenis yang Anda minta. Buka Record otoritas untuk memahami konteks jawaban negatif atau rujukan ke server lain.
Setiap hasil penyedia dan lokasi memiliki waktu pengamatan serta durasi. Waktu itu menjelaskan kueri ini, bukan kapan administrator terakhir mengubah DNS. Durasi mencakup jalur permintaan serta pekerjaan HTTP dan pemrosesan; ini bukan tolok ukur DNS saja untuk koneksi Anda. Jika kegagalan menyebabkan record atau indikator tidak tersedia, anggap informasi itu tidak tersedia dan jangan menebak nilainya.
RFC 1035: implementasi DNS dan format recordRFC 2308: cache negatif kueri DNS
Bedakan ketiadaan data DNS dari kegagalan permintaan
Jawaban negatif yang valid dan permintaan yang tidak dapat diselesaikan memerlukan tindak lanjut berbeda. Di ToolMellow, klasifikasi positif NOERROR memuat jawaban dari jenis yang diminta. Respons DNS berhasil lainnya diklasifikasikan memakai konteks SOA, CNAME, atau NS. Tabel menjelaskan status yang terlihat tanpa menyamakan setiap jawaban kosong dengan domain yang tidak ada.
Respons terpotong belum lengkap meski sebagian memuat teks yang diharapkan. Alat menandai perbandingan sebagai tidak konklusif jika respons terpotong atau ada kegagalan operasional. Satu penyedia dapat berhasil ketika yang lain gagal; simpan keduanya alih-alih menganggap kegagalan sebagai bukti record tidak ada.
| Status atau kondisi | Arti pada pemeriksa ini | Langkah berikut yang berguna |
|---|---|---|
| NOERROR | Respons berhasil memuat jawaban dari jenis yang diminta | Periksa nilai relevan, nama, dan TTL; keberhasilan DNS tidak menguji layanan tujuan. |
| NXDOMAIN | Resolver melaporkan nama DNS yang diminta tidak ada | Periksa ejaan dan nama yang dimaksud. Ini bukan pemeriksaan ketersediaan pendaftaran domain. |
| NODATA | Tidak ada jawaban jenis yang diminta; respons berhasil memuat SOA pada Authority | Periksa apakah nama seharusnya memiliki jenis ini. AAAA yang tidak ada tidak sama dengan domain yang tidak ada. |
| ALIAS_ONLY | Setelah pemeriksaan SOA, CNAME dikembalikan tanpa jawaban jenis yang diminta | Periksa alias dan tujuannya; respons A dengan CNAME saja tidak memberi nilai A yang diharapkan. |
| REFERRAL | Setelah klasifikasi sebelumnya, tidak ada jawaban yang diminta tetapi ada NS pada Authority | Periksa Record otoritas; ini bukan jawaban lengkap untuk record yang diminta. |
| EMPTY_ANSWER | Tidak ada jawaban yang diminta atau konteks SOA, CNAME, maupun NS yang dikenali | Simpan detailnya; jangan mengubahnya menjadi NXDOMAIN. |
| SERVFAIL atau REFUSED | Server DNS melaporkan kegagalan atau penolakan | Selidiki penyedia dan konfigurasi domain; status saja tidak mengidentifikasi satu penyebab tertentu. |
| Error HTTP, waktu habis, respons tidak sesuai format, atau kegagalan probe | Pengamatan tidak dapat diselesaikan dengan andal | Baca informasi koneksi dan coba lagi dengan sengaja saat sesuai; ketiadaan record belum terbukti. |
| Terpotong / TC | Penyedia melaporkan respons tidak lengkap | Anggap perbandingan tidak konklusif dan simpan indikator respons parsial. |
RFC 2308: cache negatif kueri DNSGoogle Public DNS: API JSON untuk DNS melalui HTTPSCloudflare 1.1.1.1: permintaan DNS melalui HTTPS dengan JSON
Arti TTL setelah perubahan record DNS
TTL menyatakan masa berlaku cache dalam detik. Resolver rekursif dapat mengembalikan waktu tersisa dari informasi yang disimpan, sehingga dua respons dengan data sama dapat menunjukkan TTL berbeda. Angka itu bukan hitung mundur sampai semua resolver di dunia memakai nilai baru Anda.
Jawaban positif, jawaban negatif, dan informasi delegasi dapat memiliki riwayat cache berbeda. Menurunkan TTL sekarang tidak memperpendek secara retroaktif masa berlaku salinan yang sudah disimpan. Sebagian resolver juga dapat menyajikan data kedaluwarsa menurut kebijakan ketahanan tertentu. Kueri baru memberi pengamatan lain, bukan bukti bahwa setiap cache sudah mutakhir.
Untuk perubahan terencana, pastikan nama dan nilai yang dimaksud dengan layanan hosting DNS, simpan pengamatan lama dan baru, lalu ulangi pemeriksaan relevan pada interval yang berguna. Rencanakan verifikasi berdasarkan instruksi penyedia serta konteks cache sebelumnya. Pernyataan umum 24 atau 48 jam tidak dapat menjelaskan setiap perubahan DNS.
RFC 2181, bagian 8: masa berlakuRFC 2308: cache negatif kueri DNSRFC 8767: menyajikan data DNS kedaluwarsa
Mengapa kesepakatan penyedia tidak membuktikan propagasi global
Google dan Cloudflare dapat mengembalikan jawaban berbeda karena pengamatan dalam cache atau perilaku resolusinya. Jawaban otoritatif yang bergantung lokasi juga dapat berpengaruh. Bandingkan dahulu nama yang dinormalisasi dan jenis yang sama pada waktu tercatat; kemudian periksa status, nama, nilai, dan TTL. Perbedaan tidak otomatis mengidentifikasi jawaban yang benar.
Setiap pemeriksaan dapat memilih paling banyak empat lokasi kueri yang dikonfigurasi, tetapi hanya lokasi yang benar-benar tercantum di antarmuka yang tersedia. Jika satu lokasi tercantum, kedua penyedia ditanya melalui lokasi itu. Wilayah yang dinyatakan bukan lokasi geografis yang dikonfirmasi secara independen saat indikator verifikasinya false. Jangan menyimpulkan jaringan probe global dari jumlah penyedia atau batas pemilihan.
Kesepakatan hanya menetapkan kesepakatan di antara pengamatan ini. Perangkat Anda, jaringan lain, atau resolver perusahaan privat masih dapat melihat jawaban berbeda, terutama dengan cache lokal atau tampilan DNS berbeda menurut jaringan. Gunakan layanan multilokasi dengan cakupan sesuai atau diagnostik jaringan sendiri saat memerlukan perspektif tambahan tersebut.
RFC 1034: nama domain, resolusi, dan cacheRFC 8767: menyajikan data DNS kedaluwarsa
Bandingkan nilai secara literal dengan Sama persis atau Mengandung
Perbandingan memeriksa nilai Answer dari jenis yang diminta dan didukung fungsi ini. Sama persis berarti seluruh teks yang dikembalikan sama dengan teks yang diharapkan; Mengandung berarti teks itu memuat substring yang diharapkan. Keduanya membedakan huruf kapital dan huruf kecil. Satu nilai cocok membuat hasil penyedia dan lokasi itu cocok, walaupun nilai lain berbeda. Ini tidak membuktikan seluruh kumpulan record sama dengan konfigurasi yang dimaksud.
Perbandingan tidak memangkas spasi, menghapus tanda kutip atau titik terakhir, menormalkan penulisan IPv6, atau mengurai sintaks kebijakan DNS. Ekspresi reguler tidak didukung. Perbandingan nama host pada protokol DNS dapat mengabaikan kapitalisasi, tetapi perbandingan string ini membedakannya. Gunakan bentuk yang dikembalikan untuk kesamaan literal, dan periksa data lengkap sebelum memakai substring pendek sebagai bukti.
- NXDOMAIN dan NODATA biasanya dibandingkan sebagai berbeda jika nilai yang diminta tidak ada; keduanya pengamatan negatif valid, bukan kegagalan permintaan.
- Hasil gagal atau terpotong tidak konklusif. Perbandingan juga tidak tersedia untuk teks yang diharapkan kosong, melebihi 4096 unit string JavaScript, atau untuk PTR.
- Teks yang diharapkan tetap di tab ini dan laporan yang diunduh. Teks itu tidak dikirim bersama kueri DNS. Kecocokan teks saja tidak membuktikan validasi DNSSEC atau kepemilikan domain.
| Data contoh yang dikembalikan | Teks yang diharapkan | Pelajaran perbandingan |
|---|---|---|
A: 203.0.113.10 | 203.0.113.10 | Sama persis cocok dengan nilai ini; jawaban A lain masih dapat memuat alamat berbeda. |
CNAME: target.example.com. | target.example.com | Titik terakhir membuat perbandingan persis berbeda; Mengandung menemukan substring. |
MX: 10 mail.example.com. | mail.example.com | Preferensi dan titik terakhir membuat perbandingan persis berbeda; Mengandung hanya memeriksa potongan teks. |
TXT: "verification=sample-token" | verification=sample-token | Tanda kutip yang ikut dikembalikan membuat perbandingan persis berbeda; Mengandung dapat menemukan potongan teks. |
CNAME: Target.example.com. | target.example.com. | Kapitalisasi membedakan pencocokan literal, meski kesamaan nama DNS memiliki semantik lain. |
TXT: "part-one" "part-two" | part-onepart-two | Fungsi tidak menggabungkan potongan dalam tanda kutip atau menafsirkan kebijakan lengkap. |
Baca indikator data terautentikasi DNSSEC bersama sumbernya
Indikator Terautentikasi mencerminkan flag AD dari resolver rekursif yang dipilih. Resolver itulah yang menyatakan datanya terautentikasi; ToolMellow tidak memverifikasi tanda tangan DNSSEC atau rantai kepercayaan secara independen. Mengandalkan pernyataan itu juga bergantung pada kepercayaan terhadap resolver serta kanal yang membawa responsnya.
Tidak terautentikasi berarti penyedia tidak menyatakan AD. Data tanpa tanda tangan dapat memberi hasil ini, sehingga flag saja tidak membuktikan domain rusak atau berbahaya. SERVFAIL juga memerlukan penyelidikan, bukan diagnosis DNSSEC otomatis. Pemeriksa meminta data respons terkait DNSSEC dengan pemeriksaan di penyedia tetap aktif, tetapi bukan audit DNSSEC lengkap atau pengujian kebocoran DNS browser.
RFC 4035: DNSSEC dan pernyataan data terautentikasiGoogle Public DNS: API JSON untuk DNS melalui HTTPSCloudflare 1.1.1.1: permintaan DNS melalui HTTPS dengan JSON
Periksa DNS situs sebelum menyelidiki hosting dan HTTPS
Saat situs mengarah ke tujuan lama, periksa nama host persis yang dipakai pengunjung. Bandingkan A dan AAAA secara terpisah, lalu periksa CNAME untuk alias seperti www. Jangan menganggap domain utama dan www memiliki konfigurasi sama. Bandingkan hasil dengan record yang diwajibkan petunjuk hosting, termasuk tujuan alias yang diperlukan.
Nilai DNS yang tampak benar hanyalah satu bagian diagnosis situs. Pengalihan HTTP, perutean host virtual, validitas sertifikat, dan respons aplikasi memerlukan pemeriksaan tersendiri. CNAME adalah alias DNS, sedangkan mengarahkan pengunjung ke URL lain merupakan perilaku HTTP. CAA berkaitan dengan otorisasi otoritas sertifikat; keberadaannya tidak memastikan situs saat ini menyajikan sertifikat valid.
RFC 1035: implementasi DNS dan format recordRFC 8659: otorisasi otoritas sertifikat
Cari TXT verifikasi, SPF, DKIM, dan DMARC pada nama yang tepat
Untuk verifikasi domain, salin nama record dari petunjuk layanan dan pilih TXT. Bandingkan record lengkap yang dikembalikan dengan token yang diwajibkan, termasuk tanda kutip dan pemisahan potongan yang ditampilkan. Menemukan token merupakan bukti berguna, tetapi layanan peminta menerapkan proses verifikasi kepemilikannya sendiri.
Kebijakan SPF memakai TXT pada domain email yang relevan. Pencarian kunci DKIM memakai nama khusus pemilih seperti selector._domainkey.example.com; ambil pemilih dari layanan email, jangan menebaknya. Pemeriksaan terkait DMARC biasanya dimulai dengan TXT pada _dmarc.example.com. Penemuan kebijakan DMARC modern dan penyelarasan pengenal memiliki aturan tambahan yang tidak dievaluasi satu pengamatan TXT.
Record MX menjelaskan perutean email, sedangkan mekanisme berbasis TXT ini memiliki peran tersendiri. Pemeriksa tidak mengikuti semua include SPF, tidak memvalidasi pesan bertanda tangan, tidak mengevaluasi seluruh penemuan kebijakan DMARC, tidak menganalisis laporan DMARC, dan tidak menguji pengiriman. Keberadaan record dan kecocokan substring tidak menggantikan pemeriksaan tersebut.
RFC 7208, bagian 3.1: kebijakan SPF dalam TXTRFC 6376: tanda tangan DKIM dan pencarian kunci berdasarkan pemilihRFC 9989: penemuan kebijakan dan penyelarasan DMARC
Pahami privasi kueri dan bagikan laporan DNS yang berguna
Nama serta jenis yang diminta melewati broker ToolMellow atau probe yang dipilih menuju resolver publik terpilih. Resolver melihat alamat jaringan probe; ToolMellow tidak meneruskan header IP klien milik pengunjung. Hosting tetap menerima metadata permintaan yang biasa. HTTPS tidak menjadikan seluruh aktivitas anonim atau membuktikan kebijakan tanpa log; nama itu sendiri dapat bersifat sensitif.
Teks yang diharapkan dibandingkan secara lokal dan dapat dimuat sebagai expectedComparison dalam dns-results.json. Sebelum berbagi, periksa nama kueri, data yang dikembalikan, dan teks yang diharapkan, khususnya token verifikasi. Kirim pengamatan relevan kepada penerima yang dituju, bukan menganggap setiap nilai ekspor layak dipublikasikan.
Untuk meminta bantuan, sertakan nama dan jenis persis, konfigurasi yang dimaksud, penyedia serta lokasi, waktu pengamatan, status, data Answer dan Authority yang relevan, serta apakah ada hasil terpotong atau gagal. Laporan yang diunduh adalah cuplikan satu saat; alat tidak menyimpan riwayat record di server atau mengekspor seluruh zona DNS Anda.
Selidiki jawaban DNS yang hilang atau tidak diharapkan secara bertahap
Mulailah dengan mencocokkan nama record yang dinormalisasi dan jenis pilihan dengan petunjuk hosting DNS. Lalu bedakan respons DNS negatif dari permintaan gagal, periksa alias dan detail Authority, serta bandingkan pengamatan kedua penyedia. Jika memakai nilai yang diharapkan, periksa teks lengkap yang dikembalikan dan mode sebelum menyimpulkan bahwa konfigurasi berbeda.
Setelah perubahan, simpan laporan dan lakukan pemeriksaan lanjutan secara terencana. Alat tidak mencoba ulang pencarian secara otomatis, dan permintaan berulang tidak mengosongkan semua cache. Gunakan Coba sambungkan lagi ketika ditawarkan untuk masalah konfigurasi, patuhi pemberitahuan batas permintaan, lalu kirim kueri baru saat sesuai. Batalkan menghentikan pekerjaan klien yang tertunda dan meneruskan pembatalan ke layanan yang memproses kueri, tetapi tidak dapat menarik kueri yang sudah dikirim.
Gunakan alat pencarian IP atau DNS balik terpisah jika mulai dari alamat, serta diagnostik DNS lokal sistem operasi saat memeriksa jalur resolver perangkat itu. Pemeriksa ini tidak mencantumkan semua subdomain, tidak memilih SRV, DS, DNSKEY, atau ANY, tidak mentransfer zona, dan tidak memeriksa ketersediaan pendaftaran domain. Pilih diagnostik sesuai pertanyaan sebelum memberi makna lebih luas pada respons berhasil.
Pertanyaan umum
Bagaimana memeriksa semua record DNS suatu domain?
Jalankan kueri terpisah untuk nama dan jenis yang didukung sesuai tugas Anda. ToolMellow memakai satu nama dan jenis per permintaan; tidak mencantumkan semua subdomain, tidak mentransfer zona, dan tidak memberi inventaris lengkap semua record.
Mengapa Google dan Cloudflare menunjukkan hasil DNS berbeda?
Riwayat cache dan perilaku resolusi keduanya dapat berbeda, dan jawaban otoritatif dapat bergantung lokasi. Bandingkan nama yang dinormalisasi serta jenis yang sama, waktu, status, nama record, nilai, dan TTL. Perbedaan saja tidak mengidentifikasi jawaban yang benar.
Apakah TTL menunjukkan kapan propagasi DNS selesai?
Tidak. TTL yang dikembalikan menjelaskan masa berlaku cache data yang diamati. Cache positif dan negatif, delegasi, serta kebijakan data kedaluwarsa dapat memengaruhi pengamatan lain. TTL tidak menetapkan waktu selesai secara global.
Apa perbedaan NXDOMAIN dan NODATA?
NXDOMAIN melaporkan nama yang diminta tidak ada. NODATA berarti tidak ada jawaban jenis yang diminta; pemeriksa mengidentifikasinya lewat SOA pada Authority dalam respons berhasil. Nama dapat memiliki record A tanpa mengembalikan data AAAA.
Mengapa Sama persis gagal untuk TXT atau CNAME saya?
Fungsi membandingkan seluruh teks yang dikembalikan dengan membedakan kapitalisasi. Tanda kutip, spasi, titik terakhir, teks preferensi MX, dan bentuk penulisan dapat berpengaruh. Periksa nilai lengkap; Mengandung hanya memeriksa substring, bukan memvalidasi record atau kebijakan lengkap.
Apakah kecocokan berarti semua record DNS benar?
Tidak. Satu nilai Answer yang cocok dari jenis yang diminta dan didukung cukup untuk membuat hasil penyedia dan lokasi itu cocok. Nilai lain dapat berbeda; kecocokan literal tidak membuktikan kepemilikan, validasi DNSSEC, pengiriman email, atau kesepakatan global.
Bisakah saya memasukkan IP untuk mencari PTR?
Gunakan alat pencarian IP atau DNS balik terpisah untuk alamat literal. Pemeriksa DNS ini memerlukan nama record balik lengkap, seperti contoh 10.113.0.203.in-addr.arpa. Perbandingan nilai yang diharapkan untuk PTR tidak tersedia.
Bagaimana memeriksa SPF, DKIM, dan DMARC?
Pilih TXT pada domain SPF yang relevan, nama pemilih DKIM dari penyedia di bawah _domainkey, atau nama _dmarc yang tepat. Kueri ini memeriksa teks terpublikasi; tidak mengevaluasi semua dependensi SPF, tanda tangan DKIM pesan, atau seluruh penemuan dan penyelarasan DMARC.
Apakah Tidak terautentikasi berarti domain saya tidak aman?
Tidak terautentikasi berarti penyedia terpilih tidak menyatakan flag AD. Data tanpa tanda tangan juga dapat memberi hasil itu. ToolMellow tidak memvalidasi DNSSEC secara independen, dan indikator itu saja tidak membuktikan domain tidak aman.
Apakah pemeriksa ini menguji server DNS perangkat saya?
Alat menanyakan penyedia publik yang dipilih melalui lokasi ToolMellow yang tersedia. Jalur itu dapat berbeda dari resolver serta cache perangkat, browser, atau jaringan privat Anda. Gunakan diagnostik lokal untuk pertanyaan ini.
Apakah kesepakatan dua penyedia membuktikan propagasi global?
Kesepakatan hanya membuktikan kesesuaian di antara pengamatan yang selesai. Dua penyedia yang ditanya melalui satu lokasi terdaftar bukan jaringan probe global. Lokasi yang tersedia dan detail keyakinan wilayah menentukan cakupan laporan.
Apakah nilai yang diharapkan dikirim ke penyedia DNS?
Tidak. Teks yang diharapkan tetap di tab browser dan dapat muncul dalam laporan unduhan. Nama DNS serta jenis sebenarnya dikirim melalui layanan ke resolver terpilih. Periksa token verifikasi dan data laporan lain sebelum berbagi.
Sumber dan bacaan lanjutan
- RFC 1034: nama domain, resolusi, dan cache
- RFC 1035: implementasi DNS dan format record
- RFC 3596: ekstensi DNS untuk IPv6
- RFC 8659: otorisasi otoritas sertifikat
- RFC 2181, bagian 8: masa berlaku
- RFC 2308: cache negatif kueri DNS
- RFC 8767: menyajikan data DNS kedaluwarsa
- RFC 4035: DNSSEC dan pernyataan data terautentikasi
- RFC 8484: kueri DNS melalui HTTPS
- Google Public DNS: API JSON untuk DNS melalui HTTPS
- Cloudflare 1.1.1.1: permintaan DNS melalui HTTPS dengan JSON
- RFC 4343: nama DNS tidak peka kapitalisasi
- RFC 5891: nama domain internasional
- Node.js: konversi URL domainToASCII
- RFC 7208, bagian 3.1: kebijakan SPF dalam TXT
- RFC 6376: tanda tangan DKIM dan pencarian kunci berdasarkan pemilih
- RFC 9989: penemuan kebijakan dan penyelarasan DMARC