DNS: Gimana Komputer Tahu Jalan ke google.com

Kenapa DNS Ada?

Komputer berkomunikasi pakai IP address — deretan angka kayak 142.250.185.206. Tapi manusia ga mungkin hafal IP setiap website yang mau dikunjungi.

Bayangin kalau mau buka Google, harus ketik 142.250.185.206 di browser. Mau buka YouTube, hafal 208.65.153.238. Mau buka Instagram, hafal 157.240.1.174.

Ga realistis.

DNS (Domain Name System) itu buku telepon internet. Kamu kasih nama (google.com), DNS return IP address-nya (142.250.185.206). Simple as that.

graph LR
    User["User: google.com"] --> DNS["DNS Server"]
    DNS --> IP["142.250.185.206"]
    IP --> Server["Google Server"]

Tanpa DNS, internet seperti yang kita kenal ga akan ada.

Proses Resolusi DNS

Ini bagian terpenting. Gimana browser tahu IP dari www.example.com?

Prosesnya ga sesimpel tanya satu server. Ada hierarchy.

Step by Step

sequenceDiagram
    participant B as Browser
    participant R as Recursive Resolver
    participant Root as Root Server
    participant TLD as TLD Server (.com)
    participant Auth as Authoritative Server

    B->>R: Mana IP dari www.example.com?
    R->>Root: Mana IP dari www.example.com?
    Root-->>R: Ga tahu, tanya TLD .com di 192.5.6.30
    R->>TLD: Mana IP dari www.example.com?
    TLD-->>R: Ga tahu, tanya Authoritative di 216.239.34.10
    R->>Auth: Mana IP dari www.example.com?
    Auth-->>R: Ini dia: 93.184.216.34
    R-->>B: IP-nya 93.184.216.34

Penjelasan setiap komponen:

1. Browser Cache

Sebelum tanya ke mana-mana, browser cek dulu: "Udah pernah resolve domain ini belum?" Kalau udah dan belum expired, langsung pakai. Selesai.

2. OS Cache

Kalau browser ga punya, tanya ke OS. Setiap OS punya DNS cache sendiri.

Di Windows bisa cek pakai: ipconfig /displaydns
Di Linux/Mac: cat /etc/hosts untuk static mapping

3. Recursive Resolver

Kalau OS juga ga punya, request dikirim ke recursive resolver. Biasanya ini DNS server dari ISP kamu, atau public DNS kayak:

• Google DNS: 8.8.8.8, 8.8.4.4
• Cloudflare DNS: 1.1.1.1
• OpenDNS: 208.67.222.222

Recursive resolver itu yang ribet. Dia yang jalan ke mana-mana buat cari jawaban.

4. Root Name Server

Recursive resolver pertama tanya ke Root Server. Ada 13 set root server di dunia (namai A sampai M), tapi setiap set punya ratusan instance di berbagai lokasi (anycast).

Root server ga tahu IP www.example.com. Tapi dia tahu: "domain .com? Tanya ke TLD server .com di alamat ini."

5. TLD (Top-Level Domain) Server

TLD server handle satu top-level domain:

• .com → Verisign
• .org → PIR
• .id → PANDI
• .io, .dev, .app → masing-masing punya operator

TLD server juga ga tahu IP-nya. Tapi dia tahu: "example.com? Authoritative server-nya di alamat ini."

6. Authoritative Name Server

Ini server yang beneran tahu jawaban. Dia yang nyimpen record DNS untuk domain tersebut.

Dia return: www.example.com → 93.184.216.34

Recursive resolver simpan jawabannya (cache), lalu kasih ke browser.

Ringkasan Flow

graph TB
    Browser --> Cache["Browser/OS Cache"]
    Cache -->|miss| Resolver["Recursive Resolver<br/>(ISP atau 8.8.8.8)"]
    Resolver -->|miss| Root["Root Server (13 set)"]
    Root -->|referral| TLD["TLD Server (.com, .id, .org)"]
    TLD -->|referral| Auth["Authoritative Server"]
    Auth -->|answer| Resolver
    Resolver -->|cache + return| Browser

Keseluruhan proses ini biasanya selesai dalam 10-100 milliseconds. Dan setelah di-cache, resolusi berikutnya instan.

DNS Records

Authoritative server ga cuma nyimpen IP. Ada berbagai tipe record dengan fungsi berbeda.

A Record (Address)

Mapping paling dasar: domain → IPv4 address.

example.com.    IN    A    93.184.216.34

Setiap kali kamu ketik domain di browser, ini yang dicari.

AAAA Record (IPv6 Address)

Sama kayak A record, tapi untuk IPv6.

example.com.    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Kenapa nama "AAAA"? Karena IPv6 itu 4x lebih panjang dari IPv4. A × 4 = AAAA. 😅

CNAME Record (Canonical Name)

Alias dari satu domain ke domain lain.

www.example.com.    IN    CNAME    example.com.
blog.example.com.   IN    CNAME    myapp.vercel.app.

www.example.com bukan domain terpisah — dia cuma alias yang nunjuk ke example.com. Resolve example.com dulu, baru dapet IP-nya.

Penting: CNAME ga boleh coexist dengan record lain di nama yang sama. Dan CNAME ga boleh dipake di root domain (naked domain) di banyak DNS provider.

MX Record (Mail Exchange)

Ngarahin email ke mail server yang benar.

example.com.    IN    MX    10    mail1.example.com.
example.com.    IN    MX    20    mail2.example.com.

Angka (10, 20) itu priority. Makin kecil, makin diprioritaskan. Kalau mail1 ga bisa, coba mail2.

Ini yang bikin user@example.com bisa nerima email — MX record bilang: "email untuk example.com, kirim ke mail1.example.com."

NS Record (Name Server)

Menentukan authoritative DNS server untuk domain.

example.com.    IN    NS    ns1.example.com.
example.com.    IN    NS    ns2.example.com.

Ini yang di-return oleh TLD server saat recursive resolver tanya.

TXT Record

Record serbaguna yang berisi text bebas. Dipakai banyak hal:

example.com.   IN    TXT    "v=spf1 include:_spf.google.com ~all"
example.com.   IN    TXT    "google-site-verification=abc123..."

Use case:

• SPF: verifikasi pengirim email (anti-spam)
• DKIM: signing email
• DMARC: policy email authentication
• Domain verification: Google, Let's Encrypt, dll minta kamu bikin TXT record sebagai bukti kamu punya domain

SOA Record (Start of Authority)

Metadata tentang DNS zone: siapa admin-nya, kapan terakhir diupdate, berapa lama cache boleh simpan.

example.com.    IN    SOA    ns1.example.com. admin.example.com. (
    2024010101  ; serial number
    3600        ; refresh (1 jam)
    900         ; retry (15 menit)
    604800      ; expire (1 minggu)
    86400       ; minimum TTL (1 hari)
)

SRV Record (Service)

Mengarahkan ke service tertentu dengan port dan priority.

_sip._tcp.example.com.    IN    SRV    10 60 5060 sip.example.com.

Dipake oleh beberapa protokol (SIP, XMPP, LDAP) untuk service discovery.

Ringkasan Record

TTL dan Caching

TTL (Time To Live)

Setiap DNS record punya TTL — berapa lama (dalam detik) record boleh di-cache sebelum harus di-refresh.

example.com.    300    IN    A    93.184.216.34

TTL 300 = 5 menit. Artinya setelah resolver dapet jawaban ini, dia boleh simpan selama 5 menit tanpa tanya lagi ke authoritative server.

Trade-off TTL

Best practice: TTL pendek sebelum maintenance/migration, TTL panjang untuk operasi normal.

DNS Caching Layers

graph TB
    subgraph Caching Hierarchy
        B["Browser Cache<br/>TTL: mengikuti record"]
        OS["OS Cache<br/>TTL: mengikuti record"]
        Router["Router/Gateway Cache"]
        ISP["ISP Resolver Cache"]
        Auth["Authoritative Server<br/>(source of truth)"]
    end
    B --> OS --> Router --> ISP --> Auth

Setiap layer bisa cache. Kalau kamu ganti DNS record, perubahan ga instan. Harus nunggu cache di semua layer expired. Inilah yang disebut DNS propagation — dan kenapa perubahan DNS bisa butuh waktu sampai 48 jam (untuk TTL yang panjang).

DNS di Production

DNS-based Load Balancing

DNS bisa jadi load balancer sederhana — return multiple A record dan client pilih secara random/round-robin.

api.myapp.com.    IN    A    10.0.0.1
api.myapp.com.    IN    A    10.0.0.2
api.myapp.com.    IN    A    10.0.0.3

Client resolve api.myapp.com → dapet 3 IP → pilih satu.

Pro: simpel, ga butuh load balancer hardware
Kontra: ga bisa health check (kalau satu mati, client masih bisa dapet IP-nya), ga bisa weighted distribution

GeoDNS

Return IP yang berbeda berdasarkan lokasi user.

User dari Asia      → api.myapp.com → 10.0.1.1 (Singapore server)
User dari Eropa     → api.myapp.com → 10.0.2.1 (Frankfurt server)
User dari Amerika   → api.myapp.com → 10.0.3.1 (Virginia server)

CDN seperti Cloudflare, AWS CloudFront, dan Akamai pakai ini buat route user ke server terdekat.

Failover DNS

DNS provider bisa monitor server dan otomatis hapus record kalau server mati.

graph LR
    DNS[DNS Provider]
    DNS -->|"health check OK"| S1["Server 1: 10.0.0.1 ✅"]
    DNS -->|"health check fail"| S2["Server 2: 10.0.0.2 ❌"]
    
    Note1["DNS hanya return 10.0.0.1<br/>10.0.0.2 dihapus sementara"]

Tapi ada masalah cache: walaupun DNS provider udah hapus record, client yang udah cache IP lama masih ngarah ke server mati sampai TTL expired. Itulah kenapa TTL untuk failover harus pendek.

DNS Security

DNS Spoofing / DNS Cache Poisoning

Attacker menyisipkan record palsu ke DNS cache.

sequenceDiagram
    participant U as User
    participant R as Resolver
    participant A as Attacker

    U->>R: Mana IP bank.com?
    A->>R: bank.com = 66.66.66.66 (fake!)
    R-->>U: bank.com = 66.66.66.66
    U->>A: Login ke "bank.com" (actually attacker's server)

User pikir dia buka bank.com, padahal dia ke server attacker. Semua credential bocor.

Solusi: DNSSEC (DNS Security Extensions) — menambahkan digital signature ke DNS record supaya bisa diverifikasi keasliannya.

DNS Amplification Attack (DDoS)

Attacker kirim DNS query kecil (misal 60 bytes) tapi response-nya besar (misal 4000 bytes). Kalau source IP di-spoof jadi target victim:

1. Attacker kirim ribuan query ke open resolver, source IP = IP korban
2. Open resolver kirim response gede ke korban
3. Korban kewalahan → down

Amplification factor bisa sampai 70x. Query 60 bytes → response 4000 bytes.

Solusi: rate limiting di resolver, disable open resolver, Response Rate Limiting (RRL).

DNS Tunneling

Menyisipkan data di dalam DNS query untuk bypass firewall. Karena DNS biasanya diizinkan lewat firewall (port 53), attacker bisa encode data di subdomain:

aGVsbG8td29ybGQ.exfil.attacker.com

Subdomain aGVsbG8td29ybGQ itu base64 encoded data. Authoritative server attacker decode dan extract datanya.

Dipakai untuk: data exfiltration, command & control server, bypass captive portal.

Solusi: monitoring DNS query yang abnormal (query panjang, frekuensi tinggi, subdomain random).

DoH dan DoT (Encrypted DNS)

DNS tradisional itu plaintext. ISP, network admin, siapa aja di network bisa lihat domain yang kamu akses.

• DoH (DNS over HTTPS): DNS query dikirim lewat HTTPS (port 443). Keliatan kayak traffic web biasa.
• DoT (DNS over TLS): DNS query di-encrypt pakai TLS (port 853). Dedicated port.

Browser modern (Firefox, Chrome) udah support DoH. Cloudflare (1.1.1.1) dan Google DNS (8.8.8.8) support keduanya.

Tools untuk Debug DNS

nslookup

nslookup example.com
# atau query specific record type
nslookup -type=MX example.com

dig (lebih detail)

# Query A record
dig example.com

# Query specific type
dig example.com MX

# Trace full resolution path
dig +trace example.com

# Query specific DNS server
dig @8.8.8.8 example.com

dig +trace itu sangat berguna — bisa lihat persis step-by-step resolusi dari root server sampai authoritative.

host (simpel)

host example.com
host -t CNAME www.example.com

Ringkasan

Kesimpulan

DNS itu infrastruktur paling fundamental di internet. Setiap kali kamu buka website, kirim email, atau connect ke API — DNS bekerja di balik layar.

Yang perlu diingat:

1. DNS itu hierarki: Browser → OS → Resolver → Root → TLD → Authoritative
2. Caching itu di mana-mana — dan itu kenapa perubahan DNS ga instan
3. TTL itu penting — terlalu panjang bikin failover lambat, terlalu pendek bikin DNS server sibuk
4. DNS bukan cuma A record — MX untuk email, TXT untuk verifikasi, CNAME untuk alias
5. Security itu concern — DNS spoofing, amplification attack, tunneling itu nyata
6. Encrypted DNS (DoH/DoT) sudah jadi standar baru untuk privacy

DNS sering diabaikan sampai dia bermasalah. Dan kalau DNS bermasalah, semuanya bermasalah. Karena tanpa DNS, ga ada yang bisa resolve domain, ga ada yang bisa connect ke server.

Seperti kata pepatah: "It's always DNS." Dan pepatah itu benar lebih sering dari yang kita mau akui.