Domain Name System (DNS) adalah sistem penamaan hirarkis didistribusikan untuk komputer, jasa, atau sumber daya apapun yang terhubung ke internet atau jaringan pribadi . Ini asosiasi berbagai informasi dengan nama domain ditugaskan untuk masing-masing entitas yang berpartisipasi. Yang paling penting, menerjemahkan nama domain berarti bagi manusia ke dalam pengidentifikasi numerik yang terkait dengan peralatan jaringan untuk tujuan mencari dan menangani perangkat ini di seluruh dunia.
Sebuah analogi yang mungkin untuk menjelaskan Sistem Nama Domain adalah bahwa ia berfungsi sebagai buku telepon untuk Internet dengan membiarkan mencari-up manusia-komputer ramah nama host mana kita menemukan (atau ditemukan) yang terkait alamat IP dalam banyak cara yang sama kita mencari nama dalam buku telepon untuk mencari nomor telepon yang terkait. Dengan DNS kita ketikkan nama domain ke kami peramban address bar dan mendongak DNS identifier numerik yang terkait atau alamat IP. Misalnya, nama domain www.example.com menerjemahkan ke alamat 192.0.32.10 ( IPv4 ) dan 2620:0:2 d0: 200:: 10 ( IPv6 ).
Domain Name System memungkinkan untuk menetapkan nama domain untuk kelompok pengguna sumber daya Internet dan dalam cara yang berarti, independen dari lokasi fisik masing-masing entitas. Karena ini, World Wide Web (WWW) hyperlink Internet dan informasi kontak dapat tetap konsisten dan konstan bahkan jika internet saat mengubah pengaturan rute atau peserta menggunakan perangkat mobile. Internet nama domain yang mudah untuk diingat daripada alamat IP seperti 208.77.188.166 (IPv4) atau 2001: DB8: 1f70:: 999: de8: 7648:6 e8 (IPv6). Pengguna mengambil keuntungan dari ini ketika mereka membacakan bermakna Uniform Resource Locator (URL) dan alamat e-mail tanpa harus mengetahui bagaimana komputer benar-benar menempatkan mereka.
Domain Name System mendistribusikan tanggung jawab menetapkan nama domain dan pemetaan nama-nama ke alamat IP dengan menunjuk server nama otoritatif untuk setiap domain. Server nama otoritatif yang ditugaskan bertanggung jawab untuk domain khusus mereka, dan pada gilirannya dapat menetapkan server lain nama otoritatif untuk sub-domain. Mekanisme ini telah membuat DNS terdistribusi dan fault tolerant dan telah membantu menghindari kebutuhan untuk mendaftar pusat tunggal untuk terus-menerus berkonsultasi dan diperbarui.
Secara umum, Sistem Nama Domain juga menyimpan informasi jenis lain, seperti daftar mail server yang menerima email untuk domain internet yang diberikan. Dengan menyediakan, di seluruh dunia didistribusikan kata kunci berbasis layanan redirection, Sistem Nama Domain adalah komponen penting dari fungsi dari internet .
Pengenal lainnya seperti RFID tag , UPCs , karakter Internasional di alamat email dan nama host, dan berbagai pengenal lainnya semua bisa berpotensi menggunakan DNS. 
Domain Name System juga menentukan fungsi teknis dari layanan database. Ini mendefinisikan DNS protokol, spesifikasi rinci dari struktur data dan pertukaran komunikasi yang digunakan dalam DNS, sebagai bagian dari Internet Protocol Suite .

v · d · e

Ikhtisar

Internet mempertahankan dua utama ruang nama , hirarki nama domain  dan Internet Protocol (IP) address space.  Domain Name System mempertahankan hirarki nama domain dan menyediakan layanan terjemahan antara itu dan ruang alamat. Name server internet dan komunikasi protokol mengimplementasikan Domain Name System. ^[5] Sebuah server nama DNS adalah server yang menyimpan catatan DNS untuk nama domain, seperti alamat (A) catatan, nama server (NS) catatan, dan surat exchanger (MX) record (lihat juga daftar jenis catatan DNS ); server nama DNS merespon dengan jawaban untuk query terhadap database-nya.

Sejarah

Praktek menggunakan nama sebagai abstraksi, sederhana lebih mudah diingat alamat numerik host pada sebuah jaringan tanggal kembali ke ARPANET zaman. Sebelum DNS diciptakan pada 1982, setiap komputer pada jaringan diambil file bernama HOSTS.TXT dari komputer di SRI (sekarang SRI International ).  File HOSTS.TXT nama dipetakan ke alamat numerik. Sebuah host file masih ada pada sistem operasi paling modern secara default dan umumnya berisi pemetaan alamat IP 127.0.0.1 untuk "localhost". Banyak sistem operasi menggunakan nama logika resolusi yang memungkinkan administrator untuk mengkonfigurasi prioritas pemilihan untuk metode resolusi nama yang tersedia.
Pesatnya pertumbuhan jaringan membuat, pusat kerajinan tangan mempertahankan berkas HOSTS.TXT tidak lestari; menjadi perlu untuk menerapkan sistem yang lebih scalable otomatis mampu menyebarluaskan informasi yang diperlukan.
Atas permintaan Jon Postel , Paul Mockapetris menemukan Domain Name System pada tahun 1983 dan menulis implementasi pertama. Spesifikasi asli diterbitkan oleh Internet Engineering Task Force di RFC 882 dan RFC 883 , yang digantikan pada November 1987 oleh RFC 1034  dan RFC 1035 .  Beberapa tambahan Request for Comments telah mengusulkan berbagai ekstensi ke DNS inti protokol.
Pada tahun 1984, empat Berkeley siswa-Douglas Terry, Mark Painter, Riggle David, dan Songnian Zhou-wrote pertama UNIX pelaksanaan, yang disebut Berkeley Internet Nama Domain ( BIND ) Server.  Pada tahun 1985, Kevin Dunlap dari Desember signifikan ulang menulis implementasi DNS. Mike Karels, Phil Almquist, dan Paul Vixie telah mempertahankan BIND sejak itu. BIND adalah porting ke Windows NT platform di awal 1990-an.
BIND didistribusikan secara luas, terutama pada sistem Unix, dan merupakan perangkat lunak DNS dominan digunakan di Internet.  Dengan menggunakan berat dan hasil pengawasan dari kode open-source nya, serta metode serangan semakin canggih keamanan, banyak kekurangan ditemukan di BIND ^{[ kutipan diperlukan ].} Hal ini memberikan kontribusi terhadap pengembangan sejumlah server nama alternatif dan program resolver . BIND versi 9 ini ditulis dari awal dan sekarang memiliki catatan keamanan yang sebanding dengan perangkat lunak DNS modern lainnya

  Struktur

  Domain ruang nama

Ruang nama domain terdiri dari pohon nama domain. Setiap node atau daun di pohon memiliki nol atau catatan sumber daya lebih, yang memegang informasi yang terkait dengan nama domain. Pohon sub-terbagi menjadi zona awal di zona akar . Sebuah zona DNS dapat terdiri dari hanya satu domain, atau mungkin terdiri dari banyak domain dan sub-domain, tergantung pada otoritas administratif didelegasikan kepada manajer.
Tanggung jawab administratif atas setiap zona dapat dibagi dengan menciptakan zona tambahan. Otoritas dikatakan didelegasikan untuk bagian ruang lama, biasanya dalam bentuk sub-domain, nameserver lain dan entitas administratif. Zona lama berhenti menjadi otoritatif untuk zona baru.

  Domain sintaks nama

Uraian definitif aturan untuk membentuk nama domain muncul dalam RFC 1035 , RFC 1123 , dan RFC 2181 . Sebuah nama domain terdiri dari satu atau lebih bagian, secara teknis disebut label, yang konvensional concatenated, dan dibatasi oleh titik-titik, seperti example.com.

• Label paling kanan menyampaikan domain top-level , misalnya, www.example.com nama domain milik com top-level domain.
• Hirarki domain turun dari kanan ke kiri; setiap label di sebelah kirinya menyatakan sebuah sub-divisi, atau subdomain dari domain ke kanan. Sebagai contoh: contoh label menetapkan subdomain dari domain com, dan www adalah sebuah sub domain dari example.com. Ini pohon subdivisi mungkin memiliki hingga 127 level.
• Setiap label dapat berisi hingga 63 karakter. Nama domain lengkap tidak boleh melebihi total panjang 253 karakter dalam spesifikasi eksternal bertitik-label.  Dalam representasi biner internal dari DNS panjang maksimum 255 oktet memerlukan penyimpanan.  Dalam praktek, beberapa pendaftar domain mungkin memiliki batas singkat ^[. 
• Nama DNS teknis dapat terdiri dari setiap karakter representable dalam oktet. Namun, perumusan diperbolehkan nama domain di zona akar DNS, dan sebagian besar sub domain lain, menggunakan format pilihan dan set karakter. Karakter diperbolehkan dalam label adalah subset dari ASCII set karakter, dan termasuk karakter melalui z, A sampai Z, angka 0 sampai 9, dan tanda hubung. Aturan ini dikenal sebagai aturan LDH (huruf, angka, tanda hubung). Nama domain yang ditafsirkan dalam kasus-independen cara. Label mungkin tidak memulai atau diakhiri dengan tanda hubung. ^[11]
• Sebuah nama host adalah nama domain yang memiliki setidaknya satu alamat IP yang terkait. Misalnya, nama domain example.com www.example.com dan juga nama host, sedangkan domain com adalah tidak.
•  

  Nama domain internasionalisasi

Karakter diizinkan set DNS mencegah representasi dari nama dan kata-kata dari berbagai bahasa dalam huruf asli mereka atau script. ICANN telah menyetujui Internasionalisasi Nama Domain di Aplikasi (IDNA) sistem, yang memetakan Unicode string ke dalam karakter yang valid DNS diatur menggunakan Punycode . Pada tahun 2009 ICANN menyetujui pemasangan kode negara IDN top-level domain. Selain itu, banyak pendaftar nama domain tingkat atas yang ada ( TLD ) telah mengadopsi IDNA s.

 

  Nama server

Domain Name System dikelola oleh database terdistribusi sistem, yang menggunakan client-server model. Node dari database ini adalah server nama. Setiap domain memiliki setidaknya satu server otoritatif DNS yang mempublikasikan informas tentang domain dan server nama dari setiap domain bawahan untuk itu. Bagian atas hirarki adalah dilayani oleh nameserver akar , server untuk query saat mencari (menyelesaikan) TLD.

  server nama Resmi

Sebuah server nama otoritatif adalah server nama yang memberikan jawaban yang telah dikonfigurasi oleh sumber asli, misalnya, administrator domain atau dengan metode DNS dinamis, berbeda dengan jawaban yang diperoleh melalui DNS query biasa ke server lain nama. Sebuah server nama otoritatif-satunya hanya mengembalikan jawaban atas pertanyaan tentang nama domain yang telah dikonfigurasi secara khusus oleh administrator.
Sebuah server nama otoritatif dapat menjadi server master atau server budak. Sebuah server master adalah server yang menyimpan (master) salinan asli dari semua catatan zona. Sebuah server budak menggunakan mekanisme pembaruan otomatis dari protokol DNS dalam komunikasi dengan master untuk menjaga salinan identik dari catatan master.
Setiap zona DNS harus diberi satu set server nama otoritatif yang diinstal dalam catatan NS di zona induk.
Ketika nama domain yang terdaftar dengan registrasi nama domain , instalasi mereka di registri domain dari sebuah domain tingkat atas membutuhkan penugasan dari server nama primer dan paling tidak satu server nama sekunder. Persyaratan dari server nama multiple bertujuan untuk membuat domain masih fungsional bahkan jika salah satu server nama menjadi tidak dapat diakses atau bisa dioperasi.  Penunjukan dari server nama primer adalah semata-mata ditentukan oleh prioritas diberikan kepada pendaftar nama domain. Untuk tujuan ini, umumnya hanya memenuhi syarat nama domain dari server nama diperlukan, kecuali server yang terkandung dalam domain terdaftar, dalam hal yang sesuai alamat IP juga diperlukan.
Nama server primer sering menguasai nama server, sementara server nama sekunder dapat diimplementasikan sebagai server budak.
Sebuah server otoritatif menunjukkan status penyediaan jawaban yang pasti, dianggap otoritatif, dengan menetapkan bendera perangkat lunak (sedikit struktur protokol), yang disebut Jawaban Resmi (AA) bit dalam tanggapan.Bendera ini biasanya direproduksi jelas dalam output dari query DNS alat administrasi (seperti menggali ) untuk menunjukkan bahwa nama server menanggapi adalah otoritas untuk nama domain yang dimaksud.

  server nama Rekursif dan caching

Pada prinsipnya, server nama otoritatif yang cukup untuk pengoperasian Internet. Namun, dengan hanya otoritatif nama server operasi, setiap query DNS harus mulai dengan query rekursif di zona akar Sistem Nama Domain dan setiap sistem pengguna harus mengimplementasikan perangkat lunak resolver mampu operasi rekursif.
Untuk meningkatkan efisiensi, mengurangi lalu lintas DNS di Internet, dan meningkatkan kinerja aplikasi pengguna akhir, Domain Name System mendukung server DNS cache yang menyimpan hasil query DNS untuk jangka waktu yang ditentukan dalam konfigurasi (time-to-live) dari nama domain rekor di pertanyaan. Biasanya, seperti caching DNS server, juga disebut DNS cache, juga menerapkan algoritma rekursif yang diperlukan untuk menyelesaikan nama yang diberikan dimulai dengan akar DNS melalui ke server nama otoritatif dari domain dipertanyakan. Dengan fungsi ini diimplementasikan dalam nama server, aplikasi pengguna mendapatkan efisiensi dalam desain dan operasi.
Kombinasi caching DNS dan fungsi rekursif dalam server nama tidak wajib, fungsi dapat diimplementasikan secara independen di server untuk tujuan khusus.
Penyedia layanan Internet biasanya menyediakan server nama rekursif dan cache untuk pelanggan mereka. Selain itu, router jaringan rumah banyak menerapkan cache DNS dan recursor untuk meningkatkan efisiensi di jaringan lokal.

 

  DNS resolver

Klien-samping DNS disebut DNS resolver. Hal ini bertanggung jawab untuk memulai dan urutan permintaan yang pada akhirnya mengarah pada resolusi penuh (terjemahan) dari sumber daya dicari, misalnya, terjemahan dari nama domain ke alamat IP.
Sebuah query DNS dapat berupa query rekursif atau non-query rekursif:

• Sebuah query non-rekursif adalah satu di mana server DNS menyediakan catatan untuk domain yang berwibawa itu sendiri, atau memberikan hasil parsial tanpa query server lain.
• Sebuah query rekursif adalah salah satu yang server DNS akan sepenuhnya menjawab pertanyaan (atau memberikan kesalahan) dengan query server nama lain yang diperlukan. Server DNS tidak diperlukan untuk mendukung permintaan rekursif.

Resolver, atau server DNS lain secara rekursif bertindak atas nama resolver, negosiasi penggunaan layanan recursive menggunakan bit dalam header permintaan.
Menyelesaikan biasanya memerlukan iterasi melalui beberapa nama server untuk mencari informasi yang dibutuhkan. Namun, beberapa resolvers fungsi lebih hanya dengan berkomunikasi hanya dengan nama server tunggal. Ini resolver sederhana (disebut "resolver rintisan") bergantung pada server nama rekursif untuk melakukan pekerjaan mencari informasi bagi mereka.

 

  Operasi

Alamat mekanisme resolusi

Resolver nama domain menentukan nama domain yang tepat server bertanggung jawab untuk nama domain yang dimaksud dengan urutan pertanyaan dimulai dengan label paling kanan (top-level) domain.
Proses ini memerlukan:

1. Sebuah host network dikonfigurasi dengan cache awal (disebut petunjuk) dari alamat yang dikenal dari nameserver akar . Seperti sebuah file petunjuk diperbarui secara berkala oleh administrator dari sumber yang dapat dipercaya.
2. Sebuah query ke salah satu root server untuk menemukan server otoritatif untuk top-level domain.
3. Sebuah permintaan ke server TLD diperoleh untuk alamat server DNS otoritatif untuk domain tingkat kedua.
4. Pengulangan langkah sebelumnya untuk memproses setiap label nama domain secara berurutan, sampai langkah terakhir yang mengembalikan alamat IP dari host yang dicari.

Diagram ini menggambarkan proses ini untuk host www.wikipedia.org.
Mekanisme dalam bentuk sederhana akan menempatkan beban operasi yang besar pada root server, dengan setiap mencari alamat dimulai dengan query salah satu dari mereka. Menjadi sama pentingnya dengan mereka untuk keseluruhan fungsi sistem, menggunakan berat tersebut akan menciptakan hambatan dapat diatasi untuk ditempatkan triliunan pertanyaan setiap hari. Dalam praktek caching digunakan dalam DNS server untuk mengatasi masalah ini, dan sebagai hasilnya, akar nameserver sebenarnya terlibat dengan sangat sedikit dari total lalu lintas.

 

  Edaran dependensi dan lem catatan

Nama server di delegasi diidentifikasi dengan nama, bukan dengan alamat IP. Ini berarti bahwa nama server harus menyelesaikan masalah lain permintaan DNS untuk mencari tahu alamat IP dari server yang telah dirujuk. Jika nama yang diberikan dalam delegasi adalah subdomain dari domain yang delegasi yang disediakan, ada ketergantungan melingkar . Dalam kasus ini nameserver menyediakan delegasi juga harus menyediakan satu atau lebih alamat IP untuk nameserver otoritatif disebutkan dalam delegasi. Informasi ini disebut lem. Nama server mendelegasikan menyediakan lem ini dalam bentuk catatan di bagian tambahan dari respon DNS, dan memberikan delegasi pada bagian jawaban dari respon.
Sebagai contoh, jika nama server otoritatif untuk example.org adalah ns1.example.org, komputer mencoba untuk menyelesaikan www.example.org pertama menyelesaikan ns1.example.org. Sejak ns1 terkandung dalam example.org, ini memerlukan menyelesaikan example.org pertama, yang menyajikan ketergantungan melingkar. Untuk memecahkan ketergantungan, nameserver untuk org domain tingkat atas termasuk lem bersama dengan delegasi untuk example.org. Catatan lem alamat catatan yang menyediakan alamat IP untuk ns1.example.org. Resolver menggunakan satu atau lebih dari alamat IP untuk query salah satu server otoritatif domain, yang memungkinkan untuk menyelesaikan permintaan DNS.

 

  Caching Rekam

Karena volume besar permintaan DNS dihasilkan untuk internet publik, para desainer berharap untuk menyediakan mekanisme untuk mengurangi beban pada server DNS individu. Untuk tujuan ini, proses resolusi DNS memungkinkan untuk caching catatan untuk periode waktu setelah jawaban. Hal ini memerlukan rekaman lokal dan konsultasi berikutnya menyalin bukannya memulai permintaan baru hulu. Waktu yang penyelesai sebuah cache respon DNS adalah ditentukan oleh nilai yang disebut waktu untuk tinggal (TTL) yang berhubungan dengan tiap rekaman. TTL diatur oleh administrator dari server DNS yang memberikan jawaban otoritatif. Masa berlaku dapat bervariasi dari hanya detik untuk hari atau bahkan berminggu-minggu.
Sebagai konsekuensi penting dari arsitektur tersebar dan cache, perubahan DNS record tidak menyebarkan seluruh jaringan segera, tetapi membutuhkan semua cache akan berakhir dan menyegarkan setelah TTL. RFC 1912 menyampaikan aturan-aturan dasar untuk menentukan nilai yang sesuai TTL.
Beberapa resolver dapat mengganti nilai TTL, sebagai protokol mendukung caching hingga 68 tahun caching atau tidak sama sekali. caching negatif , yaitu caching fakta non-keberadaan catatan, ditentukan oleh server nama otoritatif untuk zona yang harus menyertakan Mulai dari Authority (SOA) merekam ketika tidak ada pelaporan data yang diminta jenis ada. Nilai bidang MINIMUM dari catatan SOA dan TTL dari SOA itu sendiri digunakan untuk mendirikan TTL untuk jawaban negatif.

 

Reverse lookup

Sebuah reverse lookup adalah query dari DNS untuk nama domain ketika alamat IP yang diketahui. Beberapa nama domain dapat dikaitkan dengan alamat IP. DNS alamat IP toko dalam bentuk nama domain sebagai nama khusus diformat dalam pointer (PTR) record dalam infrastruktur top-level domain ARPA . Untuk IPv4, domain di-addr.arpa. Untuk IPv6, domain reverse lookup ip6.arpa. Alamat IP direpresentasikan sebagai nama secara terbalik-memerintahkan representasi oktet untuk IPv4, dan reverse-memerintahkan representasi menggigit untuk IPv6.
Ketika melakukan reverse lookup, klien DNS mengkonversi alamat ke format ini, dan kemudian query nama untuk catatan PTR berikut rantai delegasi sebagai untuk setiap kueri DNS. Sebagai contoh, alamat IPv4 208.80.152.2 direpresentasikan sebagai nama DNS sebagai 2.152.80.208.in-addr.arpa. DNS resolver dimulai dengan query root server, yang mengarah ke server ARIN untuk zona 208.in-addr.arpa. Dari sana server Wikimedia ditugaskan untuk 152.80.208.in-addr.arpa, dan PTR lookup melengkapi dengan query nameserver Wikimedia untuk 2.152.80.208.in-addr.arpa, yang menghasilkan respon otoritatif.

  Klien pencarian

Pengguna umumnya tidak berkomunikasi langsung dengan DNS resolver. Sebaliknya resolusi DNS berlangsung transparan dalam program-program aplikasi seperti web browser , e-mail client , dan aplikasi Internet lainnya. Bila aplikasi yang membuat permintaan yang memerlukan nama domain lookup, program tersebut mengirimkan permintaan ke resolusi DNS resolver dalam sistem operasi lokal, yang pada gilirannya menangani komunikasi yang diperlukan.
DNS resolver akan hampir selalu memiliki cache (lihat diatas) yang memiliki isi pencarian terakhir. Jika cache dapat memberikan jawaban atas permintaan, resolver akan kembali nilai dalam cache untuk program yang dibuat permintaan. Jika cache tidak berisi jawaban, resolver akan mengirimkan permintaan ke satu atau lebih server DNS yang ditunjuk. Dalam kasus kebanyakan pengguna di rumah, para penyedia layanan Internet yang menghubungkan komputer tersebut biasanya akan menyediakan server DNS: pengguna tersebut akan memiliki dikonfigurasi alamat server secara manual atau diperbolehkan DHCP untuk mengatur itu, namun, di mana administrator sistem telah mengkonfigurasi sistem untuk menggunakan server DNS mereka sendiri, mereka DNS resolver menunjuk ke nameserver dipelihara secara terpisah dari organisasi. Dalam hal apapun, nama server sehingga query akan mengikuti proses yang dijelaskan di atas , sampai baik berhasil menemukan hasil atau tidak. Kemudian kembali hasilnya kepada DNS resolver; asumsi itu telah menemukan hasilnya, resolver akan menyimpan hasilnya di cache untuk penggunaan masa depan, dan tangan hasilnya kembali kepada software yang meminta pencarian DNS tersebut.

  resolver Patah

Tambahan tingkat kompleksitas muncul ketika resolver melanggar aturan dari protokol DNS. Sejumlah ISP besar telah dikonfigurasi server DNS mereka melanggar aturan (mungkin untuk memungkinkan mereka untuk berjalan di hardware yang lebih murah daripada penyelesai sepenuhnya kompatibel), seperti dengan TTLs tidak patuh, atau dan menunjukkan bahwa nama domain tidak ada hanya karena salah satu server nama tidak merespon. 
Sebagai akhir dari kerumitan ini, beberapa aplikasi (seperti web-browser) juga memiliki DNS cache mereka sendiri, dalam rangka untuk mengurangi penggunaan referensi DNS resolver. Praktek ini dapat menambah kesulitan ekstra ketika debugging masalah DNS, karena mengaburkan kesegaran data, dan / atau data apa yang berasal dari cache. Cache ini biasanya menggunakan caching kali sangat pendek-di urutan satu menit 
Internet Explorer merupakan pengecualian: versi hingga ke IE 3.x Cache DNS record selama 24 jam secara default. Internet Explorer 4.x dan versi (hingga IE 8) mengurangi waktu default keluar nilai setengah jam, yang dapat berubah dalam kunci registri yang sesuai

. 

Aplikasi lain

Sistem yang dijabarkan diatas memberikan skenario yang disederhanakan. Domain Name System meliputi beberapa fungsi lainnya:

• Hostname dan alamat IP tidak berarti terhubung secara satu-banding-satu. Mungkin beberapa hostname sesuai dengan alamat IP tunggal: gabungan dengan virtual hosting , ini memungkinkan satu komputer untuk melayani banyak situs web. Atau sebuah nama host dapat mewakili beberapa alamat IP: ini dapat memfasilitasi toleransi kesalahan dan distribusi beban, dan juga memungkinkan sebuah situs untuk memindahkan lokasi fisik mulus.
• Ada banyak kegunaan DNS selain menerjemahkan nama ke alamat IP. Misalnya, Surat agen mentransfer menggunakan DNS untuk mencari tahu di mana untuk memberikan e-mail untuk alamat tertentu. Domain untuk pemetaan mail exchanger yang disediakan oleh MX mengakomodasi lapisan lain toleransi kesalahan dan distribusi beban di atas nama untuk pemetaan alamat IP.

• E-mail Blacklist: Sistem DNS digunakan untuk penyimpanan yang efisien dan distribusi alamat IP dari daftar hitam e-mail host. Metode yang biasa digunakan adalah menempatkan alamat IP dari host subjek ke dalam sub-domain dari sebuah nama domain tingkat yang lebih tinggi, dan menyelesaikan nama itu untuk catatan yang berbeda untuk menunjukkan positif atau negatif. Berikut adalah daftar hitam contoh hipotetis:
  • 102.3.4.5 adalah daftar hitam => Membuat 5.4.3.102.blacklist.example dan menyelesaikan ke 127.0.0.1
  • 102.3.4.6 tidak => 6.4.3.102.blacklist.example tidak ditemukan, atau default 127.0.0.2
  • E-mail server kemudian dapat permintaan blacklist.example melalui mekanisme DNS untuk mencari tahu apakah sebuah host tertentu menghubungkan kepada mereka adalah di blacklist. Saat ini banyak dari blacklist tersebut, baik gratis atau berbasis langganan, tersedia terutama untuk digunakan oleh administrator email dan software anti-spam.

• Pembaruan perangkat lunak: banyak anti-virus dan perangkat lunak komersial sekarang menggunakan sistem DNS untuk menyimpan nomor versi dari pembaruan perangkat lunak terbaru sehingga komputer klien tidak perlu untuk menghubungkan ke server setiap kali pembaruan. Untuk jenis aplikasi, waktu cache dari catatan DNS biasanya lebih pendek.

• Sender Policy Framework dan DomainKeys , bukan menciptakan jenis mereka sendiri catatan, dirancang untuk mengambil keuntungan dari yang lain jenis rekod DNS, dikenal sebagai rekod TXT.
• Untuk memberikan ketahanan dalam peristiwa kegagalan komputer, beberapa server DNS biasanya disediakan untuk cakupan dari setiap domain, dan pada tingkat atas, tiga belas sangat ampuh root server ada, dengan tambahan "salinan" dari beberapa dari mereka didistribusikan di seluruh dunia melalui Anycast .
• Dynamic DNS (kadang-kadang disebut DDNS) memungkinkan klien untuk memperbarui entri DNS sebagai perubahan alamat IP mereka, seperti halnya, misalnya, ketika bergerak antara ISP atau mobile hot spot .
•  
•  

  Protokol rincian

DNS terutama menggunakan User Datagram Protocol (UDP) pada nomor port 53 untuk melayani permintaan. ^[5] permintaan DNS berisi permintaan UDP tunggal dari klien diikuti oleh jawaban UDP tunggal dari server. Para Transmission Control Protocol (TCP) digunakan ketika ukuran data jawaban melebihi 512 byte, atau untuk tugas-tugas seperti transfer zona . Beberapa sistem operasi, seperti HP-UX , yang dikenal memiliki implementasi resolver yang menggunakan TCP untuk semua pertanyaan, bahkan ketika UDP akan cukup.

 

  DNS sumber daya catatan

Sebuah Resource Record (RR) adalah elemen data dasar dalam sistem nama domain. Setiap record memiliki tipe (A, MX, dll), suatu batas waktu kadaluarsa , kelas, dan beberapa jenis data spesifik. Sumber daya catatan dari jenis yang sama mendefinisikan suatu set resource record (RRset). Urutan catatan sumber daya dalam satu set, dikembalikan oleh resolver untuk aplikasi, tidak terdefinisi, tetapi sering server menerapkan round-robin memesan untuk mencapai load balancing. DNSSEC , bagaimanapun, bekerja pada set catatan sumber daya yang lengkap dalam urutan kanonik.
Saat dikirim melalui jaringan IP, semua catatan umum menggunakan format yang ditetapkan dalam RFC 1035 : 

RR (Resource catatan) bidang

Lapangan	Deskripsi	Panjang ( oktet )
NAMA	Nama node yang merekam ini berkaitan	(Variabel)
JENIS	Jenis RR dalam bentuk numerik (misalnya 15 untuk MX RR)	2
KELAS	Kode kelas	2
TTL	Count detik yang RR tetap berlaku (maksimum adalah 2 31 -1, yaitu sekitar 68 tahun.)	4
RDLENGTH	Panjang bidang RDATA	2
RDATA	Tambahan RR-data spesifik	(Variabel)

NAME adalah nama domain berkualifikasi lengkap dari node di pohon. Pada kawat, nama dapat dipersingkat menggunakan kompresi label jika ujung nama domain disebutkan sebelumnya dalam paket dapat digantikan untuk akhir nama domain saat ini.
TYPE adalah tipe record. Hal ini menunjukkan format data dan memberikan petunjuk penggunaan yang dimaksudkan. Sebagai contoh, catatan A digunakan untuk menerjemahkan dari nama domain ke sebuah alamat IPv4 , daftar NS record yang nama server dapat menjawab pencarian pada zona DNS , dan MX record menentukan mail server yang digunakan untuk menangani email untuk domain tertentu dalam sebuah alamat e-mail (lihat juga Daftar jenis catatan DNS ).
RDATA adalah data tipe-spesifik relevansi, seperti alamat IP untuk catatan alamat, atau prioritas dan hostname untuk MX. Jenis catatan terkenal dapat menggunakan kompresi label di bidang RDATA, tetapi "tidak diketahui" jenis catatan tidak boleh ( RFC 3597 ).
CLASS dari sebuah record set ke IN (untuk Internet) untuk catatan DNS yang umum yang melibatkan nama host internet, server, atau alamat IP. Selain itu, kelas Chaos (CH) dan Hesiod (HS) ada. ^[16] Setiap kelas adalah ruang nama independen dengan delegasi berpotensi berbeda dari zona DNS .
Selain catatan sumber daya didefinisikan dalam file zona , sistem nama domain juga mendefinisikan beberapa jenis permintaan yang hanya digunakan dalam komunikasi dengan node DNS lain (pada kawat), seperti ketika melakukan transfer zona (AXFR / IXFR) atau untuk EDNS (OPT).

 

Wildcard DNS record

Sistem nama domain mendukung nama domain wildcard yang nama-nama yang dimulai dengan label tanda bintang, '*', misalnya, *. misalnya. ^{[3] [17]} DNS record milik nama domain wildcard menetapkan aturan untuk menghasilkan catatan sumber daya dalam satu zona DNS dengan menggantikan seluruh label dengan komponen pencocokan nama query, termasuk keturunan tertentu. Sebagai contoh, dalam x.example zona DNS, konfigurasi berikut menetapkan bahwa semua subdomain (termasuk subdomain dari subdomain) dari x.example menggunakan axexample mail exchanger. Catatan untuk axexample diperlukan untuk menentukan mail exchanger. Karena ini memiliki hasil dari tidak termasuk nama domain ini dan subdomainnya dari pertandingan wildcard, semua subdomain dari axexample harus didefinisikan dalam pernyataan wildcard terpisah.
Peran catatan wildcard diolah di RFC 4592 , karena definisi asli dalam RFC 1034 tidak lengkap dan mengakibatkan salah tafsir oleh pelaksana

. 

  Protokol ekstensi

DNS protokol asli telah membatasi ketentuan untuk perpanjangan dengan fitur-fitur baru. Pada tahun 1999, Paul Vixie diterbitkan dalam RFC 2671 mekanisme ekstensi, yang disebut mekanisme Ekstensi untuk DNS (EDNS) yang memperkenalkan unsur-unsur protokol opsional tanpa overhead meningkat bila tidak digunakan. Hal ini dicapai melalui catatan pseudo-sumber daya OPT yang hanya ada di transmisi kawat protokol, tetapi tidak dalam setiap file zona. Ekstensi awal juga disarankan (EDNS0), seperti meningkatkan ukuran pesan DNS di datagrams UDP.

 

Update zona Dinamis

Dynamic DNS update menggunakan opcode UPDATE DNS untuk menambah atau menghapus catatan sumber daya dinamis dari zona base data yang dikelola pada server DNS otoritatif. Fitur ini dijelaskan dalam RFC 2136 . Fasilitas ini berguna untuk mendaftarkan klien jaringan ke DNS saat mereka boot atau menjadi sebaliknya yang tersedia pada jaringan. Karena klien dapat boot diberi alamat IP yang berbeda setiap waktu dari DHCP server, tidak mungkin untuk memberikan tugas statis DNS untuk klien tersebut.

 

  Masalah keamanan

Awalnya, masalah keamanan tidak pertimbangan desain utama untuk perangkat lunak DNS atau perangkat lunak untuk penyebaran di Internet awal, sebagai jaringan itu tidak terbuka untuk partisipasi oleh masyarakat umum. Namun, ekspansi dari Internet ke sektor komersial pada 1990-an mengubah persyaratan untuk langkah-langkah keamanan untuk melindungi data integritas dan otentikasi pengguna.
Beberapa isu-isu kerentanan ditemukan dan dieksploitasi oleh pengguna yang jahat. Salah satu isu tersebut adalah DNS cache keracunan , di mana data didistribusikan kepada caching resolver dengan dalih menjadi server asal otoritatif, sehingga mencemari menyimpan data dengan informasi palsu dan berpotensi kali kedaluwarsa panjang (waktu-ke-hidup). Selanjutnya, permintaan aplikasi yang sah mungkin dialihkan ke host jaringan yang dioperasikan dengan maksud jahat.
DNS tanggapan biasanya tidak cryptographically ditandatangani, yang mengarah ke kemungkinan serangan banyak, sedangkan Ekstensi Domain Name Sistem Keamanan (DNSSEC) memodifikasi DNS untuk menambahkan dukungan untuk respon cryptographically ditandatangani. Beberapa ekstensi telah dirancang untuk mengamankan zona transfer juga.
Beberapa nama domain dapat digunakan untuk mencapai efek spoofing. Sebagai contoh, paypal.com dan paypa1.com adalah nama-nama berbeda, namun pengguna mungkin tidak dapat membedakan mereka dalam antarmuka pengguna grafis tergantung pada pengguna yang dipilih jenis huruf . Dalam banyak font huruf l dan angka 1 terlihat sangat mirip atau bahkan identik. Masalah ini akut dalam sistem yang mendukung nama domain internasional , karena banyak kode karakter ISO 10646 , dapat muncul identik pada layar komputer khas. Kerentanan ini kadang-kadang dimanfaatkan dalam phishing . ^[18]
Teknik seperti reverse DNS dikonfirmasi ke depan juga dapat digunakan untuk membantu memvalidasi hasil DNS.

 

  Domain registrasi nama

Hak untuk menggunakan nama domain yang didelegasikan oleh pendaftar nama domain yang diakreditasi oleh Internet untuk Corporation Ditugaskan Nama dan Nomor (ICANN), organisasi yang bertugas mengawasi nama dan jumlah sistem Internet. Selain ICANN, setiap domain tingkat atas (TLD) dipertahankan dan diservis secara teknis oleh organisasi administrasi, operasi registry. Sebuah registri bertanggung jawab untuk menjaga database nama yang terdaftar dalam mengelola TLD itu. Registri menerima informasi pendaftaran dari setiap registrar nama domain yang berwenang untuk menetapkan nama di TLD sesuai dan menerbitkan informasi menggunakan layanan khusus, whois protokol.
ICANN menerbitkan daftar lengkap pendaftar TLD dan pendaftar nama domain. Informasi pendaftar terkait dengan nama domain dipertahankan dalam sebuah database online dapat diakses dengan WHOIS layanan. Untuk sebagian besar dari lebih dari 240 kode negara top-level domain (ccTLDs), pendaftar domain penuh menjaga WHOIS (Pendaftar, nama server, tanggal kadaluwarsa, dll) informasi. Sebagai contoh, DENIC , Jerman NIC, memegang data domain DE. Sejak sekitar 2001, sebagian besar gTLD registries telah mengadopsi pendekatan yang disebut registri tebal, yaitu menjaga WHOIS data dalam pendaftar pusat bukan database registrasi.
Untuk nama domain COM dan NET, model tipis registri digunakan: domain registri (misalnya VeriSign ) memegang dasar WHOIS (pendaftar dan nama server, dll) data. Satu dapat menemukan detil WHOIS (pendaftar, server nama , tanggal kadaluwarsa, dll) di pendaftar.
Beberapa pendaftar nama domain, pusat informasi sering disebut jaringan (NIC), juga berfungsi sebagai pendaftar ke pengguna-akhir. Para pendaftar domain utama generik tingkat atas, seperti untuk NET, COM, ORG, INFO domain, menggunakan model registri-registrar yang terdiri dari pendaftar nama domain banyak ^{[19] [20]} Dalam metode ini manajemen, registri hanya mengelola nama domain database dan hubungan dengan pendaftar. Para pendaftar (pengguna nama domain) adalah pelanggan dari registrar, dalam beberapa kasus melalui tambahan lapisan reseller.