Memilih Conditional Forwarder atau Stub Zone Saat Setup Resolver DNS

Koneksi antar-layanan di jaringan internal tiba-tiba terputus dengan galat resolusi nama domain yang serentak. Aplikasi melaporkan kegagalan koneksi basis data atau microservice lain, sementara status jaringan dan pod aplikasi terpantau sehat. Banyak tim langsung mencurigai adanya gangguan upstream ISP atau serangan distributed denial-of-service, padahal akar masalahnya sering kali berawal dari penambahan satu baris aturan forwarding baru pada resolver lokal yang tanpa sengaja memicu query loop. Dalam infrastruktur hosting multi-kluster, hybrid cloud, atau integrasi antar-datacenter, resolver DNS privat harus tahu ke mana ia harus mengarahkan query untuk domain yang bukan otoritasnya. Di titik ini, kita biasanya dihadapkan pada dua pilihan: memasang conditional forwarder atau membuat stub zone. Keduanya tampak memberikan hasil yang sama di awal pengujian, namun mekanisme di balik layarnya sangat berbeda dan menentukan apakah sistem kita tahan terhadap salah konfigurasi atau rentan tumbang total.

Gejala Awal Resolver Mengalami Kematian Resolusi

Gejala paling umum saat terjadi masalah delegasi internal bukan respons NXDOMAIN (domain tidak ditemukan), melainkan gelombang respons SERVFAIL atau client query yang habis masa tunggunya (timeout). Di sisi aplikasi, panggilan API internal mulai menghasilkan pengecualian jaringan bertubi-tubi karena waktu resolusi melonjak dari hitungan milidetik menjadi puluhan detik. Jika kamu membuka server resolver dan memeriksa utilisasi resource, penggunaan CPU sering kali melonjak tanpa adanya lonjakan trafik organik dari user luar. Log resolver mulai dipenuhi ribuan kueri untuk subdomain internal yang sama persis secara berulang dalam jendela waktu yang sangat sempit. Ini adalah tanda khas rekursi yang tidak pernah tuntas. Langkah pertama saat menghadapi laporan ini adalah mengisolasi resolusi langsung dari sisi server DNS menggunakan tool dig. Hindari menguji lewat caching client lokal agar kita melihat respons murni dari recursor.

BASH

dig @127.0.0.1 db-cluster.internal.corp +time=2 +tries=1 +trace

Jika query tersebut berhenti di tengah jalan dengan status SERVFAIL atau mengembalikan peringatan bahwa loop terdeteksi, perhatikan baris otoritas yang dilewati. Bila query justru berputar bolak-balik di antara dua atau tiga alamat IP resolver internal yang kita miliki, maka kita sedang berhadapan dengan circular forwarding.

Melacak Alur Kueri dan Titik Circular Forwarding

Langkah kedua adalah membedah bagaimana query berpindah antar server resolver. Circular forwarding terjadi ketika Resolver A diprogram untuk meneruskan query zona tertentu ke Resolver B, tetapi Resolver B—baik karena wildcard rule, default upstream, maupun aturan warisan lama—meneruskan kembali query tersebut ke Resolver A. DNS resolver modern memiliki mekanisme pengaman bernama recursion depth limit, yaitu batas kedalaman kueri berantai sebelum resolver menyerah dan mengembalikan SERVFAIL. Namun sebelum batas itu tercapai, setiap kueri tunggal dari client dapat memicu puluhan sub-query internal. Ketika ratusan worker aplikasi melakukan resolusi bersamaan, antrean kueri (query queue) internal resolver akan penuh seketika. Buffer socket UDP mulai menjatuhkan paket, dan resolver berhenti melayani kueri domain publik lain yang sebenarnya normal. Untuk memverifikasi server mana yang mengoper query tanpa menyelesaikan otoritasnya, jalankan pengujian tanpa rekursi langsung ke target forwarder:

BASH

dig @10.0.2.15 db-cluster.internal.corp +norecurse

Periksa respons flag dan bagian AUTHORITY atau ANSWER dari output perintah tersebut:

Jika target mengembalikan flag aa (Authoritative Answer) beserta record IP tujuan, maka server target tersebut adalah server otoritatif yang valid.
Jika target justru mengembalikan referral kosong atau melempar balik kueri dengan respons rekursi yang menunjuk IP resolver awal kita, maka rantai delegasi kita telah melingkar (loop).

Masalah rantai melingkar ini paling sering dipicu oleh penggunaan conditional forwarder statis yang tidak dirancang dengan batas hierarki yang tegas.

Memahami Perbedaan Mekanisme Conditional Forwarder dan Stub Zone

Untuk mencegah insiden serupa terulang, kita perlu membedah cara kerja kedua metode delegasi internal ini. Conditional forwarder adalah instruksi statis yang sangat kaku. Konsepnya sederhana: kita memberi tahu resolver bahwa jika ada kueri yang berakhiran zona tertentu (misalnya *.corp.internal), resolver tidak boleh mencari delegasi secara hierarkis, melainkan langsung meneruskan paket mentah DNS tersebut ke daftar IP spesifik yang kita tentukan secara manual. Kelemahan conditional forwarder muncul saat arsitektur jaringan berkembang. Resolver tidak memeriksa apakah IP tujuan benar-benar memegang otoritas atas record tersebut. Forwarder hanya bertindak layaknya proxy: terima kueri, teruskan ke IP A. Jika admin di sisi kluster seberang menambahkan forwarder default kembali ke jaringan utama kita, lingkaran loop tercipta seketika. Sebaliknya, stub zone bekerja lebih menyerupai delegasi DNS standar di internet. Saat kita membuat stub zone untuk suatu domain privat di resolver kita, resolver tersebut hanya menyimpan salinan minimal dari record penanda otoritas, yaitu Start of Authority (SOA) dan Name Server (NS) record beserta glue record (alamat IP dari nameserver tersebut). Ketika client menanyakan suatu host di stub zone, resolver lokal tidak sekadar mem-forward kueri secara buta. Resolver membaca NS record yang tersimpan di dalam stub zone, lalu mengirimkan query rekursif langsung ke authoritative nameserver yang terdaftar secara sah. Karena stub zone selalu memperbarui daftar nameserver langsung dari master zone target, resolver tahu persis batas otoritas domain tersebut. Perbedaan mendasar ini bisa kita rangkum dalam beberapa aspek teknis:

Karakteristik	Conditional Forwarder	Stub Zone
Mekanisme Operasional	Meneruskan query langsung ke IP statis tertentu (proxy kueri).	Mengambil dan menyimpan salinan NS/SOA record untuk menunjuk nameserver otoritatif.
Kemampuan Adaptasi	Kaku; jika IP nameserver otoritatif berubah, konfigurasi manual harus diperbarui di setiap forwarder.	Dinamis; resolver otomatis memperbarui alamat authoritative nameserver saat NS record di zona master berubah.
Risiko Circular Loop	Tinggi; rentan loop jika kedua kluster saling melempar aturan forwarding.	Rendah; resolver hanya bertanya langsung ke host yang memegang bendera otoritatif (Authoritative Flag).
Kebutuhan Akses	Hanya butuh akses UDP/TCP port 53 untuk query biasa.	Memerlukan izin transfer zona minimal (AXFR/IXFR) untuk menyalin record NS dan SOA.

Kapan Harus Memilih Conditional Forwarder dan Kapan Stub Zone

Gunakan conditional forwarder ketika kamu menghubungkan lingkungan yang berada di bawah pengawasan satu tim tunggal dengan topologi yang sangat sederhana, misalnya forwarding kueri dari server Active Directory ke resolver lokal Linux dalam satu subnet privat. Metode ini juga dipilih jika authoritative nameserver di kluster seberang memblokir penuh transfer zona sehingga pembentukan stub zone tidak dimungkinkan. Namun, jika kamu mengelola multi-kluster antar-cabang, kluster Kubernetes yang berinteraksi dengan infrastruktur bare-metal, atau integrasi jaringan antar-divisi yang berbeda tim, stub zone adalah pilihan yang jauh lebih aman. Dengan stub zone, resolver lokal kamu tidak akan terjebak oleh salah arah kueri rekursif pihak ketiga karena resolver kamu hanya berbicara langsung dengan nameserver otoritatif yang sah. Dalam mitigasi kegagalan kueri tingkat lanjut, kamu juga bisa mempelajari skenario galat DNS terkait pada panduan How to Test If a Broken CNAME Target Is Causing DNS SERVFAIL untuk memastikan bahwa masalah resolusi bukan berasal dari rantai alias yang terputus, atau melihat analisis degradasi recursor skala besar di Post-Mortem: Debugging BGP Anycast DNS Blackholes and BIND9 Recursor Collapse Under DDoS.

Pengamanan Tambahan untuk Mencegah Loop

Memilih antara forwarder atau stub zone tidak serta-merta membebaskan infrastruktur dari risiko kesalahan manusia di masa depan. Ada beberapa lapisan proteksi yang wajib dipasang pada konfigurasi daemon DNS kamu (seperti CoreDNS, Unbound, atau BIND9): Pertama, batasi kedalaman rekursi (maximum recursion depth) dan terapkan rate limiting untuk kueri internal yang identik. Ini memastikan bahwa seandainya aturan loop masuk tanpa sengaja ke server staging atau produksi, dampaknya terisolasi dan daemon tidak akan mengalami kehabisan memory socket atau hang. Kedua, terapkan safe-mode configuration profile. Jika pod resolver DNS kamu berada di lingkungan container yang mengunduh konfigurasi forwarding secara dinamis, pastikan ada mekanisme boot fallback. Jangan sampai satu file konfigurasi forwarder yang salah membuat seluruh pod resolver gagal boot atau terjebak dalam crash-loop. Terakhir, validasi setiap perubahan konfigurasi DNS lewat pipeline CI/CD sebelum diterapkan ke kluster utama. Lakukan uji coba semantik untuk memastikan tidak ada aturan forwarding yang merujuk balik ke IP resolver itu sendiri atau membentuk cincin rekursi tertutup dengan resolver cabang lain. Stabilitas resolver internal sangat bertumpu pada kejelasan batas tanggung jawab DNS: server rekursif harus fokus melayani pencarian client, dan delegasi ke domain internal harus diarahkan langsung ke nameserver yang memegang otoritas penuh atas zona tersebut, bukan diover tanpa henti antar resolver.