Apa Itu DNS? Panduan Pemilik Server untuk VPS

Apa itu DNS, dan mengapa domain Anda belum mengarah ke VPS

DNS (domain name system) menerjemahkan nama seperti example.com menjadi alamat IP (internet protocol) seperti 203.0.113.10. Browser tidak dapat terhubung ke nama. Browser terhubung ke alamat, sehingga setiap pemuatan halaman dimulai dengan permintaan DNS dan jawaban. Jika Anda baru membeli domain dan VPS milik Anda sendiri, tetapi tidak ada yang dimuat, salah satu dari dua hal berikut terjadi: belum ada record yang menghubungkan nama tersebut ke alamat server Anda, atau record sudah ada, tetapi sesuatu di jalur tersebut masih memberikan jawaban lama.

Kedua situasi ini normal, dan tidak berarti ada yang rusak. Bagian-bagian di bawah ini membahasnya sesuai urutan saat Anda menanganinya, dimulai dari hal yang paling sering membuang waktu: panel kontrol mana yang sebenarnya menyimpan record Anda.

Setiap pemeriksaan di sini menggunakan dig, yang tidak terpasang secara default pada mesin Ubuntu atau Debian yang baru.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameserver, dan host DNS: mana yang harus Anda edit

Ketiga istilah ini merujuk pada fungsi yang berbeda. Kesalahan dalam membedakannya merupakan alasan paling umum mengapa perubahan tidak berdampak apa pun.

• Registrar adalah perusahaan tempat Anda membeli domain. Tugas pentingnya adalah melakukan delegasi: registrar memberi tahu registry yang mengelola TLD (top-level domain, bagian .com) tentang nameserver yang berwenang untuk domain Anda.
• Nameserver otoritatif menyimpan record sebenarnya untuk zona Anda. Zona adalah domain Anda beserta nama-nama di bawahnya.
• Host DNS adalah pihak yang mengoperasikan nameserver tersebut. Pihak ini dapat berupa registrar, provider terpisah, atau bind9 yang berjalan pada server milik Anda.

Anda membeli domain melalui registrar. Anda mengedit record melalui host DNS. Jika Anda memindahkan domain ke nameserver milik provider lain, panel DNS registrar tetap menampilkan sebuah zona, tetap menyimpan perubahan Anda, dan tidak ada pihak di Internet yang pernah meminta informasi dari zona tersebut. Record itu memang ada. Namun, record tersebut tidak pernah digunakan.

Cari tahu nameserver mana yang digunakan oleh Internet:

dig example.com NS +short
dig +trace example.com

Perintah pertama menampilkan nameserver yang menjawab untuk domain tersebut saat ini. Perintah kedua menelusuri rantai mulai dari root server dan menampilkan rujukan yang diberikan server TLD. Rujukan itu adalah delegasi yang dikendalikan oleh registrar Anda. Jika nama nameserver tersebut berasal dari provider yang tidak Anda kenali, panel yang perlu Anda gunakan berada pada provider tersebut.

Bagaimana satu pencarian berjalan

Ada empat pihak yang terlibat, dan masing-masing menyimpan salinan informasi yang dipelajarinya.

1. Stub resolver pada komputer Anda. Komponen ini tidak melakukan pencarian. Komponen ini mengajukan pertanyaan kepada satu server yang dikonfigurasi dan mempercayai jawabannya. Pada Ubuntu, /etc/resolv.conf biasanya merupakan symlink ke /run/systemd/resolve/stub-resolv.conf dan mengarah ke 127.0.0.53, yaitu systemd-resolved yang berjalan secara lokal dengan cache-nya sendiri.
2. Recursive resolver. Resolver ini dijalankan oleh ISP (internet service provider) Anda, atau oleh layanan publik seperti 1.1.1.1, atau oleh Anda sendiri. Resolver ini melakukan proses pencarian jawaban.
3. Server root dan TLD. Recursive resolver meminta jawaban kepada server root. Server root tidak mengetahui alamat Anda, tetapi membalas dengan rujukan ke server .com. Server tersebut kemudian membalas dengan rujukan ke nameserver Anda.
4. Authoritative nameserver. Server ini tidak meminta jawaban kepada pihak lain. Server ini menjawab berdasarkan zone Anda dan menandai jawabannya sebagai authoritative.

dig +trace example.com memperlihatkan proses ini karena perintah tersebut memulainya langsung dari root dan mencetak setiap rujukan, bukan meminta jawaban dari cache. Ini adalah cara tercepat untuk memeriksa apakah delegation dan zone memberikan informasi yang konsisten.

Catatan DNS yang penting saat Anda menjalankan server

• A: nama ke alamat IPv4. example.com. A 203.0.113.10. Record ini mengarahkan domain Anda ke VPS.
• AAAA: nama ke alamat IPv6, seperti 2001:db8::10. Publikasikan record ini hanya jika service Anda benar-benar listen pada alamat tersebut. Klien pada jaringan IPv6 mencoba jawaban AAAA terlebih dahulu, sehingga alamat yang tidak memiliki service yang merespons akan menambah jeda pada setiap kunjungan.
• CNAME: alias dari satu nama ke nama lain. www.example.com. CNAME example.com. mengarahkan pengunjung www ke tujuan yang digunakan oleh bare domain. CNAME tidak dapat digunakan pada apex (example.com tanpa subdomain), karena apex harus memiliki record SOA (start of authority) dan NS sendiri, sedangkan CNAME tidak boleh menggunakan nama yang sama dengan record lain. Provider menyediakan solusi alternatif dengan nama seperti ALIAS, ANAME, atau CNAME flattening.
• MX: tempat pengiriman mail untuk domain. Record ini berisi hostname dan angka preferensi. Angka yang lebih rendah dicoba lebih dahulu. MX harus mengarah ke nama yang memiliki address record. Mengarahkannya ke CNAME tidak valid, dan beberapa server pengirim akan menolaknya.
• TXT: teks bebas yang digunakan untuk verifikasi dan kebijakan. Record autentikasi mail (SPF, DKIM, DMARC) berada di sini, begitu juga token ACME (automatic certificate management environment) yang menerbitkan sertifikat wildcard.
• NS: nameserver yang melayani zone. Salinan yang menentukan tempat dunia meminta informasi DNS berada di parent zone dan berasal dari delegation registrar Anda, bukan dari salinan di dalam zone Anda sendiri.

Dua detail menyebabkan lebih banyak kebingungan daripada jenis record itu sendiri. Nama yang diakhiri titik bersifat absolut. Jadi, www.example.com. berarti nama tersebut secara persis dan tidak lebih. Sebagian besar panel mengharapkan nama relatif lalu menambahkan domain untuk Anda. Jadi, memasukkan www.example.com pada kotak nama akan menghasilkan www.example.com.example.com, yang tidak dapat di-resolve oleh siapa pun. Detail lainnya adalah @, yang pada hampir semua panel berarti apex: domain itu sendiri tanpa subdomain.

Arahkan record A ke VPS Anda

Pertama, dapatkan alamat yang terlihat oleh Internet untuk server Anda:

curl -4 https://ifconfig.me
ip -brief -4 address show

Kemudian, buat satu record di penyedia DNS Anda: jenis A, nama @, nilai berupa alamat tersebut, TTL (time to live) 300. Tambahkan record kedua untuk www, berupa A lain dengan alamat yang sama atau CNAME yang mengarah ke apex.

Kemudian, pastikan record tersebut ter-resolve. Sebaiknya lakukan dari laptop, bukan dari server itu sendiri:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Perintah pertama menggunakan jalur normal mesin Anda, termasuk cache. Perintah kedua melewati cache lokal dan meminta jawaban dari recursive resolver publik. Perintah ketiga menanyakan langsung kepada authoritative nameserver Anda. Dengan demikian, jawabannya merupakan kondisi terkini tanpa cache di sepanjang jalur. Jika perintah ketiga mengembalikan alamat Anda, sedangkan perintah pertama tidak, konfigurasi DNS Anda sudah benar dan Anda hanya perlu menunggu salinan jawaban lama yang tersimpan di cache kedaluwarsa.

Resolving tidak memuat

Resolusi nama membuktikan bahwa DNS berfungsi. Namun, resolusi nama tidak membuktikan apa pun tentang web server Anda. Setelah dig mengembalikan alamat yang benar, uji koneksi:

curl -I http://example.com

curl: (6) Could not resolve host: example.com adalah masalah DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused bukan masalah DNS: nama berhasil di-resolve dan paket telah tiba, sehingga masalahnya adalah tidak ada proses yang listening pada port tersebut. Permintaan yang menunggu lalu mengalami timeout biasanya berarti firewall menjatuhkan paket secara diam-diam, bukan menolaknya. Pada tahap ini, DNS tidak lagi menjadi masalah utama, dan port serta socket yang listening serta aturan firewall ufw pada VPS Anda mulai berperan. Setelah koneksi selesai, proses pemuatan halaman lainnya adalah HTTP yang menjalankan tugasnya.

Mengapa browser masih menampilkan host lama

Tidak ada proses propagasi. Tidak ada server yang mengirim perubahan Anda ke pihak lain. Nameserver otoritatif menyimpan nilai baru segera setelah Anda menyimpannya, dan setiap salinan jawaban sebelumnya yang tersimpan di cache tetap berlaku sampai penghitung waktunya sendiri berakhir. Penghitung waktu tersebut adalah TTL, dalam detik, yang dibawa record saat diberikan.

Salinan dapat berada di lebih banyak tempat daripada yang diperkirakan: cache singkat milik browser, stub resolver pada mesin, recursive resolver yang digunakan jaringan tersebut, dan resolver apa pun yang dipasang VPN pada client. Masing-masing menyimpan salinannya hingga TTL yang diterimanya berakhir. Dua orang pada dua jaringan dapat melihat jawaban yang berbeda selama berjam-jam, dan kedua mesin tersebut tetap berfungsi dengan benar.

Pantau hitung mundur pada caching resolver:

dig @1.1.1.1 example.com +noall +answer

Jalankan dua kali dengan jeda beberapa detik. TTL pada jawaban akan berkurang. Saat mencapai nol, resolver membuang record tersebut dan kembali meminta jawabannya kepada nameserver Anda.

Ada cache kedua yang hampir tidak pernah diperhitungkan: jawaban negatif. Saat resolver diberi tahu bahwa suatu nama tidak ada, resolver juga menyimpan NXDOMAIN tersebut selama durasi yang ditetapkan oleh field terakhir pada record SOA zone Anda.

dig example.com SOA +short

Angka terakhir pada baris tersebut adalah negative TTL, biasanya 3600. Jadi, jika Anda mencari staging.example.com sebelum membuatnya, record tersebut dapat tetap tersembunyi selama satu jam penuh setelah dibuat. Buat record terlebih dahulu, lalu lakukan query.

Mengubah nameserver lebih lambat daripada mengubah record karena alasan mekanis. Record delegasi pada zone .com disajikan dengan TTL 172800 detik, yaitu dua hari. Karena itu, resolver yang menyimpan nameserver lama dalam cache dapat terus menggunakannya selama durasi tersebut. Inilah asal anjuran untuk “menunggu hingga 48 jam”. Anjuran itu berlaku untuk perubahan nameserver, bukan untuk perubahan record biasa.

Rencanakan migrasi berdasarkan TTL, bukan dengan berusaha mengabaikannya:

1. Turunkan TTL record menjadi 300, lalu simpan.
2. Tunggu lebih lama daripada TTL lama agar setiap salinan yang menyimpan nilai lama di cache telah kedaluwarsa.
3. Ubah alamatnya.
4. Setelah trafik berpindah, naikkan kembali TTL menjadi 3600 atau lebih tinggi karena TTL rendah membuat setiap resolver lebih sering meminta jawaban kepada nameserver Anda.

Untuk menghapus data yang disimpan oleh mesin Anda sendiri:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics menampilkan bagian cache dengan penghitung hit dan miss. Karena itu, tepat setelah proses flush, pencarian berikutnya akan tercatat sebagai miss. Browser menyimpan cache terpisah. Artinya, Chrome masih dapat menggunakan jawaban lama setelah cache sistem dikosongkan. Hapus cache tersebut di chrome://net-internals/#dns. Periksa juga /etc/hosts karena baris yang tersisa di sana akan mengesampingkan DNS pada mesin tersebut, dan hanya pada mesin tersebut. getent hosts example.com menampilkan jawaban yang benar-benar akan digunakan sistem, termasuk /etc/hosts.

Sertifikat wildcard dibuktikan dengan record TXT

CA (certificate authority) memeriksa kendali atas sebuah nama sebelum menerbitkan sertifikat. Challenge HTTP-01 menyajikan file melalui port 80 pada hostname tersebut, sehingga cocok untuk satu nama. Sertifikat wildcard mencakup *.example.com, yaitu kumpulan hostname terbuka yang tidak dapat diambil filenya oleh CA. Karena itu, Let's Encrypt hanya menerbitkan wildcard melalui challenge DNS-01. Anda menerbitkan record TXT pada _acme-challenge.example.com yang berisi token dari CA. Kendali atas zone menjadi buktinya.

Dengan demikian, host DNS Anda menjadi bagian dari proses pembaruan sertifikat. Certbot harus membuat dan menghapus record TXT tersebut pada setiap pembaruan tanpa campur tangan Anda. Karena itu, Certbot memerlukan API dan plugin yang sesuai untuk provider Anda. Jika validasi gagal, pesan yang biasanya muncul adalah DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Artinya, CA melakukan pemeriksaan sebelum record tersebut terlihat. Record mungkin belum pernah disimpan, atau jawaban negatif masih tersimpan dalam cache. Prosedur lengkap tersedia dalam panduan sertifikat wildcard dengan challenge DNS-01.

Ketika VPN mengambil alih resolver Anda

Klien VPN (virtual private network) biasanya mengganti resolver sistem selama koneksi aktif karena mengirimkan pencarian nama ke jaringan lokal akan memberi tahu jaringan tersebut nama setiap situs yang Anda kunjungi. Ini adalah perilaku yang benar, tetapi dapat gagal dalam dua kondisi.

Jika tunnel aktif dan resolusi nama berhenti, sementara alamat masih dapat diakses, resolver yang dipasang klien tidak dapat dijangkau dari dalam tunnel. ping 1.1.1.1 berhasil, sedangkan curl https://example.com mengembalikan curl: (6) Could not resolve host: example.com. Jika tunnel aktif tetapi pencarian nama tetap dikirim ke jaringan tempat Anda terhubung, trafik Anda melewati tunnel, sementara resolver lokal tetap melihat setiap nama yang Anda minta.

resolvectl status

Perintah tersebut menampilkan resolver yang digunakan untuk setiap link. Dengan demikian, Anda dapat melihat resolver yang dipasang tunnel dan memastikan apakah resolver tersebut sesuai dengan yang Anda inginkan. Tunnel WireGuard menetapkan resolver ini dari baris DNS = dalam konfigurasi klien. Panduan memperbaiki DNS ketika WireGuard mengambil alih resolver membahas kasus systemd-resolved dan resolvconf secara lebih rinci.

Kode respons dan informasi yang ditunjukkan masing-masing

• NXDOMAIN: server otoritatif menyatakan bahwa nama tersebut tidak ada. Periksa ejaannya, periksa apakah akhiran domain tercantum dua kali, dan pastikan Anda mengedit zona yang menjadi tujuan delegasi.
• NOERROR dengan ANSWER SECTION kosong: nama tersebut ada, tetapi tidak memiliki record dengan tipe yang diminta. Meminta AAAA ketika hanya ada A menghasilkan kondisi ini.
• SERVFAIL: resolver mencoba menjawab, tetapi tidak dapat menghasilkan jawaban. Dua penyebab yang paling umum adalah server otoritatif tidak pernah merespons dan validasi DNSSEC (domain name system security extensions) gagal. Uji dengan dig @1.1.1.1 example.com A +cd, yang menonaktifkan validasi. Jika tanpa opsi tersebut terdapat jawaban dengan +cd dan SERVFAIL, berarti masalahnya ada pada signature. Hal ini dapat terjadi setelah pemindahan nameserver ketika parent masih memublikasikan record DS (delegation signer) lama.
• REFUSED: server yang Anda tanyai tidak akan menjawab pertanyaan tersebut. Biasanya, hal ini terjadi karena Anda mengarahkan dig ke server otoritatif untuk domain yang tidak dilayaninya.
• ;; connection timed out; no servers could be reached: dig tidak pernah mencapai resolver. Ini merupakan masalah jaringan atau resolver di sisi Anda, sehingga domain bukan sumber masalahnya.

ping: example.com: Temporary failure in name resolution adalah kelas kegagalan yang sama, tetapi dilaporkan oleh glibc, bukan oleh dig.

Haruskah Anda menjalankan nameserver pada VPS sendiri?

Anda bisa melakukannya. bind9, knot, atau nsd akan melayani zone Anda dari server tersebut, dan Anda akan mempelajari DNS lebih banyak daripada melalui panel apa pun. Keberatannya bersifat praktis. Sebuah domain sebaiknya memiliki setidaknya dua nameserver pada jaringan yang terpisah. Dengan demikian, satu VPS tidak menjadi satu titik kegagalan bagi semua service pada domain tersebut, termasuk email. Nameserver yang namanya berada di dalam domain yang dilayaninya memerlukan glue record pada registrar. Glue record tersebut berisi alamat ns1.example.com yang disimpan di parent zone, karena tanpa informasi itu proses lookup tidak memiliki titik awal. Jika resolver tidak dapat menjangkau nameserver Anda, resolver tidak akan beralih ke website Anda. Seluruh domain tidak dapat diakses oleh pengguna tersebut. Hosted DNS dengan API merupakan pilihan berisiko lebih rendah bagi kebanyakan orang. Menjalankan caching resolver pada VPS untuk mesin Anda sendiri merupakan pekerjaan yang berbeda dan komitmen yang jauh lebih kecil.

FAQ

Mengapa perubahan DNS saya belum terpropagasi?

Tidak ada proses propagasi. Nameserver otoritatif menyimpan nilai baru segera setelah Anda menyimpannya, sedangkan setiap resolver yang sudah melakukan permintaan tetap menyimpan salinan dalam cache sampai TTL yang diterimanya berakhir. Tanyakan langsung kepada server otoritatif dengan dig @ns1.your-dns-host.net example.com A +short. Jika hasilnya menunjukkan alamat baru, perubahan tersebut sudah aktif dan yang tersisa hanyalah masalah cache. Jika Anda mengubah nameserver, bukan record, prosesnya dapat memerlukan waktu jauh lebih lama karena delegasi TLD diberikan dengan TTL dua hari.

Bagaimana cara mengetahui nameserver yang sebenarnya digunakan domain saya?

dig example.com NS +short menampilkan nameserver yang saat ini memberikan jawaban untuk domain tersebut, sedangkan dig +trace example.com menampilkan rantai rujukan dari root, termasuk delegasi yang diberikan oleh server TLD. Jika nama tersebut bukan provider yang panelnya sedang Anda gunakan untuk melakukan perubahan, itulah penyebab masalahnya. Edit record pada provider yang tercantum dalam delegasi, atau ubah delegasi pada registrar agar mengarah ke lokasi yang Anda inginkan.

Domain saya berhasil di-resolve, tetapi situs masih tidak dapat dimuat. Apa yang harus dilakukan?

DNS selesai ketika dig example.com A +short mengembalikan alamat server Anda. Setelah itu, masalahnya berada pada koneksi. Jika curl -I http://example.com mengembalikan Connection refused, berarti tidak ada proses yang listening pada port tersebut. Permintaan yang terus menunggu hingga timeout berarti paket dijatuhkan oleh firewall. Pastikan web server berjalan dan terikat pada alamat publik, lalu periksa firewall pada server serta firewall jaringan terpisah pada panel kontrol provider Anda.

Mengapa saya tidak dapat memasang CNAME pada root domain?

CNAME menyatakan bahwa sebuah nama merupakan alias untuk nama lain. Nama yang memiliki CNAME tidak boleh memiliki record lain. Root domain Anda harus memiliki record SOA dan NS agar dapat berfungsi sebagai zone, sehingga root domain tidak dapat sekaligus menjadi CNAME. Gunakan record A yang menyimpan alamat pada root, atau gunakan fitur provider yang dipasarkan sebagai ALIAS, ANAME, atau CNAME flattening. Fitur tersebut menyimpan sebuah nama dan menjawab query dengan alamat yang saat ini di-resolve oleh nama tersebut.