DNS Mendalam: Bagaimana Nama Domain Berubah Jadi Alamat IP

Kamu mengetik acypartner.example di browser, tekan Enter, lalu halamannya muncul. Di balik momen biasa itu, ada salah satu sistem tersibuk sekaligus terindah di internet: Domain Name System, atau DNS. Seluruh tugasnya adalah menjawab satu pertanyaan yang kelihatannya sederhana — angka mana sebenarnya yang harus aku hubungi? — karena komputer tidak mengarahkan lalu lintas ke nama, melainkan ke alamat IP.

Kebanyakan orang berkenalan dengan DNS lewat kalimat “buku telepon internet”, dan itu titik awal yang oke. Tapi perumpamaan buku telepon menyembunyikan hampir semua bagian menariknya: DNS bukan satu buku besar, melainkan proses pencarian terdistribusi sedunia yang melompat lewat beberapa server, sangat mengandalkan caching, dan diperbarui dengan cara yang bisa terasa lambat menjengkelkan. Begitu kamu benar-benar melihat bagaimana sebuah pencarian mengalir, banyak perilaku jaringan yang tadinya misterius — propagasi lambat, record basi, satu perangkat yang “masih lihat situs lama” — tiba-tiba jadi masuk akal.

Masalah yang dipecahkan DNS

Setiap mesin di internet bisa dijangkau lewat alamat IP — angka seperti 203.0.113.42 (atau string IPv6 yang lebih panjang). Router dan switch cuma paham angka-angka itu. Manusia sebaliknya: payah mengingat angka, jago mengingat nama. DNS adalah lapisan penerjemah yang membuat kita bisa hidup di dunia nama yang ramah sementara jaringan tetap berjalan di atas angka.

Kalau kamu sudah berkenalan dengan ide nama versus angka di domain dan DNS, artikel ini adalah lapisan di bawahnya: bukan apa itu domain, tapi bagaimana pencariannya benar-benar terjadi, server demi server.

Inilah pertukaran inti yang dipilih DNS. Alih-alih satu direktori pusat raksasa yang harus dihubungi setiap pencarian di seluruh dunia, DNS menyebar pekerjaannya ke jutaan server, masing-masing hanya bertanggung jawab atas sepotong kecil ruang nama. Tidak ada satu mesin pun yang tahu semua nama di internet. Sebagai gantinya, sistemnya dirancang supaya resolver mana pun bisa menemukan jalan menuju satu server yang memang tahu jawaban untuk sebuah nama.

Para pemain dalam ceritanya

Satu pencarian DNS melibatkan beberapa peran berbeda. Gampang ketukar, jadi ayo kita beri nama yang jelas:

Stub resolver — klien DNS mungil yang tertanam di sistem operasimu. Saat sebuah aplikasi meminta sebuah nama, dialah yang diajak bicara. Dia hampir tidak berpikir sendiri; tugasnya cuma meneruskan pertanyaan.
Recursive resolver (atau cukup resolver) — sang kuda beban. Biasanya dijalankan oleh penyedia internetmu, atau oleh layanan publik. Dia mengambil pertanyaanmu lalu melakukan semua kerja keras yang diperlukan untuk mendapat jawaban akhir, lalu menyerahkannya kembali. Dia juga menyimpan jawaban (caching) dengan rajin.
Root server — titik awal hierarki. Mereka tidak tahu IP domainmu, tapi tahu harus bertanya ke mana berikutnya untuk top-level domain mana pun.
TLD server — bertanggung jawab atas sebuah top-level domain seperti .com, .org, atau .id. Mereka juga tidak tahu jawaban akhirmu, tapi tahu server mana yang otoritatif untuk domain spesifikmu.
Authoritative name server — server yang benar-benar menyimpan record asli sebuah domain. Di sinilah kebenaran berada. Siapa yang mengendalikan server ini, dialah yang mengendalikan ke mana sebuah domain mengarah.

Bagian pintarnya adalah cara resolver menuruni rantai ini — dari root, ke TLD, ke authoritative — mempersempit pencarian di tiap langkah sampai mendarat di satu server yang sungguh tahu jawabannya.

Menelusuri satu pencarian nyata

Mari kita telusuri pencarian baru untuk shop.acypartner.example, dengan asumsi belum ada yang ter-cache di mana pun (kasus terburuk, yang hampir tidak pernah benar-benar terjadi — tapi ini memperlihatkan seluruh mesinnya).

  PERANGKATMU                 RECURSIVE RESOLVER              HIERARKI
 (stub resolver)              (ISP / publik)
      │                              │
      │ "di mana                     │
      │  shop.acypartner.example?"   │
      │ ───────────────────────────► │
      │                              │  1. tanya ROOT server
      │                              │ ─────────────────────► [ ROOT ]
      │                              │ ◄── "tanya TLD server .example"
      │                              │
      │                              │  2. tanya TLD server .example
      │                              │ ─────────────────────► [ TLD .example ]
      │                              │ ◄── "tanya authoritative server
      │                              │      milik acypartner.example"
      │                              │
      │                              │  3. tanya authoritative server
      │                              │ ─────────────────────► [ AUTHORITATIVE ]
      │                              │ ◄── "shop = 203.0.113.42"
      │                              │
      │ ◄── "alamatnya 203.0.113.42" │
      │                              │
   hubungi 203.0.113.42

Dibaca dari atas ke bawah, inilah yang terjadi:

Perangkatmu bertanya ke recursive resolver yang sudah diatur: apa IP untuk shop.acypartner.example?
Resolver, yang belum tahu apa-apa, mulai dari paling atas. Dia bertanya ke root server. Root tidak tahu jawaban akhirnya, tapi membalas, intinya, “Aku tidak menangani itu, tapi ini server-server untuk top-level domain .example — tanya ke mereka.”
Resolver bertanya ke TLD server .example. Server itu juga tidak tahu IP akhirnya, tapi tahu siapa yang otoritatif untuk acypartner.example, jadi dia membalas, “tanya ke name server ini.”
Resolver bertanya ke authoritative name server milik acypartner.example. Server inilah yang punya record asli. Dia menjawab: “shop mengarah ke 203.0.113.42.”
Resolver mengembalikan jawaban akhir itu ke perangkatmu, lalu browser-mu membuka koneksi ke 203.0.113.42.

Dari sudut pandang perangkatmu, ini disebut recursive resolution (kamu mengajukan satu pertanyaan dan menerima satu jawaban akhir). Dari sudut pandang resolver, ini disebut iterative resolution (dia mengajukan serangkaian pertanyaan, mempersempit di tiap lompatan). Kedua istilah itu menggambarkan pencarian yang sama dari sisi yang berbeda.

Titik di ujung yang tak pernah kamu lihat

Nama domain secara teknis berakhir dengan sebuah titik — acypartner.example. — dan titik terakhir itu mewakili root dari hierarki. Kamu hampir tidak pernah mengetiknya, dan tool menambahkannya untukmu, tapi itulah sebabnya pencarian selalu dimulai dari root: setiap nama, dibaca dari kanan ke kiri, berawal di sana. shop.acypartner.example. sebenarnya adalah root → example → acypartner → shop, di-resolve satu label demi satu label.

Caching: kenapa tidak selalu selambat itu

Kalau setiap pencarian melakukan semua kerja keras tadi, internet bakal merangkak. Untungnya tidak, berkat caching. Di hampir setiap lapisan, jawaban diingat untuk beberapa waktu supaya pencarian berikutnya bisa melompati langkah.

Sistem operasimu meng-cache jawaban terbaru, jadi membuka situs yang sama dua kali berturut-turut biasanya melewati DNS sepenuhnya.
Recursive resolver-mu meng-cache dengan agresif. Begitu dia tahu bahwa .example ditangani oleh TLD server tertentu, dia tidak akan bertanya ulang ke root selama berjam-jam. Begitu dia tahu ke mana shop.acypartner.example mengarah, dia menyajikan jawaban itu langsung dari memori untuk siapa pun yang bertanya.
Bahkan browser-mu menyimpan cache pendeknya sendiri.

Jadi dalam kehidupan nyata, kebanyakan pencarian dijawab dalam hitungan milidetik dari sebuah cache di sepanjang jalur. Perjalanan penuh root-ke-authoritative cuma terjadi sesekali — ketika sebuah jawaban sudah kedaluwarsa atau tidak ada orang di sekitar yang baru-baru ini menanyakan nama itu.

   Pengunjung pertama       →  perjalanan penuh: root → TLD → authoritative  (agak lambat)
   10.000 pengunjung berikut →  disajikan dari cache resolver                (instan)

Berapa lama sebuah cache menyimpan jawaban? Itu dikendalikan oleh sebuah nilai yang menempel di setiap record: TTL.

TTL dan alasan perubahan DNS terasa lambat

TTL singkatan dari time to live. Ini sebuah angka, dalam detik, yang menempel di tiap record DNS dan berkata, “kamu boleh meng-cache jawaban ini selama sekian sebelum mengecek lagi.” TTL 3600 berarti satu jam. TTL 300 berarti lima menit.

TTL adalah hal terpenting yang perlu kamu pahami soal kenapa perubahan DNS seperti makan waktu selamanya. Saat kamu memperbarui sebuah record — misalnya mengarahkan domainmu ke server baru — perubahannya instan di authoritative server-mu. Tapi setiap resolver di muka bumi yang sudah meng-cache jawaban lama akan terus menyajikannya sampai salinannya kedaluwarsa. Kalau record lama tadi punya TTL 24 jam, sebagian pengguna bisa terus mendarat di server lama selama hampir satu hari penuh.

Inilah yang orang sebut secara longgar sebagai propagasi DNS. Sebenarnya tidak ada yang benar-benar “menyebar” ke seluruh dunia — tidak ada dorongan global. Yang sebenarnya terjadi adalah jutaan cache independen diam-diam kedaluwarsa, satu TTL demi satu TTL, dan barulah setelah itu mengambil jawaban baru.

Turunkan TTL sebelum perubahan yang direncanakan

Kalau kamu tahu sebuah migrasi akan datang, turunkan TTL record ke angka kecil (misalnya 300 detik) sehari atau dua hari sebelum waktunya. Begitu TTL kecil itu sudah menyebar, setiap resolver akan mengecek ulang record-mu setiap lima menit. Lalu ketika kamu berpindah ke server baru, dunia menyusul dalam hitungan menit, bukan jam. Naikkan lagi TTL-nya setelahnya supaya kamu tidak menciptakan pencarian yang sia-sia. Merencanakan sekitar TTL adalah salah satu dari sedikit “kekuatan super” sejati dalam operasi DNS.

Jenis-jenis record yang akan kamu temui

Authoritative server sebuah domain tidak cuma menyimpan satu jawaban — dia menyimpan koleksi kecil record, masing-masing bertipe berbeda untuk tujuan berbeda. Kamu tidak butuh semuanya, tapi ada beberapa yang muncul terus-menerus:

A — memetakan sebuah nama ke alamat IPv4 (misalnya shop → 203.0.113.42). Record paling umum yang ada.
AAAA — ide yang sama, tapi untuk alamat IPv6. (Ya, empat huruf A; begitu cara menyebutnya.)
CNAME — sebuah alias yang mengarahkan satu nama ke nama lain, bukan ke IP (misalnya www → acypartner.example). Resolver lalu mencari target itu. Praktis, tapi CNAME tidak boleh berada di root sebuah domain dan tidak bisa berdampingan dengan record lain pada nama yang sama.
MX — mail exchange. Memberi tahu dunia server mana yang menangani email untuk domain itu. Pengaturan rute email sepenuhnya bergantung pada record ini.
TXT — teks bebas yang menempel pada sebuah nama. Awalnya untuk catatan, sekarang banyak dipakai untuk verifikasi dan record keamanan email (membuktikan kamu pemilik sebuah domain, mengatur kebijakan anti-spam, dan sebagainya).
NS — name server. Mendaftar authoritative name server untuk sebuah domain. Inilah record yang mendelegasikan kendali — TLD memakai record NS-mu untuk tahu ke mana mengarahkan resolver.

acypartner.example.   kumpulan record (disederhanakan)
  @       A       203.0.113.42
  www     CNAME   acypartner.example.
  shop    A       203.0.113.42
  @       MX      10 mail.acypartner.example.
  @       TXT     "v=spf1 include:mailhost.example ~all"
  @       NS      ns1.dnsprovider.example.
  @       NS      ns2.dnsprovider.example.

@ di sini adalah singkatan untuk domain itu sendiri (apex atau root dari zona). Semua yang lain adalah subdomain yang menggantung di bawahnya.

Memeriksa DNS sendiri

DNS bukan kotak hitam — kamu bisa bertanya langsung kepadanya dari terminal. Tool baris perintah standar memungkinkanmu melihat persis apa yang dilihat resolver. Contoh universal:

# Minta record alamat dari sebuah nama
dig acypartner.example A

# Lihat seluruh rantai yang ditelusuri resolver (root → TLD → authoritative)
dig acypartner.example +trace

# Cari tipe record tertentu
dig acypartner.example MX
dig acypartner.example TXT

# Tanya resolver tertentu, bukan resolver default-mu
dig @9.9.9.9 acypartner.example A

# Klasik yang lebih sederhana dan ramah (tersedia hampir di mana-mana)
nslookup acypartner.example

Opsi +trace sangat bagus untuk melihat isi artikel ini beraksi: dia memperlihatkan resolver mulai dari root, dirujuk ke TLD, lalu ke authoritative server, dan akhirnya mendapat jawaban — seluruh perjalanan, dicetak langkah demi langkah.

Mesin berbeda bisa melihat jawaban berbeda

Karena tiap resolver dan tiap perangkat menyimpan cache-nya sendiri, dua orang — atau bahkan dua aplikasi di laptop yang sama — bisa secara sah mendapat jawaban DNS berbeda di saat yang sama, apalagi tepat setelah sebuah perubahan. Yang satu cache-nya sudah kedaluwarsa dan melihat record baru; yang lain masih di dalam TTL lama dan melihat record lama. Ini bukan bug; ini caching yang melakukan persis apa yang dirancang. Saat kamu menguji perubahan DNS, selalu cek resolver mana yang sedang kamu tanyai sebelum panik.

Di mana DNS duduk dalam gambaran besar

DNS adalah langkah paling pertama dari hampir setiap koneksi yang kamu buat online. Sebelum browser-mu bisa berbicara HTTP atau HTTPS ke sebuah situs, sebelum ada data yang mengalir lewat TCP/IP, dia harus tahu dulu alamat IP yang harus dihubungi — dan itu sebuah pencarian DNS. Diam-diam, inilah langkah pembuka dari cara kerja internet di tataran praktis.

DNS juga melakukan lebih dari sekadar mengarahkan ke satu server. Dia adalah alat penting untuk mengarahkan lalu lintas. Sebuah CDN, misalnya, sering memakai DNS untuk mengirim tiap pengunjung ke lokasi edge terdekat dengan mengembalikan alamat IP yang berbeda tergantung dari mana permintaan datang. Pencarian yang sama yang kamu telusuri tadi bisa diam-diam menyerahkan jawaban yang paling pas secara geografis untuk kamu. Fleksibilitas itu — jawaban tergantung siapa yang bertanya — adalah salah satu sebab kenapa DNS, meski berumur puluhan tahun, masih mengerjakan pekerjaan serius dalam infrastruktur modern.

Penutup

Ini gambaran utuhnya dalam satu tempat:

DNS menerjemahkan nama domain yang ramah bagi manusia menjadi alamat IP yang benar-benar dihubungi mesin.
Dia bukan satu direktori pusat melainkan hierarki terdistribusi: root server mengarah ke TLD server, yang mengarah ke server authoritative yang menyimpan record asli.
Sebuah recursive resolver melakukan kerja kerasnya — menuruni root → TLD → authoritative — lalu menyerahkan satu jawaban akhir ke perangkatmu.
Caching di tiap lapisan adalah sebab kenapa pencarian biasanya instan; perjalanan penuh cuma terjadi sesekali.
TTL mengendalikan berapa lama jawaban di-cache, dan itulah sebab sebenarnya perubahan DNS terasa lambat — jawaban lama bertahan sampai tiap cache kedaluwarsa (apa yang orang sebut propagasi).
Jenis record umum — A, AAAA, CNAME, MX, TXT, NS — masing-masing punya tugas berbeda, dan kamu bisa memeriksa semuanya dengan dig atau nslookup.

Akrabkan dirimu dengan rantai resolver dan TTL, maka DNS berhenti jadi sumber penundaan misterius dan berubah jadi alat yang presisi serta bisa diprediksi. Berikutnya, ada baiknya beralih ke sisi praktis — apa yang harus dilakukan ketika sebuah pencarian gagal — dan membangun pendekatan yang tenang dan metodis untuk troubleshooting jaringan saat ada yang tidak beres di antara mesinmu dan server.