Domain dan Mengarahkan DNS: Menyambungkan Nama Asli ke Server-mu

Bagian tersulit sudah kelar. Kode sudah ada di server, prosesnya jalan, dan kalau kamu tempel alamat IP mentah server-nya ke browser, situsmu langsung muncul. Tinggal satu masalah: tidak akan ada orang yang mengetik 203.0.113.45 cuma buat berkunjung. Mereka maunya sebuah nama — sesuatu seperti acypartner.example. Langkah yang menjembatani dua dunia itu disebut mengarahkan DNS, dan langkah inilah yang paling sering bikin orang yang baru pertama kali deploy kelimpungan, biasanya gara-gara hal-hal kecil yang sebenarnya gampang dibetulin.

Artikel ini adalah sisi praktik dari urusan domain. Kita tidak akan menjelaskan lagi DNS itu apa dari nol — sudah ada artikel khusus untuk itu, ada tautannya di bawah. Di sini kita fokus ke pekerjaan sebenarnya: kamu sudah punya server yang ter-deploy, kamu punya (atau sebentar lagi punya) domain, dan kamu perlu menyambungkan keduanya supaya pengunjung sampai ke aplikasimu lewat nama.

Mengarahkan domain itu sebenarnya apa

Tanpa istilah ribet, mengarahkan domain itu satu ide saja: kamu memberi tahu buku alamat sedunia bahwa namamu harus menunjuk ke alamat server-mu. Saat seseorang mengetik domain-mu, komputer mereka bertanya “IP untuk nama ini apa?”, dan kamu mau jawaban yang kembali adalah server milikmu.

Tidak ada bagian dari permintaan itu yang benar-benar lewat domain-nya. Domain cuma jadi kunci pencarian. Browser memakainya untuk menemukan IP, lalu langsung ngobrol ke IP itu. Jadi “mengarahkan domain ke server” sebenarnya berarti “menerbitkan record yang memetakan nama ke alamat IP server.” Kalau kamu mau tahu mekanisme di baliknya — bagaimana pencarian itu menjalar lewat internet — DNS mendalam membahasnya langkah demi langkah, dan artikel dasar domain dan DNS mengupas konsepnya. Di sini kita tetap fokus mengerjakannya.

  pengunjung ketik       lookup DNS            browser pengunjung
  "acypartner.example"  ───────────►  203.0.113.45  ───────────►  SERVER-MU
       (sebuah nama)    (kamu terbitkan   (sebuah IP)   (ngobrol ke IP-nya)
                         pemetaan ini)

Hal-hal yang perlu kamu siapkan dulu

Ada tiga hal yang harus beres sebelum mengarahkan domain jadi masuk akal:

Server yang jalan dengan IP publik. Aplikasimu harus benar-benar bisa dijangkau dari luar lewat sebuah alamat. Kalau memuat situsmu lewat IP saja belum bisa, beresin itu dulu — DNS tidak bisa memunculkan koneksi yang memang belum ada. (Untuk gambaran besar memindahkan kode ke server sejak awal, lihat apa itu deployment.)
Domain yang sudah terdaftar. Ini kamu beli dari registrar domain — perusahaan yang punya izin menjual nama. Pendaftaran itu sifatnya sewa tahunan, bukan beli sekali putus; kalau telat perpanjang, namanya balik ke pasaran.
Akses ke pengaturan DNS domain-nya. Di sinilah record-nya tinggal. Bisa jadi di registrar-mu, atau di penyedia DNS terpisah yang sudah kamu serahi domain itu. Yang jelas, kamu perlu login di tempat yang memang mengizinkanmu mengedit record.

Registrar dan tempat hosting DNS tidak selalu sama

Banyak orang mengira tempat dia beli domain otomatis jadi tempat dia mengedit DNS. Sering memang begitu — tapi tidak selalu. Kamu bisa beli domain di satu tempat lalu menghosting DNS-nya di tempat lain dengan mengganti nameserver domain itu. Kalau record-mu seakan tidak berefek apa pun apa pun yang kamu lakukan, cek ulang penyedia mana yang sebetulnya berwenang atas domain itu. Bisa jadi kamu sedang mengedit record di panel yang internet bahkan tidak mendengarkannya.

Record yang benar-benar mengarahkan domain

DNS punya banyak jenis record, tapi untuk urusan sehari-hari menaikkan website ke internet, cuma segelintir yang mengerjakan hampir semuanya. Kamu tidak perlu menghafal seluruh kebun binatangnya — cukup yang ini.

Record A — nama ke IPv4

Record A adalah tulang punggungnya. Dia memetakan sebuah nama langsung ke alamat IPv4. Record inilah yang membuat domain polos menunjuk ke server-mu.

Tipe   Nama (host)   Nilai          TTL
A      @             203.0.113.45   3600

@ itu singkatan dari apex domain-mu — namanya yang polos, acypartner.example tanpa apa-apa di depannya. (Sebagian panel minta kamu mengosongkan kolom nama, bukan mengetik @; maksudnya sama saja.) Nilainya adalah IPv4 publik server-mu. Kalau kamu belum begitu paham alamat IPv4 itu apa, artikel alamat IP dan port membahasnya.

Record AAAA — nama ke IPv6

Record AAAA melakukan persis seperti record A, tapi untuk alamat IPv6. Kalau server-mu punya alamat IPv6 (banyak host modern punya), tambahkan ini berdampingan dengan record A supaya pengunjung yang IPv6-nya aktif sampai ke kamu lewat jalur yang lebih cepat.

Tipe   Nama   Nilai                                    TTL
AAAA   @      2001:db8::45                             3600

Kamu tidak wajib menambahkan AAAA — record A saja sudah cukup untuk bisa dijangkau — tapi kalau server-mu punya IPv6, menerbitkannya itu praktik yang baik.

Record CNAME — nama ke nama lain

Sebuah CNAME menunjuk satu nama ke nama lain, bukan ke IP. Pemakaian klasiknya adalah subdomain www: kamu menjadikan www sebagai alias dari apex supaya kedua ejaan itu mendarat di tempat yang sama.

Tipe    Nama   Nilai                  TTL
CNAME   www    acypartner.example      3600

Sekarang www.acypartner.example mengikuti ke mana pun apex menunjuk. Aturan besar yang harus diingat: kamu tidak bisa memasang CNAME di apex itu sendiri. Domain polos harus berupa record A (dan/atau AAAA), tidak pernah CNAME, karena memang begitu spesifikasi DNS dirancang. Sebagian penyedia menawarkan jalan pintas yang mereka sebut “CNAME flattening” atau record “ALIAS” untuk apex — berguna kalau sebuah platform memberimu hostname alih-alih IP — tapi DNS biasa tidak akan membiarkanmu mem-CNAME apex secara langsung.

Pilih satu ejaan kanonis, redirect yang lainnya

Kamu tidak mau acypartner.example dan www.acypartner.example terasa seperti dua situs berbeda. Pastikan DNS membuat keduanya menunjuk ke server-mu, lalu tentukan pilihannya di server: pilih satu sebagai kanonis dan suruh server me-redirect yang satu lagi ke situ. Dengan begitu pengunjung dan mesin pencari sama-sama menetap di satu alamat, yang lebih rapi untuk SEO maupun untuk cookie.

Pemain pendukung

Kamu akan ketemu beberapa jenis record lain bahkan di situs sederhana:

MX — mail exchange. Cuma relevan kalau kamu mau punya email di domain-mu. Mengarahkan record A website ke server tidak otomatis menyiapkan email; itu urusan terpisah dengan record MX sendiri, sering kali di penyedia yang berbeda.
TXT — teks bebas. Sering dipakai untuk verifikasi (membuktikan ke suatu layanan bahwa kamu pemilik domain) dan untuk record anti-pemalsuan email seperti SPF dan DKIM.
NS — record nameserver. Ini menyatakan server mana yang berwenang atas domain-mu. Ubah ini dan kamu sudah memindahkan seluruh hosting DNS-mu ke tempat lain — tuas yang jauh lebih besar daripada mengedit record satu per satu.

Menelusuri satu kasus nyata: arahkan lalu deploy

Biar nyata. Jane Doe di ACY Partner Indonesia sudah men-deploy sebuah aplikasi ke server di 203.0.113.45 dan memiliki domain acypartner.example. Ini urutan lengkapnya.

1. Pastikan server merespons lewat IP. Sebelum menyentuh DNS, dia membuka http://203.0.113.45 di browser dan melihat aplikasinya muncul. Kalau itu gagal, DNS cuma jadi pengalih perhatian — masalahnya ada di server, firewall, atau aplikasi yang belum mendengarkan. (Firewall yang memblokir sebuah port itu biang kerok klasik; port menentukan pintu mana yang terbuka.)

2. Buka panel DNS domain-nya. Dia login ke penyedia mana pun yang berwenang atas acypartner.example dan mencari editor DNS / zone-nya.

3. Tambahkan record A untuk apex.

A      @      203.0.113.45   3600

4. Tambahkan alias www.

CNAME  www    acypartner.example   3600

5. (Opsional) tambahkan AAAA kalau server punya alamat IPv6.

6. Simpan, lalu tunggu — tapi diverifikasi, bukan dipencet-refresh sambil berdoa. Di sinilah kesabaran berperan. Record tidak langsung muncul di mana-mana seketika. Sambil menunggu, dia memeriksa pakai alat lookup dari command line alih-alih cuma menggebuki browser:

# minta record A dari domain polosnya
dig acypartner.example A +short

# cek alias www ikut menunjuk dengan benar
dig www.acypartner.example +short

# tanya resolver publik tertentu, lewati cache lokal
dig @1.1.1.1 acypartner.example +short

Saat dig mengembalikan 203.0.113.45, record-nya sudah aktif di resolver yang dia tanya. Begitu hasilnya konsisten, dia memuat domain-nya di browser — dan aplikasinya muncul, lewat nama.

Propagasi: kenapa tidak instan

Kamu akan sering mendengar kata propagasi dilempar seakan perubahan DNS itu merayap fisik ke seluruh dunia. Tidak persis begitu. DNS cepat dalam menerbitkan; yang lambat adalah caching. Resolver di seantero internet menyimpan jawaban sebelumnya selama durasi yang ditentukan oleh TTL record (time to live, dalam detik). Kalau sebuah resolver tadi sejam yang lalu meng-cache “record tidak ada” atau IP lama, dan TTL-mu 3600, dia bisa terus menyajikan jawaban basi itu sampai satu jam itu habis.

TTL = 3600  →  jawaban ter-cache bisa bertahan sampai 1 jam
TTL = 300   →  jawaban ter-cache menyegar dalam ~5 menit

Dua konsekuensi praktisnya:

Untuk record yang benar-benar baru, biasanya belum ada apa-apa yang ter-cache, jadi dia bisa muncul dalam hitungan menit — tapi sebagian resolver meng-cache jawaban negatif, jadi ada beberapa yang telat.
Untuk perubahan record yang sudah ada (kamu pindah dari IP lama ke IP baru), TTL lama yang menentukan berapa lama jawaban basi itu bertahan. Trik yang dipakai para pro: turunkan TTL jauh-jauh hari sebelum perubahan, biarkan TTL pendek itu sendiri menyebar, baru lakukan pergantiannya supaya peralihan cepat, lalu naikkan lagi TTL-nya setelahnya.

'Di komputerku jalan kok' itu dobel benar untuk DNS

Komputermu sendiri meng-cache DNS dengan agresif, begitu juga browser-mu. Setelah mengedit sebuah record, kamu bisa saja masih melihat hasil lama untuk sementara murni karena cache lokal, padahal seluruh dunia sudah melihat yang baru (atau sebaliknya). Jangan menilai propagasi dari satu browser di satu laptop. Tanya langsung ke resolver publik (dig @1.1.1.1 … atau @8.8.8.8), coba jaringan lain, dan bersihkan cache DNS lokalmu sebelum menyimpulkan ada yang rusak.

Kesalahan yang bisa menghabiskan satu sore

Hampir semua pusing-pusing soal mengarahkan DNS itu salah satu dari ini:

Mengedit record di penyedia yang salah. Nameserver domain menunjuk ke penyedia X, tapi kamu mengedit record di penyedia Y. Apa pun yang kamu lakukan tidak berefek. Cek record NS lebih dulu.
Mencoba mem-CNAME apex. Panelnya entah menolak entah diam-diam berulah aneh. Pakai record A (atau fitur ALIAS/flattening dari penyediamu) untuk domain polos.
Lupa www (atau lupa apex). Kamu mengarahkan satu ejaan tapi mengetes ejaan yang lain, lalu menyimpulkan “tidak jalan,” dan mengejar hantu. Arahkan keduanya.
Titik di ujung atau salah ketik di nilainya. CNAME yang menunjuk ke acypartner.exampel (salah ketik) atau ada spasi nyasar akan menunjuk ke ketiadaan. DNS mengerjakan persis apa yang kamu ketik.
Mengira HTTPS bakal muncul sendiri. Mengarahkan DNS membawa pengunjung ke server-mu lewat HTTP polos. Gembok — enkripsi — itu langkah terpisah. Begitu nama-nya menunjuk dengan benar, kamu menyiapkan sertifikat; artikel sertifikat SSL dalam praktik adalah perhentian lanjutan yang pas, dan kebanyakan alat sertifikat justru mensyaratkan DNS sudah menunjuk dengan benar sebelum mau menerbitkannya.
Tidak sabar. Kamu mengubah record, refresh sekali, lihat situs lama, lalu mulai “membetulkan” hal-hal yang sebenarnya sudah benar — malah jadi tambah kacau. Tunggu, baru verifikasi dengan dig.

Kenapa ini penting untuk dibetulkan dengan benar

Mengarahkan DNS adalah momen proyekmu berhenti menjadi “server entah di mana dengan sebuah IP” dan berubah jadi tujuan asli yang punya nama. Ini juga fondasi tempat beberapa langkah berikutnya berpijak. Sertifikat HTTPS diterbitkan ke sebuah nama, jadi mereka butuh DNS menunjuk lebih dulu. Email, pengindeksan mesin pencari, berbagi tautan, dan kepercayaan semuanya menempel ke domain, bukan ke IP mentah. Dan karena DNS itu di-cache, disiplin yang kamu bangun di sini — menurunkan TTL sebelum pindah, memverifikasi dengan lookup sungguhan alih-alih refresh penuh harap — itu persis yang membuat migrasi server di masa depan tidak menyebabkan situs tumbang.

Biasakan membaca file zone dan menjalankan dig, dan satu golongan kepanikan “situsnya mati” berubah jadi diagnosis sepuluh detik.

Penutup

Ini semuanya dalam satu tempat:

Mengarahkan domain berarti menerbitkan record DNS yang memetakan namamu ke IP server-mu. Trafiknya tetap langsung ke IP — nama cuma jadi kunci pencarian.
Kamu perlu tiga hal dulu: server yang bisa dijangkau lewat IP, domain yang terdaftar, dan akses ke record DNS-nya di penyedia mana pun yang berwenang.
Record intinya: A (nama → IPv4), AAAA (nama → IPv6), dan CNAME (nama → nama lain, klasik untuk www). Kamu tidak bisa mem-CNAME apex — pakai record A di situ.
Arahkan keduanya, apex dan www, lalu pilih satu sebagai kanonis dan redirect yang lain di server.
Perubahan tidak instan karena caching dan TTL, bukan “propagasi” yang ajaib. Turunkan TTL sebelum perubahan terencana; verifikasi dengan dig ke resolver publik alih-alih percaya pada satu browser.
DNS membawa pengunjung ke server-mu lewat HTTP. HTTPS itu langkah terpisah yang butuh DNS menunjuk dengan benar lebih dulu.

Dengan nama-nya sudah menunjuk ke server-mu, langkah berikutnya yang jelas adalah mengunci koneksinya — mengubah http:// polos itu jadi https:// yang tepercaya dengan sertifikat sungguhan.