Setiap kali kamu mengetik nama situs dan menekan Enter, browser menghadapi masalah yang tidak bisa ia selesaikan sendiri. Ia tahu namanya, tetapi internet hanya mengarahkan trafik ke angka. Sesuatu harus menerjemahkan nama itu menjadi alamat, dan harus melakukannya dalam hitungan milidetik, miliaran kali sehari, tanpa pernah bingung. Sesuatu itu adalah Domain Name System, atau DNS, dan ia adalah infrastruktur yang tenang di balik hampir semua hal yang kamu lakukan online.
Poin Penting
DNS menerjemahkan nama domain yang mudah dibaca manusia menjadi alamat IP, angka yang dipakai komputer untuk saling menemukan.
Sebuah lookup biasanya melewati empat lapisan: cache perangkatmu, recursive resolver, root server, server TLD, dan server otoritatif, meski caching sering melewati sebagian besar lapisan itu.
Ada 13 identitas root server bernama, berlabel A sampai M, masing-masing direplikasi di banyak lokasi di seluruh dunia sehingga query mencapai salinan terdekat.
Record DNS tidak hanya mengarahkan situs ke server. Record ini mengarahkan email, memverifikasi kepemilikan domain, dan mengatur server mana yang boleh mengirim email untuk sebuah domain.
Query DNS klasik tidak terenkripsi. DNSSEC memeriksa keaslian jawaban, sementara DNS over HTTPS dan DNS over TLS mengenkripsi query dalam perjalanan ke resolver.
Apa Sebenarnya Tugas DNS
Komputer saling menemukan lewat alamat IP, misalnya 93.184.216.34 untuk example.com. Manusia mengingat nama, bukan deretan angka, dan nama bisa tetap stabil sementara server di baliknya berpindah. DNS adalah database terdistribusi yang memetakan satu ke yang lain. Ia bersifat hierarkis, seperti pohon, dan tidak ada satu server pun yang memegang semuanya. Setiap lapisan hanya tahu cukup untuk mengarahkan query selangkah lebih dekat ke jawaban.
Desain itulah yang membuat DNS bisa diskalakan. Perangkatmu bertanya ke resolver terdekat, resolver bertanya ke sejumlah kecil server, dan masing-masing server menjawab dari potongannya sendiri dalam pohon itu. Sistem ini dirancang pada awal 1980-an, ketika satu file teks bersama berisi nama host sudah runtuh di bawah pertumbuhan jaringan, dan ia masih menjalankan logika lookup dasar yang sama hingga hari ini.
Sebuah Lookup, Langkah demi Langkah
Inilah yang terjadi saat kamu mengunjungi sebuah situs untuk pertama kalinya, tanpa cache sama sekali:
Perangkatmu memeriksa cache-nya sendiri. Browser, lalu sistem operasimu, mencari jawaban terbaru. Jika salah satunya punya jawaban yang belum kedaluwarsa, lookup berhenti di sini.
Recursive resolver mengambil alih. Perangkatmu mengirim query ke recursive resolver, biasanya dijalankan oleh penyedia internetmu, atau resolver publik seperti Cloudflare (1.1.1.1) atau Google (8.8.8.8). Resolver inilah yang mengerjakan pencarian atas namamu.
Root server menunjukkan arah. Resolver bertanya ke salah satu dari 13 identitas root server, server mana yang menangani top-level domain yang diminta, misalnya .com. Root server tidak tahu alamat situs itu. Ia hanya tahu siapa yang harus ditanya berikutnya.
Server TLD mempersempit pencarian. Server top-level domain untuk .com tahu server nama otoritatif mana yang menangani domain spesifik itu, dan ia menyerahkannya.
Server otoritatif memberikan jawaban. Ini satu-satunya lapisan yang memegang record sebenarnya dari domain itu. Ia mengembalikan record A, alamat IPv4, atau record AAAA untuk IPv6, dan resolver meneruskannya kembali ke perangkatmu.
Semuanya menyimpan hasil ke cache. Setiap lapisan menyimpan jawaban selama waktu tertentu, yang disebut TTL (Time To Live), sehingga kunjungan berikutnya melewati sebagian besar rantai itu.
Pada lookup dingin, rantai itu hanya beberapa kali bolak-balik jaringan. Pada kunjungan berulang, biasanya nol, karena jawabannya sudah tersimpan di cache di suatu tempat antara kamu dan resolver. Itulah sebabnya kunjungan pertama ke situs baru kadang terasa sedikit lebih lambat, dan setiap kunjungan setelahnya terasa instan.
Record yang Menjalankan Sebuah Domain
Zone file sebuah domain memuat lebih dari satu jenis record. Yang paling umum:
Record | Fungsinya |
|---|---|
A | Mengarahkan nama ke alamat IPv4 |
AAAA | Mengarahkan nama ke alamat IPv6 |
CNAME | Menjadikan satu nama sebagai alias dari nama lain |
MX | Menyebutkan server mana yang menerima email untuk domain itu |
NS | Menyebutkan server mana yang otoritatif untuk domain itu |
TXT | Membawa teks, dipakai untuk pemeriksaan kepemilikan dan kebijakan email seperti SPF, DKIM, dan DMARC |
CAA | Membatasi certificate authority mana yang boleh menerbitkan sertifikat untuk domain itu |
SOA | Memuat detail administratif tentang zone itu sendiri |
Sebuah situs membutuhkan record A atau AAAA. Pengaturan email yang berjalan membutuhkan record MX plus record TXT yang membuktikan server pengirim itu sah. Satu salah ketik di record mana pun bisa membuat situs atau kotak surat tidak bisa diakses, itulah sebabnya perubahan DNS biasanya dilakukan dengan hati-hati, dan dengan TTL pendek selama migrasi supaya kesalahan bisa cepat diperbaiki.
Sejarah Singkat: Dari Satu File Teks Menjadi Pohon Global
Sebelum DNS, ARPANET awal menyimpan satu tabel host, HOSTS.TXT, yang dikelola dengan tangan. Saat jaringan tumbuh pada awal 1980-an, file itu menjadi terlalu lambat dan terlalu rapuh untuk terus diperbarui lewat telepon pada jam kerja. Pada 1983, Paul Mockapetris, yang bekerja di Information Sciences Institute milik University of Southern California, merancang Domain Name System untuk menggantikannya dengan layanan terdistribusi dan hierarkis.
Inti sistem baru itu pertama kali dijelaskan dalam RFC 882 dan RFC 883 pada 1983, dan desainnya disempurnakan menjadi standar yang masih dipakai semua implementasi hingga kini: RFC 1034 (Domain Names, Concepts and Facilities) dan RFC 1035 (Domain Names, Implementation and Specification), keduanya diterbitkan pada November 1987. Sejarah BIND dari Internet Systems Consortium mencatat urutan itu, dari draf 1983 hingga standar 1987, dan mencatat bahwa server nama pertama yang berfungsi, bernama Jeeves, ditulis oleh Mockapetris pada 1983 dan 1984. Mahasiswa Berkeley segera menulis BIND, server nama Unix yang membawa DNS ke pemakaian luas.
Mengapa DNS Cepat, dan Kapan Ia Tidak Cepat
DNS terasa instan karena dua trik. Pertama adalah caching di setiap lapisan, seperti dijelaskan di atas. Kedua adalah anycast: 13 identitas root itu bukan 13 mesin, melainkan 13 alamat yang diumumkan dari banyak lokasi di seluruh dunia, sehingga query-mu diarahkan ke salinan terdekat, bukan melintasi planet.
Saat DNS lambat, penyebabnya biasanya salah satu dari tiga hal. TTL yang disetel terlalu panjang membuat perubahan butuh berjam-jam untuk sampai ke resolver yang menyimpan cache. Record yang salah konfigurasi mengarahkan pengunjung ke server yang salah, atau ke tempat yang tidak ada. Atau resolver itu sendiri lambat atau jauh, itulah sebabnya beralih dari default ISP ke resolver publik seperti 1.1.1.1 atau 8.8.8.8 kadang membuat browsing terasa jelas lebih cepat. Jika sebuah situs bisa dibuka semua orang kecuali kamu, membersihkan cache DNS lokal atau mencoba resolver lain adalah pemeriksaan pertama yang masuk akal, sebelum menganggap situs itu sendiri sedang down.
Keamanan: DNSSEC, DoH, dan DoT
DNS klasik punya sifat yang canggung: query berjalan dalam teks biasa, dan jawaban dipercaya sebagian besar karena datang dari server yang diharapkan. Dua perbaikan berbeda menangani dua separuh berbeda dari masalah itu.
DNSSEC (Domain Name System Security Extensions) menambahkan tanda tangan kriptografis ke record DNS, sehingga resolver bisa memverifikasi bahwa jawaban benar-benar berasal dari server otoritatif domain itu dan tidak diubah dalam perjalanan. Ia melindungi integritas jawaban, tetapi tidak mengenkripsi query. Siapa pun yang mengawasi jaringan tetap bisa melihat domain apa yang kamu cari.
DNS over TLS (DoT) dan DNS over HTTPS (DoH) mengenkripsi query itu sendiri. DoT membungkus query dalam TLS pada port-nya sendiri, 853, dan umumnya dikonfigurasi pada level sistem operasi atau router. DoH mengirim query sebagai trafik HTTPS biasa pada port 443, sehingga menyatu dengan trafik web normal dan sering diaktifkan di dalam satu browser. Cloudflare mencatat trade-off-nya: DoT lebih mudah dipantau dan dikendalikan administrator jaringan, sementara DoH memberi pengguna lebih banyak privasi dari pengamat di jaringan lokal. Keduanya tetap menyisakan satu fakta yang tidak berubah: resolver itu sendiri melihat setiap domain yang kamu tanyakan. DNS terenkripsi menyembunyikan query-mu dari orang yang mengawasi kabel, bukan dari resolver yang kamu pilih.
DNS dalam Kehidupan Sehari-hari
Kamu bertemu DNS lebih sering daripada yang kamu sadari. Saat perusahaan memindahkan situsnya ke host baru, ia mengubah record A. Saat ia menyiapkan email pada penyedia baru, ia mengubah record MX. Saat ia membuktikan kepemilikan domain ke layanan seperti Google Search Console, ia menambahkan record TXT. Saat developer menambahkan subdomain untuk situs staging, itu pun record DNS.
Dan lookup yang sama berada di balik semua hal lain dalam stack. Begitu DNS mengembalikan alamat, browser membuka koneksi dan protokol web lainnya mengambil alih. REST API Dijelaskan: Cara Kerja Gaya API Web yang Paling Umum membahas apa yang terjadi setelah koneksi itu dibuat. DNS adalah langkah sebelum semua itu, langkah yang mengubah nama yang kamu ketik menjadi tempat yang bisa dijangkau komputer.
Pertanyaan yang Sering Diajukan
Apakah DNS sama dengan alamat IP saya?
Tidak. Alamat IP-mu adalah asal trafikmu. DNS adalah sistem yang menerjemahkan nama menjadi alamat server yang ingin kamu capai. Keduanya menjelaskan ujung berbeda dari koneksi yang sama.
Mengapa perubahan DNS butuh waktu untuk berlaku di semua tempat?
Karena resolver menyimpan jawaban lama di cache sampai TTL-nya kedaluwarsa. Menurunkan TTL sebelum perubahan yang direncanakan membuat peralihan lebih cepat, tetapi perubahan yang dibuat dengan TTL panjang yang sudah tersimpan di cache bisa butuh berjam-jam untuk menjangkau semua orang.
Haruskah saya mengganti resolver DNS saya?
Ini eksperimen yang masuk akal jika browsing terasa lambat atau jika kamu menginginkan query terenkripsi. Resolver publik seperti 1.1.1.1 dari Cloudflare dan 8.8.8.8 dari Google mudah dikonfigurasi di kebanyakan perangkat dan router, dan keduanya mendukung DoH dan DoT. Ingat saja bahwa resolver yang kamu pilih bisa melihat setiap domain yang kamu cari, jadi pilih yang kebijakan privasinya kamu percaya.
Apa yang terjadi jika DNS down?
Jika server otoritatif sebuah domain gagal, tidak ada yang bisa me-resolve domain itu, meski server situsnya sendiri berjalan sempurna. Itulah sebabnya outage DNS terasa begitu total: situsnya tidak rusak, ia tidak bisa dijangkau, karena tidak ada pengunjung yang bisa menemukan alamatnya.