Cara Kerja DNS: Perjalanan Pencarian

Kamu mengetik blog.acy-partner.com di browser, menekan Enter, dan dalam sekejap halaman muncul. Rasanya seperti satu gerakan mulus, padahal di balik layar komputermu baru saja mengajukan pertanyaan lalu menunggu jawaban: “Sebenarnya, di alamat mana nama ini berada?” Tanya jawab itulah yang disebut DNS, dan perjalanan yang ditempuhnya jauh lebih menarik daripada yang kamu kira.

Artikel ini akan menemani satu pencarian DNS dari awal sampai selesai. Kita akan menyusuri setiap tempat yang dicek komputermu, setiap server yang mungkin dihubungi, dan bagaimana caching diam-diam membuat semuanya terasa cepat. Di akhir nanti, kamu akan bisa membayangkan persis apa yang terjadi antara menekan Enter dan melihat halaman terbuka.

Kenapa DNS perlu ada

Komputer di internet sebenarnya tidak saling menemukan lewat nama. Mereka saling menemukan lewat alamat IP — label berupa angka seperti 203.0.113.42 (untuk IPv4) atau deretan heksadesimal yang lebih panjang seperti 2001:db8::1 (untuk IPv6). Alamat itulah yang benar-benar dibutuhkan browser untuk membuka koneksi.

Masalahnya, manusia payah dalam menghafal angka, tapi jago mengingat nama. Jadi kita memakai nama yang ramah seperti acy-partner.com, dan kita butuh sistem yang menerjemahkan nama itu menjadi alamat angka yang dipakai mesin. Sistem itulah DNS, kependekan dari Domain Name System. Anggap saja DNS seperti buku telepon raksasa milik internet: kamu tahu namanya, DNS yang memberi nomornya.

Yang menarik, tidak ada satu buku telepon tunggal. Dengan ratusan juta domain, tak ada satu mesin pun yang sanggup menyimpan atau melayani semuanya sendirian. Karena itu DNS dirancang sebagai sistem yang tersebar dan berlapis — tugasnya dibagi ke banyak server, masing-masing mengurus satu bagian kecil. Perjalanan pencarian yang akan kita bahas sebenarnya adalah tur menyusuri lapisan-lapisan itu.

Gambaran besar: rantai pencarian

Sebelum kita masuk ke detail, ini dia keseluruhan perjalanannya dalam satu diagram. Tiap kotaknya akan kita bedah di bawah.

   KAMU mengetik blog.acy-partner.com
            │
            ▼
   ┌──────────────────┐   ketemu? → selesai
   │  Cache browser   │ ─────────────►
   └──────────────────┘
            │ tidak ada
            ▼
   ┌──────────────────┐   ketemu? → selesai
   │   Cache sistem   │ ─────────────►
   └──────────────────┘
            │ tidak ada
            ▼
   ┌──────────────────┐
   │ Recursive        │  bekerja mewakili kamu
   │ resolver (ISP)   │
   └──────────────────┘
            │
            ▼
   ┌──────────────────┐  "tanya ke server .com"
   │   Root server    │
   └──────────────────┘
            │
            ▼
   ┌──────────────────┐  "tanya nameserver
   │ TLD server (.com)│   acy-partner.com"
   └──────────────────┘
            │
            ▼
   ┌──────────────────┐  "ini IP-nya:
   │  Authoritative   │   203.0.113.42"
   │   nameserver     │
   └──────────────────┘
            │
            ▼
   IP mengalir naik kembali → browser terhubung

Inti yang penting: setiap langkah adalah kesempatan untuk berhenti lebih awal. Kalau salah satu cache sudah tahu jawabannya, perjalanan langsung selesai di situ. Tur lengkap sampai ke root dan kembali hanya terjadi kalau belum ada satu pun pihak terdekat yang mengingat jawabannya.

Langkah 1: Cache browser

Tempat pertama yang dicek browser adalah dirinya sendiri. Browser modern menyimpan daftar kecil dan berumur pendek berisi nama-nama yang baru saja ia cari. Kalau kamu mengunjungi blog.acy-partner.com semenit yang lalu, kemungkinan besar browser masih ingat IP-nya, dan ia langsung melewati semua langkah lain.

Ini hasil paling cepat yang mungkin terjadi: nol permintaan ke jaringan. Inilah juga alasan kunjungan kedua ke sebuah situs sering terasa lebih ngebut dibanding kunjungan pertama.

Langkah 2: Cache sistem operasi

Kalau browser tidak punya jawabannya, ia bertanya ke sistem operasi. Sistem operasimu punya cache DNS sendiri yang dipakai bersama oleh semua program di mesin itu — bukan cuma browser. Jadi kalau aplikasi email tadi sempat mencari sebuah nama, browser bisa ikut menikmati hasil yang sudah tersimpan itu.

Sistem operasi juga mengecek satu berkas lokal khusus (namanya hosts file) yang bisa memaksakan nama tertentu menunjuk ke alamat tertentu. Berkas ini umumnya alat para pengembang, tapi tetap bagian dari urutan pencarian: kalau hosts file punya catatan untuk sebuah nama, catatan itu mengalahkan segalanya.

Kalau cache sistem operasi punya jawaban yang masih segar, sekali lagi — selesai. Tidak ada lalu lintas yang keluar dari komputermu.

Langkah 3: Recursive resolver

Ketika kedua cache lokal sama-sama tidak tahu jawabannya, komputermu menyerahkan pertanyaan itu ke recursive resolver. Resolver ini biasanya dijalankan oleh penyedia internetmu, walau kamu juga bisa memilih resolver publik. Tugas resolver adalah mengerjakan semua sisa pekerjaan untukmu, lalu menyerahkan satu jawaban final yang sudah jadi.

Kenapa disebut “recursive”? Karena ia bersedia mengejar pertanyaan itu lewat sebanyak apa pun server yang diperlukan. Komputermu mengajukan satu pertanyaan — “berapa IP untuk blog.acy-partner.com?” — dan resolver berjanji kembali dengan jawabannya, berapa pun server lain yang harus ia tanyai.

Resolver juga menyimpan cache yang besar miliknya sendiri. Karena melayani banyak pengguna, besar kemungkinan ia baru saja mencari nama-nama populer. Kalau blog.acy-partner.com sudah ada di cache-nya dan masih segar, resolver langsung menjawab, dan perjalanan berhenti di sini — root, TLD, dan authoritative server di bawah ini sama sekali tidak ikut terlibat.

Tapi mari kita anggap cache resolver sedang kosong untuk nama ini. Sekarang tur yang sesungguhnya dimulai.

Langkah 4: Root server

Resolver memulai dari puncak hierarki: sebuah root server. Root tidak tahu IP dari blog.acy-partner.com — itu memang bukan tugasnya. Yang diketahui root adalah siapa yang mengurus setiap top-level domain (TLD): .com, .org, .net, .id, dan seterusnya.

Resolver membaca nama dari kanan ke kiri. Bagian paling kanan dari blog.acy-partner.com adalah .com, jadi resolver pada dasarnya bertanya ke root: “Siapa yang bertanggung jawab atas .com?” Root menjawab dengan rujukan: “Aku tidak punya jawaban finalnya, tapi inilah server-server yang mengurus .com — tanyakan ke mereka.”

Perhatikan, root tidak menyelesaikan apa pun. Ia hanya menunjuk satu tingkat lebih bawah. Pola ini berlaku juga untuk beberapa langkah berikutnya: tiap server mempersempit pencarian dan mengoper kamu makin dekat ke tujuan.

Langkah 5: TLD server (.com)

Berbekal rujukan dari root, resolver kini bertanya ke sebuah TLD server .com. Server ini bertanggung jawab atas seluruh zona .com, dan ia tahu satu fakta penting soal domain kita: authoritative nameserver mana yang memegang kendali atas acy-partner.com.

Maka resolver bertanya: “Siapa nameserver untuk acy-partner.com?” Server TLD menjawab dengan rujukan lagi: “Inilah nameserver untuk acy-partner.com — tanyakan detailnya ke mereka.” Saat seseorang mendaftarkan sebuah domain, kaitan inilah yang dicatat: registrar memberi tahu TLD nameserver mana yang memiliki domain tersebut.

Masih belum ada IP final. Server TLD, sama seperti root, hanya mempersempit pencarian satu tingkat. Kita sudah hampir sampai.

Langkah 6: Authoritative nameserver

Akhirnya, resolver tiba di authoritative nameserver untuk acy-partner.com. Kata “authoritative” berarti inilah sumber kebenaran — ia memegang catatan DNS asli milik domain itu, yang diatur oleh siapa pun pengelolanya. Di sinilah jawaban sebenarnya berada.

Resolver meminta catatan yang ia butuhkan. Untuk alamat sebuah situs web, biasanya itu adalah A record (yang memetakan nama ke alamat IPv4) atau AAAA record (untuk IPv6). Authoritative server mencari blog.acy-partner.com lalu menjawab: “A record-nya menunjuk ke 203.0.113.42.”

Selesai. Pertanyaan itu akhirnya punya jawaban.

Berikut jenis-jenis catatan yang paling sering kamu temui:

Jawaban mengalir kembali ke atas

IP tidak langsung melompat ke browser-mu. Ia menempuh kembali jalur yang tadi dilewati:

Authoritative → Recursive resolver → Sistem operasi → Browser
       (203.0.113.42 dibawa kembali di tiap perpindahan)

Recursive resolver menerima 203.0.113.42 lalu mengopernya ke sistem operasimu, yang kemudian mengopernya ke browser. Sekarang browser akhirnya memegang alamat angkanya dan bisa membuka koneksi sungguhan ke server — dan halaman pun mulai dimuat.

Tapi resolver melakukan satu hal penting lagi dalam perjalanan pulangnya: ia menyimpan jawaban itu ke cache, supaya orang berikutnya yang menanyakan blog.acy-partner.com mendapatkannya seketika, tanpa harus mengulang seluruh tur.

Caching dan TTL: kenapa ini bisa cepat

Kalau setiap kunjungan memicu perjalanan penuh dari root sampai authoritative, web akan terasa lambat dan server-server di atas akan kewalahan. Caching mencegah itu. Hampir setiap langkah yang kita bahas tadi bisa menyimpan jawaban lalu memakainya ulang.

Berapa lama sebuah jawaban boleh hidup di cache? Itu diatur oleh nilai bernama TTL, kependekan dari time to live. Setiap catatan DNS membawa TTL — sejumlah detik — yang ditetapkan oleh pengelola authoritative nameserver. Anggap ini timer kesegaran: “kamu boleh memakai ulang jawaban ini selama sekian detik, setelah itu buang dan tanyakan lagi.”

A record:  blog.acy-partner.com → 203.0.113.42   TTL 3600
                                                   │
                       boleh dipakai ulang selama ─┘ 3600 detik (1 jam)

TTL itu soal untung-rugi:

Pola yang umum: turunkan TTL sehari sebelum kamu memindahkan situs ke server baru, supaya perubahannya cepat menyebar, lalu naikkan lagi setelah semuanya stabil.

Ringkasan singkat perjalanannya

Mari kita telusuri ulang semuanya dalam satu tarikan napas. Kamu meminta sebuah nama. Cache browser dicek, lalu cache sistem operasi. Kalau keduanya tidak punya, recursive resolver mengambil alih dan mengerjakan sisanya: ia bertanya ke root server (yang menunjuk ke server .com), lalu ke TLD server .com (yang menunjuk ke nameserver domain), lalu ke authoritative nameserver (yang akhirnya mengembalikan IP). Jawaban mengalir kembali ke atas, disimpan di cache pada tiap lapisan sesuai TTL-nya, dan browser-mu pun terhubung.

Bagian yang elegan, sebagian besar pencarian tidak pernah menempuh perjalanan penuh. Caching membuat kasus yang umum terasa cepat, dan perjalanan panjang hanya terjadi kalau sebuah jawaban memang benar-benar baru atau sudah kedaluwarsa.

Kalau kamu ingin menyelam lebih dalam ke sisi server — perangkat lunak resolver, berkas zona, dan detail operasional di balik server-server ini — bacaan lanjutan yang pas adalah DNS Lebih Dalam (sisi server). Dengan perjalanan pencarian sudah jelas di kepalamu, detail-detail itu akan langsung terasa pas pada tempatnya.