Apa Itu DNS dan Hierarki DNS? Panduan Teknis Lengkap

DNS (Domain Name System) adalah sistem penamaan hierarkis dan terdistribusi yang menerjemahkan nama domain yang dapat dibaca manusia — seperti `www.example.com` — menjadi alamat IP yang dapat dibaca mesin seperti `192.0.2.1`. Tanpa DNS, setiap pengguna internet harus menghafal alamat numerik untuk setiap situs web, endpoint API, atau server email yang mereka gunakan. DNS adalah protokol yang membuat internet modern dapat dinavigasi dalam skala besar.

Pada intinya, DNS berfungsi sebagai basis data yang terdistribusi secara global. Kueri diselesaikan melalui rantai delegasi yang terstruktur — dari server root di bagian atas, melalui server TLD (top-level domain), hingga ke server nama otoritatif yang menyimpan catatan aktual untuk domain tertentu. Arsitektur inilah yang membuat DNS sekaligus cepat, tangguh, dan dapat dikembangkan.

Mengapa DNS Lebih dari Sekadar “Buku Telepon”

Analogi “buku telepon” adalah titik awal yang berguna, namun sangat meremehkan apa yang sebenarnya dilakukan DNS di lingkungan produksi. DNS menopang:

• Resolusi nama — mengonversi FQDN (Fully Qualified Domain Names) ke alamat IPv4 dan IPv6
• Perutean email — rekaman MX mengarahkan lalu lintas SMTP ke infrastruktur email yang tepat
• Penemuan layanan — rekaman SRV memungkinkan aplikasi menemukan layanan secara dinamis (digunakan secara luas dalam SIP, XMPP, dan Kubernetes)
• Rekayasa lalu lintas — rekaman Geo-DNS dan weighted routing memungkinkan load balancing global dan failover berbasis latensi
• Penegakan keamanan — rekaman TXT membawa kebijakan SPF, DKIM, dan DMARC; DNSSEC menambahkan validasi kriptografis
• Orkestrasi CDN — CNAME flattening dan perutean Anycast memungkinkan CDN melayani node edge terdekat secara transparan

Bagi siapa pun yang mengelola lingkungan VPS Hosting atau Dedicated Server, memahami DNS pada level ini bukanlah pilihan — DNS yang salah dikonfigurasi adalah salah satu penyebab paling umum dari gangguan aplikasi, kegagalan pengiriman email, dan kesalahan provisi SSL.

Proses Resolusi DNS: Langkah demi Langkah

Ketika pengguna mengetik `www.example.com` di browser, urutan berikut terjadi. Memahami setiap langkah sangat penting untuk mendiagnosis kegagalan resolusi dan mengoptimalkan strategi TTL.

Langkah 1: Pemeriksaan Cache Lokal

Sistem operasi pertama kali memeriksa cache DNS lokalnya (yang diisi dari pencarian sebelumnya). Di Linux, ini mungkin melibatkan `systemd-resolved` atau `nscd`. Di Windows, layanan DNS Client memelihara cache ini. Jika rekaman yang di-cache masih valid dalam TTL-nya, resolusi berhenti di sini.

Langkah 2: Stub Resolver ke Recursive Resolver

Jika tidak ada cache lokal yang cocok, stub resolver OS meneruskan kueri ke recursive DNS resolver — biasanya resolver ISP Anda, atau resolver publik yang dikonfigurasi seperti:

• Google Public DNS: `8.8.8.8` / `8.8.4.4`
• Cloudflare: `1.1.1.1` / `1.0.0.1`
• Quad9: `9.9.9.9`

Recursive resolver melakukan pekerjaan berat dalam menelusuri hierarki DNS atas nama klien.

Langkah 3: Kueri Server Root

Jika recursive resolver tidak memiliki jawaban yang di-cache, ia mengkueri salah satu dari 13 kluster server root (dialamatkan sebagai `a.root-servers.net` hingga `m.root-servers.net`). Ini bukan 13 mesin individual — melainkan 13 kelompok alamat Anycast yang dioperasikan oleh organisasi termasuk ICANN, Verisign, NASA, dan RIPE NCC, dengan lebih dari 1.500 instansi fisik yang tersebar di seluruh dunia.

Server root tidak mengembalikan alamat IP. Ia mengembalikan sebuah referral — alamat server TLD otoritatif untuk sufiks yang dikueri (misalnya, `.com`).

Langkah 4: Kueri Server TLD

Recursive resolver mengkueri server nama TLD yang sesuai. Untuk `.com`, ini dioperasikan oleh Verisign. Server TLD mengembalikan referral lain — server nama otoritatif untuk domain tingkat kedua tertentu (misalnya, `ns1.example.com`).

Langkah 5: Kueri Server Nama Otoritatif

Recursive resolver mengkueri server nama otoritatif, yang menyimpan file zona untuk `example.com`. Server ini mengembalikan rekaman DNS aktual — misalnya, rekaman A yang memetakan `www.example.com` ke `93.184.216.34`.

Langkah 6: Caching Respons dan Pengiriman

Recursive resolver menyimpan respons dalam cache sesuai dengan nilai TTL (Time to Live) rekaman tersebut, kemudian mengembalikan alamat IP ke stub resolver klien, yang meneruskannya ke browser. Browser kemudian membuka koneksi TCP (atau QUIC untuk HTTP/3) ke alamat IP tersebut.

Nuansa penting: Nilai TTL ditetapkan oleh pemilik domain di server otoritatif. TTL 300 detik berarti rekaman dapat di-cache selama 5 menit sebelum dikueri ulang. Selama migrasi atau respons insiden, menurunkan TTL terlebih dahulu (menjadi 60–300 detik) adalah praktik operasional standar untuk meminimalkan penundaan propagasi.

Hierarki DNS: Arsitektur dan Komponen

Namespace DNS terstruktur sebagai pohon terbalik. Setiap node dalam pohon adalah sebuah label, dan jalur lengkap dari daun ke root membentuk nama domain. Titik di akhir `www.example.com.` mewakili root.

Level 1: Zona Root

Zona root adalah puncak hierarki DNS, diwakili oleh label kosong (`.`). Zona ini berisi rekaman NS yang menunjuk ke server TLD untuk setiap top-level domain yang ada. File zona root dikelola oleh IANA (Internet Assigned Numbers Authority) dan saat ini berisi delegasi untuk lebih dari 1.500 TLD.

Server root beroperasi di bawah model trust anchor — rantai validasi DNSSEC pada akhirnya berakhir di Key Signing Key (KSK) zona root, yang dikelola melalui proses upacara yang sangat diaudit.

Level 2: Top-Level Domain (TLD)

Server TLD bersifat otoritatif untuk semua domain yang terdaftar di bawah sufiksnya. Ada beberapa kategori:

Level 3: Domain Tingkat Kedua (SLD) dan Subdomain

Domain tingkat kedua adalah label yang langsung berada di sebelah kiri TLD — `example` dalam `example.com`. Inilah unit yang dibeli dan dikelola oleh pendaftar domain. Ketika Anda mendaftarkan domain melalui layanan seperti Pendaftaran Domain, Anda memperoleh hak untuk mengontrol delegasi DNS untuk SLD tersebut.

Subdomain adalah label yang ditambahkan di depan SLD (`www`, `mail`, `api`, `blog`). Subdomain dikonfigurasi sepenuhnya dalam file zona server nama otoritatif — tidak diperlukan pendaftaran tambahan. Kedalaman subdomain secara teoritis tidak terbatas, meskipun ada batasan praktis (total panjang FQDN tidak boleh melebihi 253 karakter; setiap label tidak boleh melebihi 63 karakter).

Level 4: Server Nama Otoritatif dan File Zona

Server nama otoritatif adalah sumber kebenaran untuk rekaman DNS suatu domain. Mereka merespons kueri dengan flag AA (Authoritative Answer) yang disetel. File zona adalah basis data teks biasa yang berisi semua rekaman sumber daya untuk suatu domain.

Jenis rekaman DNS utama yang harus diketahui setiap administrator:

Rekaman CAA layak mendapat perhatian khusus: rekaman ini adalah kontrol keamanan yang sering diabaikan yang mencegah otoritas sertifikat yang tidak sah menerbitkan Sertifikat SSL untuk domain Anda. Jika rekaman CAA Anda tidak mencantumkan CA yang Anda gunakan, penerbitan sertifikat akan gagal.

Recursive Resolver vs. Server Otoritatif: Perbedaan yang Kritis

Kedua komponen ini secara arsitektur berbeda dan sering membingungkan bagi pendatang baru.

Satu server secara teknis dapat menjalankan kedua peran, namun hal ini sangat tidak disarankan dalam produksi karena implikasi keamanan dan kinerja (resolver terbuka adalah vektor untuk serangan DDoS amplifikasi DNS).

DNSSEC: Integritas Kriptografis untuk Rantai DNS

DNS standar tidak memiliki autentikasi bawaan — respons dapat dipalsukan melalui serangan cache poisoning (serangan Kaminsky adalah yang paling terkenal). DNSSEC (DNS Security Extensions) mengatasi hal ini dengan menambahkan tanda tangan digital ke rekaman DNS.

Rantai kepercayaan DNSSEC bekerja sebagai berikut:

1. Setiap zona menandatangani rekamannya dengan Zone Signing Key (ZSK)
2. Kunci publik ZSK diterbitkan sebagai rekaman DNSKEY
3. Zona induk menandatangani hash DNSKEY anak, membuat rekaman DS (Delegation Signer)
4. Rantai ini meluas dari zona root (trust anchor utama) hingga ke rekaman individual

Validasi DNSSEC terjadi di level recursive resolver. Validator memeriksa tanda tangan terhadap kunci yang diterbitkan; jika validasi gagal, resolver mengembalikan `SERVFAIL` daripada respons yang berpotensi diracuni.

Peringatan operasional: DNSSEC meningkatkan kompleksitas manajemen zona secara signifikan. Pergantian kunci, kedaluwarsa tanda tangan, dan sinkronisasi rekaman DS dengan zona induk adalah sumber umum gangguan. Selalu uji konfigurasi DNSSEC dengan alat seperti `dnsviz.net` sebelum mengaktifkannya di produksi.

DNS di Lingkungan Hosting: Pertimbangan Praktis

Propagasi vs. TTL

“Propagasi DNS” adalah istilah yang banyak disalahgunakan. Yang sebenarnya terjadi adalah kedaluwarsa TTL di seluruh cache. Ketika Anda mengubah rekaman A, resolver yang telah menyimpan nilai lama dalam cache akan terus menyajikannya hingga TTL kedaluwarsa. Tidak ada mekanisme “push” aktif dalam DNS standar.

Untuk meminimalkan downtime selama migrasi:

1. Turunkan TTL rekaman yang terpengaruh menjadi 300 detik setidaknya 24–48 jam sebelum perubahan (memungkinkan cache yang ada untuk kedaluwarsa)
2. Lakukan perubahan DNS
3. Setelah mengonfirmasi konfigurasi baru stabil, kembalikan TTL ke nilai produksi (3600–86400 detik)

Split-Horizon DNS

Di lingkungan dengan segmen jaringan publik dan privat — umum pada VPS Hosting atau Dedicated Server — split-horizon DNS (juga disebut split-brain DNS) menyajikan jawaban berbeda berdasarkan sumber kueri. Klien internal me-resolve `db.example.com` ke alamat privat RFC 1918; klien eksternal menerima IP publik atau alamat load balancer. Ini diimplementasikan di BIND menggunakan direktif `view` atau di PowerDNS melalui skrip Lua.

Reverse DNS (Rekaman PTR)

Reverse DNS memetakan alamat IP kembali ke hostname menggunakan zona `in-addr.arpa` (IPv4) atau `ip6.arpa` (IPv6). Rekaman PTR sangat penting untuk:

• Kemampuan pengiriman email — banyak server email penerima menolak atau sangat menghukum email dari IP tanpa rekaman PTR yang cocok
• Pencatatan keamanan — memperkaya log firewall dan akses dengan hostname
• Kepatuhan — beberapa kerangka regulasi mengharuskan reverse DNS untuk jejak audit

Jika Anda menjalankan pengaturan Email Hosting atau server email yang dikelola sendiri, pastikan penyedia hosting Anda telah mengonfigurasi rekaman PTR untuk alamat IP server Anda.

DNS dan Provisi Sertifikat SSL

Tantangan DNS-01 ACME (digunakan oleh Let’s Encrypt dan CA lainnya) mengharuskan penulisan rekaman TXT tertentu ke zona domain Anda untuk membuktikan kontrol domain. Metode ini diperlukan untuk penerbitan sertifikat wildcard. Manajemen sertifikat otomatis (melalui `certbot` atau `acme.sh`) memerlukan akses API ke penyedia DNS Anda untuk membuat dan menghapus rekaman TXT ini secara terprogram.

Mode Kegagalan DNS yang Umum dan Diagnostik

Memahami mode kegagalan adalah yang membedakan administrator yang mahir dari seseorang yang hanya mengikuti tutorial.

NXDOMAIN — Nama yang dikueri tidak ada dalam zona. Penyebab umum: kesalahan ketik dalam nama rekaman, zona tidak dimuat, atau delegasi menunjuk ke server nama yang salah.

SERVFAIL — Server tidak dapat menyelesaikan kueri. Penyebab umum: kegagalan validasi DNSSEC, server otoritatif tidak dapat dijangkau, atau file zona yang rusak (kesalahan sintaks dalam rekaman SOA atau NS).

Cache basi — Resolver menyajikan rekaman yang kedaluwarsa atau usang. Gunakan `dig +nocache` atau kueri server otoritatif secara langsung untuk melewati cache resolver.

Delegasi lame — Rekaman NS zona induk menunjuk ke server nama yang sebenarnya tidak otoritatif untuk zona tersebut (tidak memiliki zona yang dimuat). Ini adalah mode kegagalan diam yang menyebabkan kegagalan resolusi intermiten.

Perintah diagnostik penting:

“`bash

Query a specific resolver for an A record

dig @8.8.8.8 www.example.com A

Trace the full resolution path from root

dig +trace www.example.com

Check authoritative answer directly

dig @ns1.example.com www.example.com A +norec

Verify reverse DNS

dig -x 93.184.216.34

Check DNSSEC chain

dig www.example.com A +dnssec

Inspect SOA record (useful for checking serial after zone update)

dig example.com SOA

“`

Optimasi Kinerja DNS

• Penerapan Anycast — Server otoritatif yang diterapkan melalui Anycast merespons dari node yang paling dekat secara geografis, mengurangi latensi kueri
• Penyesuaian TTL — TTL yang lebih tinggi (3600–86400 detik) mengurangi beban resolver dan meningkatkan tingkat cache hit untuk rekaman yang stabil; TTL yang lebih rendah (60–300 detik) memungkinkan failover lebih cepat untuk infrastruktur dinamis
• Negative caching — Respons NXDOMAIN di-cache selama durasi yang ditentukan dalam field minimum TTL SOA; TTL negatif yang terlalu panjang menunda pemulihan dari kesalahan konfigurasi
• EDNS Client Subnet (ECS) — Memungkinkan recursive resolver meneruskan sebagian IP klien ke server otoritatif, memungkinkan keputusan geo-routing yang lebih akurat (dengan mengorbankan sebagian privasi)
• DNS over HTTPS (DoH) / DNS over TLS (DoT) — Mengenkripsi kueri DNS dalam transit, mencegah intersepsi dan manipulasi di level ISP; semakin penting untuk penerapan yang sensitif terhadap privasi

Matriks Keputusan: Memilih Konfigurasi DNS yang Tepat

Poin Teknis Utama

• Resolusi DNS adalah rantai delegasi multi-langkah: stub resolver > recursive resolver > root > TLD > server otoritatif
• 13 kluster server root (bukan mesin individual) menggunakan Anycast untuk melayani lebih dari 1.500 instansi fisik di seluruh dunia
• TTL mengontrol durasi cache — “propagasi” hanyalah menunggu cache kedaluwarsa, bukan push aktif
• Server otoritatif menyimpan file zona; recursive resolver menyimpan dalam cache dan meneruskan — jangan pernah mengacaukan kedua peran ini
• DNSSEC menambahkan validasi kriptografis tetapi memperkenalkan kompleksitas operasional; pergantian kunci dan sinkronisasi DS adalah titik kegagalan yang umum
• Rekaman PTR tidak dapat dinegosiasikan untuk penerapan server email dan pencatatan keamanan
• Rekaman CAA membatasi otoritas sertifikat mana yang dapat menerbitkan sertifikat SSL untuk domain Anda
• Delegasi lame dan cache negatif yang basi adalah salah satu mode kegagalan DNS yang paling berbahaya
• Selalu gunakan `dig +trace` untuk mendiagnosis masalah resolusi dari root ke bawah daripada mengandalkan output level resolver

Pertanyaan yang Sering Diajukan

Apa perbedaan antara recursive resolver dan server DNS otoritatif?

Recursive resolver mengkueri hierarki DNS atas nama klien dan menyimpan respons dalam cache. Server DNS otoritatif menyimpan file zona aktual untuk suatu domain dan mengembalikan jawaban definitif dengan flag AA yang disetel. Keduanya adalah peran yang secara arsitektur terpisah, meskipun secara teknis satu daemon dapat menjalankan keduanya.

Mengapa propagasi DNS memakan waktu lama setelah saya mengubah rekaman?

DNS tidak “menyebar” dalam arti aktif. Resolver menyimpan rekaman dalam cache selama durasi TTL yang disetel pada rekaman tersebut. Jika rekaman A Anda memiliki TTL 86400 detik (24 jam), resolver yang menyimpan nilai lama dalam cache akan terus menyajikannya hingga 24 jam. Untuk meminimalkan hal ini, turunkan TTL menjadi 300 detik setidaknya 24 jam sebelum melakukan perubahan.

Apa yang menyebabkan respons SERVFAIL dan bagaimana cara memperbaikinya?

SERVFAIL paling sering disebabkan oleh kegagalan validasi DNSSEC, server nama otoritatif yang tidak dapat dijangkau, atau file zona yang rusak/tidak valid. Gunakan `dig +dnssec` untuk memeriksa masalah DNSSEC, verifikasi server otoritatif Anda dapat dijangkau dan merespons, serta validasi sintaks file zona Anda dengan `named-checkzone`.

Apakah saya memerlukan DNSSEC untuk domain saya?

DNSSEC sangat direkomendasikan untuk domain yang menangani transaksi sensitif, infrastruktur email, atau layanan keuangan. DNSSEC mencegah serangan cache poisoning. Namun, DNSSEC menambah beban operasional — pergantian kunci dan manajemen rekaman DS memerlukan otomasi yang cermat. Untuk sebagian besar domain produksi, manfaat keamanan lebih besar daripada kompleksitasnya.

Rekaman DNS apa yang diperlukan untuk server email yang berfungsi?

Minimal: rekaman MX yang menunjuk ke hostname server email Anda, rekaman A yang me-resolve hostname tersebut, rekaman PTR pada IP server (dikonfigurasi oleh penyedia hosting Anda), dan rekaman TXT untuk SPF, DKIM, dan DMARC. Jika salah satu dari ini tidak ada, akan terjadi kegagalan pengiriman atau penolakan langsung oleh server email penerima.