Sistem Nama Domain (DNS) adalah layanan nama hierarkis dan terdistribusi yang menyediakan sistem penamaan untuk komputer, layanan, dan sumber daya lainnya di Internet atau jaringan Protokol Internet (IP) lainnya. Ini mengaitkan berbagai informasi dengan nama domain (string identifikasi) yang diberikan kepada setiap entitas terkait. Yang paling penting, ini menerjemahkan nama domain yang mudah diingat menjadi alamat IP numerik yang diperlukan untuk menemukan dan mengidentifikasi layanan dan perangkat komputer dengan protokol jaringan yang mendasarinya. DNS telah menjadi komponen penting dari fungsionalitas Internet sejak tahun 1985.
Sistem Nama Domain menugaskan tanggung jawab penugasan nama domain dan pemetaan nama-nama tersebut ke sumber daya Internet dengan menunjuk server nama berwibawa untuk setiap domain. Administrator jaringan dapat menugaskan otoritas atas subdomain dari ruang nama yang diberikan mereka ke server nama lain. Mekanisme ini menyediakan layanan yang didistribusikan dan toleran terhadap kesalahan dan dirancang untuk menghindari database pusat tunggal yang besar. Selain itu, DNS menetapkan fungsionalitas teknis dari layanan database yang menjadi inti. Ini mendefinisikan protokol DNS, spesifikasi rinci struktur data dan pertukaran komunikasi data yang digunakan dalam DNS, sebagai bagian dari suite protokol internet.
Internet menjaga dua namespace utama, yaitu hierarki nama domain dan ruang alamat IP. Sistem Nama Domain menjaga hierarki nama domain dan menyediakan layanan terjemahan antara ini dan ruang alamat. Server nama internet dan protokol komunikasi menerapkan Sistem Nama Domain. Sebuah server nama DNS adalah server yang menyimpan catatan DNS untuk sebuah domain; server nama DNS merespons dengan jawaban terhadap pertanyaan terhadap database-nya.Jenis catatan yang paling umum disimpan dalam database DNS adalah untuk awal otoritas (SOA), alamat IP (A dan AAAA), pertukaran surat elektronik SMTP (MX), server nama (NS), penunjuk untuk pencarian DNS terbalik (PTR), dan alias nama domain (CNAME). Meskipun tidak dimaksudkan untuk menjadi database umum, DNS telah diperluas dari waktu ke waktu untuk menyimpan catatan untuk jenis data lain untuk entri otomatis, seperti catatan DNSSEC, atau untuk kueri manusia seperti catatan orang yang bertanggung jawab (RP). Sebagai database umum, DNS juga telah digunakan dalam memerangi email yang tidak diinginkan (spam) dengan menyimpan daftar blokir. Database DNS secara konvensional disimpan dalam file teks terstruktur, file zona, tetapi sistem database lain umum. Sistem Nama Domain awalnya menggunakan User Datagram Protocol (UDP) sebagai transportasi di atas IP. Keandalan, keamanan, dan masalah privasi mendorong penggunaan Transmission Control Protocol (TCP) serta banyak pengembangan protokol lainnya.
Fungsi DNS sering dijelaskan dengan analogi sebagai buku telepon untuk Internet yang menerjemahkan nama host komputer yang ramah pengguna menjadi alamat IP. Misalnya, nama host www.example.com dalam nama domain example.com diterjemahkan menjadi alamat 93.184.216.34 (IPv4) dan 2606:2800:220:1:248:1893:25c8:1946 (IPv6). DNS dapat diperbarui dengan cepat dan transparan, memungkinkan lokasi layanan di jaringan berubah tanpa memengaruhi pengguna akhir, yang terus menggunakan nama host yang sama. Pengguna memanfaatkan ini ketika mereka menggunakan URL yang bermakna dan alamat email tanpa harus tahu bagaimana komputer benar-benar menemukan layanan tersebut.
Fungsi penting dan luas dari DNS adalah peran sentralnya dalam layanan Internet terdistribusi seperti layanan cloud dan jaringan pengiriman konten. Ketika pengguna mengakses layanan Internet terdistribusi menggunakan URL, nama domain dari URL diterjemahkan ke alamat IP server yang berdekatan dengan pengguna. Fungsi kunci dari DNS yang dieksploitasi di sini adalah bahwa pengguna yang berbeda dapat secara bersamaan menerima terjemahan yang berbeda untuk nama domain yang sama, titik perbedaan utama dari pandangan buku telepon tradisional dari DNS. Proses menggunakan DNS untuk menetapkan server yang berdekatan dengan pengguna adalah kunci untuk memberikan respon yang lebih cepat dan lebih dapat diandalkan di Internet dan luas digunakan oleh sebagian besar layanan Internet utama.
DNS mencerminkan struktur tanggung jawab administratif di Internet. Setiap subdomain adalah zona otonomi administratif yang didelegasikan kepada seorang manajer. Untuk zona yang dioperasikan oleh sebuah registrar, informasi administratif sering dilengkapi dengan layanan RDAP dan WHOIS registrar. Data tersebut dapat digunakan untuk mendapatkan wawasan dan melacak tanggung jawab untuk host tertentu di Internet.
Sejarah
Menggunakan nama yang lebih sederhana dan mudah diingat sebagai pengganti alamat numerik host berasal dari era ARPANET. Stanford Research Institute (sekarang SRI International) memelihara file teks bernama HOSTS.TXT yang memetakan nama host ke alamat numerik komputer di ARPANET. Elizabeth Feinler mengembangkan dan menjaga direktori ARPANET pertama. Pemeliharaan alamat numerik, yang disebut Daftar Angka Tertentu, ditangani oleh Jon Postel di Information Sciences Institute (ISI) University of Southern California, yang bekerja sama dengan SRI.
Alamat diberikan secara manual. Komputer, termasuk nama host dan alamatnya, ditambahkan ke file utama dengan menghubungi SRI Network Information Center (NIC), yang dipimpin oleh Feinler, melalui telepon selama jam kerja. Kemudian, Feinler menyiapkan direktori WHOIS di server NIC untuk pengambilan informasi tentang sumber daya, kontak, dan entitas. Dia dan timnya mengembangkan konsep domain. Feinler menyarankan bahwa domain harus didasarkan pada lokasi alamat fisik komputer. Komputer di lembaga pendidikan akan memiliki domain edu, misalnya. Dia dan timnya mengelola Host Naming Registry dari tahun 1972 hingga 1989. Pada awal 1980-an, memelihara tabel host tunggal yang terpusat menjadi lambat dan sulit diurus dan jaringan yang muncul membutuhkan sistem penamaan otomatis untuk mengatasi masalah teknis dan personil. Postel menugaskan tugas untuk merumuskan kompromi antara lima proposal solusi yang bersaing kepada Paul Mockapetris. Mockapetris malah menciptakan Sistem Nama Domain pada tahun 1983 saat berada di University of Southern California.
Internet Engineering Task Force menerbitkan spesifikasi asli dalam RFC 882 dan RFC 883 pada November 1983. Ini diperbarui dalam RFC 973 pada Januari 1986. Pada tahun 1984, empat mahasiswa UC Berkeley, Douglas Terry, Mark Painter, David Riggle, dan Songnian Zhou, menulis implementasi server nama Unix pertama untuk Berkeley Internet Name Domain, yang umumnya disebut BIND. Pada tahun 1985, Kevin Dunlap dari DEC secara substansial merevisi implementasi DNS. Mike Karels, Phil Almquist, dan Paul Vixie kemudian mengambil alih pemeliharaan BIND. Internet Systems Consor|-tium didirikan pada tahun 1994 oleh Rick Adams, Paul Vixie, dan Carl Malamud, khusus untuk memberikan tempat bagi pengembangan dan pemeliharaan BIND. Versi BIND mulai dari 4.9.3 ke atas dikembangkan dan dipelihara oleh ISC, dengan dukungan yang diberikan oleh sponsor ISC. Sebagai arsitek/programmer bersama, Bob Halley dan Paul Vixie merilis versi BIND produksi pertama yaitu versi 8 pada Mei 1997. Sejak tahun 2000, lebih dari 43 pengembang inti yang berbeda telah bekerja pada BIND. Pada November 1987, RFC 1034 dan RFC 1035 menggantikan spesifikasi DNS tahun 1983. Beberapa Request for Comments tambahan telah mengusulkan perluasan pada protokol inti DNS.
Ruang nama domain
Ruang nama domain terdiri dari struktur data pohon. Setiap node atau daun dalam pohon memiliki label dan nol atau lebih catatan sumber daya (RR), yang menyimpan informasi yang terkait dengan nama domain. Nama domain itu sendiri terdiri dari label, digabungkan dengan nama node induknya di sebelah kanan, dipisahkan oleh titik.Pohon ini terbagi menjadi zona yang dimulai dari zona akar. Sebuah zona DNS dapat terdiri dari banyak domain dan subdomain sesuai pilihan manajer zona. DNS juga dapat dipartisi sesuai dengan kelas di mana kelas-kelas terpisah dapat dianggap sebagai array pohon ruang nama paralel.
Tanggung jawab administratif untuk setiap zona dapat dibagi dengan membuat zona tambahan. Otoritas atas zona baru dikatakan di-delegasikan ke server nama yang ditentukan. Zona induk berhenti menjadi otoritatif untuk zona baru.
Sintaks nama domain, internasionalisasi
Deskripsi definitif aturan untuk membentuk nama domain terdapat di RFC 1035, RFC 1123, RFC 2181, dan RFC 5892. Sebuah nama domain terdiri dari satu atau lebih bagian, yang secara teknis disebut label, yang biasanya digabungkan, dan dipisahkan oleh titik, seperti contoh.com. Label paling kanan menyampaikan domain tingkat atas; misalnya, nama domain www.contoh.com milik domain tingkat atas com. Hiranrkhi domain turun dari kanan ke kiri; setiap label ke kiri menentukan subdivisi, atau subdomain dari domain ke kanan. Misalnya, label contoh menentukan subdomain dari domain com, dan www adalah subdomain dari contoh.com. Pohon subdivisi ini dapat memiliki hingga 127 tingkatan. Sebuah label dapat mengandung nol hingga 63 karakter, karena panjangnya hanya diizinkan mengambil 6 bit. Label nol panjang nol direservasi untuk zona akar. Nama domain lengkap tidak boleh melebihi panjang 253 karakter dalam representasinya secara tekstual (atau 254 dengan titik terakhir). Dalam representasi biner internal DNS panjang maksimum 253 ini memerlukan 255 oktet penyimpanan, karena juga menyimpan panjang label pertama dari banyak label dan menambahkan byte nol terakhir. Panjang 255 hanya tercapai dengan setidaknya 6 label (menghitung label nol terakhir). Meskipun tidak ada batasan teknis yang ada untuk mencegah label nama domain menggunakan karakter apa pun yang dapat direpresentasikan oleh oktet, nama host menggunakan format dan set karakter yang disukai. Karakter yang diizinkan dalam label adalah subset dari set karakter ASCII, terdiri dari karakter a sampai z, A sampai Z, angka 0 sampai 9, dan tanda hubung. Aturan ini dikenal sebagai aturan LDH (huruf, angka, tanda hubung). Nama domain diinterpretasikan secara tidak bergantung pada kasus. Label tidak boleh diawali atau diakhiri dengan tanda hubung. Aturan tambahan mensyaratkan bahwa nama domain tingkat atas tidak boleh seluruhnya numerik. Set karakter ASCII terbatas yang diizinkan dalam DNS mencegah representasi nama dan kata dari banyak bahasa dalam abjad atau aksara asli mereka. Untuk membuat ini memungkinkan, ICANN menyetujui sistem Nama Domain Internasional dalam Aplikasi (IDNA), di mana aplikasi pengguna, seperti browser web, memetakan string Unicode ke dalam set karakter DNS yang valid menggunakan Punycode. Pada tahun 2009, ICANN menyetujui pemasangan domain kode negara nama domain internasional (ccTLD). Selain itu, banyak registrasi dari nama domain tingkat atas yang ada (TLD) telah mengadopsi sistem IDNA, yang dipandu oleh RFC 5890, RFC 5891, RFC 5892, RFC 5893.
Server Name adalah bagian dari Sistem Nama Domain yang dipelihara oleh sistem pangkalan data terdistribusi, yang menggunakan model klien-server. Setiap domain memiliki setidaknya satu server DNS yang berwenang yang mempublikasikan informasi tentang domain tersebut dan server nama dari domain-domain yang lebih rendah darinya. Bagian paling atas dari hierarki ini dilayani oleh server nama akar, server untuk mengajukan pertanyaan saat mencari (menyelesaikan) TLD.
Server nama yang berwenang adalah server nama yang hanya memberikan jawaban kepada pertanyaan DNS dari data yang telah dikonfigurasi oleh sumber asli, misalnya, administrator domain atau dengan metode DNS dinamis, berbeda dengan jawaban yang diperoleh melalui pertanyaan ke server nama lain yang hanya memelihara cache data.Server nama yang berwenang dapat berupa server primer atau server sekunder. Secara historis, istilah master/slave dan primer/sekunder kadang-kadang digunakan secara bergantian tetapi praktik saat ini adalah menggunakan bentuk terakhir. Server primer adalah server yang menyimpan salinan asli dari semua catatan zona. Server sekunder menggunakan mekanisme pembaruan otomatis khusus dalam protokol DNS dalam komunikasi dengan server primer untuk menjaga salinan identik dari catatan primer.
Setiap zona DNS harus ditugaskan set server nama yang berwenang. Set server ini disimpan dalam zona domain induk dengan catatan server nama (NS). Sebuah server yang berwenang menunjukkan statusnya sebagai sumber jawaban definitif, dianggap berwenang, dengan mengatur tanda protokol, yang disebut "Jawaban Berwenang" (AA) dalam responnya. Tanda ini biasanya diproduksi dengan jelas dalam output alat kueri administrasi DNS, seperti dig, untuk menunjukkan bahwa server nama yang merespons adalah otoritas untuk nama domain yang ditanyakan. Ketika server nama ditunjuk sebagai server berwenang untuk sebuah nama domain yang tidak memiliki data yang berwenang, itu menimbulkan jenis kesalahan yang disebut "delegasi tidak berfungsi" atau "tanggapan tidak berfungsi".
Mekanisme resolusi alamat merupakan proses di mana resolusi nama domain menentukan server nama domain yang bertanggung jawab atas nama domain yang dimaksud dengan urutan pertanyaan dimulai dari label domain paling kanan (domain paling atas).
Sebuah resolver DNS yang menerapkan pendekatan iteratif yang diwajibkan oleh RFC 1034; dalam hal ini, resolver mengonsultasikan tiga server nama untuk menyelesaikan nama domain penuh "www.contoh.org".
Untuk operasi yang tepat dari resolver nama domainnya, sebuah host jaringan dikonfigurasi dengan cache awal (petunjuk) dari alamat yang diketahui dari server nama root. Petunjuk ini diperbarui secara berkala oleh administrator dengan mengambil dataset dari sumber yang dapat dipercaya. Diasumsikan resolver tidak memiliki catatan cache untuk mempercepat proses, proses resolusi dimulai dengan pertanyaan ke salah satu server root. Dalam operasi yang tipikal, server root tidak menjawab secara langsung, tetapi memberikan referral ke server yang lebih berwenang, misalnya, sebuah pertanyaan untuk "www.wikipedia.org" dirujuk ke server org. Resolver sekarang mengajukan pertanyaan ke server yang dirujuk, dan mengulangi proses ini secara iteratif sampai menerima jawaban yang berwenang. Diagram mengilustrasikan proses ini untuk host yang dinamai oleh nama domain penuh "www.contoh.org".
Mekanisme ini akan menempatkan beban lalu lintas yang besar pada server root, jika setiap resolusi di Internet memerlukan memulai dari root. Dalam praktiknya, caching digunakan di server DNS untuk mengurangi beban pada server root, dan akibatnya, server nama root sebenarnya hanya terlibat dalam sebagian kecil permintaan.
Server nama rekursif dan caching
Secara teoritis, server nama otoritatif sudah cukup untuk operasi Internet. Namun, dengan hanya server nama otoritatif yang beroperasi, setiap kueri DNS harus dimulai dengan kueri rekursif di zona root Sistem Nama Domain dan setiap sistem pengguna harus menerapkan perangkat lunak resolver yang mampu beroperasi rekursif.
Untuk meningkatkan efisiensi, mengurangi lalu lintas DNS di seluruh Internet, dan meningkatkan kinerja dalam aplikasi pengguna akhir, Sistem Nama Domain mendukung server cache DNS yang menyimpan hasil kueri DNS untuk jangka waktu yang ditentukan dalam konfigurasi (time-to-live) dari catatan nama domain yang dimaksud. Biasanya, server DNS caching tersebut juga menerapkan algoritma rekursif yang diperlukan untuk menyelesaikan nama yang diberikan dimulai dari akar DNS hingga server nama otoritatif dari domain yang ditanya. Dengan fungsi ini diimplementasikan di server nama, aplikasi pengguna mendapatkan efisiensi dalam desain dan operasi. Kombinasi caching DNS dan fungsi rekursif dalam server nama tidak wajib; fungsi tersebut dapat diimplementasikan secara independen di server untuk tujuan khusus. Penyedia layanan Internet biasanya menyediakan server nama rekursif dan caching untuk pelanggannya. Selain itu, banyak router jaringan rumahan mengimplementasikan cache DNS dan rekursi untuk meningkatkan efisiensi dalam jaringan lokal.
Resolver DNS
Bagian klien dari DNS disebut resolver DNS. Sebuah resolver bertanggung jawab untuk memulai dan mengurutkan kueri yang pada akhirnya mengarah pada resolusi penuh (terjemahan) dari sumber yang dicari, misalnya, terjemahan nama domain menjadi alamat IP. Resolver DNS diklasifikasikan berdasarkan berbagai metode kueri, seperti rekursif, non-rekursif, dan iteratif. Proses resolusi dapat menggunakan kombinasi metode ini.
Dalam kueri non-rekursif, resolver DNS mengajukan pertanyaan ke server DNS yang memberikan catatan baik yang dimana server tersebut berwenang, atau memberikan hasil parsial tanpa mengajukan pertanyaan ke server lain. Dalam kasus resolver DNS caching, kueri non-rekursif dari cache DNS lokal memberikan hasil dan mengurangi beban pada server DNS hulu dengan menyimpan catatan sumber daya DNS dalam jangka waktu setelah respons awal dari server DNS hulu.
Dalam kueri rekursif, resolver DNS mengajukan pertanyaan ke satu server DNS, yang pada gilirannya dapat mengajukan pertanyaan ke server DNS lain atas nama pengaju. Sebagai contoh, resolver stub sederhana yang berjalan pada router rumah biasanya membuat kueri rekursif ke server DNS yang dijalankan oleh ISP pengguna. Kueri rekursif adalah kueri di mana server DNS menjawab kueri sepenuhnya dengan mengajukan pertanyaan ke server nama lain sesuai kebutuhan. Dalam operasi tipikal, klien mengeluarkan kueri rekursif ke server DNS rekursif caching, yang kemudian mengeluarkan kueri non-rekursif untuk menentukan jawaban dan mengirimkan satu jawaban kembali ke klien. Resolver, atau server DNS lain yang bertindak rekursif atas nama resolver, bernegosiasi penggunaan layanan rekursif menggunakan bit di header kueri. Server DNS tidak diwajibkan untuk mendukung kueri rekursif.
Prosedur kueri iteratif adalah proses di mana resolver DNS mengajukan pertanyaan kepada satu atau lebih server DNS. Setiap server merujuk klien ke server berikutnya dalam rantai, sampai server saat ini dapat menyelesaikan permintaan sepenuhnya. Sebagai contoh, resolusi yang mungkin dari www.example.com akan mengajukan pertanyaan ke server root global, kemudian server "com", dan akhirnya server "example.com".
Ketergantungan lingkaran dan catatan lem adalah hal umum dalam sistem DNS. Saat server nama dalam delegasi diidentifikasi berdasarkan nama, bukan alamat IP, maka server nama yang memecahkan nama harus mengeluarkan permintaan DNS lain untuk mengetahui alamat IP server yang disebutkan dalam delegasi. Jika nama yang diberikan dalam delegasi adalah subdomain dari domain yang delegasinya diberikan, maka terjadi ketergantungan lingkaran.
Dalam kasus ini, server nama yang memberikan delegasi juga harus memberikan satu atau lebih alamat IP untuk server nama yang diotorisasi yang disebut dalam delegasi tersebut. Informasi ini disebut sebagai lem. Server nama yang memberikan delegasi ini memberikan lem dalam bentuk catatan di bagian tambahan dari respons DNS, dan memberikan delegasi di bagian otoritas respons. Catatan lem adalah kombinasi dari server nama dan alamat IP.
Sebagai contoh, jika server nama yang diotorisasi untuk example.org adalah ns1.example.org, komputer yang mencoba menyelesaikan www.example.org pertama kali menyelesaikan ns1.example.org. Karena ns1 terdapat dalam example.org, ini memerlukan penyelesaian example.org terlebih dahulu, yang menyajikan ketergantungan lingkaran. Untuk memutus ketergantungan ini, server nama untuk domain tingkat atas org menyertakan lem bersama dengan delegasi untuk example.org. Catatan lem adalah catatan alamat yang menyediakan alamat IP untuk ns1.example.org. Resolver menggunakan satu atau lebih alamat IP ini untuk mengirim permintaan ke salah satu server yang diotorisasi domain, yang memungkinkannya menyelesaikan kueri DNS.
Pengelompokan catatan
Pendekatan umum untuk mengurangi beban pada server DNS adalah dengan menyimpan hasil resolusi nama secara lokal atau pada host resolver perantara. Setiap hasil kueri DNS dilengkapi dengan waktu hidup (TTL), yang mengindikasikan berapa lama informasi tetap valid sebelum harus dibuang atau diperbarui. TTL ini ditentukan oleh administrator server DNS yang diotorisasi dan dapat bervariasi dari beberapa detik hingga beberapa hari atau bahkan minggu.
Akibat arsitektur caching yang didistribusikan ini, perubahan pada catatan DNS tidak menyebar ke seluruh jaringan secara langsung, namun memerlukan semua cache untuk kedaluwarsa dan diperbarui setelah TTL. RFC 1912 menunjukkan aturan dasar untuk menentukan nilai TTL yang sesuai.
Beberapa resolver mungkin mengesampingkan nilai TTL, karena protokol mendukung caching hingga enam puluh delapan tahun atau tanpa caching sama sekali. Caching negatif, yaitu caching fakta tidak adanya catatan, ditentukan oleh server nama yang berwenang untuk zona yang harus menyertakan catatan Start of Authority (SOA) ketika melaporkan tidak ada data tipe yang diminta. Nilai bidang minimum dari catatan SOA dan TTL dari SOA itu sendiri digunakan untuk menetapkan TTL untuk jawaban negatif.
Pencarian balik
Pencarian DNS balik adalah kueri DNS untuk nama domain ketika alamat IP diketahui. Beberapa nama domain mungkin terkait dengan satu alamat IP. DNS menyimpan alamat IP dalam bentuk nama domain sebagai nama yang diformat khusus dalam catatan penunjuk (PTR) dalam domain tingkat atas infrastruktur arpa. Untuk IPv4, domainnya adalah in-addr.arpa. Untuk IPv6, domain pencarian baliknya adalah ip6.arpa. Alamat IP direpresentasikan sebagai nama dalam representasi oktet terbalik untuk IPv4, dan representasi nibble terbalik untuk IPv6.
Saat melakukan pencarian balik, klien DNS mengubah alamat menjadi format ini sebelum menanyakan nama untuk catatan PTR mengikuti rantai delegasi seperti kueri DNS lainnya. Sebagai contoh, jika alamat IPv4 208.80.152.2 dialokasikan untuk Wikimedia, maka direpresentasikan sebagai nama DNS dalam urutan terbalik: 2.152.80.208.in-addr.arpa. Ketika resolver DNS mendapatkan permintaan penunjuk (PTR), ia mulai dengan menanyakan server akar, yang menunjuk ke server American Registry for Internet Numbers (ARIN) untuk zona 208.in-addr.arpa. Server ARIN mendelegerasikan 152.80.208.in-addr.arpa ke Wikimedia yang mana resolver mengirim kueri lain untuk 2.152.80.208.in-addr.arpa, yang menghasilkan respons yang berwenang.
Urutan resolusi DNS
Biasanya pengguna tidak berkomunikasi langsung dengan resolver DNS. Sebaliknya, resolusi DNS berlangsung secara transparan dalam aplikasi seperti peramban web, klien surel, dan aplikasi Internet lainnya. Ketika sebuah aplikasi membuat permintaan yang memerlukan pencarian nama domain, program-program tersebut mengirim permintaan resolusi ke resolver DNS dalam sistem operasi lokal, yang pada gilirannya menangani komunikasi yang diperlukan.
Resolver DNS hampir selalu memiliki cache (lihat di atas) yang berisi pencarian terbaru. Jika cache dapat memberikan jawaban atas permintaan, resolver akan mengembalikan nilai dalam cache ke program yang membuat permintaan. Jika cache tidak mengandung jawaban, resolver akan mengirim permintaan ke satu atau lebih server DNS yang ditunjuk. Dalam kasus sebagian besar pengguna rumahan, penyedia layanan Internet ke mana mesin terhubung biasanya akan menyediakan server DNS ini: pengguna seperti itu akan atau telah mengkonfigurasi alamat server tersebut secara manual atau membiarkan DHCP mengaturnya; namun, di mana administrator sistem telah mengkonfigurasi sistem untuk menggunakan server DNS mereka sendiri, resolver DNS mereka menunjuk ke server nama yang dipelihara terpisah dari organisasi. Dalam setiap kasus, server nama yang ditanyakan akan mengikuti proses yang dijelaskan di atas, sampai berhasil menemukan hasil atau tidak. Kemudian mengembalikan hasilnya ke resolver DNS; diasumsikan telah menemukan hasil, resolver tersebut dengan senang hati menyimpan hasil tersebut untuk penggunaan di masa depan, dan memberikan hasil kembali ke perangkat lunak yang memulai permintaan.
Resolver rusak
Beberapa ISP besar telah mengkonfigurasi server DNS mereka untuk melanggar aturan, seperti dengan tidak patuh terhadap TTL, atau dengan menunjukkan bahwa sebuah nama domain tidak ada hanya karena salah satu dari name server-nya tidak merespons. Beberapa aplikasi seperti peramban web menjaga cache DNS internal untuk menghindari pencarian berulang melalui jaringan. Praktik ini dapat menambah kesulitan ekstra ketika debugging masalah DNS karena menyembunyikan riwayat data tersebut. Cache ini biasanya menggunakan waktu penahanan yang sangat singkat sekitar satu menit. Internet Explorer merupakan pengecualian yang mencolok: versi hingga IE 3.x menyimpan catatan DNS selama 24 jam secara default. Internet Explorer 4.x dan versi lebih baru (hingga IE 8) mengurangi nilai waktu habis default menjadi setengah jam, yang dapat diubah dengan mengubah konfigurasi default. Ketika Google Chrome mendeteksi masalah dengan server DNS, itu menampilkan pesan kesalahan khusus.
Aplikasi lain
Sistem Nama Domain mencakup beberapa fungsi dan fitur lainnya. Nama host dan alamat IP tidak perlu cocok dalam hubungan satu lawan satu. Beberapa nama host dapat sesuai dengan satu alamat IP, yang berguna dalam hosting virtual, di mana banyak situs web disajikan dari satu host. Sebaliknya, satu nama host dapat meresolusi banyak alamat IP untuk memfasilitasi toleransi kesalahan dan distribusi beban ke beberapa instansi server di seluruh perusahaan atau Internet global. DNS melayani tujuan lain selain menerjemahkan nama menjadi alamat IP. Misalnya, agen transfer surel menggunakan DNS untuk menemukan server surel terbaik untuk mengirim surel: Catatan MX menyediakan pemetaan antara domain dan penukar surel; ini dapat memberikan lapisan tambahan toleransi kesalahan dan distribusi beban. DNS digunakan untuk penyimpanan dan distribusi efisien alamat IP dari host surel yang terdaftar dalam blok. Metode umum adalah menempatkan alamat IP host subjek ke dalam sub-domain dari nama domain level lebih tinggi, dan untuk meresolusi nama itu ke catatan yang menunjukkan indikasi positif atau negatif. Sebagai contoh: Alamat 203.0.113.5 terdaftar dalam blok. Ini menunjuk ke 5.113.0.203.blocklist.example, yang meresolusi ke 127.0.0.1. Alamat 203.0.113.6 tidak terdaftar dalam blok dan menunjuk ke 6.113.0.203.blocklist.example. Nama host ini entah tidak dikonfigurasi, atau meresolusi ke 127.0.0.2. Server surel dapat menanyakan blocklist.example untuk mengetahui apakah host tertentu yang terhubung ke mereka ada dalam daftar blok. Banyak daftar blok seperti itu, baik berlangganan atau gratis, tersedia untuk digunakan oleh administrator surel dan perangkat lunai anti-spam. Untuk memberikan ketahanan dalam kasus kegagalan komputer atau jaringan, biasanya beberapa server DNS disediakan untuk cakupan setiap domain. Pada level teratas DNS global, terdapat tiga belas kelompok server nama root, dengan "salinan" tambahan dari mereka yang didistribusikan di seluruh dunia melalui penyediaan anycast. DNS Dinamis (DDNS) memperbarui server DNS dengan alamat IP klien secara langsung, misalnya, ketika berpindah antara ISP atau hotspot seluler, atau ketika alamat IP berubah secara administratif.
Format pesan DNS terdiri dari header dan empat bagian: pertanyaan, jawaban, otoritas, dan tambahan. Sebuah bidang header (flag) mengontrol konten dari empat bagian tersebut. Bagian header terdiri dari Identification, Flags, Jumlah pertanyaan, Jumlah jawaban, Jumlah catatan sumber otoritas, dan Jumlah catatan tambahan. Setiap bidang memiliki panjang 16 bit, dan muncul dalam urutan yang diberikan. Bidang identifikasi digunakan untuk mencocokkan respons dengan pertanyaan. Setelah kata-kata flag, header berakhir dengan empat bilangan bulat 16 bit yang berisi jumlah catatan di setiap bagian yang mengikuti, dalam urutan yang sama.
Catatan sumber daya
Sistem Nama Domain menentukan basis data informasi untuk sumber daya jaringan. Jenis elemen informasi dikategorikan dan diorganisir dengan daftar jenis catatan DNS, yaitu catatan sumber daya (RRs). Setiap catatan memiliki tipe (nama dan nomor), waktu kedaluwarsa (time to live), kelas, dan data khusus tipe. Catatan sumber daya dengan tipe yang sama dijelaskan sebagai kumpulan catatan sumber daya (RRset), tanpa urutan khusus. Resolver DNS mengembalikan seluruh set saat query, namun server dapat menerapkan pengurutan putaran untuk mencapai keseimbangan beban. Sebaliknya, Ekstensi Keamanan Sistem Nama Domain (DNSSEC) bekerja pada set lengkap catatan sumber daya dalam urutan kanonikal.
Ketika dikirim melalui jaringan Protokol Internet, semua catatan (jawaban, otoritas, dan bagian tambahan) menggunakan format umum yang ditentukan dalam RFC 1035: NAMA adalah nama domain lengkap dari simpul dalam pohon. Di kabel, nama dapat dipersingkat menggunakan kompresi label di mana ujung nama domain yang disebut sebelumnya dalam paket dapat digantikan dengan ujung nama domain saat ini.
TIPE adalah tipe catatan. Ini menunjukkan format data dan memberikan petunjuk penggunaannya. Misalnya, catatan A digunakan untuk menerjemahkan dari nama domain ke alamat IPv4, catatan NS mencantumkan server nama yang dapat menjawab pencarian pada zona DNS, dan catatan MX menentukan server surat yang digunakan untuk menangani surat untuk sebuah domain yang ditentukan dalam alamat e-mail.
RDATA adalah data relevan dengan tipe, seperti alamat IP untuk catatan alamat, atau prioritas dan nama host untuk catatan MX. Jenis catatan yang terkenal dapat menggunakan kompresi label di bidang RDATA, tetapi jenis catatan "tidak dikenal" tidak boleh melakukannya (RFC 3597).
KELAS catatan diatur ke IN (untuk Internet) untuk catatan DNS umum yang melibatkan nama host Internet, server, atau alamat IP. Selain itu, kelas Chaos (CH) dan Hesiod (HS) ada. Setiap kelas adalah ruang nama independen dengan delegasi zona DNS yang berbeda.
Selain catatan sumber daya yang ditentukan dalam file zona, sistem nama domain juga menentukan beberapa jenis permintaan yang hanya digunakan dalam komunikasi dengan node DNS lainnya (di kabel), seperti saat melakukan transfer zona (AXFR/IXFR) atau untuk EDNS (OPT).
Wildcard records
Sistem nama domain mendukung catatan DNS wildcard yang menentukan nama yang dimulai dengan label asterisk, *, misalnya *.contoh. Catatan DNS yang dimiliki oleh nama domain wildcard menentukan aturan untuk menghasilkan catatan sumber daya dalam satu zona DNS dengan menggantikan seluruh label dengan komponen pencocokan dari nama permintaan, termasuk keturunan yang ditentukan. Sebagai contoh, dalam konfigurasi berikut, zona DNS x.contoh menetapkan bahwa semua subdomain, termasuk subdomain dari subdomain, dari x.contoh menggunakan penukar surat (MX) a.x.contoh. Catatan AAAA untuk a.x.contoh diperlukan untuk menentukan alamat IP penukar surat. Karena ini menghasilkan pengecualian nama domain ini dan subdomainnya dari pencocokan wildcard, catatan MX tambahan untuk subdomain a.x.contoh, serta catatan MX wildcard untuk semua subdomainnya, juga harus ditentukan dalam zona DNS.
*.a.x.contoh. MX 10 a.x.contoh.
a.x.contoh. AAAA 2001:db8::1
Peran catatan wildcard disempurnakan dalam RFC 4592, karena definisi asli dalam RFC 1034 tidak lengkap dan menghasilkan penafsiran yang salah oleh para implementor.
Perpanjangan protokol
Protokol DNS asli memiliki ketentuan terbatas untuk perpanjangan dengan fitur-fitur baru. Pada tahun 1999, Paul Vixie menerbitkan dalam RFC 2671 (digantikan oleh RFC 6891) mekanisme perpanjangan, yang disebut Mekanisme Perpanjangan untuk DNS (EDNS) yang memperkenalkan elemen protokol opsional tanpa meningkatkan overhead saat tidak digunakan. Hal ini dicapai melalui catatan sumber daya pseudo OPT yang hanya ada dalam transmisi kawat protokol, tetapi tidak ada dalam file zona. Perpanjangan awal juga diusulkan (EDNS0), seperti meningkatkan ukuran pesan DNS dalam datagram UDP.
Pembaruan zona dinamis
Pembaruan DNS dinamis menggunakan opcode DNS UPDATE untuk menambah atau menghapus catatan sumber daya secara dinamis dari database zona yang dikelola pada server DNS yang bersifat otoritatif. Fasilitas ini berguna untuk mendaftarkan klien jaringan ke dalam DNS saat mereka boot atau menjadi tersedia pada jaringan. Karena klien yang boot mungkin diberikan alamat IP yang berbeda setiap kali dari server DHCP, tidak mungkin untuk menyediakan penugasan DNS statis untuk klien-klien tersebut.
Protokol transportasi
Sejak awal mula pada tahun 1983, DNS telah menggunakan User Datagram Protocol (UDP) untuk transportasi melalui IP. Keterbatasannya telah mendorong berbagai pengembangan protokol untuk keandalan, keamanan, privasi, dan kriteria lainnya, dalam beberapa dekade berikutnya.
Konvensional: DNS di atas UDP dan TCP port 53 (Do53)
UDP mengalokasikan nomor port 53 untuk server yang mendengarkan pertanyaan. Pertanyaan tersebut terdiri dari permintaan teks yang dikirim dalam satu paket UDP dari klien, dan dijawab dengan balasan teks yang dikirim dalam satu paket UDP dari server. Ketika panjang jawaban melebihi 512 byte dan keduanya klien dan server mendukung Mekanisme Ekstensi untuk DNS (EDNS), paket UDP yang lebih besar dapat digunakan. Penggunaan DNS melalui UDP dibatasi oleh, antara lain, kekurangan enkripsi lapisan transportasi, otentikasi, pengiriman yang dapat diandalkan, dan panjang pesan. Pada tahun 1989, RFC 1123 menetapkan Transport Control Protocol (TCP) sebagai opsi transportasi untuk pertanyaan DNS, balasan, dan, khususnya, transfer zona. Melalui fragmentasi balasan yang panjang, TCP memungkinkan respon yang lebih panjang, pengiriman yang dapat diandalkan, dan penggunaan koneksi yang berumur panjang antara klien dan server. Untuk respon yang lebih besar, server mengarahkan klien ke transportasi TCP.
DNS di atas TLS (DoT) DNS di atas TLS
DNS di atas TLS muncul sebagai standar IETF untuk DNS terenkripsi pada tahun 2016, memanfaatkan Transport Layer Security (TLS) untuk melindungi seluruh koneksi, bukan hanya muatan DNS. Server DoT mendengarkan pada port TCP 853. RFC 7858 menetapkan bahwa enkripsi oportunis dan enkripsi yang terotentikasi dapat didukung, namun tidak membuat otentikasi server atau klien menjadi wajib.
DNS di atas HTTPS (DoH) DNS di atas HTTPS
DNS di atas HTTPS dikembangkan sebagai standar alternatif untuk transportasi kueri DNS pada tahun 2018, dengan mengirimkan data kueri DNS melalui HTTPS, yang mengangkut HTTP di atas TLS. DoH dipromosikan sebagai alternatif yang lebih ramah web daripada DNS karena, seperti DNSCrypt, itu menggunakan port TCP 443, dan oleh karena itu terlihat mirip dengan lalu lintas web, meskipun keduanya mudah dibedakan dalam praktik tanpa padding yang tepat.
DNS di atas QUIC (DoQ)
RFC 9250, yang diterbitkan pada tahun 2022 oleh Internet Engineering Task Force, menggambarkan DNS di atas QUIC. Ini memiliki "sifat privasi yang mirip dengan DNS di atas TLS (DoT) , dan karakteristik latensi yang mirip dengan DNS klasik melalui UDP". Metode ini bukanlah sama dengan DNS di atas HTTP/3.
Oblivious DoH (ODoH) dan pendahulu Oblivious DNS (ODNS)
DNS di atas HTTPS – Oblivious DNS di atas HTTPS
Oblivious DNS (ODNS) ditemukan dan diimplementasikan oleh para peneliti di Universitas Princeton dan Universitas Chicago sebagai perpanjangan dari DNS yang tidak terenkripsi, sebelum DoH distandarisasi dan didistribusikan secara luas. Apple dan Cloudflare kemudian menerapkan teknologi tersebut dalam konteks DoH, sebagai Oblivious DoH (ODoH). ODoH menggabungkan pemisahan masuk/keluar (ditemukan dalam ODNS) dengan penyelubungan HTTPS DoH dan enkripsi lapisan transportasi TLS dalam satu protokol.
DNS melalui Tor
DNS bisa dijalankan melalui jaringan pribadi virtual (VPN) dan protokol tunneling. Keuntungan privasi dari DNS Oblivious dapat diperoleh melalui penggunaan jaringan Tor yang sudah ada dengan node masuk dan keluar, dipasangkan dengan enkripsi lapisan transport yang disediakan oleh TLS.
DNSCrypt
Protokol DNSCrypt, yang dikembangkan pada tahun 2011 di luar kerangka standar IETF, mengenalkan enkripsi DNS di sisi hilir resolusi rekursif, di mana klien mengenkripsi payload kueri dengan menggunakan kunci publik server, yang dipublikasikan di DNS (daripada mengandalkan otoritas sertifikat pihak ketiga) dan yang pada gilirannya dapat dilindungi oleh tanda tangan DNSSEC. DNSCrypt menggunakan entah TCP port 443, port yang sama dengan lalu lintas web HTTPS terenkripsi, atau UDP port 443. Ini memperkenalkan tidak hanya privasi mengenai konten kueri, tetapi juga kemampuan penembusan firewall yang signifikan. Pada tahun 2019, DNSCrypt diperluas lebih lanjut untuk mendukung mode "anonim", mirip dengan yang diusulkan "Oblivious DNS", di mana sebuah node masuk menerima kueri yang telah dienkripsi dengan kunci publik server yang berbeda, dan meneruskannya ke server tersebut, yang bertindak sebagai node keluar, melakukan resolusi rekursif. Privasi pasangan pengguna/kueri diciptakan, karena node masuk tidak mengetahui konten kueri, sementara node keluar tidak mengetahui identitas klien. DNSCrypt pertama kali diimplementasikan dalam produksi oleh OpenDNS pada bulan Desember 2011. Ada beberapa implementasi perangkat lunak gratis dan sumber terbuka yang juga mengintegrasikan ODoH. Ini tersedia untuk berbagai sistem operasi, termasuk Unix, Apple iOS, Linux, Android, dan Windows.
Masalah Keamanan
Awalnya, masalah keamanan bukanlah pertimbangan desain utama untuk perangkat lunak DNS atau perangkat lunak lain untuk implementasi di Internet awal, karena jaringan tidak terbuka untuk partisipasi masyarakat umum. Namun, ekspansi Internet ke sektor komersial pada tahun 1990-an mengubah persyaratan untuk tindakan keamanan guna melindungi integritas data dan otentikasi pengguna. Beberapa masalah kerentanan ditemukan dan dieksploitasi oleh pengguna jahat. Salah satu isu tersebut adalah pemanasan cache DNS, di mana data didistribusikan ke resolver caching dengan dalih menjadi server asal yang berwewenang, dengan demikian mencemari toko data dengan informasi yang mungkin salah dan waktu kedaluwarsa yang panjang (time-to-live). Selanjutnya, permintaan aplikasi yang sah dapat dialihkan ke host jaringan yang dioperasikan dengan niat jahat. Respons DNS tradisional tidak memiliki tanda tangan kriptografis, menyebabkan banyak kemungkinan serangan; Ekstensi Sekuritas Ekstensi Sistem Nama Domain (DNSSEC) memodifikasi DNS untuk menambahkan dukungan untuk respons yang ditandatangani secara kriptografis. DNSCurve telah diusulkan sebagai alternatif untuk DNSSEC. Ekstensi lain, seperti TSIG, menambahkan dukungan untuk otentikasi kriptografis antara rekan tepercaya dan umumnya digunakan untuk mengotorisasi operasi transfer zona atau update dinamis. Teknik seperti konfirmasi maju mundur DNS juga dapat digunakan untuk membantu memvalidasi hasil DNS. DNS juga dapat "bocor" dari koneksi yang seharusnya aman atau pribadi, jika tidak diperhatikan konfigurasinya, dan terkadang DNS telah digunakan untuk melewati firewall oleh orang-orang jahat, dan mengeluarkan data, karena sering dianggap tidak berbahaya.
DNS spoofing
Beberapa nama domain dapat digunakan untuk mencapai efek spoofing. Misalnya, paypal.com dan paypa1.com adalah nama yang berbeda, namun pengguna mungkin tidak dapat membedakan keduanya dalam antarmuka pengguna grafis tergantung pada tipe huruf yang dipilih oleh pengguna. Pada banyak font, huruf l dan angka 1 terlihat sangat mirip atau bahkan identik. Masalah ini, yang dikenal sebagai serangan homograf IDN, sangat kritis dalam sistem yang mendukung nama domain internasional, karena banyak kode karakter dalam ISO 10646 mungkin tampak identik pada layar komputer yang tipikal. Kerentanan ini kadang-kadang dieksploitasi dalam phishing.
DNSMessenger
DNSMessenger merupakan jenis teknik serangan cyber yang menggunakan DNS untuk berkomunikasi dan mengendalikan malware secara remote tanpa mengandalkan protokol konvensional yang mungkin menimbulkan kecurigaan. Serangan DNSMessenger bersifat sembunyi karena DNS pada dasarnya digunakan untuk resolusi nama domain dan seringkali tidak dipantau secara ketat oleh alat keamanan jaringan, menjadikannya saluran efektif bagi penyerang untuk mengeksploitasi.
Teknik ini melibatkan penggunaan catatan DNS TXT untuk mengirim perintah ke sistem yang terinfeksi. Setelah malware secara diam-diam diinstal pada mesin korban, ia menghubungi domain yang terkendali untuk mengambil perintah yang dienkripsi dalam catatan teks DNS. Bentuk komunikasi malware ini bersifat rahasia, karena permintaan DNS biasanya diizinkan melalui firewall, dan karena lalu lintas DNS sering dianggap tidak berbahaya, komunikasi ini dapat melewati banyak pertahanan keamanan jaringan.
Serangan DNSMessenger dapat memungkinkan berbagai aktivitas jahat, mulai dari pengeluaran data hingga pengiriman muatan tambahan, semuanya sambil tetap tidak terdeteksi oleh tindakan keamanan jaringan tradisional. Memahami dan mempertahankan metode tersebut penting untuk menjaga keamanan cyber yang kokoh.
Privasi dan masalah pelacakan
Awalnya dirancang sebagai database publik, hierarkis, terdistribusi, dan sangat di-cache, protokol DNS tidak memiliki kontrol kerahasiaan. Pertanyaan pengguna dan respon nameserver dikirim tanpa enkripsi, memungkinkan penyadapan paket jaringan, perusakan DNS, keracunan DNS cache, dan serangan man-in-the-middle. Kekurangan ini umumnya digunakan oleh penjahat cyber dan operator jaringan untuk tujuan pemasaran, otentikasi pengguna pada portal penjebak, dan sensor. Privasi pengguna lebih terbuka dengan proposal untuk meningkatkan tingkat informasi IP klien dalam pertanyaan DNS (RFC 7871) untuk kepentingan jaringan pengiriman konten.
Pendekatan utama yang digunakan untuk melawan masalah privasi dengan DNS antara lain:
VPN, yang memindahkan resolusi DNS ke operator VPN dan menyembunyikan lalu lintas pengguna dari ISP lokal. Tor, yang menggantikan resolusi DNS tradisional dengan domain .onion anonim, menyembunyikan resolusi nama dan lalu lintas pengguna di balik onion routing counter-surveillance.
Proksi dan server DNS publik, yang memindahkan resolusi DNS aktual ke penyedia tepercaya pihak ketiga.
Beberapa server DNS publik mungkin mendukung ekstensi keamanan seperti DNS over HTTPS, DNS over TLS, dan DNSCrypt. Solusi untuk mencegah pemeriksaan DNS oleh operator jaringan lokal telah dikritik karena menghalangi kebijakan keamanan jaringan korporat dan sensor internet. Server DNS publik juga dikritik karena berkontribusi pada sentralisasi Internet dengan menempatkan kontrol atas resolusi DNS di tangan sedikit perusahaan besar yang mampu menjalankan resolver publik.
Google adalah penyedia platform dominan di Android, browser di Chrome, dan resolver DNS dalam layanan 8.8.8.8. Apakah skenario ini merupakan kasus dimana satu entitas korporat memiliki kendali yang sangat besar atas seluruh namespace Internet? Netflix telah mengeluarkan aplikasi yang menggunakan mekanisme resolusi DNSnya sendiri independen dari platform tempat aplikasi tersebut berjalan. Bagaimana jika aplikasi Facebook termasuk DoH? Bagaimana jika iOS Apple menggunakan mekanisme resolusi DoH untuk menghindari resolusi DNS lokal dan mengarahkan semua pertanyaan DNS dari platform Apple ke sekumpulan resolver nama yang dioperasikan oleh Apple?
Pendaftaran nama domain
Hak untuk menggunakan nama domain didelegasikan oleh registrar nama domain yang diakreditasi oleh Internet Corporation for Assigned Names and Numbers (ICANN) atau organisasi lain seperti OpenNIC, yang bertugas mengawasi sistem nama dan nomor Internet. Selain ICANN, setiap top-level domain (TLD) dipelihara dan dilayani secara teknis oleh sebuah organisasi administratif yang mengoperasikan registry. Sebuah registry bertanggung jawab untuk mengoperasikan database nama dalam zona otoritatifnya, meskipun istilah ini lebih sering digunakan untuk TLD. Seorang registran adalah orang atau organisasi yang meminta pendaftaran domain. Registry menerima informasi pendaftaran dari setiap registrar nama domain, yang diotorisasi (diakreditasi) untuk menetapkan nama dalam zona yang sesuai dan mempublikasikan informasi tersebut menggunakan protokol WHOIS. Mulai tahun 2015, penggunaan RDAP sedang dipertimbangkan.
ICANN menerbitkan daftar lengkap TLD, registry TLD, dan registrar nama domain. Informasi registran yang terkait dengan nama domain dipelihara dalam database online yang dapat diakses dengan layanan WHOIS. Untuk sebagian besar dari lebih dari 290 kode top-level domain negara (ccTLD), registry domain memelihara informasi WHOIS (Registran, name server, tanggal kadaluarsa, dll.). Misalnya, DENIC, NIC Jerman, memegang data domain DE. Mulai sekitar tahun 2001, sebagian besar registri generic top-level domain (gTLD) telah mengadopsi pendekatan registri tebal yang disebut ini, yaitu menyimpan data WHOIS di registri pusat daripada basis data registrar. Untuk domain-level atas pada COM dan NET, model registri tipis digunakan. Registri domain (misalnya, GoDaddy, BigRock dan PDR, VeriSign, dll.) memegang data WHOIS dasar (yaitu, registrar dan name server, dll.). Organisasi, atau registran yang menggunakan ORG di sisi lain, eksklusif untuk Public Interest Registry.
Beberapa registri nama domain, sering disebut sebagai pusat informasi jaringan (NIC), juga berfungsi sebagai registrar untuk pengguna akhir, selain memberikan akses ke kumpulan data WHOIS. Registri domain top-level, seperti untuk domain COM, NET, dan ORG menggunakan model registri-registrar yang terdiri dari banyak registrar nama domain. Dalam metode manajemen ini, registri hanya mengelola database nama domain dan hubungan dengan registrar. Registran (pengguna nama domain) merupakan pelanggan dari registrar, dalam beberapa kasus melalui subkontrak tambahan dari reseller.
Posting Komentar