DNS Deep Dive: Memahami Resolusi Rekursif secara Praktis

Pendahuluan

DNS adalah salah satu layanan paling fundamental di infrastruktur modern, tetapi sering diperlakukan seperti utilitas yang selalu ada dan jarang perlu dipahami. Padahal banyak gangguan aplikasi, masalah konektivitas antarservice, kegagalan validasi sertifikat, hingga perilaku aneh pada Kubernetes sebenarnya memiliki komponen DNS yang cukup dominan.

Selama resolusi nama bekerja dalam hitungan milidetik, kebanyakan tim tidak memikirkannya. Namun ketika resolver melambat, cache miss melonjak, atau delegasi salah, dampaknya bisa terasa ke seluruh sistem.

Konsep Utama

Resolver rekursif melakukan kerja berat

Saat aplikasi meminta alamat untuk api.example.com, ia biasanya tidak menghubungi root server secara langsung. Stub resolver lokal akan meneruskan query ke recursive resolver. Resolver rekursif inilah yang mencari jawaban atas nama klien.

Jika cache masih punya jawaban valid, respons langsung dikirim. Jika tidak, resolver akan mengikuti rantai delegasi:

1. root memberi tahu ke mana TLD terkait diarahkan
2. TLD memberi tahu authoritative name server domain
3. authoritative server memberi record final
4. hasil dicache sesuai TTL

Delegasi adalah mekanisme skalabilitas DNS

Tidak ada satu server pun yang menyimpan semua nama di internet. Root tahu TLD, TLD tahu authoritative server sebuah domain, dan authoritative server tahu isi zonenya sendiri. Resolver rekursif menyusun jalur tersebut menjadi jawaban untuk klien.

Caching mempercepat sekaligus memperumit perubahan

Caching adalah alasan DNS mampu menangani volume query tinggi. Namun caching juga membuat perubahan record tidak terlihat seketika. TTL panjang memberi stabilitas, sedangkan TTL pendek memberi fleksibilitas migrasi.

Arsitektur / Cara Kerja

Resolusi DNS melibatkan beberapa lapisan:

• stub resolver di host
• recursive resolver milik ISP, perusahaan, atau cluster
• root dan TLD
• authoritative server
• cache di beberapa titik

Performa lookup sangat dipengaruhi oleh cache hit ratio, kualitas upstream, TTL, serta perilaku transport seperti fallback dari UDP ke TCP.

Negative caching juga penting. Respons seperti NXDOMAIN dapat disimpan sementara oleh resolver. Artinya, record yang baru dibuat belum tentu langsung terlihat jika sebelumnya pernah dinilai tidak ada.

DNSSEC menambah validasi kriptografis, tetapi juga membawa mode gagal baru seperti signature kedaluwarsa, DS record salah, atau rollover key yang tidak sinkron.

Studi Kasus / Masalah Nyata

TTL diturunkan terlalu terlambat

Tim ingin memindahkan traffic dari satu IP ke IP baru dan menurunkan TTL sesaat sebelum cutover. Hasilnya tidak sesuai harapan karena banyak resolver sudah lebih dulu mencache jawaban lama dengan TTL yang lebih panjang. Kesalahannya ada pada asumsi bahwa TTL baru berlaku retroaktif.

Resolver internal overload karena pola koneksi aplikasi

Dalam arsitektur microservices, satu perubahan kecil pada library koneksi dapat membuat setiap request membuka koneksi baru dan memicu lookup DNS berulang. Resolver internal yang tadinya cukup stabil mendadak mengalami lonjakan query dan latency lookup meningkat.

DNSSEC memutus akses secara selektif

Zona tampak normal jika diuji dengan resolver non-validating, tetapi pengguna dengan validating resolver gagal mengakses domain. Setelah ditelusuri, ternyata DS record di parent zone tidak cocok dengan key yang aktif. Ini contoh klasik bahwa “DNS berfungsi di mesin saya” tidak cukup.

Best Practices

Ubah TTL jauh sebelum cutover

Jika migrasi bergantung pada propagasi cepat, TTL harus diturunkan lebih awal agar cache lama sempat kadaluarsa.

Pantau resolver, bukan hanya authoritative DNS

Metrik penting meliputi query per second, cache hit ratio, upstream latency, timeout, dan error rate. Banyak organisasi hanya memonitor zone authoritative mereka, padahal pengalaman pengguna sangat dipengaruhi resolver.

Dokumentasikan delegasi dan ownership

Untuk setiap zona penting, pastikan jelas:

• siapa pemilik authoritative server
• bagaimana NS dan DS record dikelola
• bagaimana prosedur rollover dijalankan
• siapa yang bertanggung jawab saat insiden

Kesalahan Umum

• menurunkan TTL saat cutover sudah dimulai
• lupa bahwa respons negatif juga bisa dicache
• menganggap DNS internal otomatis skala bersama pertumbuhan service
• mengganti authoritative server tanpa validasi delegasi parent
• mengaktifkan DNSSEC tanpa proses rollover dan monitoring yang matang

Kesimpulan

Resolusi rekursif DNS adalah pekerjaan tersembunyi yang membuat sistem modern bisa saling menemukan dengan cepat dan konsisten. Ia bergantung pada delegasi, caching, transport yang sehat, dan kadang DNSSEC. Ketika kita memahaminya dengan baik, troubleshooting menjadi jauh lebih cepat dan keputusan migrasi menjadi lebih aman.