Domain Dibangun Dalam Struktur Hierarki
Nama seperti www.example.com dibaca sebagai bagian dari hierarki DNS. Label paling kanan, seperti .com, merupakan top-level domain, sementara example berada di bawahnya dan www dapat digunakan sebagai subdomain. Registry mengelola database untuk TLD tertentu, registrar menyediakan layanan pendaftaran kepada registrant, dan registrant adalah pihak yang mendaftarkan nama tersebut. Struktur ini memungkinkan pengelolaan domain dibagi ke banyak organisasi tanpa bergantung pada satu database pusat untuk seluruh nama di internet.
Nama domain juga tidak harus menunjuk hanya ke website. Satu domain dapat memiliki subdomain untuk API, email, dashboard, atau layanan lain, masing-masing dengan record DNS yang berbeda. Domain level registrasi dan hostname yang dipakai aplikasi karena itu perlu dibedakan. example.com dapat menjadi domain terdaftar, sementara www.example.com atau api.example.com adalah nama yang berada di bawah zone tersebut.
Nameserver Menentukan Tempat Jawaban DNS Berasal
Setelah domain terdaftar, delegasi menunjuk authoritative nameserver yang berwenang menjawab record untuk zone tersebut. Record seperti A dan AAAA mengarahkan nama ke alamat IP, CNAME membuat alias menuju nama lain, MX berkaitan dengan server email, dan TXT menyimpan informasi teks yang sering digunakan untuk verifikasi atau kebijakan. Mengubah record pada panel DNS yang tidak lagi menjadi authoritative tidak akan mengubah jawaban publik, sehingga nameserver yang aktif perlu diperiksa terlebih dahulu ketika melakukan troubleshooting.
Nameserver juga dapat menggunakan beberapa server authoritative untuk redundansi. Resolver tidak bergantung pada satu server saja jika delegasi menyediakan lebih dari satu tujuan. Perubahan pada zone perlu konsisten pada authoritative infrastructure yang digunakan. Jika sebagian server memberikan jawaban berbeda, pengguna dapat melihat hasil yang tidak konsisten tergantung server mana yang menjawab query.
Browser Menggunakan DNS Sebelum Menghubungi Server
Saat pengguna mengetik domain, browser atau sistem operasi biasanya meminta resolver rekursif untuk mencari alamat yang diperlukan. Resolver dapat menjawab dari cache atau mengikuti hierarki DNS sampai authoritative server. Setelah alamat diperoleh, browser membangun koneksi menggunakan protokol jaringan dan mengirim permintaan HTTP atau HTTPS. Karena itu, domain dapat terdaftar dengan benar tetapi website tetap gagal dibuka jika DNS salah, server tidak merespons, sertifikat bermasalah, atau aplikasi web menghasilkan error.
Setelah DNS selesai, jaringan masih harus menemukan rute menuju alamat server. Server dapat berada di data center, cloud, reverse proxy, CDN, atau load balancer. Satu domain bahkan dapat mengembalikan alamat berbeda kepada pengguna berbeda untuk mendekatkan traffic atau membagi beban. Karena itu, DNS menunjukkan arah logis, tetapi tidak menggambarkan seluruh arsitektur fisik layanan.
Perubahan Domain Dan DNS Tidak Selalu Terlihat Seketika
Jawaban DNS dapat disimpan sementara berdasarkan TTL sehingga resolver yang berbeda masih menggunakan data lama sampai cache berakhir. Situasi ini sering disebut “propagasi DNS”, padahal yang terjadi umumnya adalah kombinasi cache, TTL, dan perubahan delegasi. Pemindahan registrar juga berbeda dari perubahan hosting: domain dapat tetap berada pada registrar yang sama sementara DNS diarahkan ke server baru. Memisahkan setiap lapisan membuat migrasi dan diagnosis masalah lebih terukur.
Sebelum migrasi website, TTL dapat diturunkan terlebih dahulu agar cache lama berakhir lebih cepat ketika perubahan dilakukan. Namun penurunan TTL hanya efektif setelah nilai lama tidak lagi tersimpan di cache. Perencanaan semacam ini mengurangi periode ketika sebagian pengguna masih menuju server lama dan sebagian lainnya sudah menuju server baru.
