Server Lemot? Coba Cek DNS Resolver

Sumber: Gambar 1

Banyak pengguna server menganggap DNS resolver hanya bertugas menerjemahkan nama domain menjadi alamat IP. Padahal di dunia server Linux, DNS resolver adalah salah satu komponen paling penting yang sangat mempengaruhi performa dan stabilitas sistem. Mulai dari update sistem yang stuck, API yang timeout, sampai perintah curl yang lambat, bisa jadi akibat dariDNS resolver.

Saya mengalami masalah DNS beberapa kali, namun sering baru disadari setelah beberapa service tidak berjalan. Padahal, akar persoalannya bisa sesederhana salah konfigurasi di satu file kecil bernama /etc/resolv.conf

Bagaimana DNS Resolver Bekerja di Server Linux?

Setiap kali server mengakses domain, misalnya saat menjalankan apt update, yum update, atau melakukan request ke API eksternal, langkah pertama yang terjadi adalah proses DNS resolving. Server akan bertanya: “Domain ini IP-nya apa?”

Jawaban dari pertanyaan itu sepenuhnya bergantung pada DNS resolver yang dikonfigurasi di /etc/resolv.conf. Jika resolver lambat, tidak responsif, atau salah alamat, maka semua layanan yang bergantung pada domain akan ikut tersendat.

Inilah alasan kenapa koneksi internet terlihat “normal”, tapi server tetap terasa lemot.

Update Server Gagal Bukan Karena Internet

Dari pengalaman saya, server bisa ping ke IP publik, tapi apt update atau yum update macet dan loading lama lalu timeout. Setelah ditelusuri, bukan internet yang bermasalah, melainkan DNS resolver mengarah ke server DNS yang sering down.

Proses update sebenarnya menunggu DNS resolve, bukan download paket. Begitu DNS bermasalah, semua proses ikut berhenti.

Peran DNS Resolver dalam Operasi Penting Server

DNS resolver bukan hanya soal browsing. Hampir semua aktivitas server modern bergantung pada DNS:

  • Update sistem → repository berbasis domain

  • Akses API eksternal → REST API, webhook, integrasi aplikasi

  • CLI tools → curl, wget, git, docker pull

  • Mail server → MX record, LDAP, relay SMTP

Satu resolver bermasalah bisa membuat seluruh ekosistem server ikut “tersedak”.

Stub Resolver vs Caching Resolver

Secara default, Linux menggunakan stub resolver, yaitu resolver sederhana yang hanya meneruskan query ke DNS eksternal yang ditulis di /etc/resolv.conf.

Namun untuk server yang sering melakukan query DNS berulang, pendekatan ini tidak ideal.

Caching Resolver

Caching resolver seperti Unbound atau Bind9 menyimpan hasil query DNS sementara. Hasilnya:

  • Resolve lebih cepat

  • Hemat bandwidth

  • Lebih tahan jika DNS upstream bermasalah

/etc/resolv.conf

Jika ada satu file yang sering bikin admin frustrasi, itu adalah /etc/resolv.conf.

File ini biasanya berisi:

  • nameserver → alamat DNS server

  • search → domain pencarian

  • options → timeout, retry, dan parameter lain

Masalahnya, file ini sering diubah otomatis oleh sistem.

Kenapa resolv.conf Sering Berubah Sendiri?

Tanpa disadari, beberapa service bisa menimpa /etc/resolv.conf:

  • DHCP Client → DNS dari DHCP server

  • NetworkManager → saat koneksi berubah

  • systemd-resolved → membuat resolv.conf sebagai symlink dinamis

Akibatnya, edit manual sering “hilang” setelah reboot atau restart network.

Mengamankan Konfigurasi DNS agar Tidak Berubah

Jika server menggunakan IP statis dan butuh DNS tetap, pendekatan paling aman adalah:

  1. Cek apakah resolv.conf adalah symlink

  2. Gunakan DNS yang andal

  3. Kunci file agar tidak dioverwrite

Contoh DNS publik yang umum digunakan:

  • Cloudflare: 1.1.1.1

  • Google DNS: 8.8.8.8

Urutan juga penting, karen server akan mencoba resolver pertama, baru ke berikutnya jika gagal.

Cloudflare vs Google DNS: Mana Lebih Cocok?

Tidak ada jawaban mutlak, tapi ada pertimbangan umum:

Cloudflare (1.1.1.1)

  • Latency rendah

  • Fokus privasi

  • Sangat cepat di banyak wilayah Asia

Google DNS (8.8.8.8)

  • Infrastruktur sangat stabil

  • Global coverage luas

  • Cocok untuk fallback

Praktik terbaik adalah menggunakan keduanya untuk redundancy.

Keamanan DNS: Jangan Fokus ke Cepat Saja

DNS juga sering jadi target serangan:

  • DNS spoofing

  • Amplification attack

  • Abuse resolver publik

Langkah dasar pengamanan:

  • Aktifkan DNSSEC

  • Batasi akses port 53 (TCP/UDP)

  • Jangan biarkan resolver terbuka ke publik

  • Aktifkan logging

Banyak server bermasalah bukan karena CPU atau RAM, tapi karena resolver disalahgunakan.

Troubleshooting DNS dengan Dig dan Nslookup 

Saat server bermasalah, jangan langsung curiga ke aplikasi. Mulai dari DNS.

Perintah wajib:

  • dig domainmu.com

  • nslookup domainmu.com

  • systemd-resolve --status

Error seperti NXDOMAIN atau timeout hampir selalu mengarah ke DNS.

Kesimpulan

DNS resolver sering dianggap remeh karena “kelihatannya kecil”. Padahal, satu kesalahan di resolver bisa membuat seluruh layanan server lumpuh.

Memahami cara kerja DNS resolver, mengamankan /etc/resolv.conf, memilih nameserver yang tepat, dan menggunakan caching resolver adalah investasi kecil dengan dampak besar terhadap stabilitas server.

Jika server terasa lambat, update sering gagal, atau API timeout tanpa alasan jelas, cek DNS dulu. Bisa jadi disitu letak permasalahannya.

Comments

Post a Comment

Popular posts from this blog

Belajar Zimbra Mail Server

Image
Di era komunikasi digital, email masih menjadi sangat penting untuk komunikasi formal di organisasi. Salah satu solusi email server yang banyak digunakan di lingkungan enterprise dan institusi adalah Zimbra Mail Server. Pada tulisan ini, saya akan membagikan panduan belajar Zimbra Mail Server secara bertahap, ditujukan untuk pemula, peserta magang, maupun sysadmin yang ingin memperdalam pengelolaan email server. Mengenal Cara Kerja Email Server Sebelum mengenalkan apa itu zimbra, penting memahami bagaimana email bekerja. Secara umum, pengiriman email melibatkan beberapa komponen utama seperti SMTP untuk mengirim email, POP3/IMAP untuk mengambil email, serta peran Mail Transfer Agent (MTA), Mail Delivery Agent (MDA), dan Mail User Agent (MUA). Email server juga sangat bergantung pada konfigurasi DNS, seperti record MX, A, PTR, SPF, DKIM, dan DMARC (bisa coba dalami tentang ini). Kesalahan kecil pada DNS kadang menjadi penyebab utama email gagal terkirim atau masuk ke folder spam. La...
Read more

Mendalami tentang Linux (Sejarah dan Pelopor)

Image
Ringkasan Sejarah Linux Linux adalah sistem operasi komputer sumber terbuka yang awalnya dikembangkan untuk dan pada komputer pribadi berbasis Intel x86. Sistem ini kemudian diporting ke daftar platform hardware yang sangat panjang, mulai dari perangkat tertanam berukuran kecil hingga superkomputer terbesar di dunia. Pada bagian ini, kita akan mengikuti sejarah yang mengejutkan tentang bagaimana Linux berkembang dari proyek seorang mahasiswa perguruan tinggi Finlandia menjadi upaya besar yang memiliki dampak besar pada dunia saat ini. Linus Torvalds adalah seorang mahasiswa di Helsinki, Finlandia, pada tahun 1991, ketika ia memulai sebuah proyek: menulis kernel sistem operasi miliknya sendiri. Ia juga mengumpulkan dan/atau mengembangkan komponen-komponen esensial lainnya yang diperlukan untuk membangun sistem operasi lengkap dengan kernelnya sebagai inti. Tidak lama kemudian, ini dikenal sebagai kernel Linux. Pada tahun 1992, Linux dilisensikan ulang menggunakan General Public Licens...
Read more