Mengira Subdomain Baru Langsung Aktif, Padahal NXDOMAIN Sudah Tercache Resolver

Kamu baru menambahkan record A untuk shop.example.com di zona DNS. Waktu dicek langsung ke nameserver, jawabannya sudah benar. Tapi browser masih bilang alamatnya tidak ditemukan, dan beberapa tool pengecekan online menampilkan NXDOMAIN. Biasanya zonanya tidak salah. Subdomain itu sempat ditanyakan ke resolver sebelum record-nya dibuat, entah oleh kamu, oleh proses validasi SSL, atau oleh monitoring. Jawaban 'nama ini tidak ada' dari saat itu sekarang disimpan di cache. Banyak orang mengira cache DNS cuma menyimpan jawaban yang berhasil. Kenyataannya, jawaban negatif juga di-cache, dan durasinya diatur oleh nilai yang jarang dilirik, yaitu SOA zona.

Apa yang terjadi saat resolver menanyakan nama yang belum ada

Supaya jelas di mana cache-nya terbentuk, kita urutkan alur query-nya. Ada dua peran di sini. Recursive resolver adalah server yang mencarikan jawaban atas nama klien, misalnya resolver ISP, resolver publik, atau resolver internal di jaringan kantor. Nameserver otoritatif adalah server yang benar-benar memegang isi zona domain kamu.

Aplikasi di komputer klien minta stub resolver (komponen DNS di OS) mencari shop.example.com. Stub meneruskan pertanyaan itu ke recursive resolver.
Recursive resolver mengecek cache-nya. Kalau belum ada data untuk nama itu, dia mengikuti delegasi dari root, lalu TLD, sampai ke nameserver otoritatif example.com. Biasanya data NS untuk zona ini sudah tersimpan dari query sebelumnya, jadi langkah ini sering dipersingkat.
Nameserver otoritatif mencari nama itu di zonanya dan tidak menemukannya. Dia membalas dengan RCODE 3, yaitu NXDOMAIN. Answer section kosong, flag aa (authoritative answer) menyala, dan authority section berisi record SOA milik zona.
Recursive resolver menyimpan hasil negatif itu di cache. Lama penyimpanannya dihitung dari SOA yang ikut dikirim tadi.
Selama entri itu belum kedaluwarsa, setiap query untuk shop.example.com langsung dijawab NXDOMAIN dari cache. Resolver tidak bertanya lagi ke nameserver otoritatif.

Langkah kelima ini yang sering membingungkan. Begitu record dibuat, nameserver otoritatif memang langsung tahu. Tapi resolver yang sudah menyimpan jawaban negatif tidak punya alasan untuk bertanya ulang. Resolver tidak menerima pemberitahuan apa pun saat zona kamu berubah. Ada juga jawaban negatif jenis kedua, yaitu NODATA. Di sini status-nya NOERROR, tapi answer section kosong. Artinya namanya ada, hanya saja tipe record yang ditanya tidak ada. Misalnya kamu sudah punya record A, lalu ada yang menanyakan AAAA. NODATA juga di-cache dengan cara yang sama, tapi hanya untuk kombinasi nama dan tipe tersebut. NXDOMAIN lebih luas karena berlaku untuk nama itu secara keseluruhan.

Dari mana angka negative TTL berasal

Record SOA (Start of Authority) berisi tujuh field: nameserver primer, email admin zona, serial, refresh, retry, expire, dan minimum. Field terakhir dulu dipakai sebagai TTL minimum untuk semua record di zona. Sejak RFC 2308, maknanya berubah menjadi acuan lama negative caching. Aturannya, resolver mengambil nilai yang lebih kecil antara TTL record SOA itu sendiri dan field minimum. Sebagai contoh, kalau SOA punya TTL 3600 dan field minimum-nya 86400, jawaban NXDOMAIN akan disimpan sekitar satu jam. Kalau keduanya sama-sama 86400, jawaban negatif itu bisa bertahan seharian. Di atas itu, resolver biasanya punya batas atas sendiri. Di BIND batas ini diatur lewat max-ncache-ttl, dan di Unbound lewat cache-max-negative-ttl. Untuk resolver publik atau resolver ISP, kita tidak bisa melihat konfigurasinya dari luar. Yang bisa kita lakukan hanya mengamati sisa TTL yang mereka kembalikan. Dari mekanisme ini ada dua konsekuensi praktis. Pertama, menurunkan TTL pada record A yang baru dibuat tidak membantu. Saat jawaban negatif di-cache, record itu belum ada, jadi yang dipakai adalah nilai dari SOA. Kedua, mengubah field minimum di SOA sekarang juga tidak memperpendek entri yang sudah tersimpan. Resolver sudah mencatat TTL-nya saat entri dibuat dan akan menunggu sampai habis. Perubahan SOA hanya berlaku untuk jawaban negatif berikutnya. Polanya mirip dengan kasus record yang sudah ada, yang dibahas di Kenapa Website Masih ke Server Lama Padahal TTL Sudah Diturunkan. Bedanya, di kasus ini yang tersimpan adalah ketiadaan record.

Kenapa kadang subdomain yang belum pernah dicek ikut kena

RFC 8020 menegaskan bahwa NXDOMAIN untuk sebuah nama juga berarti tidak ada nama apa pun di bawahnya. Resolver yang menerapkan aturan ini bisa langsung menjawab NXDOMAIN untuk www.shop.example.com begitu shop.example.com tercatat sebagai tidak ada, tanpa bertanya lagi ke otoritatif. Kalau zonanya memakai DNSSEC, ada efek tambahan. Jawaban negatif dari zona bertanda tangan menyertakan record NSEC atau NSEC3, yang menunjukkan rentang nama yang memang kosong di zona. RFC 8198 mengizinkan resolver yang melakukan validasi untuk memakai rentang itu sebagai bukti bahwa nama lain di rentang yang sama juga tidak ada. Akibatnya, subdomain yang belum pernah ditanyakan sama sekali bisa saja dijawab NXDOMAIN dari cache. Apakah dua perilaku ini aktif atau tidak, tergantung software dan konfigurasi resolver masing-masing. Jadi kalau gejalanya muncul di nama yang 'rasanya belum pernah dicek', kemungkinan ini patut dipertimbangkan sebelum menyalahkan zona.

Cara memastikannya lewat dig

Ketika ada laporan subdomain baru 'tidak jalan', urutan pengecekan yang paling hemat waktu adalah mulai dari sumbernya. Tanyakan dulu ke nameserver otoritatif, baru ke resolver. Semua perintah di bawah hanya membaca data dan aman dijalankan.

BASH

# Cari nameserver otoritatif zona
dig example.com NS +short

# Lihat SOA langsung dari nameserver otoritatif (ganti dengan hasil perintah di atas)
dig @ns1.example.com example.com SOA +norecurse

# Tanyakan subdomain ke setiap nameserver otoritatif
dig @ns1.example.com shop.example.com A +norecurse
dig @ns2.example.com shop.example.com A +norecurse

# Bandingkan dengan beberapa resolver publik
dig @8.8.8.8 shop.example.com A
dig @1.1.1.1 shop.example.com A

Jangan pakai +short untuk query subdomain, karena opsi itu menyembunyikan baris status. Yang perlu kamu lihat adalah header-nya. Dari nameserver otoritatif, hasil yang sehat adalah status: NOERROR, flag aa muncul, dan answer section berisi IP yang kamu pasang. Kalau otoritatif sudah benar tapi resolver masih NXDOMAIN, outputnya kira-kira seperti ini (contoh format output, bukan data nyata):

TEXT

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41020
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;shop.example.com.            IN      A

;; AUTHORITY SECTION:
example.com.     2715    IN      SOA     ns1.example.com. hostmaster.example.com. 2026102801 7200 3600 1209600 3600

Perhatikan angka TTL di baris SOA pada authority section. Di jawaban dari cache, angka itu biasanya menunjukkan sisa waktu sebelum entri negatif kedaluwarsa. Jalankan query yang sama beberapa kali dengan jeda. Kalau angkanya terus turun, berarti kamu sedang melihat cache, dan perkiraan kapan masalahnya hilang sendiri ada di angka itu. Resolver publik yang besar biasanya memakai anycast. Satu alamat IP dilayani oleh banyak node di berbagai lokasi, dan setiap node bisa punya cache sendiri. Karena itu, hasilnya bisa NXDOMAIN di satu percobaan lalu NOERROR di percobaan berikutnya, atau berbeda antara dua lokasi. Ini wajar selama cache di node-node itu belum seragam kedaluwarsa. Kalau nameserver otoritatif juga menjawab NXDOMAIN, berarti masalahnya bukan cache. Cek apakah record tersimpan di zona yang benar, apakah ada nameserver yang belum menerima perubahan (bandingkan serial SOA di setiap NS), dan apakah domain memang didelegasikan ke nameserver yang sedang kamu edit.

Cache di sisi klien juga ikut berperan

Selain recursive resolver, klien juga bisa menyimpan jawaban negatif. Di Linux yang memakai systemd-resolved, cache lokal bisa dibersihkan dengan resolvectl flush-caches. Di Windows, perintahnya ipconfig /flushdns. Beberapa browser juga punya cache DNS internal, jadi kadang browser perlu ditutup sepenuhnya, atau gunakan jendela atau profil lain untuk tes. Yang perlu diingat, membersihkan cache lokal tidak menyentuh resolver di upstream. Kalau resolver ISP masih menyimpan NXDOMAIN, klien yang sudah di-flush akan bertanya lagi dan menerima jawaban negatif yang sama. Sebagian resolver publik menyediakan cara untuk meminta cache sebuah nama dibersihkan, jadi cek dokumentasi resmi resolver yang dipakai. Untuk resolver ISP, biasanya pilihannya hanya menunggu TTL habis, atau sementara mengarahkan perangkat tes ke resolver lain.

Kebiasaan yang mencegah masalah ini

Polanya hampir selalu sama: nama sudah ditanyakan sebelum record-nya ada. Jadi buat record lebih dulu, cek ke nameserver otoritatif sampai semua NS menjawab benar, baru setelah itu buka di browser, jalankan penerbitan SSL, atau pasang monitoring. Sebelum peluncuran yang penting, lihat juga field minimum dan TTL di SOA zona kamu. Dari situ kamu tahu berapa lama kesalahan kecil semacam ini bisa bertahan di cache orang lain, dan bisa memutuskan apakah nilainya perlu disesuaikan sebelum hari H. Kalau masalahnya sudah terlanjur terjadi, dig ke otoritatif dan ke resolver, ditambah sisa TTL di authority section, sudah cukup untuk menjelaskan ke siapa pun kenapa subdomain itu belum muncul dan kapan kira-kira akan muncul.