Subzona DNS: apa itu dan bagaimana cara kerjanya dalam zona DNS

Informatec Digital » Sumber daya » Subzona DNS: apa itu dan bagaimana cara kerjanya dalam zona DNS

Jika Anda bekerja dengan domain dan hosting , atau sekadar mengelola situs web, cepat atau lambat Anda akan menemukan istilah-istilah seperti zona DNS, subzona, file zona, dan record . Istilah-istilah ini terdengar teknis, tetapi begitu Anda mempraktikkannya, Anda akan melihat bahwa semuanya masuk akal dan bahwa, dengan beberapa pemahaman yang jelas, Anda dapat mengelola DNS Anda sendiri tanpa tersesat dalam prosesnya.

Pada uraian berikut, kita akan dengan tenang menelaah apa itu zona DNS dan subzona, bagaimana keduanya masuk ke dalam hierarki sistem nama domain, jenis-jenis zona yang ada , bagaimana zona tersebut didelegasikan, apa saja record yang paling umum, masalah apa yang menyebabkan kesulitan dan bagaimana cara menghindarinya, semuanya dijelaskan dengan bahasa yang mudah dipahami, tetapi tanpa kehilangan ketelitian teknis.

Pengingat singkat: bagaimana cara kerja DNS dari dalam.

Untuk memahami apa itu subzona DNS, Anda perlu memahami terlebih dahulu Sistem Nama Domain (DNS) itu sendiri . DNS adalah sistem hierarkis dan terdistribusi yang menerjemahkan nama yang mudah dibaca manusia (seperti example.com) menjadi alamat IP yang dapat dipahami oleh komputer.

Banyak orang membandingkan DNS dengan "buku telepon internet", meskipun saat ini gagasan daftar kontak ponsel lebih tepat : Anda mencari berdasarkan nama, dan sistem akan menemukan nomor tersebut tanpa Anda harus menghafalnya.

Saat Anda mengetikkan domain ke browser Anda, sebuah kueri DNS (pencarian atau resolusi) akan dimulai . Perangkat pengguna meminta "resolver rekursif" (biasanya DNS dari penyedia internet Anda atau layanan publik seperti Google atau Cloudflare), dan resolver tersebut akan menanyakan berbagai server DNS hingga menemukan catatan yang benar.

Resolusi tersebut mengikuti struktur hierarki yang sangat jelas: pertama, server akar dikueri , yang mengelola zona akar DNS dan mengembalikan server mana yang membawa setiap domain tingkat atas (TLD) seperti .com, .es, .ovh, dll.

Selanjutnya, resolver akan menanyakan server nama untuk TLD yang sesuai (.com, .gov, .ovh, dll.) untuk mengetahui server nama mana yang berwenang untuk domain tertentu, misalnya, mydomain.com. Terakhir, server nama yang berwenang untuk domain tersebut akan merespons dengan catatan DNS spesifik: alamat IP situs web , server email, subdomain, dll.

Hierarki domain, FQDN, dan struktur bertingkat

Seluruh sistem ini didasarkan pada fakta bahwa sebuah domain terdiri dari blok-blok yang dipisahkan oleh titik , yang diuraikan dari kanan ke kiri. Nama domain yang sepenuhnya memenuhi syarat, yang terkenal dengan FQDN (Fully Qualified Domain Name), mencakup semua tingkatan ini dan diakhiri dengan titik akar, meskipun titik terakhir tersebut biasanya tidak ditampilkan di browser.

Jadi, dalam nama seperti support.mydomain.ovh, blok paling kanan adalah TLD (.ovh) , di sebelah kirinya adalah domain tingkat kedua (mydomain), dan kemudian diikuti oleh subdomain (support, www, blog, dll.). DNS menyelesaikan setiap blok dalam urutan terbalik: pertama root, kemudian TLD, kemudian domain, lalu subdomain.

Setiap koneksi internet biasanya memiliki setidaknya satu server DNS utama dan satu server DNS sekunder yang terkait dengannya , yang diperoleh secara otomatis melalui DHCP. Server sekunder berfungsi sebagai cadangan jika server utama gagal, membantu menjaga agar situs web dan layanan tetap dapat diakses.

Saat menerima permintaan, server DNS dapat berperilaku dengan dua cara: jika sudah mengetahui domain tersebut karena sudah tersimpan dalam cache, server akan merespons secara instan menggunakan informasi yang tersimpan, dibatasi oleh parameter TTL (Time To Live) ; jika belum mengetahuinya, server akan memulai seluruh rantai permintaan menuju server root, TLD, dan server otoritatif hingga mencapai zona yang berisi subdomain atau domain yang diminta.

Apa itu zona DNS dan apa itu subzona DNS?

Di dalam pohon nama yang besar itu, ruang DNS diorganisasikan ke dalam zona DNS . Zona DNS adalah bagian dari ruang nama yang dikelola oleh entitas tertentu (perusahaan, penyedia hosting, atau administrator).

Dalam praktiknya, zona DNS adalah unit administratif: zona ini mendefinisikan lingkup wewenang untuk membuat, memodifikasi, dan menghapus catatan . Zona ini dapat mencakup hanya domain dasar (misalnya, ecohosting.cl) atau juga mencakup satu atau lebih subdomainnya.

Bayangkan domain ecohosting.cl dengan subdomain berikut: support.ecohosting.cl, clients.ecohosting.cl, dan blog.ecohosting.cl. Jika support dan clients adalah layanan sederhana yang terkait dengan hosting utama, akan lebih mudah untuk mengelolanya di zona yang sama dengan ecohosting.cl . Tetapi jika blog adalah proyek independen, yang dikembangkan oleh tim lain atau dengan penyedia lain, akan sangat masuk akal untuk memberikannya zona DNS tersendiri.

Dalam hal ini, ecohosting.cl, soporte.ecohosting.cl, dan clientes.ecohosting.cl akan berbagi zona, sementara blog.ecohosting.cl akan menjadi subzona DNS yang didelegasikan , dengan server nama dan file zonanya sendiri. Di sinilah konsep "subzona DNS" muncul: sebagian dari domain yang ditugaskan ke zona yang berbeda untuk mendelegasikan kendali.

Zona DNS tidak perlu dipisahkan secara fisik pada server yang berbeda; ini lebih merupakan pemisahan logis untuk mendelegasikan wewenang . Satu server nama dapat memiliki beberapa zona, masing-masing dengan file zona independennya sendiri.

Jenis-jenis zona DNS: primer, sekunder, maju, mundur, dan stub

Jika Anda mempelajari lebih dalam tentang administrasi DNS, Anda akan melihat bahwa tidak semua zona itu sama. Ada berbagai jenis zona DNS , yang dirancang untuk memenuhi kebutuhan yang berbeda dalam infrastruktur.

Zona DNS utama adalah salinan baca/tulis utama dari suatu zona. Datanya disimpan dalam file master pada server tertentu, dan setiap perubahan pada record harus dilakukan di sana. Hanya boleh ada satu file master per zona pada server tertentu.

Zona DNS sekunder adalah salinan zona primer yang hanya dapat dibaca. Zona ini disinkronkan dengan master menggunakan transfer AXFR penuh atau IXFR inkremental. Fungsi utamanya adalah untuk menyediakan redundansi dan ketersediaan : jika server primer gagal, resolver dapat terus melakukan kueri ke server sekunder yang tercantum dalam catatan NS.

Kami juga memiliki yang disebut zona pencarian maju (forward lookup zone ), yang digunakan untuk menerjemahkan nama domain menjadi alamat IP. Zona ini menyimpan catatan A (untuk IPv4) dan catatan AAAA (untuk IPv6), bersama dengan jenis catatan lain yang terkait dengan nama tersebut.

Di sisi lain, terdapat area pencarian terbalik , yang bekerja secara terbalik: area ini mengembalikan nama domain dari alamat IP menggunakan catatan PTR. Sangat umum bagi layanan email dan sistem keamanan untuk memeriksa hubungan terbalik ini untuk memvalidasi bahwa alamat IP benar-benar sesuai dengan domain yang diklaimnya.

Terakhir, ada tipe khusus yang disebut zona stub , versi ringkas dari zona yang hanya berisi catatan penting: NS untuk mengidentifikasi server otoritatif, A/AAAA untuk membuat server tersebut dapat ditemukan, dan SOA. Tipe zona ini membantu jaringan besar untuk mempertahankan daftar server otoritatif yang mutakhir untuk zona yang didelegasikan tanpa perlu menyimpan semua catatan.

File zona DNS dan elemen kunci

Semua informasi untuk suatu zona disimpan dalam file zona DNS -nya , yang merupakan file teks biasa di server nama. Setiap baris mewakili catatan sumber daya, dan kumpulan semuanya menjelaskan sepenuhnya bagaimana domain tersebut dan subdomainnya harus diselesaikan.

Setiap berkas zona harus diawali dengan catatan Start of Authority (SOA) . SOA menentukan server nama utama zona, pemimpin teknis, nomor seri, dan stempel waktu yang mengatur caching, transfer ke server sekunder, dan percobaan ulang.

Parameter penting dalam semua ini adalah Time To Live (TTL) , yang memberi tahu resolver berapa lama mereka dapat menyimpan setiap record dalam cache sebelum melakukan query lagi. TTL yang tinggi mengurangi traffic DNS tetapi membuat perubahan membutuhkan waktu lebih lama untuk menyebar; TTL yang rendah mempercepat perubahan tetapi meningkatkan jumlah query.

Berkas zona ini mencakup berbagai jenis catatan: alamat IP, server email, catatan teks untuk keamanan email, alias subdomain, dll. Setiap catatan menggunakan sintaks DNS yang sangat spesifik , mirip dengan "instruksi" kecil yang dipahami server untuk mengetahui cara merespons.

Jenis-jenis catatan DNS yang paling umum dalam suatu zona atau subzona

Di dalam zona DNS, Anda terutama akan bekerja dengan serangkaian catatan tertentu. Ini adalah catatan DNS paling umum yang akan Anda temui saat mengelola zona atau subzona.

Record A menghubungkan nama domain atau subdomain ke alamat IPv4. Misalnya, www.mydomain.com mengarah ke 203.0.113.10. Ini sangat penting agar sebuah situs web dapat dimuat dari alamat IP tertentu.

Catatan AAAA memiliki tujuan yang sama, tetapi mengarah ke alamat IPv6. Hal ini semakin umum di lingkungan modern, terutama jika penyedia layanan Anda sepenuhnya mendukung IPv6.

Catatan MX menunjukkan server email yang bertanggung jawab untuk menerima email untuk domain tersebut. Catatan ini biasanya disertai dengan prioritas numerik yang menunjukkan server mana yang digunakan terlebih dahulu dan mana yang disimpan sebagai cadangan.

Record CNAME digunakan untuk membuat alias: sebuah nama mengarah ke nama lain, bukan alamat IP. Misalnya, blog.mydomain.com bisa menjadi record CNAME untuk mydomainblog.externalhosting.com. Record ini tidak mengembalikan alamat IP secara langsung, melainkan mengarahkan ke nama lain yang akan memiliki alamat IP.

Catatan NS menentukan server nama mana yang berwenang untuk suatu zona atau subzona. Catatan ini sangat penting untuk delegasi: ketika Anda membuat subzona DNS untuk subdomain, Anda mendaftarkan catatan NS di zona utama yang mengarah ke server yang berwenang untuk subzona tersebut.

Catatan SOA yang disebutkan di atas menyimpan data otorisasi: server master, email administrator (dengan format khusus), nomor seri zona, dan berbagai waktu penyegaran, percobaan ulang, masa berlaku, dan TTL minimum.

Catatan TXT menyimpan rangkaian teks sembarang yang terkait dengan suatu domain. Catatan ini banyak digunakan untuk keamanan email (SPF, DKIM, DMARC), verifikasi domain dengan layanan eksternal (Google, Microsoft, dll.), dan berbagai metadata.

Catatan SRV menunjukkan host dan port mana yang menyediakan layanan tertentu (misalnya, VoIP, perpesanan, atau layanan internal tertentu), sedangkan catatan PTR digunakan di zona terbalik untuk memetakan IP ke nama domain.

Catatan DNS yang jarang ditemukan tetapi penting.

Selain yang klasik, standar DNS mendefinisikan sejumlah besar catatan yang kurang dikenal yang digunakan dalam konteks yang sangat spesifik, seringkali terkait dengan keamanan atau layanan tingkat lanjut.

Registry AFSDB dirancang untuk Andrew Distributed File System (AFS) dan membantu menemukan sel AFS dalam struktur penyimpanan jaringan.

Register APL bersifat eksperimental dan digunakan untuk menyimpan daftar rentang alamat, sesuatu yang sangat tidak biasa di lingkungan umum.

Catatan CAA menjadi semakin penting: catatan ini memungkinkan pemilik domain untuk menentukan otoritas sertifikat (CA) mana yang dapat menerbitkan sertifikat untuk domain tersebut , sehingga memperkuat keamanan lapisan TLS. Tanpa CAA, CA mana pun dapat menerbitkan sertifikat untuk domain tersebut.

Catatan DNSKEY menyimpan kunci publik yang digunakan oleh DNSSEC (Domain Name System Security Extensions), yaitu serangkaian ekstensi yang menambahkan tanda tangan kriptografi ke catatan DNS untuk mencegah perubahan yang tidak sah.

Catatan CDNSKEY pada dasarnya adalah salinan "turunan" dari DNSKEY yang dimaksudkan untuk ditransfer ke zona induk, sehingga mempermudah validasi dalam string DNSSEC.

Registri CERT menyimpan sertifikat kunci publik, sedangkan registri DHCID menyimpan informasi yang digunakan oleh DHCP (protokol konfigurasi host dinamis) untuk mengoordinasikan penugasan dan menghindari konflik.

Record DNAME mirip dengan CNAME tetapi pada level yang berbeda: record ini membuat alias domain lengkap, sehingga tidak hanya nama yang ditunjuk tetapi semua subdomainnya dialihkan ke pohon nama lain.

Data LOC dapat menyimpan informasi geografis (lintang, bujur, ketinggian) yang terkait dengan suatu domain, sesuatu yang terkadang digunakan dalam layanan geolokasi atau dokumentasi internal.

Registri NAPTR yang dikombinasikan dengan SRV memungkinkan pembuatan URI layanan secara dinamis berdasarkan pola, yang berguna dalam aplikasi suara melalui IP atau perpesanan tertentu.

Dalam dunia DNSSEC, terdapat juga catatan NSEC , yang berfungsi untuk membuktikan secara kriptografis bahwa suatu catatan TIDAK ada, dan catatan RRSIG , yang menyimpan tanda tangan digital dari kumpulan catatan.

Terakhir, ada yang lain seperti catatan RP (responsible person) , yang mengarah ke email pemilik domain, atau catatan SSHFP , yang memungkinkan penerbitan sidik jari kunci publik SSH untuk memperkuat keamanan koneksi jarak jauh.

DNSSEC, keamanan, dan praktik terbaik dalam manajemen zona.

Zona dan subzona DNS merupakan target utama bagi penyerang karena mengubah beberapa catatan saja dapat mengalihkan lalu lintas web, membajak email, atau meniru layanan . Itulah mengapa keamanan manajemen zona sangat penting.

Langkah pertama adalah melindungi kredensial panel DNS Anda (baik itu cPanel, Plesk, panel milik penyedia layanan, atau panel seperti core-admin). Disarankan untuk menggunakan kata sandi yang kuat, menghindari berbagi akses, dan mengaktifkan otentikasi dua faktor jika memungkinkan.

Mengaktifkan DNSSEC menambahkan lapisan perlindungan ekstra: catatan DNS ditandatangani secara digital, dan resolver yang memvalidasi DNSSEC dapat mendeteksi jika seseorang mencoba menyuntikkan jawaban palsu atau memanipulasi catatan selama pengiriman.

Penting juga untuk meninjau setiap perubahan data dengan cermat untuk menghindari kesalahan konfigurasi: prioritas yang salah di MX , IP yang salah eja di A, CNAME yang terjebak dalam perulangan, atau titik yang hilang di akhir nama dapat membuat situs web atau email Anda tidak dapat digunakan.

Disarankan untuk membiasakan diri menggunakan alat verifikasi DNS untuk memvalidasi perubahan: CMD (dig, nslookup), panel diagnostik dari penyedia layanan itu sendiri, atau layanan online untuk memeriksa propagasi dan status DNSSEC.

Penyebaran perubahan dan TTL di zona dan subzona

Saat Anda mengedit zona atau subzona DNS (misalnya, dengan mengubah alamat IP server web atau memodifikasi catatan MX), perubahan tersebut diterapkan segera pada server otoritatif, tetapi tidak langsung tercermin di seluruh dunia.

Penyebabnya adalah caching : resolver DNS menyimpan respons selama waktu yang ditentukan oleh TTL (Time To Live) dari record tersebut. Hingga TTL tersebut berakhir, mereka akan terus menyajikan versi lama, sehingga terjadilah "propagasi DNS" yang terkenal.

Proses ini dapat memakan waktu mulai dari beberapa menit hingga 24-48 jam dalam skenario ekstrem, tergantung pada nilai TTL yang dikonfigurasi dan bagaimana setiap ISP menyimpan data dalam cache . Oleh karena itu, untuk perubahan penting, disarankan untuk sementara menurunkan TTL beberapa hari sebelumnya, menunggu nilai TTL baru untuk diterapkan, dan kemudian melakukan perubahan besar.

Selama proses peluncuran, beberapa pengguna mungkin masih melihat situs web atau email lama, sementara yang lain sudah dilayani oleh server baru. Anda dapat memantau proses ini dengan alat daring yang meninjau log Anda dari berbagai lokasi.

Penggunaan subdomain, subzona, dan pengalihan

Membuat subdomain adalah cara yang sangat fleksibel untuk mengatur proyek Anda: Anda dapat memiliki blog.mydomain.com, store.mydomain.com, support.mydomain.com dan dengan demikian memisahkan layanan, teknologi, atau bahkan penyedia.

Untuk banyak subdomain, mengelolanya di zona yang sama dengan domain utama sudah cukup, dengan menambahkan catatan A, AAAA, atau CNAME sesuai kebutuhan. Namun, ketika subdomain menjadi sangat kompleks atau Anda ingin tim atau penyedia lain mengelolanya, mungkin lebih masuk akal untuk mendelegasikannya ke subzona DNS terpisah.

Pendelegasian ini dilakukan dengan membuat catatan NS di dalam zona utama yang mengarah ke server nama subdomain. Mulai saat itu, semua kueri untuk cabang namespace tersebut diselesaikan di subzona.

Selain subdomain, umum juga menggunakan pengalihan HTTP dari satu domain atau subdomain ke domain atau subdomain lain, yang didefinisikan pada server web atau melalui layanan pengalihan registrar. Ini bukan catatan DNS (kecuali dalam kasus tertentu dengan catatan khusus), melainkan respons server HTTP.

Panel kontrol seperti cPanel, Plesk, ISPConfig, atau panel yang disediakan oleh masing-masing penyedia hosting biasanya menawarkan wizard grafis untuk membuat subdomain, mengedit zona, dan mengkonfigurasi pengalihan tanpa harus menyentuh file zona secara langsung.

Manfaat zonasi dan subzonasi DNS

Membagi ruang nama yang besar menjadi beberapa zona dan subzona DNS memiliki keuntungan yang jelas, terutama seiring pertumbuhan proyek atau organisasi.

Di satu sisi terdapat desentralisasi : unit, departemen, atau penyedia yang berbeda dapat mengelola bagian domain mereka sendiri tanpa saling mengganggu.

Hal ini juga meningkatkan kinerja dan skalabilitas : dengan file zona yang lebih kecil, pembaruan dan transfer antara server primer dan sekunder menjadi lebih ringan, dan beban didistribusikan di antara beberapa server nama.

Delegasi subzona juga memfasilitasi distribusi lalu lintas antara pusat data atau penyedia yang berbeda, yang membantu menyeimbangkan beban, meningkatkan latensi, dan meningkatkan ketahanan terhadap gangguan dari satu penyedia.

Dari sudut pandang organisasi, hal ini memungkinkan manajemen yang lebih rinci : setiap tim hanya mengontrol catatan yang memengaruhinya, yang mengurangi risiko kesalahan di domain atau layanan eksternal.

Mendelegasikan subzona DNS langkah demi langkah (secara konseptual)

Mendelegasikan subzona DNS melibatkan pembagian zona besar menjadi zona yang lebih kecil dan menetapkan setiap zona ke server otoritatif yang berbeda , biasanya untuk subdomain tertentu.

Misalkan Anda memiliki domain yourdomain.com dan ingin tim atau penyedia lain mengelolanya. Langkah pertama adalah membuat serangkaian catatan NS untuk it.yourdomain.com di zona utama, yang mengarah ke nama-nama server DNS yang akan menangani subzona tersebut.

Jika server-server tersebut berada di dalam domain itu sendiri (misalnya, ns1.yourdomain.com), di zona utama Anda juga harus menambahkan catatan A (atau AAAA) untuk server-server tersebut , agar server-server tersebut dapat diresolusi dan resolver dapat menemukannya dengan benar.

Dari situ, pada server yang ditunjuk untuk subzona it.yourdomain.com, file zona baru dibuat dengan SOA-nya sendiri, NS-nya, dan semua catatan yang diperlukan (A, MX, TXT, dll.) untuk subdomain tersebut.

Dengan cara ini, permintaan untuk www.yourdomain.com akan terus diselesaikan di zona utama, sementara permintaan yang menuju ke it.yourdomain.com atau subdomain di dalam cabang tersebut akan menuju ke subzona yang didelegasikan , yang sekarang akan menjadi otoritas di bagian pohon tersebut.

Perubahan, pemantauan, dan masalah umum pada zona DNS

Setiap kali Anda menambahkan, memodifikasi, atau menghapus catatan di zona atau subzona DNS, Anda melakukan perubahan zona . Meskipun perubahan ini tampak sederhana, kelalaian dapat menimbulkan konsekuensi serius terhadap ketersediaan situs web, email, atau layanan penting.

Beberapa sistem memungkinkan Anda untuk mengaktifkan pemberitahuan perubahan zona (ZCN) atau mekanisme serupa sehingga server sekunder atau layanan eksternal mengetahui bahwa telah terjadi pembaruan dan menyinkronkan versi baru.

Masalah awal yang sangat umum adalah penundaan propagasi karena TTL yang panjang. Pengguna di berbagai belahan dunia mungkin melihat versi lama dan baru secara bersamaan, yang mempersulit diagnosis jika Anda tidak jelas mengenai masalah apa yang memengaruhi siapa.

Serangkaian kegagalan umum lainnya melibatkan kesalahan konfigurasi : IP yang salah, prioritas MX yang tidak tepat, CNAME yang disusun dengan buruk, nama tanpa titik di akhir padahal seharusnya ada, catatan duplikat atau bertentangan, dan lain sebagainya.

Untuk meminimalkan risiko, sebaiknya gunakan metodologi perubahan terkontrol: dokumentasikan modifikasi, terapkan perubahan terlebih dahulu di lingkungan pengujian jika memungkinkan, dan kemudian verifikasi dengan alat diagnostik DNS bahwa semuanya merespons sebagaimana mestinya.

Perbedaan antara zona DNS, subzona, dan server DNS

Sangat mudah untuk mengacaukan zona DNS dengan server DNS itu sendiri atau dengan konsep domain , tetapi ini adalah hal yang berbeda yang harus dipisahkan secara mental.

Zona DNS adalah cakupan administratif yang mendefinisikan sejauh mana wewenang suatu berkas zona tertentu. Zona ini dapat mencakup seluruh domain dan semua subdomainnya, atau hanya sebagian yang didelegasikan, seperti subzona tertentu.

Server DNS adalah mesin (fisik atau virtual) atau perangkat lunak yang menyimpan berkas zona ini dan menanggapi permintaan. Beberapa zona dan subzona yang termasuk dalam domain berbeda dapat berada di server yang sama.

Domain adalah nama yang terdaftar di TLD (mydomain.com, mydomain.es, dll.). Domain ini dapat diimplementasikan pada tingkat DNS sebagai zona tunggal atau sebagai beberapa subzona, tergantung pada bagaimana Anda ingin mendistribusikan administrasi dan beban.

Memisahkan zona berdasarkan subdomain bukanlah suatu keharusan, tetapi ini merupakan praktik yang sangat berguna seiring pertumbuhan infrastruktur Anda, karena memungkinkan delegasi yang lebih baik, skalabilitas, dan isolasi masalah . Kuncinya adalah selalu mendefinisikan dengan jelas bagian mana dari pohon nama Anda yang membutuhkan kemandirian administratif atau teknis.

Setelah konsep-konsep ini dipahami dan jelas apa itu zona, subzona, peran file zona, dan berbagai jenis record, pengelolaan DNS tidak lagi menjadi wilayah yang membingungkan; dengan perencanaan zona dan subzona yang baik, penggunaan TTL yang bijaksana, dan alat diagnostik yang tersedia, akan jauh lebih mudah untuk menjaga agar domain, subdomain, dan layanan berjalan dengan stabil, berkinerja tinggi, dan aman.