1. Domain dan Subdomain: Apa Bedanya?

Domain adalah nama yang digunakan sebagai alamat utama suatu layanan internet. Dalam contoh namamadrasah.sch.id, nama tersebut berada di bawah ruang nama .sch.id. Sementara itu, subdomain adalah label tambahan yang dibuat di bawah domain yang sudah dikelola.

Membuat rdm.namamadrasah.sch.id tidak berarti mendaftarkan domain .sch.id kedua. Pengelola domain cukup membuat record DNS yang diperlukan pada zona namamadrasah.sch.id, kemudian menyiapkan layanan tujuan agar mengenali hostname tersebut.

2. Posisi .sch.id untuk Institusi Pendidikan

.sch.id merupakan salah satu Domain Tingkat Dua di bawah .id yang peruntukannya terkait institusi pendidikan sesuai kebijakan registri .id. Pendaftaran domain induk dilakukan melalui registrar sesuai persyaratan yang berlaku. Karena kebijakan dan dokumen pendaftaran dapat diperbarui, institusi sebaiknya memeriksa persyaratan terkini pada registrar terakreditasi sebelum mendaftarkan atau memindahkan domain.

Kepemilikan domain institusi sebaiknya tercatat dengan identitas dan kontak yang dapat dikendalikan lembaga. Simpan informasi registrar, tanggal kedaluwarsa, akun pengelola, dan mekanisme pemulihan akses sebagai bagian dari administrasi aset digital madrasah.

3. Memilih Pola URL RDM

Tidak ada satu format URL yang wajib untuk semua instalasi RDM. Pilih pola yang mudah dikenali, dapat dikelola, dan tidak menimbulkan kesan seolah-olah suatu alamat memiliki status resmi yang sebenarnya tidak dimilikinya.

4. Bagaimana DNS Mengarahkan Subdomain?

DNS menerjemahkan hostname yang dibaca manusia menjadi tujuan teknis yang diperlukan untuk menemukan layanan. Pada implementasi sederhana, pengelola dapat memakai record seperti A/AAAA untuk menunjuk ke alamat IP atau CNAME untuk menunjuk ke hostname lain, bergantung pada arsitektur layanan.

Contoh konseptual, bukan nilai yang harus disalin:

rdm.namamadrasah.sch.id.   A       192.0.2.10
portal.namamadrasah.sch.id. CNAME  target.example.net.

Alamat 192.0.2.10 dan example.net di atas hanya contoh dokumentasi. Record aktual harus menggunakan tujuan yang diberikan oleh administrator server/penyedia layanan.

TTL, cache, dan istilah “propagasi”

Setelah record DNS diubah, hasil yang terlihat pengguna tidak selalu berubah pada detik yang sama. Resolver dapat menyimpan jawaban sebelumnya selama TTL/cache masih berlaku. Karena itu, jika alamat baru belum terlihat, jangan hanya “menunggu propagasi”; periksa apakah record otoritatif sudah benar, TTL yang berlaku, resolver yang digunakan, dan apakah perangkat masih menyimpan cache.

5. Subdomain Tidak Sama dengan Folder

Artikel lama mengaitkan subdomain dengan document root. Itu benar pada sebagian lingkungan shared hosting, tetapi bukan aturan universal. Sebuah hostname dapat diarahkan ke virtual host, reverse proxy, container, VPS, load balancer, atau layanan lain tanpa harus menggunakan satu folder publik tertentu.

Karena itu, tujuan teknis yang benar adalah memastikan DNS, konfigurasi web server, aplikasi, dan TLS/HTTPS saling konsisten, bukan sekadar “membuat folder subdomain”.

6. HTTPS dan Identitas Akses

Jika RDM diakses melalui internet, gunakan HTTPS dengan sertifikat yang valid untuk hostname yang dipakai. HTTPS membantu mengenkripsi lalu lintas antara browser dan endpoint TLS, tetapi ikon gembok bukan bukti bahwa situs tersebut resmi, bebas phishing, atau seluruh server otomatis aman.

Sebelum membagikan URL kepada guru, periksa:

1. hostname pada browser sama dengan alamat resmi yang diumumkan;
2. sertifikat berlaku untuk hostname tersebut dan browser tidak menampilkan peringatan;
3. HTTP dialihkan ke HTTPS bila konfigurasi memang dirancang demikian;
4. tidak ada aset penting yang gagal dimuat karena konfigurasi URL/HTTPS;
5. halaman login yang tampil benar-benar instalasi RDM institusi yang dimaksud.

7. Alur Implementasi Subdomain RDM yang Lebih Aman

1. Tentukan pemilik domain dan pengelola DNS. Pastikan institusi tahu siapa yang memiliki akses perubahan DNS.
2. Tentukan hostname. Pilih nama pendek dan konsisten, misalnya rdm.
3. Inventarisasi record yang sudah ada. Simpan kondisi DNS sebelum melakukan perubahan.
4. Dapatkan tujuan teknis dari server. Gunakan IP/hostname yang memang diberikan untuk instalasi tersebut.
5. Buat record DNS yang diperlukan. Jangan mengubah nameserver atau record lain jika tidak diperlukan.
6. Konfigurasikan server. Pastikan web server/platform mengenali hostname baru.
7. Aktifkan HTTPS. Pasang/terbitkan sertifikat sesuai mekanisme server yang digunakan.
8. Uji aplikasi. Login, navigasi, input terbatas, dan fungsi penting harus diuji; keberhasilan membuka halaman depan saja belum cukup.
9. Uji dari jaringan berbeda. Ini membantu membedakan cache/resolver lokal dari masalah layanan.
10. Publikasikan satu alamat resmi. Hindari menyebarkan URL sementara atau alamat IP sebagai tautan utama jika hostname final sudah tersedia.
11. Dokumentasikan perubahan. Catat tanggal, record DNS, tujuan server, penanggung jawab, dan rollback bila diperlukan.

8. Contoh Pola dari Infrastruktur yang Dikelola Hosch.id

Dalam inventaris konfigurasi infrastruktur Hosch.id, terdapat implementasi hostname RDM pada beberapa pola domain: subdomain di bawah domain institusi .sch.id, subdomain pada domain organisasi/lembaga, dan hostname di bawah hosch.id. Contoh berikut ditampilkan untuk menunjukkan pola arsitektur nama, bukan sebagai daftar klien lengkap atau bukti bahwa seluruh endpoint selalu aktif pada saat pembaca membuka artikel.

9. Troubleshooting Subdomain RDM Berdasarkan Gejala

Urutan diagnosis singkat

Gunakan alur nama → DNS → koneksi → TLS → web server/proxy → aplikasi → database. Urutan ini membantu operator mempersempit lapisan masalah sebelum melakukan perubahan besar.

10. Keamanan dan Pengelolaan Akun

Subdomain yang mudah diingat juga lebih mudah ditemukan. Karena itu, jangan mengandalkan URL yang “tidak diketahui orang” sebagai kontrol keamanan.

1. gunakan akun individual sesuai peran dan hindari kredensial admin bersama bila tidak diperlukan;
2. batasi akses panel DNS/hosting hanya kepada petugas yang berwenang;
3. aktifkan autentikasi tambahan pada registrar/panel bila tersedia;
4. jangan menaruh password, token, atau kredensial database di artikel, screenshot, atau grup publik;
5. buat backup dan uji pemulihan sesuai risiko serta mekanisme instalasi;
6. catat perubahan DNS, server, sertifikat, dan akun administratif;
7. pastikan kontak registran/administrator domain tetap dapat dipulihkan ketika terjadi pergantian operator.

Informasi pengelolaan RDM yang lebih luas tersedia pada Panduan Teknis, sedangkan kebijakan terkait data dapat dibaca pada Kebijakan Perlindungan Data Pribadi.

11. FAQ Subdomain RDM

12. Metodologi dan Batas Artikel

Artikel ini direvisi dari materi Hosch.id yang sebelumnya berfokus pada “subdomain RDM tampil seperti domain .sch.id”. Audit September 2026 mempertahankan contoh implementasi yang berasal dari dokumentasi operasional Hosch.id, lalu memperjelas perbedaan antara domain induk, subdomain, DNS, hosting, document root, HTTPS, dan performa.

Penjelasan teknis DNS dan troubleshooting merupakan sintesis operasional Hosch.id. Peruntukan dan tata kelola .sch.id dirujukkan pada kebijakan registri .id/PANDI, sedangkan detail registrasi aktual tetap harus diperiksa pada registrar terakreditasi karena persyaratan dapat diperbarui. Hosch.id bukan PANDI, bukan registrar .id, dan bukan pengembang aplikasi RDM.