Apa yang Dilakukan DNS dan Bagaimana Cara Kerjanya?

DNS (Domain Name System) adalah infrastruktur penamaan terdistribusi internet yang menerjemahkan nama domain yang dapat dibaca manusia — seperti example.com — menjadi alamat IP yang dapat dibaca mesin seperti 93.184.216.34. Tanpa DNS, setiap permintaan browser, panggilan API, dan pengiriman email akan mengharuskan pengguna dan aplikasi mengetahui alamat numerik yang tepat dari setiap host jarak jauh, sehingga internet modern tidak dapat beroperasi dalam skala besar.

Pada intinya, DNS adalah database terdistribusi secara global dan hierarkis. Ini bukan server tunggal atau registri terpusat — melainkan pohon delegasi yang mencakup ratusan ribu server nama otoritatif di seluruh dunia, dikoordinasikan melalui sekumpulan kecil server root dan diatur oleh standar yang didefinisikan dalam RFC 1034 dan RFC 1035.

Mengapa DNS Lebih dari Sekadar "Buku Telepon"

Analogi buku telepon berguna bagi pemula, tetapi sangat meremehkan apa yang sebenarnya dilakukan DNS. DNS adalah sistem pencarian real-time, toleran terhadap kesalahan, dan direplikasi secara global yang juga menangani:

• Perutean email melalui record MX, mengarahkan email ke server email yang tepat
• Penemuan layanan melalui record SRV, digunakan oleh protokol seperti SIP, XMPP, dan jaringan internal Kubernetes
• Verifikasi kepemilikan domain melalui record TXT, digunakan untuk SPF, DKIM, DMARC, dan Google Search Console
• Penamaan kanonik melalui record CNAME, memungkinkan integrasi CDN dan load balancing
• Pengalamatan IPv6 melalui record AAAA
• Pencarian terbalik melalui record PTR di zona in-addr.arpa, penting untuk reputasi server email dan audit keamanan
• Validasi DNSSEC, yang menambahkan tanda tangan kriptografis pada respons DNS untuk mencegah keracunan cache

Setiap kali Anda mengirim email, terhubung ke VPN, atau memuat aplikasi web, DNS menyelesaikan beberapa jenis record di latar belakang — seringkali puluhan kueri per pemuatan halaman.

Hierarki DNS: Bagaimana Namespace Disusun

DNS diorganisasikan sebagai pohon terbalik. Memahami struktur ini sangat penting untuk memahami mengapa resolusi bekerja seperti yang dilakukannya.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Root Zone (.): Dikelola oleh IANA. Ada 13 alamat server root logis (A hingga M), dioperasikan oleh organisasi seperti Verisign, NASA, dan ICANN. Dalam praktiknya, ini dilayani oleh ratusan mesin fisik melalui perutean anycast.
• Top-Level Domains (TLD): TLD generik seperti .com, .net, .org, dan TLD kode negara seperti .uk, .de, .md. Setiap TLD memiliki kumpulan server nama otoritatifnya sendiri.
• Second-Level Domains (SLD): Domain yang Anda daftarkan — example.com. DNS otoritatif untuk zona ini dikendalikan oleh siapa pun yang mendaftarkan domain tersebut.
• Subdomain: www, mail, api, staging — ini adalah record dalam zona SLD, sepenuhnya dikendalikan oleh pemilik domain.

Langkah demi Langkah: Bagaimana Kueri DNS Diselesaikan

Resolusi DNS rekursif penuh melibatkan hingga tujuh pertukaran jaringan yang berbeda. Berikut adalah urutan yang tepat:

Langkah 1 — Pemeriksaan Cache Browser

Ketika Anda mengetik www.example.com di browser Anda, sistem operasi pertama-tama memeriksa cache DNS lokalnya. Di Linux, ini mungkin dikelola oleh systemd-resolved; di Windows, oleh layanan DNS Client. Jika record yang di-cache valid ada dan TTL (Time to Live)-nya belum kedaluwarsa, resolusi berhenti di sini.

Anda dapat memeriksa cache DNS lokal di Linux dengan:

resolvectl statistics

Atau menghapusnya dengan:

sudo resolvectl flush-caches

Di Windows:

ipconfig /displaydns
ipconfig /flushdns

Langkah 2 — Kueri Recursive Resolver

Jika tidak ada jawaban yang di-cache, OS meneruskan kueri ke recursive resolver yang dikonfigurasi (juga disebut server DNS rekursif atau full-service resolver). Ini biasanya:

• Resolver ISP Anda (ditetapkan melalui DHCP)
• Resolver publik: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Resolver yang di-host sendiri seperti Unbound atau BIND di infrastruktur VPS Hosting Anda sendiri

Recursive resolver melakukan pekerjaan berat. Ia akan melintasi hierarki DNS atas nama Anda dan menyimpan hasil dalam cache untuk melayani kueri di masa mendatang dengan lebih cepat.

Langkah 3 — Referral Server Root

Recursive resolver mengkueri salah satu dari 13 kluster server root. Server root tidak mengetahui alamat IP dari www.example.com. Sebaliknya, ia mengembalikan referral — daftar server nama otoritatif untuk zona TLD .com, beserta alamat IP mereka (disebut glue records).

Langkah 4 — Kueri Server Nama TLD

Resolver mengkueri server nama TLD .com (dioperasikan oleh Verisign). Server-server ini juga tidak menyimpan jawaban akhir. Mereka mengembalikan referral lain — server nama otoritatif untuk example.com secara khusus (misalnya, ns1.example.com, ns2.example.com).

Langkah 5 — Kueri Server Nama Otoritatif

Resolver mengkueri server nama otoritatif untuk example.com. Server ini menyimpan file zona yang sebenarnya dan mengembalikan jawaban definitif — record A yang berisi alamat IPv4 (atau AAAA untuk IPv6).

Langkah 6 — Caching Respons dan Pengiriman

Recursive resolver menyimpan respons dalam cache sesuai dengan nilai TTL record (misalnya, 300 detik = 5 menit, 86400 detik = 24 jam). Kemudian mengembalikan alamat IP ke OS klien, yang meneruskannya ke browser.

Langkah 7 — Koneksi TCP/IP

Browser menggunakan alamat IP yang telah diselesaikan untuk membuka koneksi TCP (biasanya pada port 443 untuk HTTPS). Tugas DNS kini selesai. Server web merespons dan halaman dimuat.

Seluruh proses ini — langkah 2 hingga 6 — biasanya selesai dalam 20–120 milidetik pada cache resolver yang hangat, dan di bawah 500 milidetik untuk resolusi penuh yang dingin dan tidak di-cache yang melintasi semua tingkat hierarki.

Jenis Record DNS: Referensi Teknis

Record CAA layak mendapat perhatian khusus: record ini menginstruksikan Certificate Authority organisasi mana yang diizinkan untuk menerbitkan Sertifikat SSL untuk domain Anda — kontrol keamanan penting yang sering diabaikan.

Jenis Kueri DNS: Rekursif vs. Iteratif vs. Non-Rekursif

Sebagian besar perangkat pengguna akhir mengirimkan kueri rekursif ke resolver yang dikonfigurasi. Resolver itu sendiri menggunakan kueri iteratif saat melintasi hierarki.

TTL: Parameter DNS yang Paling Sering Disalahpahami

TTL (Time to Live) adalah jumlah detik sebuah record DNS dapat di-cache oleh resolver dan klien. Ini ditetapkan oleh pemilik domain dalam file zona.

• TTL rendah (60–300 detik): Propagasi perubahan lebih cepat. Penting sebelum migrasi yang direncanakan, perubahan IP, atau peristiwa failover. Meningkatkan beban kueri pada server otoritatif.
• TTL tinggi (3600–86400 detik): Mengurangi beban resolver dan mempercepat kueri berulang. Perubahan membutuhkan waktu lebih lama untuk menyebar secara global.

Wawasan operasional penting: Saat merencanakan migrasi server atau perubahan IP, kurangi TTL Anda menjadi 300 detik setidaknya 48 jam sebelum perubahan. Ini memastikan bahwa pada saat Anda memperbarui record A, tidak ada resolver yang menyimpan nilai lama dalam cache selama lebih dari 5 menit. Gagal melakukan ini adalah salah satu penyebab paling umum dari downtime yang berkepanjangan selama migrasi.

Ketika Anda mendaftarkan domain melalui Pendaftaran Domain dan mengarahkannya ke server baru, jendela propagasi secara langsung diatur oleh nilai TTL sebelumnya — bukan aturan "24–48 jam" yang sewenang-wenang yang sering dikutip secara tidak tepat.

Protokol Transport DNS: UDP, TCP, DoH, dan DoT

DNS tradisional beroperasi melalui UDP port 53 untuk kueri di bawah 512 byte. Respons yang melebihi ukuran ini memicu fallback ke TCP port 53. Respons DNSSEC, transfer zona (AXFR), dan record TXT yang besar umumnya memerlukan TCP.

Protokol privasi DNS modern telah mengubah lanskap ini secara signifikan:

DoH vs. DoT — perbedaan operasional yang sebenarnya: DoH mengarahkan DNS di dalam lalu lintas HTTPS pada port 443, membuatnya tidak dapat dibedakan dari lalu lintas web biasa. Ini berguna untuk privasi tetapi membuat pemantauan dan pemfilteran jaringan perusahaan jauh lebih sulit. DoT menggunakan port khusus (853), yang dapat dipantau, diblokir, atau diperiksa secara independen oleh administrator jaringan. Untuk infrastruktur yang dikelola sendiri di Dedicated Server, menjalankan resolver DoT atau DoH lokal memberi Anda privasi sekaligus kontrol penuh atas kebijakan resolusi.

DNSSEC: Integritas Kriptografis untuk DNS

DNSSEC (DNS Security Extensions) menambahkan rantai tanda tangan kriptografis pada respons DNS, memungkinkan resolver untuk memverifikasi bahwa respons adalah autentik dan tidak dirusak dalam perjalanan. Ini melindungi terhadap keracunan cache DNS (serangan Kaminsky) dan spoofing DNS man-in-the-middle.

DNSSEC tidak mengenkripsi lalu lintas DNS — hanya menandatanganinya. Rantai tanda tangan bekerja sebagai berikut:

1. Pemilik zona menghasilkan Zone Signing Key (ZSK) dan Key Signing Key (KSK)
2. Setiap kumpulan record DNS ditandatangani dengan ZSK, menghasilkan record RRSIG
3. KSK menandatangani kumpulan record DNSKEY
4. Record DS (Delegation Signer) diterbitkan di zona induk (misalnya, .com), menciptakan rantai kepercayaan kembali ke root

Mengaktifkan DNSSEC sangat direkomendasikan untuk domain mana pun yang menangani transaksi keuangan, autentikasi, atau email. DNSSEC yang salah dikonfigurasi — khususnya tanda tangan yang kedaluwarsa atau record DS yang tidak cocok — akan menyebabkan kegagalan resolusi total untuk resolver yang memvalidasi, yang merupakan mode kegagalan yang lebih sulit daripada tidak ada DNSSEC sama sekali.

Kegagalan DNS Umum dan Cara Mendiagnosisnya

NXDOMAIN — Domain Tidak Ada

Server otoritatif mengonfirmasi bahwa domain tidak ada. Penyebab umum: kesalahan ketik dalam nama domain, pendaftaran domain yang kedaluwarsa, record DNS yang dihapus.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Kegagalan Server

Resolver tidak dapat menyelesaikan kueri. Penyebab umum: kegagalan validasi DNSSEC, server otoritatif tidak dapat dijangkau, file zona yang salah dikonfigurasi.

dig +dnssec example.com
# Look for: status: SERVFAIL

Untuk melewati validasi DNSSEC dan mengisolasi masalah:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Cache Basi / Penundaan Propagasi

Setelah memperbarui record DNS, nilai lama tetap ada dalam cache resolver hingga TTL kedaluwarsa. Untuk mengkueri server otoritatif secara langsung dan melewati cache resolver:

dig @ns1.example.com www.example.com

Memeriksa Propagasi DNS Secara Global

Gunakan dig dengan resolver publik tertentu untuk memeriksa status propagasi:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS di Lingkungan Hosting: Konfigurasi Praktis

Ketika Anda men-deploy situs web atau aplikasi di VPS dengan cPanel, manajemen DNS biasanya ditangani melalui kluster DNS WHM atau Zone Editor cPanel. Memahami struktur file zona yang mendasarinya memungkinkan Anda membuat perubahan yang tidak diekspos oleh GUI.

File zona minimal untuk example.com terlihat seperti ini:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Agar Email Hosting berfungsi dengan benar, record MX harus menunjuk ke hostname (bukan langsung ke alamat IP), dan hostname tersebut harus dapat diselesaikan sendiri melalui record A. Kesalahan konfigurasi umum adalah mengarahkan MX langsung ke IP — ini melanggar RFC 2821 dan menyebabkan kegagalan pengiriman dengan server email yang ketat.

Performa DNS: Apa yang Sebenarnya Mempengaruhi Kecepatan Resolusi

• Kedekatan resolver: Resolver yang secara geografis dekat dengan klien (atau di jaringan yang sama) mengurangi waktu round-trip secara dramatis.
• Tingkat hit cache: Domain dengan lalu lintas tinggi dan TTL yang wajar hampir selalu dilayani dari cache. Resolusi cache dingin 5–20x lebih lambat.
• Perutean anycast: Server root dan resolver publik utama menggunakan anycast, merutekan kueri ke node fisik terdekat secara otomatis.
• Jumlah pencarian DNS per halaman: Satu halaman web dapat memicu 20–50 kueri DNS (aset CDN, analitik, font, jaringan iklan). Browser memparalelkan ini, tetapi setiap hostname unik memerlukan pencariannya sendiri.
• Prefetching DNS: Browser modern mendukung <link rel="dns-prefetch" href="//cdn.example.com"> untuk menyelesaikan hostname pihak ketiga sebelum diperlukan, mengurangi latensi yang dirasakan.

DNS vs. Mekanisme Resolusi Alternatif

File /etc/hosts dievaluasi sebelum DNS di hampir setiap sistem operasi. Ini membuatnya sangat berharga untuk pengembangan lokal — Anda dapat memetakan myapp.local ke 127.0.0.1 tanpa menyentuh infrastruktur DNS apa pun.

Poin Utama dan Daftar Periksa Keputusan

Gunakan daftar periksa ini saat mengonfigurasi atau memecahkan masalah DNS untuk lingkungan produksi mana pun:

• Sebelum migrasi server apa pun: Turunkan TTL menjadi 300 detik setidaknya 48 jam sebelumnya
• Untuk kemampuan pengiriman email: Verifikasi record MX, SPF (TXT), DKIM (TXT), DMARC (TXT), dan PTR semuanya dikonfigurasi dengan benar
• Untuk keamanan: Aktifkan DNSSEC pada domain Anda dan tambahkan record CAA untuk membatasi penerbitan sertifikat
• Untuk privasi: Gunakan DoT atau DoH pada perangkat klien dan server; hindari mengirim DNS teks biasa melalui jaringan yang tidak tepercaya
• Untuk performa: Tetapkan TTL ke 3600–86400 untuk record yang stabil; gunakan 300 hanya untuk record yang sering berubah
• Untuk diagnostik: Selalu kueri server otoritatif secara langsung dengan dig @ns1.yourdomain.com untuk membedakan penundaan propagasi dari kesalahan konfigurasi yang sebenarnya
• Untuk manajemen zona: Tambahkan nomor serial SOA setiap kali Anda memodifikasi file zona — resolver menggunakannya untuk mendeteksi perubahan
• Untuk hosting: Konfirmasi bahwa delegasi nameserver registrar Anda cocok dengan record NS dalam file zona Anda — ketidakcocokan adalah penyebab paling umum dari "DNS tidak berfungsi" setelah transfer domain

Pertanyaan yang Sering Diajukan

Apa perbedaan antara resolver DNS dan server DNS otoritatif?

Recursive resolver (misalnya, 8.8.8.8) adalah perantara yang mengkueri hierarki DNS atas nama perangkat Anda dan menyimpan hasil dalam cache. Server nama otoritatif menyimpan record zona yang sebenarnya untuk domain tertentu dan memberikan jawaban definitif. Resolver Anda mengkueri banyak server otoritatif; server otoritatif domain Anda hanya menjawab untuk zona yang di-host-nya.

Mengapa propagasi DNS membutuhkan waktu setelah saya memperbarui record?

Penundaan propagasi disebabkan oleh caching berbasis TTL. Setiap resolver yang sebelumnya menyimpan record lama Anda dalam cache akan terus melayaninya hingga TTL kedaluwarsa. Jika TTL Anda adalah 86400 (24 jam), resolver mungkin melayani record lama hingga 24 jam setelah pembaruan Anda. Ini bukan bug — ini adalah mekanisme caching yang dimaksudkan yang membuat DNS dapat diskalakan.

Apa itu kebocoran DNS dan mengapa itu penting?

Kebocoran DNS terjadi ketika perangkat Anda mengirimkan kueri DNS di luar resolver yang dimaksudkan — biasanya resolver ISP Anda — bahkan saat menggunakan VPN atau alat privasi. Ini mengekspos aktivitas penelusuran Anda ke ISP. Anda dapat menguji kebocoran di dnsleaktest.com dan memperbaikinya dengan mengonfigurasi klien VPN Anda untuk memaksakan perutean DNS melalui resolvernya sendiri.

Bisakah DNS digunakan sebagai vektor serangan?

Ya. Serangan berbasis DNS yang umum meliputi keracunan cache (menyuntikkan record palsu ke dalam cache resolver), DNS amplification DDoS (menggunakan resolver terbuka untuk membanjiri target dengan respons DNS yang besar), pembajakan DNS (mengalihkan kueri ke server berbahaya), dan DNS tunneling (mengekstrak data dengan mengkodekannya dalam string kueri DNS). DNSSEC mengurangi keracunan cache; pembatasan laju dan response-rate limiting (RRL) pada server otoritatif mengurangi amplifikasi.

Bagaimana cara menemukan server nama otoritatif untuk domain mana pun?

Gunakan dig dengan jenis record NS dan flag +short untuk output yang bersih:

dig NS example.com +short

Untuk melacak jalur delegasi penuh dari root ke otoritatif, gunakan:

dig +trace example.com

Ini menunjukkan setiap hop referral — root → TLD → otoritatif — yang merupakan cara paling andal untuk mendiagnosis kesalahan konfigurasi delegasi.