SanzSkuy: Created page with "'''DNS''' (''Domain Name System'', Sistem Penamaan Domain) adalah sistem hierarkis dan terdistribusi yang menerjemahkan '''nama domain''' yang mudah diingat manusia (mis. `example.com`) menjadi '''IP address''' yang dipahami mesin (mis. `93.184.216.34`), dan sebaliknya. DNS sering diibaratkan sebagai "buku telepon internet". Standar awalnya didefinisikan dalam '''RFC 1034''' dan '''RFC 1035''' (1987). Tanpa DNS, pengguna harus..."

2026-06-27T10:22:23Z

Created page with "'''DNS''' (''Domain Name System'', Sistem Penamaan Domain) adalah sistem hierarkis dan terdistribusi yang menerjemahkan '''nama domain''' yang mudah diingat manusia (mis. <code>example.com</code>) menjadi '''IP address''' yang dipahami mesin (mis. <code>93.184.216.34</code>), dan sebaliknya. DNS sering diibaratkan sebagai "buku telepon internet". Standar awalnya didefinisikan dalam '''RFC 1034''' dan '''RFC 1035''' (1987). Tanpa DNS, pengguna harus..."

New page

'''DNS''' (''Domain Name System'', Sistem Penamaan Domain) adalah sistem hierarkis dan terdistribusi yang menerjemahkan '''nama domain''' yang mudah diingat manusia (mis. <code>example.com</code>) menjadi '''[[Protokol Internet|IP address]]''' yang dipahami mesin (mis. <code>93.184.216.34</code>), dan sebaliknya. DNS sering diibaratkan sebagai "buku telepon internet". Standar awalnya didefinisikan dalam '''RFC 1034''' dan '''RFC 1035''' (1987).

Tanpa DNS, pengguna harus menghafal deretan angka IP untuk setiap layanan. DNS beroperasi di '''[[Model OSI|Layer 7 (Application)]]''' dan umumnya memakai '''port 53'''.

{| class="wikitable" style="float:right; margin-left:1em; font-size:90%; max-width:300px;"
|+ Ringkasan DNS
! Atribut !! Nilai
|-
| Fungsi || Nama domain ↔ IP
|-
| RFC || RFC 1034, RFC 1035
|-
| Layer (OSI) || 7 (Application)
|-
| Port || 53 (UDP & TCP)
|-
| Varian aman || DoT (853), DoH (443)
|}

== Dua peran yang sering tertukar ==

Banyak kebingungan tentang DNS berasal dari mencampuradukkan dua hal berbeda yang sama-sama disebut "DNS server":

* '''Recursive resolver''' — server yang '''Anda tanyai'''. Ia menerima permintaan ("berapa IP <code>example.com</code>?"), melakukan seluruh pencarian atas nama Anda, lalu mengembalikan jawaban. Inilah yang Anda isi sebagai <code>8.8.8.8</code> atau <code>1.1.1.1</code> di konfigurasi jaringan.
* '''Authoritative server''' — server yang '''menyimpan record sebenarnya''' untuk suatu domain. Ia adalah sumber kebenaran, tetapi Anda hampir tidak pernah menghubunginya langsung — resolver yang mewakili Anda.

Memahami pemisahan ini adalah kunci memahami cara kerja DNS.

== Komponen DNS ==

{| class="wikitable"
|+ Komponen utama dalam resolusi DNS
! Komponen !! Peran
|-
| '''Stub resolver''' || Bagian kecil di OS klien yang meneruskan kueri ke recursive resolver.
|-
| '''Recursive resolver''' || Melakukan pencarian penuh dan menyimpan hasil di cache (mis. <code>8.8.8.8</code>).
|-
| '''Root server''' || 13 grup server (a–m) di puncak hierarki; mengarahkan ke server TLD.
|-
| '''TLD server''' || Mengelola ''top-level domain'' seperti <code>.com</code>, <code>.org</code>, <code>.id</code>; mengarahkan ke server otoritatif domain.
|-
| '''Authoritative server''' || Menyimpan record definitif untuk suatu domain.
|}

== Proses resolusi nama ==

Misalkan klien meminta IP dari <code>www.example.com</code> dan belum ada di cache mana pun:

# Klien (stub resolver) bertanya ke '''recursive resolver''' (mis. <code>1.1.1.1</code>).
# Resolver bertanya ke '''root server''': "Di mana <code>.com</code>?" Root menjawab dengan alamat server '''TLD .com'''.
# Resolver bertanya ke '''TLD .com''': "Di mana <code>example.com</code>?" TLD menjawab dengan alamat '''authoritative server''' example.com.
# Resolver bertanya ke '''authoritative server''': "Berapa IP <code>www.example.com</code>?" Server menjawab dengan record A: <code>93.184.216.34</code>.
# Resolver menyimpan hasil di cache, lalu mengembalikan IP ke klien.

<pre>
Klien
│ "IP www.example.com?"
▼
Recursive resolver (1.1.1.1)
│── tanya ──► Root server ──► "coba TLD .com"
│── tanya ──► TLD .com server ──► "coba authoritative example.com"
│── tanya ──► Authoritative ──► "93.184.216.34"
▼
Jawaban: 93.184.216.34 (disimpan ke cache)
</pre>

Kueri dari klien ke resolver bersifat '''rekursif''' (resolver wajib mengembalikan jawaban final), sedangkan kueri resolver ke server lain bersifat '''iteratif''' (tiap server menjawab "tanya ke sana").

== Caching dan TTL ==

Untuk menghindari pengulangan pencarian penuh, hasil disimpan di '''cache''' pada resolver (dan sebagian di OS klien). Tiap record punya '''TTL''' (''Time To Live'') dalam detik yang menentukan berapa lama boleh disimpan sebelum harus diperbarui. TTL rendah = perubahan cepat menyebar tetapi beban kueri tinggi; TTL tinggi = sebaliknya.

== Jenis record DNS ==

{| class="wikitable"
|+ Record DNS yang umum
! Record !! Fungsi
|-
| '''A''' || Memetakan nama → alamat IPv4.
|-
| '''AAAA''' || Memetakan nama → alamat IPv6.
|-
| '''CNAME''' || Alias dari satu nama ke nama lain (''canonical name'').
|-
| '''MX''' || Mail exchanger; server email untuk domain.
|-
| '''NS''' || Menunjuk authoritative name server untuk zona.
|-
| '''PTR''' || Reverse lookup: IP → nama.
|-
| '''SOA''' || ''Start of Authority''; metadata zona (serial, TTL, dll).
|-
| '''TXT''' || Teks bebas; dipakai SPF, DKIM, verifikasi domain.
|-
| '''SRV''' || Lokasi layanan (host + port) untuk protokol tertentu.
|}

== Hierarki namespace ==

Nama domain dibaca dari kanan ke kiri, makin ke kanan makin tinggi tingkatnya:

<pre>
www . example . com .
│ │ │ └─ root (titik, sering tak ditulis)
│ │ └─────── TLD
│ └────────────────── domain (second-level)
└─────────────────────────── subdomain / host
</pre>

Nama lengkap berakhiran titik root disebut '''FQDN''' (''Fully Qualified Domain Name''), mis. <code>www.example.com.</code>

== Resolver publik dan konfigurasi jaringan ==

Saat mengonfigurasi jaringan, kolom "DNS server" diisi alamat '''recursive resolver'''. Secara default, ISP memberikan resolver-nya sendiri lewat DHCP, tetapi banyak pengguna menggantinya dengan resolver publik karena alasan kecepatan, privasi, atau keandalan.

{| class="wikitable"
|+ Resolver publik populer
! IP !! Penyedia
|-
| <code>8.8.8.8</code> / <code>8.8.4.4</code> || Google Public DNS
|-
| <code>1.1.1.1</code> / <code>1.0.0.1</code> || Cloudflare
|-
| <code>9.9.9.9</code> || Quad9
|-
| <code>208.67.222.222</code> || OpenDNS (Cisco)
|}

Beberapa hal penting:

* '''Mengapa IP mentah, bukan nama?''' Karena DNS-lah yang menerjemahkan nama menjadi IP. Jika alamat resolver berupa nama, dibutuhkan DNS untuk menerjemahkannya — padahal DNS belum tersedia (masalah ''chicken-and-egg''). Maka resolver harus ditulis sebagai IP mentah; ia adalah titik '''bootstrap''' sebelum resolusi nama apa pun bisa berjalan.
* '''Mengapa diisi dua (primary + secondary)?''' Redundansi. Jika resolver pertama tidak merespons, OS otomatis mencoba yang kedua.
* '''Anycast.''' IP seperti <code>8.8.8.8</code> sebenarnya dilayani oleh banyak server tersebar di dunia yang berbagi satu alamat; lalu lintas Anda otomatis diarahkan ke lokasi terdekat, sehingga responsnya cepat dari mana pun.

== Protokol dan port ==

* '''UDP port 53''' — default untuk sebagian besar kueri (cepat, ringan).
* '''TCP port 53''' — dipakai bila respons besar (mis. > 512 byte) atau untuk ''zone transfer'' antar server.
* '''DoT''' (''DNS over TLS'', port 853) dan '''DoH''' (''DNS over HTTPS'', port 443) — varian terenkripsi untuk privasi.

== Keamanan ==

DNS klasik tidak terenkripsi dan rentan terhadap beberapa serangan:

* '''DNS spoofing / cache poisoning''' — penyerang menyisipkan record palsu ke cache resolver agar korban diarahkan ke situs jahat.
* '''DNS hijacking''' — pengalihan kueri ke resolver berbahaya.

Mitigasi:
* '''DNSSEC''' — menandatangani record secara kriptografis agar keasliannya bisa diverifikasi.
* '''DoT / DoH''' — mengenkripsi kueri agar tidak bisa disadap atau dimanipulasi di jalur.

== Perintah praktis (Linux) ==

{| class="wikitable"
|+ Perintah terkait DNS
! Tujuan !! Perintah
|-
| Resolusi lengkap + detail || <code>dig www.example.com</code>
|-
| Hanya jawaban singkat || <code>dig +short www.example.com</code>
|-
| Tanya record tertentu || <code>dig MX example.com</code>
|-
| Reverse lookup (IP → nama) || <code>dig -x 93.184.216.34</code>
|-
| Gunakan resolver tertentu || <code>dig @1.1.1.1 example.com</code>
|-
| Status resolver sistem || <code>resolvectl status</code>
|-
| Alternatif klasik || <code>nslookup example.com</code>, <code>host example.com</code>
|}

== Troubleshooting ==

* '''Bisa ping IP tapi tidak bisa ping nama''' — konektivitas jaringan oke, masalah ada di DNS. Cek resolver yang dikonfigurasi (<code>resolvectl status</code> atau <code>/etc/resolv.conf</code>).
* '''Resolusi lambat''' — coba resolver publik (<code>dig @8.8.8.8</code>) untuk membandingkan; mungkin resolver ISP yang lambat.
* '''Jawaban tampak salah/usang''' — kemungkinan cache; perhatikan TTL atau bersihkan cache resolver.
* '''Beda hasil antar resolver''' — bisa karena propagasi perubahan DNS belum selesai (tunggu sesuai TTL), atau pemfilteran oleh resolver tertentu.

== Lihat pula ==

* [[Model OSI]]
* [[Model TCP/IP]]
* [[Protokol Internet]]
* [[ARP]]

== Pranala luar ==

* [https://www.rfc-editor.org/rfc/rfc1034 RFC 1034 — Domain Names: Concepts and Facilities]
* [https://www.rfc-editor.org/rfc/rfc1035 RFC 1035 — Domain Names: Implementation and Specification]

DNS - Revision history