Pencarian DNS

Cara kerjanya

1. Masukkan domain: ketik nama domain, termasuk subdomain, di kolom.
2. Pilih jenis catatan: pilih jenis catatan DNS yang akan dikueri: A, AAAA, MX, CNAME, TXT, NS, SOA, atau semua.
3. Lihat hasil: hasil diperoleh dari penyedia DNS-over-HTTPS publik dan ditampilkan dengan nilai TTL dan data.
4. Diagnosa: bandingkan hasil antara jenis catatan untuk mengidentifikasi konfigurasi yang salah, penundaan propagasi, atau catatan yang hilang.

Mengapa menggunakan pencarian DNS?

Masalah DNS adalah salah satu penyebab paling umum dari ketidaktersediaan situs web, kegagalan pengiriman email, dan masalah migrasi domain. Mampu mencari catatan DNS langsung dari browser, tanpa beralih ke alat baris perintah seperti dig atau nslookup, sangat berharga untuk developer, DevOps, dan administrator sistem. Alat ini mencari catatan melalui DNS-over-HTTPS untuk privasi dan melewati firewall. Gunakan untuk memverifikasi catatan MX setelah perubahan penyedia email, mengonfirmasi catatan A/CNAME setelah migrasi DNS, memeriksa catatan TXT untuk autentikasi SPF/DKIM, dan mendiagnosis penundaan propagasi.

Jenis catatan DNS

• A, alamat IPv4 sebuah domain
• AAAA, alamat IPv6 sebuah domain
• MX, catatan server email untuk routing email
• CNAME, alias nama kanonik yang menunjuk ke domain lain
• TXT, catatan teks untuk SPF, DKIM, verifikasi domain
• NS, server nama otoritatif untuk domain

40 tahun DNS: dari RFC 882 hingga DNS over QUIC

Domain Name System dirancang oleh Paul Mockapetris di USC/ISI dan ditentukan dalam RFC 882 dan RFC 883 (November 1983), menggantikan file datar HOSTS.TXT yang telah dilampaui oleh ARPANET. Sistem direvisi dan diformalkan dalam RFC 1034 dan RFC 1035 (November 1987), dokumen yang masih dikutip hari ini. Jon Postel mengkoordinasikan penugasan 13 nameserver root asli, diberi label a.root-servers.net sampai m.root-servers.net, jumlah yang ditetapkan bukan oleh kapasitas tetapi oleh batas ukuran paket UDP 512 byte pada masa itu. Dua kejutan besar membentuk kembali DNS di abad ini. Pada Juli 2008, Dan Kaminsky mengungkapkan serangan cache-poisoning yang memungkinkan penyerang menyuntikkan catatan palsu ke resolver dalam hitungan detik. Industri merespons dengan patch terkoordinasi (randomisasi source-port) dan minat baru pada DNSSEC (RFC 4033-4035, Maret 2005), yang menandatangani catatan secara kriptografis. Kejutan kedua adalah privasi: query berjalan dalam teks biasa di port UDP 53 selama 35 tahun. DNS over TLS (DoT, RFC 7858, Mei 2016) membungkus query dalam TLS di port 853. DNS over HTTPS (DoH, RFC 8484, Oktober 2018) menyalurkan query melalui HTTPS di port 443, menyembunyikan bahkan fakta bahwa DNS sedang terjadi. DNS over QUIC (RFC 9250, Mei 2022) adalah yang terbaru, menggunakan transport yang sama yang menggerakkan HTTP/3. Resolver publik 1.1.1.1 (Cloudflare, diluncurkan 1 April 2018), 8.8.8.8 (Google Public DNS, Desember 2009), dan 9.9.9.9 (Quad9, November 2017) semua mendukung DoH dan DoT hari ini.

Tipe record secara mendalam

• A (RFC 1035). Alamat IPv4 32-bit. Satu domain dapat memiliki banyak record A untuk load balancing; resolver bergiliran melalui mereka (round-robin DNS).
• AAAA (RFC 3596, 2003). Alamat IPv6 128-bit. Diucapkan «quad-A». Pada 2024, sekitar 45% traffic Google adalah IPv6.
• CNAME (RFC 1035). Alias: «ikuti nama ini dan cari recordnya». Tidak dapat berdampingan dengan record lain pada nama yang sama. Inilah sebabnya example.com tidak dapat memiliki CNAME dan MX atau A pada apex; alternatif modern menggunakan ALIAS atau ANAME (spesifik vendor) atau record HTTPS (RFC 9460, 2023).
• MX (RFC 1035, diperbarui oleh RFC 7505 «null MX»). Server pertukaran email dengan nilai prioritas. Prioritas lebih rendah lebih disukai; ikatan diacak. 0 . (RFC 7505, Juni 2015) secara eksplisit mengatakan «domain ini tidak menerima email», memblokir spam ke domain tanpa kotak surat.
• TXT (RFC 1035). String teks bebas. Sekarang membawa otentikasi kritis: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015), dan verifikasi kepemilikan untuk Google Search Console, Microsoft 365, tantangan ACME (Let's Encrypt) DNS-01.
• NS (RFC 1035). Nama nameserver otoritatif. Selalu setidaknya dua untuk redundansi. «Glue records» di zona induk menyediakan IP sehingga resolver rekursif dapat mencapai nameserver tanpa pencarian sirkular.
• SOA (RFC 1035). Start of Authority. Record tunggal per zona yang mencantumkan nameserver utama, email admin (dengan . pertama diganti dengan @), nomor seri (bertambah pada perubahan), refresh, retry, expire, dan TTL minimum.
• CAA (RFC 8659, 2019; awalnya RFC 6844, 2013). Certificate Authority Authorisation. Mencantumkan CA mana yang diizinkan mengeluarkan sertifikat untuk domain. Pemeriksaan wajib oleh persyaratan baseline CA/Browser Forum sejak September 2017.
• SRV (RFC 2782, 2000). Lokasi layanan: protokol, prioritas, bobot, port, host target. Microsoft Active Directory, XMPP, SIP, federasi Matrix semua menggunakan record SRV untuk penemuan layanan.
• PTR (RFC 1035). Reverse DNS. Memetakan IP kembali ke domain. Tinggal di zona in-addr.arpa (IPv4) atau ip6.arpa (IPv6). Diperlukan oleh banyak mail server untuk menerima email; PTR yang hilang adalah sinyal spam umum.
• DNSKEY / DS / RRSIG (RFC 4034-4035). Pipa DNSSEC. DNSKEY mempublikasikan kunci penandatanganan zona; DS di zona induk adalah pointer kriptografis «inilah tautan berikutnya dalam rantai»; RRSIG membawa tanda tangan aktual untuk setiap set record.

Di mana pencarian DNS sebenarnya membantu

• Mengatur email di domain baru. Verifikasi bahwa record MX mengarah ke penyedia yang tepat (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Periksa SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
• Migrasi domain dan propagasi. Setelah memperbarui nameserver di registrar, kueri baik server otoritatif lama maupun baru untuk mengonfirmasi bahwa perubahan telah merambat secara global. Resolver yang berbeda menyimpan cache untuk durasi yang berbeda (TTL adalah petunjuk, bukan kontrak).
• Pemecahan masalah sertifikat TLS / SSL. Tantangan ACME DNS-01 yang digunakan oleh Let's Encrypt dan sejenisnya memerlukan menempatkan record TXT di _acme-challenge.example.com. Periksa nilai sebelum memicu penerbitan sertifikat untuk menghindari upaya batas rate yang sia-sia.
• Mendeteksi risiko subdomain takeover. CNAME yang mengarah ke layanan yang tidak terdaftar (aplikasi Heroku dihapus, bucket S3 dirilis) memungkinkan penyerang mendaftarkannya dan menyajikan konten di subdomain Anda. Audit CNAME cepat menangkap pointer yang menggantung.
• Verifikasi CDN dan load-balancer. Konfirmasikan bahwa domain CNAME ke endpoint Cloudflare, Fastly, Akamai, CloudFront, atau Vercel yang tepat setelah deployment. Deteksi ketika staging secara tidak sengaja mengarah ke produksi.
• Perbandingan DNS geografis. Beberapa situs menyajikan record A yang berbeda berdasarkan wilayah (GeoDNS). Mengueri dari endpoint DoH yang berbeda (Cloudflare 1.1.1.1 vs Google 8.8.8.8) memberi petunjuk bagaimana pengguna di Frankfurt vs Mumbai melihat situs.
• Keamanan dan respons insiden. Cari record NS yang tidak terduga (pembajakan registrar), record TXT mencurigakan, atau record MX yang baru ditambahkan. Gunakan nomor seri SOA untuk melacak kapan zona terakhir berubah.

Kesalahan DNS yang merusak situs dan email

• CNAME di apex. RFC 1034 melarang menempatkan CNAME pada example.com itu sendiri (hanya pada subdomain seperti www.example.com). Cloudflare, Route 53, DNSimple mengatasi ini dengan flattening CNAME atau record ALIAS; Vercel, Netlify menggunakan record binding layanan HTTPS (RFC 9460). Mencobanya di panel DNS registrar dasar diam-diam merusak email.
• Lupa menurunkan TTL sebelum migrasi. Jika record A Anda memiliki TTL 86400 (24 jam) dan Anda mengubahnya pada pagi peralihan, resolver di seluruh dunia akan terus membagikan IP lama hingga satu hari. Turunkan TTL ke 300 detik beberapa hari sebelum perubahan.
• Record SPF dengan terlalu banyak pencarian DNS. RFC 7208 membatasi SPF pada 10 pencarian DNS per evaluasi. Rantai terlalu banyak direktif include: dan record SPF Anda gagal dengan permerror, yang diperlakukan DMARC sebagai kegagalan. Ratakan atau konsolidasikan dengan alat seperti SPF Surveyor.
• CNAME menggantung setelah penghapusan layanan. Menghapus aplikasi Heroku tetapi CNAME app.example.com masih mengarah ke example.herokuapp.com? Siapa pun dapat mendaftarkan nama aplikasi itu dan meng-host konten mereka di subdomain Anda. Audit dan hapus CNAME yatim.
• Tidak ada record CAA. Tanpa record CAA, CA mana pun di WebPKI (~50 di seluruh dunia) dapat mengeluarkan sertifikat untuk domain Anda. Kunci ke satu atau dua CA tepercaya: 0 issue "letsencrypt.org". Pemeriksaan CA wajib sejak September 2017.
• Record wildcard menutupi entri yang hilang. Record A *.example.com membuat setiap subdomain salah ketik diselesaikan, menyembunyikan kesalahan konfigurasi nyata. Gabungkan dengan hati-hati dengan aturan MX eksplisit untuk menghindari spam ke alamat salah ketik.
• Mencampur DNSSEC dan zona tidak ditandatangani selama cutover. Mengaktifkan DNSSEC di registrar sebelum nameserver baru menyajikan record yang ditandatangani menghasilkan SERVFAIL untuk setiap resolver yang memvalidasi (Cloudflare 1.1.1.1, Quad9). Selalu tandatangani terlebih dahulu, kemudian publikasikan record DS.

Lebih banyak pertanyaan yang sering diajukan

Alat terkait