FQDN Adalah: Kepanjangan, Anatomi, dan Cara Ceknya

Setiap perangkat yang terhubung ke jaringan perlu diberi nama supaya bisa dipanggil tanpa menghafal deretan angka. Di jaringan kantor, nama pendek seperti printer-lantai2 atau server1 biasanya sudah memadai. Semua orang di kantor itu sudah tahu jaringan mana yang sedang dibicarakan, sehingga sisa keterangannya tidak perlu diucapkan.

Persoalan muncul ketika perangkat yang sama harus dikenali dari luar jaringan tersebut. Nama server1 bisa merujuk pada ribuan mesin berbeda di internet, dan tidak ada cara menebak mana yang Anda maksud. Untuk menghilangkan keraguan itu, sebuah nama harus ditulis selengkapnya sampai ke akar hierarki penamaan internet. Bentuk lengkap itulah yang disebut FQDN.

FQDN Adalah Nama Lengkap Sebuah Mesin di Internet

FQDN adalah singkatan dari Fully Qualified Domain Name. Kepanjangan itu sebaiknya dibaca kata per kata. Qualified berarti "diberi keterangan", dan fully qualified berarti seluruh keterangannya sudah dicantumkan sehingga tidak ada bagian yang perlu ditebak siapa pun.

Glosarium resmi internet, RFC 1983, memberi contoh yang ringkas: venera adalah sebuah hostname, sedangkan venera.isi.edu adalah FQDN. Keduanya menunjuk mesin yang sama. Bedanya, nama pertama hanya bermakna di dalam jaringan tempat mesin itu berada, sedangkan nama kedua bermakna di seluruh dunia tanpa perlu konteks tambahan.

Sebagian dokumentasi menerjemahkan FQDN menjadi "nama domain yang sepenuhnya memenuhi syarat". Terjemahan itu benar secara harfiah, tetapi di lingkungan kerja sehari-hari istilah FQDN hampir selalu dipakai apa adanya.

Perbedaan yang terdengar sepele ini punya akibat teknis yang panjang. Menariknya, seluruh akibat itu berpangkal pada satu tanda baca yang hampir tidak pernah Anda ketik.

Anatomi FQDN dan Titik yang Hampir Tidak Pernah Anda Tulis

Cara paling tepat membaca sebuah FQDN adalah dari kanan ke kiri, karena hierarki penamaan internet memang tersusun dari akar menuju ranting. Ambil mail.indowebsite.co.id. sebagai contoh, lengkap dengan titik di ujungnya, lalu bacalah mundur.

Anatomi FQDN mail.indowebsite.co.id dibaca dari kanan: root, TLD id, label co, nama domain, lalu hostname mail.

Titik terakhir itulah kunci definisinya. RFC 1035 pasal 5.1 menyatakan bahwa nama yang berakhir dengan titik disebut absolut dan dianggap sudah lengkap. Nama yang tidak berakhir titik disebut relatif, dan masih harus digabungkan dengan sebuah asal sebelum bisa dipakai. Sebuah nama disebut fully qualified justru karena sifat absolut itu, bukan semata karena punya hostname di depan nama domain.

Titik akar tersebut bukan teori. Anda bisa melihatnya sendiri lewat perintah dig, yang selalu mencetak nama dalam bentuk absolut pada bagian jawaban:

dig www.indowebsite.co.id

;; ANSWER SECTION:
www.indowebsite.co.id.	236	IN	A	172.67.145.22
www.indowebsite.co.id.	236	IN	A	104.21.63.91

Perhatikan titik setelah id pada kolom pertama. Browser dan formulir pendaftaran menyembunyikan titik itu demi kenyamanan, tetapi resolver DNS selalu bekerja dengan bentuk absolutnya.

Batas panjang: 63, 253, dan 255

RFC 1035 pasal 2.3.4 menetapkan dua batas keras: setiap label maksimal 63 oktet, dan keseluruhan nama maksimal 255 oktet. Angka 255 inilah yang sering disalin menjadi "FQDN maksimal 255 karakter", padahal yang benar adalah 253 karakter saat ditulis sebagai teks.

Selisih dua oktet itu ada alasannya. Di dalam paket DNS, setiap label disimpan dengan satu byte penanda panjang di depannya, dan keseluruhan nama ditutup satu byte bernilai nol yang mewakili root. Satu byte penanda untuk label paling kiri dan satu byte penutup root tidak muncul sebagai karakter yang Anda ketik. Karena itu 255 oktet di jaringan hanya menyisakan ruang untuk 253 karakter teks.

Untuk penamaan mesin, karakter yang aman dipakai hanya huruf, angka, dan tanda hubung. Tanda garis bawah memang sah di beberapa jenis catatan DNS layanan seperti _dmarc.indowebsite.co.id, tetapi tidak sah untuk nama host dan kerap ditolak saat penerbitan sertifikat. Huruf besar dan kecil dianggap sama oleh DNS sesuai RFC 4343, sehingga Mail.Indowebsite.co.id dan mail.indowebsite.co.id menunjuk mesin yang sama.

Contoh FQDN yang Anda Pakai Setiap Hari

Sebagian besar alamat yang Anda ketik setiap hari sebenarnya sudah berbentuk FQDN.

Ada satu hal yang perlu diluruskan di sini. Nama domain telanjang seperti indowebsite.co.id, tanpa www atau label lain di depannya, tetap merupakan FQDN. Nama itu sudah absolut dan sudah menunjuk satu titik pasti di hierarki DNS. Yang membuatnya lengkap adalah posisinya sampai ke akar, bukan keberadaan hostname di depan.

Sebaliknya, ketiga bentuk berikut bukan FQDN:

1. Nama pendek: server1, printer-lantai2, atau laptop-budi. Nama ini relatif dan hanya bermakna di dalam satu jaringan.
2. Alamat IP: 192.168.1.1 atau 8.8.8.8. Alamat IP adalah hasil akhir penerjemahan sebuah nama, bukan nama itu sendiri.
3. Nama khusus: localhost selalu menunjuk mesin Anda sendiri dan tidak memiliki posisi di hierarki DNS publik.

FQDN, Hostname, Domain, dan URL yang Sering Disamakan

Empat istilah ini kerap dipertukarkan padahal masing-masing menjawab pertanyaan berbeda.

Dari tabel tersebut terlihat bahwa FQDN adalah bagian dari URL, bukan sinonimnya. Sebuah URL memuat protokol di depan dan jalur berkas di belakang, sedangkan FQDN hanya menyebut mesinnya. FQDN juga bukan DNS; DNS adalah sistem yang menerjemahkan nama tersebut menjadi alamat IP, sementara FQDN adalah nama yang diterjemahkan.

FQDN di dalam catatan DNS

Satu istilah lain yang sering dibandingkan dengan FQDN adalah CNAME (Canonical Name), yaitu jenis catatan DNS yang menunjuk sebuah nama ke nama lain. Perhatikan kedua sisinya:

dig www.github.com CNAME

;; ANSWER SECTION:
www.github.com.		3325	IN	CNAME	github.com.

Nama di kolom kiri dan nama di kolom kanan sama-sama FQDN, lengkap dengan titik akar. Jadi CNAME bukan lawan dari FQDN, melainkan salah satu jenis catatan yang isinya justru berupa FQDN. Hal yang sama berlaku untuk catatan MX yang menunjuk server email dan catatan NS yang menunjuk name server.

PQDN dan Cara Resolver Diam-diam Melengkapi Nama Anda

Lawan dari FQDN disebut PQDN (Partially Qualified Domain Name), yaitu nama yang keterangannya belum lengkap. server1 dan mail termasuk PQDN. Pertanyaannya, kenapa mengetik ping server1 di kantor sering tetap berhasil padahal nama itu belum lengkap?

Jawabannya ada pada mekanisme search list. Sistem operasi menyimpan daftar sufiks domain, biasanya di berkas /etc/resolv.conf. Sufiks itu ditempelkan satu per satu ke nama pendek yang Anda ketik, sampai ada yang berhasil dijawab. Menurut halaman manual resolv.conf, kueri yang jumlah titiknya lebih sedikit daripada nilai ndots akan dicoba lewat setiap komponen search list terlebih dahulu. Nilai bawaan ndots adalah 1.

Pada mesin uji kami dengan search localdomain di berkas tersebut, hasilnya terlihat jelas:

ping -c1 Mac

PING mac.localdomain (192.168.2.123): 56 data bytes
64 bytes from 192.168.2.123: icmp_seq=0 ttl=64 time=0.093 ms

Nama yang diketik adalah Mac, tetapi yang benar-benar dikirim ke jaringan adalah mac.localdomain. Resolver melengkapinya sendiri tanpa memberi tahu.

Alur resolver melengkapi nama pendek jadi FQDN: hitung titik, tempelkan sufiks search list, kirim kueri absolut.

Ketika kemudahan ini berbalik menjadi beban

Perilaku otomatis tersebut memudahkan pemakaian sehari-hari, tetapi menimbulkan biaya di lingkungan tertentu. Kubernetes adalah contoh paling nyata. Kubelet menuliskan options ndots:5 beserta tiga sufiks pencarian ke /etc/resolv.conf setiap Pod, supaya nama pendek antar-Service bisa saling memanggil.

Akibatnya, saat aplikasi di dalam Pod memanggil alamat eksternal seperti api.mitra.co.id yang hanya berisi dua titik, resolver menganggapnya masih kurang lengkap. Tiga sufiks dicoba lebih dulu dan gagal, baru kueri absolut dikirim. Satu panggilan berubah menjadi empat kueri DNS, dan menjadi delapan jika klien juga menanyakan catatan IPv6. Menambahkan titik di ujung nama menjadi api.mitra.co.id. memotong seluruh percobaan sia-sia itu, karena resolver langsung memperlakukannya sebagai nama absolut.

Search list yang panjang memperbesar biaya ini. Pada glibc versi 2.25 ke bawah, daftar tersebut dibatasi enam domain dengan total 256 karakter. Sejak glibc 2.26 batas itu dihapus, sehingga pengendalian jumlahnya kembali menjadi tanggung jawab Anda. Dua sampai tiga sufiks umumnya sudah memadai.

Saat FQDN Bukan Pilihan, Melainkan Syarat

Pertanyaan yang lebih sering muncul di pekerjaan sehari-hari bukan apa itu FQDN, melainkan apa fungsi FQDN dalam praktik. Jawabannya terbaca paling jelas dari daftar layanan yang menolak berjalan tanpanya.

Sejumlah layanan menolak bekerja dengan nama yang belum lengkap. Alasannya selalu sama: layanan tersebut harus memastikan identitas satu mesin secara global, dan nama relatif tidak bisa memberikan kepastian itu.

Empat layanan yang mewajibkan FQDN: sertifikat SSL, email, hostname server, dan Kubernetes.

1. Sertifikat SSL/TLS: sertifikat SSL diterbitkan untuk FQDN yang persis, dicantumkan pada kolom Subject Alternative Name. Karena itu sertifikat untuk indowebsite.co.id tidak otomatis berlaku untuk www.indowebsite.co.id. Sertifikat wildcard pun hanya menutup satu tingkat label: menurut Baseline Requirements CA/Browser Forum, *.example.com mencakup www.example.com tetapi tidak mencakup example.com maupun login.shop.example.com.
2. Pengiriman email: RFC 5321 mewajibkan argumen perintah EHLO berupa nama host utama yang dapat diresolusi, dan nama panggilan lokal tidak boleh dipakai. Server penerima memakai nama itu sebagai bahan penilaian, sehingga server pengirim dengan identitas tidak lengkap berisiko masuk folder spam.
3. Hostname server hosting: cPanel dan CWP mensyaratkan hostname server berbentuk FQDN dengan minimal dua titik. Nama itu juga tidak boleh sama dengan domain akun yang dihosting di server tersebut. Aturan ini berlaku sejak Anda menyalakan VPS untuk pertama kalinya.
4. Active Directory dan Kerberos: tiket Kerberos diterbitkan untuk nama layanan yang lengkap. Perangkat yang memanggil server memakai nama pendek akan gagal autentikasi meski koneksi jaringannya normal.
5. Service di Kubernetes: setiap Service punya FQDN internal berpola nama-service.namespace.svc.cluster.local. Nama itu hanya berlaku di dalam klaster, tetapi strukturnya mengikuti aturan yang sama persis.

Cara Mengecek FQDN di Linux, macOS, dan Windows

Mengetahui FQDN sebuah mesin berguna saat memasang sertifikat, mengatur pengiriman email, atau memeriksa kenapa sebuah layanan menolak berjalan.

Pada Linux dan macOS, gunakan opsi -f untuk meminta bentuk lengkapnya:

hostname -f

Mac.localdomain

Bandingkan dengan hostname -s yang hanya mengembalikan nama pendek. Pada Linux modern berbasis systemd, hostnamectl menampilkan rincian yang lebih lengkap termasuk jenis hostname yang sedang dipakai.

Untuk memeriksa FQDN mesin lain, bukan mesin Anda sendiri, gunakan dig atau nslookup:

dig +short www.indowebsite.co.id A
nslookup www.indowebsite.co.id

Arah sebaliknya juga mungkin. Untuk mencari FQDN dari sebuah alamat IP, jalankan pencarian terbalik yang membaca catatan PTR:

dig +short -x 8.8.8.8

dns.google.

Hasil yang kosong bukan berarti perintahnya keliru. Banyak alamat IP, terutama milik penyedia CDN, memang tidak dipasangi catatan PTR sehingga tidak punya nama balik sama sekali.

Pada Windows, jalankan ipconfig /all melalui CMD, lalu gabungkan baris Host Name dengan baris Primary Dns Suffix. Bila baris sufiks itu kosong, mesin tersebut memang belum punya FQDN. Melalui PowerShell, hasilnya bisa didapat sekaligus:

[System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName

Bila perintah di atas tetap mengembalikan nama pendek, kesimpulannya bukan bahwa perintahnya gagal. Mesin tersebut memang belum diberi sufiks domain, dan itu wajar untuk laptop pribadi yang tidak bergabung ke domain mana pun.

Menyaring Trafik Berdasarkan FQDN dan Alasan Cara Ini Rapuh

Banyak firewall modern menerima aturan berbasis nama, bukan hanya alamat IP. Anda mengizinkan update.microsoft.com dan menolak sisanya, tanpa perlu mengurus daftar IP yang berubah-ubah. Kemudahan ini terdengar ideal, tetapi cara kerjanya di balik layar membuat hasilnya sering meleset dari harapan.

Firewall tidak benar-benar menyaring berdasarkan nama. Perangkat itu meresolusi nama tersebut menjadi sekumpulan alamat IP, menyimpannya, lalu menerapkan aturan pada IP hasil resolusi. Empat persoalan lahir dari mekanisme tersebut.

1. Hasil resolusi bisa berbeda antara klien dan firewall. Jika keduanya memakai server DNS yang berbeda, keduanya dapat menerima daftar IP yang berbeda pula. Trafik klien akhirnya menuju IP yang tidak ada dalam daftar izin firewall.
2. TTL yang pendek membuat data cepat basi. Banyak layanan besar memakai TTL di bawah 60 detik. Dalam rentang itu, catatan yang disimpan firewall bisa sudah tidak sesuai dengan yang diterima klien.
3. Satu alamat IP dipakai banyak domain. Pada penyedia CDN, ribuan situs berbagi alamat IP yang sama. Mengizinkan satu nama berarti membuka pintu untuk semua domain lain yang kebetulan mendarat di IP tersebut.
4. Aturan gagal senyap saat resolusi bermasalah. Bila DNS firewall tidak bisa menjawab, aturannya kehilangan isi tanpa menghasilkan pesan kesalahan yang mencolok.

Karena itu, penyaringan berbasis FQDN sebaiknya diperlakukan sebagai alat bantu kerapian, bukan pengganti kontrol keamanan. Untuk layanan yang benar-benar kritis, tetap pakai daftar IP resmi dari penyedianya. Hindari juga memakai aturan berbasis nama untuk domain yang berada di belakang CDN besar, karena di sanalah ketiga persoalan pertama muncul bersamaan.

Rekomendasi Pola Penamaan FQDN

Setelah aturannya jelas, pertanyaan berikutnya bersifat praktis: nama seperti apa yang sebaiknya dipakai. Pola berikut bertahan saat jumlah mesin bertambah.

Susun nama dengan urutan [peran][nomor].[lingkungan].[domain], sehingga menghasilkan bentuk seperti web01.prod.perusahaan.co.id atau db02.staging.perusahaan.co.id. Empat patokan angkanya:

1. Nomor urut dua digit. Menulis web01 alih-alih web1 membuat daftar mesin terurut rapi sampai 99 unit, dan penambahan mesin kesepuluh tidak merusak urutan.
2. Panjang tiap label di bawah 20 karakter. Batas resminya memang 63 oktet, tetapi nama yang panjang menyulitkan pembacaan log dan mudah salah ketik saat menerbitkan sertifikat.
3. Maksimal empat label. Lebih dari itu, nama menjadi sulit diucapkan lewat telepon saat penanganan gangguan.
4. Huruf kecil dan tanda hubung saja. DNS memang tidak membedakan huruf besar dan kecil, tetapi konsistensi huruf kecil mencegah perbedaan penulisan antar-anggota tim. Tanda garis bawah (underscore) sebaiknya dihindari sepenuhnya untuk nama mesin.

Satu keputusan yang sering keliru sejak awal adalah pemilihan sufiks untuk mesin internal. Hindari .local, karena RFC 6762 menetapkan bahwa setiap nama yang berakhir .local. bersifat link-local dan kuerinya wajib dikirim ke alamat multicast mDNS, bukan ke server DNS biasa. Untuk jaringan rumah, RFC 8375 menyediakan home.arpa yang memang dicadangkan untuk keperluan tersebut. Untuk organisasi, pakailah subdomain dari domain yang benar-benar Anda miliki, misalnya internal.perusahaan.co.id.

Jangan menaruh informasi yang bisa berubah ke dalam nama, seperti merek perangkat keras, versi sistem operasi, atau nomor rak. Informasi semacam itu berumur lebih pendek daripada nama mesinnya, dan mengganti nama jauh lebih mahal daripada memperbarui catatan inventaris.

Pertanyaan yang Sering Muncul Seputar FQDN

Apa yang dimaksud dengan FQDN?

FQDN adalah nama lengkap sebuah mesin di jaringan, ditulis sampai ke akar hierarki DNS sehingga menunjuk satu titik yang pasti di seluruh internet. Contohnya www.indowebsite.co.id.

FQDN kepanjangan dari apa?

Dari Fully Qualified Domain Name. Dalam bahasa Indonesia sering diterjemahkan sebagai nama domain yang sudah lengkap sepenuhnya.

Apa fungsi FQDN?

Fungsinya menyebut satu mesin secara pasti tanpa bergantung pada konteks jaringan. Dari fungsi itu lahir pemakaian praktisnya: menerbitkan sertifikat SSL, mengirim email agar tidak dinilai mencurigakan, mengisi hostname server hosting, serta memanggil Service di dalam klaster Kubernetes.

Tiga bagian domain itu apa saja?

Kalau yang dimaksud tiga tingkat penamaan, urutannya dari kanan adalah top level domain (id), label tingkat kedua (co), dan nama domain yang didaftarkan (indowebsite). Label di sebelah kirinya, seperti www atau mail, dihitung sebagai subdomain atau hostname.

Apakah alamat IP bisa disebut FQDN?

Tidak. Alamat IP seperti 8.8.8.8 adalah hasil penerjemahan sebuah nama, bukan nama itu sendiri. Alamat tersebut memang bisa ditelusuri balik menjadi nama lewat catatan PTR, dan untuk 8.8.8.8 hasilnya dns.google yang merupakan FQDN milik layanan DNS publik Google.

Berapa bagian yang menyusun sebuah FQDN?

Minimal ada dua label ditambah root, misalnya indowebsite.co.id diikuti titik akar. Jumlah label di sebelah kiri bisa bertambah sesuai kebutuhan, selama total panjangnya tidak melewati 253 karakter dan tiap label tidak melewati 63 karakter.

Apa bedanya FQDN dengan DNS?

FQDN adalah namanya, DNS adalah sistem yang menerjemahkan nama tersebut menjadi alamat IP. Keduanya berpasangan, tetapi bukan hal yang sama.

Apakah localhost termasuk FQDN?

Tidak. localhost adalah nama khusus yang selalu menunjuk mesin yang sedang Anda pakai, dan nama itu tidak memiliki posisi di hierarki DNS publik.

Kesimpulan

FQDN adalah nama sebuah mesin yang ditulis lengkap sampai akar hierarki DNS, dan sifat lengkap itulah yang membuatnya bermakna sama di mana pun nama tersebut dibaca. Titik di ujung nama jarang Anda ketik, tetapi titik itulah yang secara teknis membedakan nama absolut dari nama relatif. Dari pembedaan itu pula lahir mekanisme search list yang diam-diam melengkapi nama pendek Anda.

Untuk pemakaian sehari-hari di satu jaringan, nama pendek masih memadai dan tidak perlu dipersoalkan. Begitu nama itu menyeberang keluar jaringan, dipasangi sertifikat, dipakai mengirim email, atau menjadi hostname server, pakailah bentuk lengkapnya sejak awal. Memperbaiki nama setelah sertifikat terbit dan layanan berjalan selalu lebih mahal daripada menuliskannya dengan benar di hari pertama.

Semoga artikel ini membantu.