DNS yang Setengah Hidup: Mendiagnosis Anomali Tersembunyi Akibat Pencampuran Peran

DNS yang Setengah Hidup: Mendiagnosis Anomali Tersembunyi Akibat Pencampuran Peran

Dalam dunia kerja sunyi sistem, ada masalah yang lebih berbahaya daripada error merah yang jelas: masalah yang bekerja diam-diam, membuat sistem tampak sehat namun sesekali pingsan tanpa sebab. Bab ini adalah kisah tentang mendiagnosis salah satunya: DNS yang setengah hidup.

Ceritanya dimulai dari laporan pengguna yang samar. "Web internal kita, `portal.lokal`, kadang bisa diakses, kadang nggak. Kayak hantu." Deskripsinya klasik untuk masalah jaringan intermiten. Saya coba sendiri. Di laptop, `ping portal.lokal` berhasil. Buka browser, website muncul. Besoknya, dari komputer yang sama, `ping` timeout, browser menunjukkan "This site can’t be reached". Sejam kemudian, normal lagi. Tidak ada pola yang jelas. Tidak ada error log di server web. Server itu sendiri sehat 100%, CPU dan memory rendah. Jadi, masalahnya pasti di perjalanan menuju server itu.

Pertama, saya periksa DNS. `nslookup portal.lokal`. Hasilnya: satu alamat IP. Tepat, sesuai dengan IP server. Saya flush DNS cache di laptop (`ipconfig /flushdns`). Masih bisa resolve. Jadi, sepertinya DNS server kita (yang jalan di Windows Server) bekerja dengan baik. Tapi kenapa akses bisa hilang sesekali?

Saya mulai telusuri lebih dalam dengan `nslookup` mode debug: `nslookup -debug portal.lokal`. Dan di sinilah petunjuk pertama muncul. Di bagian akhir output, ada baris yang menarik:

"Non-authoritative answer: portal.lokal canonical name = proxy-server.lokal"

Wait. Canonical name? CNAME? Ini aneh. `portal.lokal` seharusnya langsung mengarah ke IP server web, bukan ke alias lain. Siapa yang membuat record CNAME ini? Dan mengapa ke sebuah proxy?

Saya buka konsol DNS Server. Zone `lokal` tampak bersih. Record A untuk `portal` mengarah ke IP yang benar. Tidak ada CNAME. Lalu dari mana record CNAME itu muncul? Saya coba query ke DNS server lain di jaringan. Hasilnya sama: ada CNAME ke `proxy-server.lokal`. Artinya, record CNAME itu memang ada di suatu tempat dalam sistem DNS kita, tapi tidak terlihat di konsol utama.

Inilah saatnya turun ke rabbit hole. Saya ingat, setahun lalu, sebelum migrasi ke server baru, kita pernah punya reverse proxy untuk load balancing. Server proxy itu sudah lama dimatikan dan di-decommission. Tapi sepertinya, jejaknya belum sepenuhnya hilang. Setelah membongkar arsip konfigurasi dan bertanya pada senior, ternyata dulu ada secondary DNS server yang masih aktif, yang zona-nya belum pernah di-update pasca-migrasi. Server tua ini masih menjawab query DNS, dan di zonanya masih tercatat CNAME lama `portal.lokal -> proxy-server.lokal`.

Nah, ini masalahnya: pencampuran peran. DNS server utama sudah dikonfigurasi dengan benar (record A murni). Tapi DNS server sekunder yang tua masih menyebarkan konfigurasi lama (record CNAME ke proxy yang sudah mati). Karena kedua server ini ada dalam daftar nameserver jaringan (melalui DHCP), klien secara acak bisa query ke salah satunya. Jika query ke server utama, dapat IP benar, website terbuka. Jika query ke server tua, dapat CNAME yang mengarah ke proxy mati, website hilang. Itulah sebabnya perilakunya intermiten dan seperti "hantu".

Tapi tunggu, kenapa kadang bisa timeout, kadang bisa lemot? Ini lapisan kedua dari masalah. Saat klien dapat CNAME, ia lalu melakukan lookup lagi untuk `proxy-server.lokal`. Record A untuk `proxy-server.lokal` ternyata masih ada dan mengarah ke IP lama proxy yang sekarang sudah tidak ada mesinnya. Klien mencoba koneksi ke IP yang "hantu" itu. TCP SYN timeout setelah 3 detik. Tapi, di beberapa kasus, sebelum timeout penuh, klien melakukan query ulang ke DNS dan kebetulan dapat server utama, lalu sukses. Hasilnya: pengalaman pengguna yang tidak konsisten, kadang lambat, kadang error.

Ini adalah contoh sempurna dari kerja sunyi sistem yang gagal diam-diam. Tidak ada alarm berbunyi. Monitoring DNS server menunjukkan status "running". Query test sporadis mungkin berhasil jika kebetulan kena server utama. Masalah hanya muncul sebagai keluhan samar dari pengguna yang sulut direproduksi. Dan akar penyebabnya adalah warisan konfigurasi (legacy) yang tidak dibersihkan.

Solusinya bukan menambahkan sesuatu. Bukan membuat rule firewall baru atau script workaround. Solusinya adalah membersihkan. 1. Matikan DNS server sekunder yang tua itu secara permanen. Ia sudah tidak punya peran lagi selain menyebarkan kebingungan. 2. Hapus semua record zombie terkait proxy lama dari semua zona DNS, termasuk record A untuk `proxy-server.lokal`. 3. Pastikan hanya satu sumber kebenaran (single source of truth) untuk DNS, dan pastikan semua klien hanya mengarah ke sana. Setelah pembersihan ini, saya minta semua pengguna untuk renew DHCP lease dan flush DNS cache. Dalam satu jam, laporan "kadang hidup kadang mati" berhenti. `portal.lokal` sekarang selalu merespons dalam milidetik.

Pelajarannya di sini sangat dalam. Dalam kerja sistem, penambahan seringkali lebih menarik daripada pengurangan. Kita suka menambah server baru, fitur baru, aturan baru. Tapi kita jarang membersihkan yang lama yang sudah tidak berguna. Konfigurasi lama itu seperti sampah di gudang: tidak mengganggu sampai suatu hari kita butuh jalan di gudang itu dan tersandung.

Masalah pencampuran peran (DNS murni vs proxy) ini juga mengajarkan tentang pentingnya pemisahan tanggung jawab yang jelas. Server yang berfungsi sebagai DNS harus hanya melakukan itu. Jika dia juga berfungsi sebagai proxy, maka konfigurasinya menjadi rentan terhadap konflik seperti ini. Atau, jika ada perubahan infrastruktur (seperti menghapus proxy), perubahan itu harus merambat ke semua sistem yang terkait, termasuk DNS. Proses perubahan (change management) yang robust harus mencakup tahap "cleanup" sebagai bagian wajib.

Diagnosis masalah seperti ini membutuhkan pola pikir detektif, bukan sekadar teknisi. Kamu harus mau menggali sejarah sistem ("dulu pernah ada proxy"), memeriksa bukti yang tampaknya tidak relevan (CNAME di lookup), dan menghubungkan titik-titik yang terpisah. Seringkali, jawabannya tidak ada di log error terbaru, tapi di keputusan arsitektur yang dibuat setahun yang lalu.

Akhirnya, website yang stabil itu lahir bukan dari kompleksitas konfigurasi yang hebat, tetapi dari kerja sunyi membersihkan kekacauan yang tidak terlihat—sebuah pengingat bahwa di balik layar, kejelasan logika seringkali lebih penting daripada kecanggihan fitur.

FAQ (Tanya-Jawab Ringan)

Q: Kenapa tidak pakai monitoring DNS yang bisa alert kalau ada record yang tidak konsisten antar server?
A> Itu ide bagus, dan tool seperti itu ada. Tapi dalam realitas banyak organisasi kecil-menengah, monitoring sering hanya fokus pada "apakah service jalan?" bukan pada "apakah konfigurasinya konsisten?". Ini adalah celah dalam kerja sunyi: kita memantau kesehatan, tapi kurang memantau kebenaran (truth).

Q> Apa bedanya masalah ini dengan masalah DNS cache poisoning atau ISP yang nakal?
A> Sumber masalahnya berbeda. DNS cache poisoning adalah serangan di mana cache DNS diisi dengan record palsu. ISP nakal biasanya meng-redirect ke server mereka sendiri. Masalah kita adalah konfigurasi internal yang tidak konsisten—bukan serangan atau niat jahat, tapi kelalaian administrasi. Gejalanya mirip, tapi penyebab dan solusinya sangat berbeda.

Q: Kalau server tua itu masih penting untuk redundansi, bagaimana solusinya?
A> Maka ia harus dikonfigurasi ulang sebagai secondary yang benar, dengan zona yang di-transfer dari primary server, bukan menyimpan konfigurasi mandiri yang ketinggalan zaman. Atau, gunakan teknologi seperti Active Directory Integrated Zones di Windows yang memastikan konsistensi otomatis antar server.

Q> Apakah tools seperti `dig` atau `nslookup` dengan opsi debug wajib dikuasai?
A> Untuk troubleshooting jaringan level dalam, mutlak. `nslookup` biasa hanya memberi jawaban, `nslookup -debug` memberi tahu prosesnya: ke server mana ia bertanya, record apa yang dilewati, dan apakah ada redirect seperti CNAME. Tanpa itu, kita mungkin tidak akan pernah menemukan petunjuk CNAME tadi.

Q: Bagaimana mencegah masalah serupa di masa depan?
A> Buat dokumen "asset dan konfigurasi jaringan" yang hidup. Setiap perubahan infrastruktur (tambah/hapus server, ganti IP, hapus service) harus diikuti dengan update dokumen dan checklist cleanup: "Hapus record DNS lama? Hapus dari firewall rule? Hapus dari backup script?" Proses yang terdokumentasi adalah tameng terbaik dari kejutan masa lalu.

The Half-Alive DNS: Diagnosing Hidden Anomalies from Mixed Roles

In the world of quiet system work, there are problems more dangerous than clear red errors: problems that work silently, making the system appear healthy but occasionally fainting for no reason. This chapter is the story of diagnosing one of them: the half-alive DNS.

The story begins with a vague user report. "Our internal web, `portal.local`, sometimes works, sometimes doesn't. Like a ghost." A classic description for intermittent network issues. I try myself. On the laptop, `ping portal.local` succeeds. Open browser, website appears. The next day, from the same computer, `ping` times out, browser shows "This site can’t be reached". An hour later, back to normal. No clear pattern. No error logs on the web server. The server itself is 100% healthy, low CPU and memory. So, the problem must be in the journey to that server.

First, I check DNS. `nslookup portal.local`. Result: one IP address. Correct, matching the server's IP. I flush the DNS cache on the laptop (`ipconfig /flushdns`). Still resolves. So, it seems our DNS server (running on Windows Server) is working fine. But why does access disappear occasionally?

I start digging deeper with `nslookup` debug mode: `nslookup -debug portal.local`. And here the first clue appears. At the end of the output, an interesting line:

"Non-authoritative answer: portal.local canonical name = proxy-server.local"

Wait. Canonical name? A CNAME? This is weird. `portal.local` should point directly to the web server IP, not to another alias. Who created this CNAME record? And why to a proxy?

I open the DNS Server console. The `local` zone looks clean. The A record for `portal` points to the correct IP. No CNAME. So where is that CNAME record coming from? I try querying other DNS servers on the network. Same result: there's a CNAME to `proxy-server.local`. Meaning, that CNAME record truly exists somewhere in our DNS system, but it's not visible in the main console.

This is the moment to go down the rabbit hole. I remember, a year ago, before migrating to the new server, we used to have a reverse proxy for load balancing. That proxy server was decommissioned long ago. But it seems, its traces haven't completely vanished. After digging through configuration archives and asking a senior, it turned out there was an active secondary DNS server whose zone was never updated post-migration. This old server still answers DNS queries, and its zone still has the old CNAME record `portal.local -> proxy-server.local`.

Now, here's the problem: mixed roles. The primary DNS server is correctly configured (pure A record). But the old secondary DNS server is still propagating the old configuration (CNAME record to a dead proxy). Since both servers are in the network's nameserver list (via DHCP), clients can randomly query either one. If they query the primary server, they get the correct IP, website opens. If they query the old server, they get a CNAME pointing to a dead proxy, website disappears. That's why the behavior is intermittent and "ghost-like".

But wait, why sometimes timeout, sometimes just slow? This is the second layer of the problem. When a client gets the CNAME, it then does another lookup for `proxy-server.local`. The A record for `proxy-server.local` still exists and points to the old proxy IP where no machine exists now. The client tries to connect to that "ghost" IP. TCP SYN timeout after 3 seconds. But, in some cases, before a full timeout, the client re-queries DNS and happens to hit the primary server, then succeeds. Result: inconsistent user experience, sometimes slow, sometimes error.

This is a perfect example of quiet system work failing silently. No alarms sound. DNS server monitoring shows status "running". Sporadic test queries might succeed if they happen to hit the primary server. The problem only appears as vague complaints from users that are hard to reproduce. And the root cause is legacy configuration that wasn't cleaned up.

The solution is not to add something. Not to create a new firewall rule or a workaround script. The solution is to clean up. 1. Permanently shut down that old secondary DNS server. It has no role other than spreading confusion. 2. Delete all zombie records related to the old proxy from all DNS zones, including the A record for `proxy-server.local`. 3. Ensure only one source of truth for DNS, and ensure all clients only point to it. After this cleanup, I asked all users to renew their DHCP lease and flush DNS cache. Within an hour, the "sometimes alive sometimes dead" reports stopped. `portal.local` now consistently responds in milliseconds.

The lesson here is profound. In system work, addition is often more appealing than subtraction. We like to add new servers, new features, new rules. But we rarely clean up old ones that are no longer useful. Old configurations are like clutter in a warehouse: not a problem until one day we need to walk through it and trip.

This problem of mixed roles (pure DNS vs proxy) also teaches the importance of clear separation of responsibilities. A server functioning as DNS should only do that. If it also functions as a proxy, its configuration becomes vulnerable to conflicts like this. Or, if there's an infrastructure change (like removing a proxy), that change must propagate to all related systems, including DNS. A robust change management process must include a "cleanup" phase as a mandatory part.

Diagnosing problems like this requires a detective mindset, not just a technician's. You must be willing to dig into system history ("there used to be a proxy"), examine evidence that seems irrelevant (CNAME in lookup), and connect seemingly separate dots. Often, the answer isn't in the latest error log, but in an architectural decision made a year ago.

Thus, a stable website is born not from great configuration complexity, but from the quiet work of cleaning up invisible chaos—a reminder that behind the screen, clarity of logic is often more important than sophistication of features.

FAQ (Casual Q&A)

Q: Why not use DNS monitoring that can alert if there are inconsistent records between servers?
A> That's a good idea, and such tools exist. But in the reality of many small-to-medium organizations, monitoring often only focuses on "is the service running?" not on "is the configuration consistent?". This is a gap in quiet work: we monitor health, but we monitor truth less.

Q> How is this problem different from DNS cache poisoning or a rogue ISP?
A> The source of the problem is different. DNS cache poisoning is an attack where the DNS cache is filled with fake records. A rogue ISP typically redirects to their own servers. Our problem is internal inconsistent configuration—not an attack or malicious intent, but administrative oversight. The symptoms are similar, but the causes and solutions are very different.

Q: If that old server is still important for redundancy, what's the solution?
A> Then it must be reconfigured as a proper secondary, with zones transferred from the primary server, not holding outdated independent configuration. Or, use technology like Active Directory Integrated Zones on Windows that ensures automatic consistency between servers.

Q> Are tools like `dig` or `nslookup` with debug options mandatory to master?
A> For deep-level network troubleshooting, absolutely. Regular `nslookup` only gives the answer, `nslookup -debug` tells you the process: which server it asked, what records it passed through, and if there were redirects like CNAME. Without that, we might never have found the CNAME clue.

Q: How to prevent similar problems in the future?
A> Create a living "network asset and configuration" document. Every infrastructure change (add/remove server, change IP, remove service) must be followed by updating the document and a cleanup checklist: "Delete old DNS records? Remove from firewall rules? Remove from backup scripts?" A documented process is the best shield against surprises from the past.