Blog

DNS Router yang Salah Arah — Saat Domain VPS 1 Tiba-tiba Menampilkan Konten VPS 2, kok bisa?

Ditulis oleh Adam Muiz 4 menit baca

Cerita ini disamarkan cuma sebagai pembelajaran - Beberapa waktu lalu aku mengalami kejadian aneh. Aku mengakses domain vps1.domain.com — yang seharusnya menampilkan halaman utama dari VPS pertama — tapi yang muncul adalah konten dari apk.domain.com, yang sebenarnya berada di VPS yang berbeda. Bukan konten yang sama, benar-benar aplikasi yang berbeda. Aku refresh berkali-kali, tetap sama. Aku coba dari perangkat lain, tetap saja.

Ini membingungkan. Aku tidak pernah menyetting apapun yang membuat kedua domain ini saling terkait. Tidak ada redirect, tidak ada proxy pass, tidak ada alias di server block. Lalu kenapa vps1.domain.com menampilkan isi dari apk.domain.com?

Pertama yang Aku Periksa: Server Block Nginx

Aku langsung login ke VPS1 — server tempat vps1.domain.com seharusnya di-hosting. Aku cek konfigurasi nginx di /etc/nginx/sites-enabled/. Ada file untuk vps1.domain.com, lengkap dengan server_name yang benar, root directory yang sesuai, dan tidak ada redirect aneh. Aku coba nginx -t, semua OK. Aku restart nginx, tetap saja.

Lalu aku cek IP binding. Mungkin aplikasi di VPS1 bind ke IP tertentu? Aku cek netstat -tlnp, port 80 dan 443 terikat ke 0.0.0.0 — normal. Tidak ada yang salah.

Aku benar-benar buntu. Semua konfigurasi di VPS1 terlihat sempurna. Tapi kenapa vps1.domain.com tetap menampilkan konten dari server lain?

Momen "Oh Ternyata" — Cek DNS

Setelah berjam-jam frustrasi, aku iseng mencoba dig vps1.domain.com dari terminal lokal. Dan di situlah jawabannya:

;; ANSWER SECTION:
vps1.domain.com. 300 IN A 203.0.113.2

IP 203.0.113.2 itu bukan IP VPS1 — itu IP VPS2, tempat apk.domain.com di-host. DNS di lingkungan ini dikelola oleh router, dan sesorang (bukan aku, mungkin kucingku btw ingat cerita ini disamarkan cuma sebagai pembelajaran) telah mengatur DNS router untuk mengarahkan domain vps1.domain.com ke IP VPS2, bukan VPS1.

Jadi sebenarnya VPS1 tidak pernah menerima request satupun. Semua traffic untuk vps1.domain.com langsung menuju VPS2. Dan di VPS2, nginx tidak memiliki server block untuk vps1.domain.com, sehingga default_server-lah yang melayani — dan kebetulan server block pertama (secara urutan abjad) adalah apk.domain.com.

Mengapa Nginx Menampilkan Konten Server Block Lain?

Ini perilaku standar nginx: ketika sebuah request masuk dan Host header tidak cocok dengan server_name manapun, nginx akan fallback ke default_server. Jika tidak ada default_server yang eksplisit, nginx menggunakan server block pertama yang ditemukan (secara alfabet di sites-enabled/).

Jadi apk.domain.com mungkin adalah file pertama secara urutan abjad, atau yang pertama di-load. Semua request tanpa server_name yang cocok — termasuk vps1.domain.com — akan diarahkan ke sana.

Misteri Kedua: Redirect ke apk.domain.com

Yang lebih membingungkan, kadang vps1.domain.com tidak hanya menampilkan konten apk, tapi langsung redirect ke apk.domain.com di browser. Padahal tidak ada konfigurasi redirect di nginx manapun. Kenapa?

Jawabannya ada di aplikasi. Aplikasi di server block default (apk.domain.com) kemungkinan besar memiliki fitur canonical domain — yaitu aplikasi mendeteksi domain mana yang digunakan untuk mengaksesnya, lalu redirect ke domain utama aplikasi tersebut. Banyak CMS dan framework modern melakukan ini. Jadi meskipun nginx tidak redirect, aplikasi di dalamnya yang melakukannya.

Jadi urutannya:

  1. DNS router mengarahkan vps1.domain.com → IP VPS2
  2. Nginx di VPS2 tidak punya server_name untuk vps1, fallback ke default_server (apk.domain.com)
  3. Aplikasi apk mendeteksi hostname tidak sesuai, redirect ke domain kanonikalnya: apk.domain.com
Root cause sebenarnya bukan salah konfigurasi server, tapi salah setting DNS di router. Selama bertahun-tahun aku selalu curiga ke server block, IP binding, atau konfigurasi aplikasi — padahal dari awal traffic-nya saja sudah salah arah.

Pelajaran: Kenapa di Home Server Lebih Mudah?

Di rumah aku punya server lokal dengan dnsmasq yang mengatur semua DNS internal. Kalau masalah seperti ini terjadi, aku tinggal:

  1. Cek /etc/dnsmasq.d/local-domains.conf — lihat semua override DNS dalam satu file
  2. Cek /etc/hosts — lihat mapping manual
  3. Cek router DHCP — lihat DNS server mana yang diberikan ke klien

Semua lapisan DNS bisa diperiksa dalam hitungan menit. Di lingkungan kantor dengan router bersama dan banyak orang yang punya akses ke setting DNS, tracing seperti ini jauh lebih sulit karena kamu tidak tahu siapa yang mengubah apa dan kapan.

Satu hal yang aku pelajari: sebelum menyentuh konfigurasi server, cek DNS dulu. dig dan nslookup adalah sahabat terbaik debugger. Kalau IP tujuan sudah salah dari awal, apapun yang kamu ubah di server tidak akan pernah menyelesaikan masalah.

Kesimpulan

Insiden ini mengingatkan aku bahwa infrastruktur jaringan itu berlapis. Kadang kita terlalu fokus pada layer aplikasi dan server, padahal masalahnya ada di layer DNS yang jauh di bawah. DNS di router punya kekuatan besar — dia bisa mengarahkan lalu lintas ke server manapun tanpa menyentuh satu baris konfigurasi server pun.

Jadi kalau suatu saat kamu mengakses sebuah domain dan isinya tidak sesuai ekspektasi, jangan langsung curiga ke server block. Cek DNS dulu.