Beranda›Dasar komputer dan mengetik›Cara kerja internet

DNS: mengubah nama menjadi alamat

13 server nama root dijalankan oleh 12 organisasi dari 2047 mesin di seluruh dunia (root-servers.org, 17 Oktober 2026).

Latar belakangSebelum ada DNS, setiap komputer di ARPANET menyimpan salinan satu berkas teks, HOSTS.TXT, yang mencantumkan setiap nama host dan alamatnya. Network Information Center milik Stanford Research Institute mengelolanya, dan setiap lokasi mengunduh salinan terbaru. Seiring jaringan tumbuh, berkas itu ikut membesar, perubahan makin lama menyebar, dan nama-nama saling bentrok. RFC 1034 menjelaskan masalah ini dan rancangan penggantinya: pohon nama, yang setiap bagiannya diurus oleh server-servernya sendiri. DNS diterbitkan sebagai RFC 1034 dan RFC 1035 pada 1987.

Sekarang tidak ada yang mengunduh berkas itu. Kamu mengetik example.com, bukan 198.51.100.20, dan nama itu dicari tepat saat kamu membutuhkannya. Namun router tetap hanya memahami angka, jadi sebelum perambanmu bisa mengirim satu paket pun ke sebuah situs web, nama itu harus menjadi alamat. Domain Name System (DNS) melakukan hal itu, dan panduan Cloudflare menyebutnya buku telepon internet.

Nama adalah jalur menuruni pohon

Baca www.example.com dari kanan. Di puncak ada root, ditulis sebagai titik yang tak terlihat. Di bawahnya ada domain tingkat teratas (TLD) seperti com, org, dan kr. Di bawah com ada example, dan di bawahnya www. Setiap potongan adalah label; RFC 1035 membolehkan sampai 63 byte per label dan 255 byte untuk satu nama utuh. Organisasi yang berbeda mengelola cabang pohon yang berbeda, jadi tidak ada satu komputer pun yang harus tahu setiap nama, dan justru itulah yang salah pada HOSTS.TXT, ketika satu berkas di setiap mesin mencoba memuat semuanya.

Pohon DNS. www.example.com adalah jalur www → example → com → root, dibaca dari kiri ke kanan tetapi dicari dari root ke bawah.

Empat server, delapan langkah

Cloudflare mencantumkan empat jenis server dalam sebuah pencarian. Resolver rekursif, biasanya dijalankan ISP-mu atau layanan DNS publik, melakukan kerja kerasnya untukmu. Server root tahu di mana server TLD berada. Server TLD, seperti server untuk com, tahu server mana yang memegang setiap domain di bawahnya. Server otoritatif untuk sebuah domain memegang catatan sebenarnya dan memberi jawaban akhir. Tanpa cache sama sekali, sebuah pencarian memerlukan delapan langkah. Komputermu bertanya ke resolver. Resolver bertanya ke root, yang menunjukkan com. Resolver bertanya ke com, yang menunjukkan server nama domain itu. Resolver bertanya ke server-server itu, mereka menjawab dengan alamatnya, dan resolver menyerahkan alamat itu kembali kepadamu.

Memuat

Seret untuk memutar. Gulir atau cubit untuk memperbesar.

Tekan Langkah berikutnya delapan kali, atau Putar. Lalu tekan Cari lagi: cache peramban langsung menjawab dan tidak ada pesan yang keluar dari komputer. Tunggu 1 menit lalu cari lagi: salinan peramban sudah kedaluwarsa tetapi cache OS masih menyimpannya. Tunggu 1 jam: TTL 3600 detik sudah habis di mana-mana dan pencarian lengkap dimulai lagi.

Mengapa pencarian kedua langsung selesai

Jika setiap pencarian memerlukan delapan langkah, DNS akan lambat dan server root akan tenggelam dalam pertanyaan. Jadi jawaban disimpan. Jawaban di-cache di peramban, di sistem operasi, dan di resolver. Setiap catatan datang dengan waktu hidup (TTL) dalam detik, yang ditetapkan pemilik domain. TTL 3600 berarti "kamu boleh memakai ulang jawaban ini selama satu jam". TTL pendek membuat pemilik bisa memindahkan situs dengan cepat; TTL panjang menghemat pencarian. Server root juga tersebar: 13 server root bernama, a sampai m, berjalan sebagai 2047 instans terpisah pada 17 Oktober 2026.

Dua jenis pertanyaan, satu port

Satu pencarian mencampurkan dua jenis pertanyaan. Komputermu mengirim kueri rekursif ke resolver, yang artinya "beri aku jawaban akhir atau galat". Resolver lalu mengirim kueri iteratif ke server root, TLD, dan otoritatif, dan masing-masing membalas dengan yang terbaik yang dimilikinya, sering kali hanya penunjuk ke server berikutnya. Pesan DNS dikirim ke port 53, biasanya lewat UDP karena satu pertanyaan dan satu jawaban masing-masing muat dalam satu paket. Jawaban besar dan transfer antarserver memakai TCP, yang oleh RFC 7766 dijadikan bagian wajib dari setiap implementasi DNS lengkap. Kamu bisa mencobanya sendiri. Di sebagian besar komputer, perintah nslookup example.com mencetak resolver yang dipakainya dan alamat-alamat yang diterimanya.

Catatan memuat lebih dari sekadar alamat

Catatan	Memuat	Contoh
A	Alamat IPv4	www.example.com → 198.51.100.20
AAAA	Alamat IPv6 (RFC 3596)	www.example.com → 2001:db8::20
CNAME	Nama lain yang dicari sebagai gantinya	shop.example.com → example.com
MX	Server email untuk domain itu	example.com → mail.example.com
NS	Server nama otoritatif	example.com → ns1.example.com

Pencarian www.example.com tanpa cache: server mana yang ditanyai resolver, secara berurutan?
Server mana yang memberi jawaban akhir untuk www.example.com?
- Server otoritatif untuk example.com
- Server root
- Server TLD com
- Server web
Berapa langkah yang diperlukan pencarian tanpa cache menurut penjelasan Cloudflare?
Catatan mana yang memuat alamat IPv6?
- AAAA
- A
- MX
- CNAME
Sebuah catatan punya TTL 3600. Berapa menit cache boleh memakainya ulang?
Berapa panjang maksimum satu label (seperti example) menurut RFC 1035?
Ada berapa server root bernama?
Kamu mencari sebuah nama 10 detik lalu dan cache peramban menyimpannya selama 60 detik. Berapa pesan DNS yang keluar dari komputermu jika kamu mencarinya lagi sekarang?
Untuk apa catatan MX?
- Menyebut server email untuk sebuah domain
- Menyimpan halaman web
- Memuat alamat IPv6
- Menetapkan TTL catatan lain
Apa yang digantikan DNS?
- Satu berkas HOSTS.TXT yang disalin ke setiap komputer
- Jaringan telepon
- Alamat IP
- Router

Kesalahan umum

"DNS menyimpan halaman web." DNS hanya menjawab dengan catatan seperti alamat, server email, dan nama lain. Halamannya sendiri datang dari server web di alamat yang dikembalikan DNS.
"Saat sebuah situs mengganti alamatnya, semua orang langsung melihat alamat baru." Peramban, sistem operasi, dan resolver menyimpan jawaban lama sampai TTL-nya habis. Dengan TTL 3600, sebagian pengunjung masih bisa diarahkan ke alamat lama hingga satu jam.
"Ada tepat 13 komputer server root." Ada 13 nama, a sampai m, yang dijalankan 12 organisasi. Pada 17 Oktober 2026, server-server itu menjawab dari 2047 instans di seluruh dunia.
"Komputerku sendiri yang bertanya ke server root." Komputermu bertanya ke resolver rekursif satu kali. Resolver berjalan dari root ke server TLD ke server otoritatif dan hanya menyerahkan hasilnya.

Catatan untuk guruBaca beberapa nama dari kanan ke kiri bersama-sama sebelum menggambar apa pun; kebiasaan membaca itulah yang pertama perlu dibangun. Resolver adalah kotak yang sering hilang dari gambar pelajar, jadi gambar terpisah dari komputer dan buat setiap panah dari komputer berhenti di sana. Jalankan delapan langkah simulator sekali, lalu langsung tekan Cari lagi. Pencarian kedua yang tidak mengirim apa pun menjelaskan cache lebih baik daripada definisi. Jika ada terminal, nslookup pada situs yang sudah dikenal kelas mengubah diagram menjadi sesuatu yang nyata.

Poin penting

DNS mengubah nama menjadi alamat; nama dibaca dari kanan ke kiri menuruni pohon.
Resolver rekursif → root → TLD → otoritatif: delapan langkah tanpa cache.
Jawaban di-cache di peramban, OS, dan resolver selama TTL catatan (detik).
A = IPv4, AAAA = IPv6, CNAME = alias, MX = email, NS = server nama.

Sumber kursus ini (28)

(checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
RFC 792 ICMP (Time Exceeded)
RFC 801 NCP/TCP transition plan (1 January 1983)
RFC 894 Ethernet (1500-byte payload)
RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
RFC 1122 (127.0.0.0/8 loopback)
RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
RFC 8446 TLS 1.3 (one round-trip handshake)
RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
RFC 9293 TCP (three-way handshake, sequence numbers)
IANA: ip-parameters registry (recommended default TTL 64)
IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
"What is a URL?", "HTTP response status codes" (developer.mozilla.org)
Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
"What is HTTP/3?" (cloudflare.com/learning)
Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
historyofinformation.com and Wikipedia ARPANET (Kline)
Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)

Diperiksa: 2026-10-17