Arsitektur DNS di Windows Server

2025-04-04
Berlaku untuk: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

DNS adalah database terdistribusi hierarkis dan sekumpulan protokol terkait yang menentukan:

Mekanisme untuk mengkueri dan memperbarui database
Mekanisme untuk mereplikasi informasi dalam database di antara server
Sebuah skema database

Nama host DNS berada dalam database yang dapat didistribusikan di antara beberapa server, mengurangi beban pada satu server, dan memberikan kemampuan untuk mengelola sistem penamaan ini berdasarkan per partisi. DNS mendukung nama hierarkis dan memungkinkan pendaftaran berbagai tipe data selain pemetaan alamatto-IP nama host yang digunakan dalam file HOSTS. Database DNS didistribusikan, memungkinkannya untuk meningkatkan dan meluaskan skala, yang berarti performa tidak diturunkan ketika lebih banyak server ditambahkan.

DNS asli didasarkan pada Permintaan Komentar (RFC) 1035 (Nama Domain–Implementasi dan Spesifikasi). RFC lainnya menjelaskan masalah keamanan, implementasi, dan administratif DNS kemudian menambah spesifikasi desain asli.

RFC yang digunakan dalam sistem operasi Windows Server adalah:

Nama domain - konsep dan fasilitas RFC 1034
Nama domain - implementasi dan spesifikasi RFC 1035
Ekstensi DNS untuk mendukung IP versi 6 RFC 1886
Mekanisme untuk Pemberitahuan Cepat Perubahan Zona (DNS NOTIFY) RFC 1996
Transfer Zona Bertahap di DNS RFC 1995
Pembaruan Dinamis di Sistem Nama Domain (DNS UPDATE)RFC 2136
Penyimpanan Sementara Negatif Kueri DNS (DNS NCACHE) RFC 2308
Catatan Sumber Daya untuk Ekstensi Keamanan DNS RFC 4034
Modifikasi Protokol untuk Ekstensi Keamanan DNS RFC 4035
DNS RR untuk menentukan lokasi layanan (DNS SRV) RFC 2052

Nama domain DNS

DNS diimplementasikan sebagai database hierarkis dan terdistribusi yang berisi berbagai jenis data, termasuk nama host dan nama domain. Nama dalam database DNS membentuk struktur pohon hierarkis yang disebut namespace domain. Nama domain terdiri dari label individual yang dipisahkan oleh titik-titik, misalnya: mydomain.contoso.com.

Nama domain yang sepenuhnya memenuhi syarat (FQDN) secara unik mengidentifikasi posisi host dalam pohon hierarki DNS. FQDN menentukan daftar nama yang dipisahkan oleh titik-titik di jalur dari host yang direferensikan ke akar. Gambar berikut menunjukkan contoh pohon DNS dengan host yang disebut mydomain dalam domain contoso.com. Nama domain lengkap (FQDN) untuk host adalah mydomain.contoso.com.

Memahami ruang nama domain DNS

Namespace domain DNS, seperti yang ditunjukkan pada gambar sebelumnya, didasarkan pada konsep pohon domain bernama. Setiap tingkat pohon dapat mewakili cabang atau daun. Cabang adalah tingkat di mana lebih dari satu nama digunakan untuk mengidentifikasi kumpulan sumber daya bernama. Daun mewakili satu nama yang digunakan sekali pada tingkat tersebut untuk menunjukkan sumber daya tertentu.

Hierarki Nama Domain DNS

Klien dan server DNS menggunakan kueri sebagai metode penyelesaian nama di pohon ke jenis informasi sumber daya tertentu. Informasi ini disediakan oleh server DNS dalam respons kueri ke klien DNS yang kemudian mengekstrak informasi dan meneruskannya ke program yang meminta untuk menyelesaikan nama yang dikueri. Dalam proses menyelesaikan nama, server DNS sering berfungsi sebagai klien DNS, mengkueri server lain untuk menyelesaikan nama yang dikueri sepenuhnya.

Misalnya, Contoso diberikan otoritas oleh server root Internet untuk bagiannya sendiri dari pohon namespace domain DNS di Internet, yaitu contoso.com. Mengatasi nama di luar namespace contoso.com mengharuskan server DNS Contoso untuk mengkueri server DNS lain, seperti server root.

Bagaimana ruang nama domain DNS diatur

Nama domain DNS apa pun yang digunakan di pohon secara teknis adalah domain. Namun sebagian besar diskusi DNS mengidentifikasi nama dengan salah satu dari lima cara, berdasarkan tingkat dan cara nama umumnya digunakan. Misalnya, nama domain DNS yang terdaftar di Contoso (contoso.com) dikenal sebagai domain tingkat kedua. Nama ini memiliki dua bagian (dikenal sebagai label) yang menunjukkan terletak dua tingkat di bawah akar atau atas pohon. Sebagian besar nama domain DNS memiliki dua label atau lebih, yang masing-masing menunjukkan tingkat baru di pohon. Titik digunakan dalam nama untuk memisahkan label.

Tabel berikut ini menjelaskan lima kategori nama domain DNS berdasarkan fungsinya di namespace layanan, bersama dengan contoh setiap jenis nama.

Jenis nama	Deskripsi	Contoh
Domain akar (root domain)	Bagian atas pohon, mewakili tingkat yang tidak disebutkan namanya; terkadang ditampilkan sebagai dua tanda kutip kosong (""), menunjukkan nilai null. Saat digunakan dalam nama domain DNS, nama domain tersebut dinyatakan oleh periode berikutnya (.) untuk menunjuk bahwa nama tersebut terletak di tingkat akar atau tertinggi hierarki domain. Dalam hal ini, nama domain DNS dianggap lengkap dan menunjuk ke lokasi yang tepat di pohon nama. Nama yang dinyatakan dengan cara ini adalah FQDN. Satu titik (.) atau titik yang digunakan di akhir nama, seperti `example.contoso.com.`	Satu titik (.) atau titik yang digunakan di akhir nama, seperti `example.contoso.com.`
Domain tingkat atas (TLD)	Nama yang digunakan untuk menunjukkan negara atau wilayah atau jenis organisasi yang menggunakan nama.	`.com`, yang menunjukkan nama yang terdaftar ke bisnis untuk penggunaan komersial di Internet.
Domain tingkat kedua	Nama dengan panjang bervariasi yang didaftarkan untuk individu atau organisasi untuk digunakan di Internet. Nama-nama ini selalu didasarkan pada domain tingkat atas yang sesuai, tergantung pada jenis organisasi atau lokasi geografis tempat nama digunakan.	`contoso.com.` adalah nama domain tingkat kedua yang didaftarkan ke Contoso oleh pencatat nama domain DNS Internet.
Subdomain	Nama lain yang dapat dibuat organisasi yang berasal dari nama domain tingkat kedua terdaftar. Subdomain menyertakan nama yang ditambahkan untuk menumbuhkan pohon DNS nama dalam organisasi dan membaginya menjadi departemen atau lokasi geografis.	`example.contoso.com.` adalah subdomain yang ditetapkan oleh Contoso untuk digunakan dalam nama contoh dokumentasi.
Nama host atau sumber daya	Nama yang mewakili daun di pohon DNS nama dan mengidentifikasi sumber daya tertentu. Biasanya, label paling kiri dari nama domain DNS mengidentifikasi komputer tertentu di jaringan. Misalnya, jika nama pada tingkat ini digunakan dalam rekaman sumber daya host (A), nama tersebut digunakan untuk mencari alamat IP komputer berdasarkan nama hostnya.	`host-a.example.contoso.com.` Label pertama (host-a) adalah nama host DNS untuk komputer tertentu di jaringan.

Domain DNS dan Internet

Otoritas pendaftaran internet mengelola Sistem Nama Domain. Otoritas pendaftaran bertanggung jawab untuk mempertahankan domain tingkat atas yang ditetapkan oleh organisasi dan menurut negara/wilayah. Nama domain ini mengikuti Standar Internasional untuk kode negara (ISO 3166). Ada ratusan nama domain tingkat atas yang tersedia untuk digunakan oleh publik. Tabel berikut ini memperlihatkan beberapa TLD umum, serta contoh singkatan dua huruf yang digunakan untuk negara dan wilayah.

Nama Domain DNS	Jenis Organisasi
.Com	Organisasi komersial
.edu	Institusi pendidikan
.Org	Organisasi nirlaba
.jaring	Jaringan (tulang punggung Internet)
.Gov	Organisasi pemerintah nonmiliter
.mil	Organisasi pemerintah militer
.Arpa	DNS Terbalik
.Xx	Kode negara dua huruf (misalnya, `.us`, `.au`, `.ca`., `.fr`)

Rekaman sumber daya DNS

Rekaman sumber daya DNS berisi informasi yang dipertahankan zona tentang sumber daya (seperti host) yang dikandung zona tersebut. Catatan sumber daya umum terdiri dari:

Nama (host) rekaman sumber daya.
Informasi tentang berapa lama catatan sumber daya dapat tetap berada di cache.
Jenis catatan sumber daya, seperti catatan sumber daya host (A).
Data yang khusus untuk jenis catatan, seperti alamat IPv4 host.

Anda dapat menambahkan rekaman sumber daya secara langsung, atau mereka dapat ditambahkan secara otomatis ketika klien berkemampuan Dynamic Host Configuration Protocol (DHCP) berbasis Windows bergabung dengan jaringan menggunakan pembaruan dinamis.

Jenis rekaman sumber daya

Catatan sumber daya umum meliputi:

Jenis catatan sumber daya	Deskripsi
Catatan host (A, AAAA)	Memetakan nama host ke alamat IP.
Catatan alias (CNAME)	Teruskan nama domain alias atau subdomain ke nama utama atau kanonis lainnya. Rekaman sumber daya alias (CNAME) juga disebut rekaman sumber daya nama kanonis. Dengan catatan ini, Anda bisa menggunakan lebih dari satu nama DNS untuk menunjuk ke satu host.
Catatan mail exchanger (MX)	Menentukan nama komputer yang bertukar atau meneruskan email. Aplikasi email menggunakan catatan sumber daya mail exchanger (MX) untuk menemukan server email berdasarkan nama domain DNS di alamat tujuan untuk penerima email pesan. Jika ada beberapa catatan sumber daya mail exchanger (MX), layanan Klien DNS mencoba menghubungi server email dalam urutan preferensi dari nilai terendah (prioritas tertinggi) ke nilai tertinggi (prioritas terendah).
Rekaman pointer (PTR)	Digunakan oleh pencarian DNS terbalik untuk memetakan alamat IP ke domain. Rekaman sumber daya Pointer (PTR) mendukung proses pencarian terbalik, berdasarkan zona yang dibuat dan berakar di domain `in-addr.arpa`. Anda harus memiliki zona pencarian terbalik yang sesuai yang ada di server DNS Anda untuk membuat catatan PTR yang memetakan alamat IP ke nama host tertentu.
Rekaman lokasi layanan (SRV)	Menentukan host, port, dan protokol untuk layanan. Catatan sumber daya lokasi layanan (SRV) diperlukan saat klien menggunakan DNS untuk menemukan layanan lokasi seperti pengontrol domain Direktori Aktif.
Catatan server nama (NS)	Menentukan server nama otoritatif untuk domain.
Rekaman teks (TXT)	Mengaktifkan publikasi teks dalam catatan DNS. Rekaman teks memungkinkan Anda menambahkan informasi teks yang dikembalikan dengan mengkueri DNS. Catatan TXT sering digunakan untuk mengautentikasi kepemilikan zona DNS.
Catatan nama delegasi (DNAME)	Menyediakan alias untuk domain, seperti data CNAME, tetapi menyertakan semua subdomain.
Catatan awal otoritas (SOA)	Menyediakan informasi otoritatif tentang zona DNS. Catatan SOA mencakup server nama utama, kontak administrator zona DNS, informasi refresh, dan informasi lainnya.

Time-to-Live untuk rekaman sumber daya

Nilai Time-to-Live (TTL) dalam rekaman sumber daya menunjukkan lamanya waktu yang digunakan oleh server DNS lain untuk menentukan berapa lama menyimpan informasi untuk rekaman sebelum kedaluwarsa dan membuangnya. Misalnya, sebagian besar rekam sumber daya yang dibuat oleh layanan Server DNS mewarisi TTL minimum (default) satu jam dari rekam sumber daya awal otoritas (SOA), yang mencegah penyimpanan dalam cache yang diperpanjang oleh server DNS lainnya.

Pemecah masalah klien DNS menyimpan respons yang diterimanya saat menyelesaikan kueri DNS. Respons cache ini kemudian dapat digunakan untuk menjawab kueri nanti untuk informasi yang sama. Namun, data yang di-cache memiliki masa pakai terbatas yang ditentukan dalam parameter TTL yang dikembalikan dengan data respons. TTL memastikan bahwa server DNS tidak menyimpan informasi begitu lama sehingga menjadi kedaluarsa. TTL untuk cache dapat diatur pada database DNS (untuk setiap catatan sumber daya individual, dengan menentukan bidang TTL dari catatan tersebut dan per zona melalui bidang TTL minimum dari catatan SOA) serta di sisi resolver klien DNS dengan menentukan TTL maksimum yang diizinkan resolver untuk menyimpan cache catatan sumber daya.

Ada dua faktor yang bersaing yang perlu dipertimbangkan saat mengatur TTL. Yang pertama adalah akurasi informasi yang di-cache, dan yang kedua adalah pemanfaatan server DNS dan jumlah lalu lintas jaringan. Jika TTL pendek, maka kemungkinan memiliki informasi lama berkurang jauh, tetapi meningkatkan penggunaan server DNS dan lalu lintas jaringan, karena klien DNS harus meminta server DNS untuk data yang kedaluwarsa pada saat permintaan berikutnya. Jika TTL panjang, respons yang di-cache bisa menjadi kedaluarsa, yang berarti pemecah masalah dapat memberikan jawaban palsu untuk kueri. Pada saat yang sama, TTL panjang mengurangi pemanfaatan server DNS dan mengurangi lalu lintas jaringan karena klien DNS menjawab kueri menggunakan data yang di-cache.

Jika kueri dijawab dengan entri dari cache, maka TTL dari entri tersebut juga diteruskan bersama respons. Dengan cara ini, pemecah masalah yang menerima respons mengetahui berapa lama entri valid. Resolver mengikuti TTL dari server yang merespons; mereka tidak mengaturnya ulang berdasarkan TTL mereka sendiri. Jadi, entri benar-benar kedaluwarsa daripada bertahan selamanya saat mereka berpindah dari server DNS ke server DNS dengan TTL yang diperbarui.

Nota

Secara umum, jangan pernah mengonfigurasi TTL ke nol. Perbedaan antara pengaturan 0 atau 60 minimal terhadap akurasi rekaman, tetapi ketika TTL diatur ke 0, ada dampak signifikan pada performa server DNS karena server DNS terus mengkueri data yang kedaluwarsa.

Zona dan delegasi

Database DNS dapat dipartisi ke dalam beberapa zona. Zona adalah bagian dari database DNS yang berisi rekaman sumber daya dengan nama pemilik milik bagian yang berdampingan dari namespace DNS. File zona dipertahankan di server DNS. Satu server DNS dapat dikonfigurasi untuk menghosting nol, satu, atau beberapa zona.

Setiap zona berlabuh pada nama domain tertentu yang disebut sebagai domain akar zona. Zona berisi informasi tentang semua nama yang diakhir dengan nama domain akar zona. Server DNS dianggap otoritatif untuk nama jika memuat zona yang berisi nama tersebut. Catatan pertama dalam file zona mana pun adalah catatan sumber daya Start of Authority (SOA). Catatan sumber daya SOA mengidentifikasi server nama DNS utama untuk zona tersebut sebagai sumber informasi terbaik untuk data dalam zona tersebut. SOA juga bertindak sebagai entitas yang memproses pembaruan untuk zona tersebut.

Nama dalam zona juga dapat didelegasikan ke zona lain yang dihosting di server DNS yang berbeda. Delegasi adalah proses menetapkan tanggung jawab untuk sebagian namespace DNS ke server DNS yang dimiliki oleh entitas terpisah. Entitas terpisah ini dapat berupa organisasi, departemen, atau grup kerja lain dalam perusahaan Anda. Delegasi tersebut diwakili oleh catatan sumber daya NS yang menentukan zona yang didelegasikan dan nama DNS server otoritatif untuk zona tersebut. Mendelegasikan di beberapa zona adalah bagian dari tujuan desain asli DNS.

Untuk mempelajari selengkapnya tentang jenis dan replikasi zona DNS, lihat Zona DNS.

Alasan untuk mendelegasikan namespace DNS meliputi:

Kebutuhan untuk mendelegasikan manajemen domain DNS ke banyak organisasi atau departemen dalam organisasi.
Kebutuhan untuk mendistribusikan beban mempertahankan satu database DNS besar di antara beberapa server DNS untuk meningkatkan performa resolusi nama dan membuat lingkungan yang toleran terhadap kesalahan DNS.
Diperlukan untuk mengakomodasi afiliasi organisasi host dengan memasukkan host ke dalam domain yang tepat. Rekaman sumber daya server nama (NS) memfasilitasi delegasi dengan mengidentifikasi server DNS untuk setiap zona dan rekaman sumber daya NS muncul di semua zona. Setiap kali server DNS perlu melewati delegasi untuk memecahkan nama, mereka mengacu pada rekam sumber daya NS untuk server DNS di zona target.

Gambar berikut menunjukkan bagaimana manajemen domain contoso.com didelegasikan di dua zona, contoso.com dan mydomain.contoso.com.

Nota

Jika beberapa catatan NS ada untuk zona yang didelegasikan yang mengidentifikasi beberapa server DNS yang tersedia untuk kueri, layanan Server DNS Windows Server akan dapat memilih server DNS terdekat berdasarkan interval pulang pergi yang diukur dari waktu ke waktu untuk setiap server DNS.

Arsitektur layanan DNS

Diagram berikut mengilustrasikan arsitektur layanan DNS Klien dalam operasi pengenalan nama dan pembaruan di klien Windows dan Windows Server. Arsitektur resolusi nama ditunjukkan menggunakan aplikasi klien dan pembaruan diwakili oleh klien DHCP.

Diagram berikut mengilustrasikan arsitektur layanan DNS Server dengan alat administrasi dan antarmuka Windows Management Instrumentation (WMI) di Windows Server.

Bagian berikut ini menjelaskan proses kueri DNS dan bagaimana pembaruan DNS ditangani.

Kueri DNS

Kueri DNS dapat dikirim dari klien DNS (resolver) ke server DNS, atau di antara dua server DNS.

Kueri DNS hanyalah permintaan untuk rekaman sumber daya DNS dari jenis catatan sumber daya tertentu dengan nama DNS tertentu. Misalnya, kueri DNS dapat meminta semua rekaman sumber daya tipe A (host) dengan nama DNS tertentu.

Ada dua jenis kueri DNS yang dapat dikirim ke server DNS:

Rekursif : Kueri rekursif memaksa server DNS untuk menanggapi permintaan dengan respons gagal atau berhasil. Klien DNS (resolver) biasanya membuat kueri rekursif. Dengan kueri rekursif, server DNS harus menghubungi server DNS lain yang diperlukan untuk menyelesaikan permintaan. Ketika menerima respons yang berhasil dari server DNS lainnya (atau server), ia kemudian mengirim respons ke klien DNS. Kueri rekursif adalah jenis kueri umum yang digunakan oleh pemecah masalah yang mengkueri server DNS dan oleh server DNS yang mengkueri penerusnya, yang merupakan server DNS lain yang dikonfigurasi untuk menangani permintaan yang diteruskan ke server TERSEBUT.

Saat server DNS memproses kueri rekursif dan kueri tidak dapat diselesaikan dari data lokal (file zona lokal atau cache kueri sebelumnya), kueri rekursif harus dieskalasikan ke server DNS akar. Setiap implementasi DNS berbasis standar mencakup file cache (atau petunjuk server root) yang berisi entri untuk server DNS akar domain Internet. (Jika server DNS dikonfigurasi dengan penerus, penerus digunakan sebelum server root digunakan.)
Iteratif: Kueri iteratif adalah kueri di mana server DNS diharapkan merespons dengan informasi lokal terbaik yang dimilikinya, berdasarkan apa yang diketahui server DNS dari file zona lokal atau dari cache. Respons ini juga dikenal sebagai rujukan jika server DNS tidak otoritatif untuk nama tersebut. Jika server DNS tidak memiliki informasi lokal yang dapat menjawab kueri, server DNS hanya mengirim respons negatif. Server DNS membuat jenis kueri ini karena mencoba menemukan nama di luar domain lokalnya (atau domain) (saat tidak dikonfigurasi dengan penerus). Ini mungkin harus mengirim kueri ke server DNS eksternal untuk mencoba menyelesaikan nama.

Gambar berikut menunjukkan contoh kedua jenis kueri.

Diagram menunjukkan bagaimana beberapa kueri digunakan untuk menentukan alamat IP untuk www.contoso.com. Urutan kueri dijelaskan sebagai berikut:

Kueri rekursif untuk www.contoso.com (Rekaman sumber daya).
Kueri iteratif untuk www.contoso.com (Catatan sumber daya).
Rujukan ke server nama .com (rekaman sumber daya NS, untuk .com); untuk kesederhanaan, kueri A berulang oleh server DNS untuk menyelesaikan alamat IP dari nama Host yang dikembalikan oleh server nama lain telah dihilangkan.
Kueri iteratif untuk www.contoso.com (Catatan sumber daya).
Rujukan ke server nama contoso.com (catatan sumber daya NS, untuk contoso.com).
Kueri iteratif untuk www.contoso.com (Catatan sumber daya).
Jawaban atas kueri berulang dari server contoso.com (Alamat IP www.contoso.com).
Jawaban atas kueri rekursif asli dari server DNS lokal ke resolver (Alamat IP www.contoso.com).

Memperbarui DNS

Rekaman sumber daya sering berubah saat komputer, server, dan perangkat ditambahkan ke atau dihapus dari jaringan. Implementasi DNS di Windows Server mendukung pembaruan statis dan dinamis database DNS.

Rekaman sumber daya dapat ditambahkan ke zona yang sudah ada menggunakan perintah PowerShell Add-DNSServerResourceRecord . Beberapa jenis catatan sumber daya umum memiliki perintah PowerShell lainnya di mana Anda tidak perlu menentukan jenis catatan sumber daya. Anda juga dapat menambahkan rekaman sumber daya menggunakan konsol DNS Manager. Lihat Mengelola rekaman sumber daya DNS untuk panduan tentang bekerja dengan rekaman sumber daya, termasuk membuat dan memodifikasi rekaman sumber daya yang ada dari semua jenis.

Dukungan karakter Unicode

Ketika DNS diperkenalkan sebagai bagian dari RFC 1035, nama dibatasi untuk menggunakan huruf besar dan huruf kecil (A-Z, a-z), angka (0-9), dan tanda hubung (-). Selain itu, karakter pertama nama DNS dapat berupa angka dan nama harus dikodekan dan diwakili menggunakan karakter berbasis AS-ASCII. Untuk penggunaan DNS dalam pengaturan internasional, persyaratan ini menciptakan batasan signifikan di mana set karakter yang diperluas digunakan untuk standar penamaan lokal. Layanan DNS Windows Server menyediakan dukungan yang ditingkatkan, di luar spesifikasi RFC 1035, untuk karakter UTF-8.

Apa itu UTF-8?

UTF-8 adalah set karakter yang direkomendasikan untuk protokol yang berkembang di luar penggunaan ASCII. Protokol UTF-8 menyediakan dukungan karakter ASCII yang diperluas dan terjemahan UCS-2, set karakter Unicode 16-bit yang mencakup sebagian besar sistem penulisan dunia. UTF-8 memungkinkan rentang nama yang jauh lebih besar daripada yang dapat dicapai menggunakan ASCII atau pengodean ASCII yang diperluas untuk data karakter.

Komputer yang menjalankan Windows Server 2008 mengetahui UTF-8. Artinya, ketika karakter yang dikodekan UTF-8 diterima atau digunakan sebagai data oleh server, server dapat memuat dan menyimpan data ini di zonanya. Meskipun server DNS berbasis Windows mengetahui UTF-8, server DNS tersebut tetap kompatibel dengan server DNS lain yang menggunakan pengodean data US-ASCII tradisional dan standar DNS saat ini.

Bagaimana layanan DNS menerapkan UTF-8

Untuk memberikan kompatibilitas standar dan interoperabilitas dengan implementasi DNS lainnya, layanan DNS menggunakan downcasing seragam dari data karakter yang diterima. Dalam proses ini, layanan DNS mengonversi semua karakter huruf besar yang digunakan dalam data US-ASCII standar menjadi data yang setara huruf kecil karena alasan berikut:

Untuk mempertahankan kompatibilitas dengan standar DNS saat ini dan yang sudah ada.
Untuk memberikan interoperabilitas dengan implementasi server DNS yang tidak mengenali atau mendukung pengodean UTF-8.

Untuk memahami mengapa downcasing seragam dipilih, beberapa poin terkait harus terlebih dahulu dipertimbangkan dari standar Internet yang direvisi saat ini untuk DNS. Beberapa poin utama dalam standar berkaitan langsung dengan bagaimana data karakter akan ditangani antara server DNS dan server dan klien lainnya. Poin utama meliputi:

String biner apa pun dapat digunakan dalam nama DNS. (RFC 2181)
Server DNS harus dapat membandingkan nama dengan cara yang tidak peka huruf besar/kecil. (RFC 1035)
Kasus asli untuk data karakter harus dipertahankan jika memungkinkan karena data dimasukkan ke dalam sistem. (RFC 1035)

Karena ketidakpekaan kasus adalah bagian yang diperlukan dari standar DNS inti dan pelestarian kasus adalah rekomendasi opsional, downcasing seragam dipilih untuk memberikan solusi yang mematuhi standar yang efektif. Dengan menurunkan skala nama yang dikodekan UTF-8 sebelum transmisi, server DNS lain (yang tidak sadar UTF-8) dapat menerima dan melakukan perbandingan biner data yang berhasil dan mendapatkan hasil yang diinginkan.

Pertimbangan untuk interoperabilitas dengan UTF-8

Layanan Server DNS dapat diatur untuk mengizinkan atau memblokir penggunaan karakter UTF-8 untuk setiap server. Beberapa server DNS yang tidak mendukung UTF-8 mungkin menerima zona dengan nama UTF-8 tetapi mungkin mengalami masalah saat menyimpan atau memuat ulang nama-nama tersebut. Berhati-hatilah saat mentransfer zona dengan nama UTF-8 ke server yang tidak mendukung UTF-8.

Beberapa protokol menempatkan pembatasan pada karakter yang diizinkan dalam nama. Selain itu, nama yang dimaksudkan untuk terlihat secara global (RFC 1958) harus berisi karakter khusus ASCII, seperti yang direkomendasikan dalam RFC 1123.

Menggunakan UTF-8 untuk mengubah karakter Unicode tidak terlihat oleh pengguna. Namun, Anda dapat melihat karakter yang dikodekan UTF-8 jika Anda menggunakan Monitor Jaringan atau alat serupa untuk menganalisis lalu lintas DNS.

Selain dukungan server DNS untuk format pengodean UTF-8, pemecah masalah klien default menggunakan format pengodean karakter UTF-8.

Nama yang dikodekan dalam format UTF-8 tidak boleh melebihi batas ukuran yang diklarifikasi dalam RFC 2181, yang menentukan maksimum 63 oktet per label dan 255 oktet per nama. Jumlah karakter tidak cukup untuk menentukan ukuran karena beberapa karakter UTF-8 melebihi satu oktet panjangnya.

Protokol pengodean UTF-8 beradaptasi untuk digunakan dengan implementasi protokol DNS yang ada yang mengharapkan karakter US-ASCII karena representasi karakter US-ASCII dalam UTF-8 identik, byte untuk byte, ke representasi US-ASCII. Implementasi klien DNS atau server yang tidak mengenali karakter UTF-8 selalu mengodekan nama dalam format US-ASCII. Layanan Server DNS dapat menginterpretasikan nama-nama tersebut dengan benar.

Layanan DNS dapat mengonfigurasi pemeriksaan nama untuk mengizinkan atau membatasi penggunaan karakter UTF-8 dalam data DNS.

Secara default, pemeriksaan nama UTF-8 multibyte digunakan, memungkinkan toleransi terbesar saat layanan DNS memproses karakter. Pemeriksaan nama UTF-8 multibyte adalah metode pemeriksaan nama pilihan untuk sebagian besar server DNS yang dioperasikan secara privat yang tidak menyediakan layanan nama untuk host Internet.