Masalah
Aplikasi menggunakan nama domain, tetapi koneksi jaringan akhirnya membutuhkan alamat tujuan. Ketika website tidak dapat dibuka, DNS adalah salah satu lapisan yang perlu dibuktikan—bukan langsung dianggap sebagai penyebab.
TutorialNetworkingPemula
Dari nama domain ke alamat IP
Pelajari alur resolver DNS, status jawaban, TTL, dan cara membandingkan hasil agar troubleshooting tidak berhenti pada sekadar melihat IP.
Tujuan latihan
Memahami peran recursive resolver dan memeriksa record A beserta status, TTL, serta sumber jawaban tanpa mengubah konfigurasi DNS.
PersiapanTerminal dengan dig (dnsutils atau bind-utils, bergantung distribusi) dan akses internet. Gunakan domain dokumentasi atau domain milik sendiri.
Aplikasi→
Recursive resolver→
Authoritative DNS→
Alamat IP
1. Query record A secara lengkap
Mulai dari output lengkap supaya status, ANSWER SECTION, TTL, dan SERVER terlihat. +short berguna setelah Anda memahami jawaban lengkap, tetapi terlalu sedikit konteks untuk diagnosis awal.
dig example.com A
dig example.com A +short2. Baca status DNS dengan benar
NOERROR berarti query diproses tanpa error DNS, tetapi belum tentu ANSWER berisi record A. NXDOMAIN berarti nama yang ditanyakan tidak ada menurut DNS. SERVFAIL menunjukkan resolver gagal menyelesaikan query, misalnya karena masalah upstream atau validasi. Timeout berarti belum ada jawaban dalam batas waktu dan perlu dibedakan dari NXDOMAIN.
3. Perhatikan ANSWER dan TTL
ANSWER SECTION menunjukkan record yang dikembalikan. TTL menunjukkan berapa lama jawaban dapat di-cache oleh resolver/client. Perbedaan TTL atau alamat antarwaktu tidak otomatis menunjukkan error karena cache, CDN, load balancing, dan geolokasi dapat menghasilkan jawaban yang berbeda.
4. Identifikasi resolver yang menjawab
Field SERVER menunjukkan resolver yang Anda tanyai. Resolver router, ISP, perusahaan, dan publik dapat memiliki cache atau policy berbeda. Catat resolver sebelum membandingkan hasil agar Anda tidak membandingkan dua sumber tanpa konteks.
5. Bandingkan dengan resolver publik
Jika jaringan mengizinkan DNS langsung, tanyakan resolver publik sebagai pembanding. Jika resolver lokal gagal tetapi resolver publik berhasil, fokuskan pemeriksaan pada resolver lokal, forwarding, firewall DNS, atau policy jaringan—bukan langsung mengubah record authoritative.
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A6. Lanjutkan ke HTTPS setelah DNS berhasil
DNS yang mengembalikan IP hanya membuktikan resolusi nama. Setelah itu, uji koneksi aplikasi dengan curl. Jika DNS sukses tetapi HTTPS gagal, troubleshooting berpindah ke routing, firewall, TLS, proxy, atau aplikasi.
curl --connect-timeout 5 --max-time 15 -I https://example.comKesalahan umum
Jangan menganggap satu jawaban IP sebagai satu-satunya IP yang benar pada layanan CDN. Jangan menghapus cache atau mengganti DNS hanya karena resolver berbeda memberi alamat berbeda. Jangan menggunakan +short saja ketika Anda perlu melihat status, TTL, atau resolver.
Checklist verifikasi
Catat hostname, tipe record, status, ANSWER, TTL, SERVER, waktu pengujian, dan hasil resolver pembanding. Jika DNS sukses, simpan juga hasil uji HTTPS agar jelas apakah masalah benar-benar berada pada DNS atau pada lapisan setelahnya.
Pelajaran
Troubleshooting DNS yang baik selalu menyebut resolver, status, jawaban, dan TTL. Dengan bukti ini Anda dapat memisahkan masalah resolusi nama dari masalah jaringan atau aplikasi tanpa melakukan perubahan spekulatif.