Sistem Nama Domain: Perbezaan antara semakan

Kandungan dihapus Kandungan ditambah
Yosri (bincang | sumb.)
Please do not use machine translation here. Jangan guna terjemahan mesin di sini.
Yosri (bincang | sumb.)
Tiada ringkasan suntingan
Baris 1:
[[Sistem Nama Domain|Sistem Nama Domain ( ''Domain Name System'' ) atau DNS]] merupakan sistem yang menyimpan maklumat mengenai '''[[nama hos]]''' dan '''[[nama domain]]''' di jaringan, seperti di [[Internet]]. Paling penting, ia memberikan [[alamat IP]] bagi setiap nama hos, dan senarai [[pelayan penukaran mel|pelayan penukaran mel ( ''mail exchange server'' )]] yang menerima mel bagi setiap domain.
'''Sistem Nama Domain'''
By : Muhammad Amin Bin Md. Hanif
 
DNS memainkan peranan penting bagi Internet, kerana perkakasan memerlukan alamat IP untuk melaksanakan [[penghalaan|penghalaan ( ''routing'' )]], tetapi manusia menggunakan nama hos dan nama domain, sebagai contoh dalam [[Penentu Sumber Seragam|Penentu Sumber Seragam ( ''Uniform Resource Locator'' ) URL]] dan [[alamat e-mail]].
Sistem Nama Domain (DNS) adalah penamaan sistem hierarki yang diedarkan untuk komputer, perkhidmatan, atau mana-mana sumber yang disambung ke Internet atau rangkaian persendirian. Ia bersekutu pelbagai maklumat dengan nama domain yang diberikan kepada setiap entiti yang mengambil bahagian. Nama Domain Perkhidmatan menyelesaikan pertanyaan bagi nama-nama ini ke dalam alamat IP bagi tujuan pencarian perkhidmatan komputer dan peranti di seluruh dunia. Dengan menyediakan seluruh dunia, teragih perkhidmatan redirection berasaskan kata kunci, Sistem Nama Domain adalah merupakan komponen penting dalam fungsi Internet.
 
[[Paul Mockapetris]] mencipta DNS pada tahun [[1983]]; spesifikasi asal muncul dalam [[Permohonan untuk komen|Permohonan untuk komen ( ''Request for Comments'' ) - RFC]] 882. Pada tahun [[1987]] penerbitan RFC 1034 dan RFC 1035 mengemaskini spesifikasi DNS dan menjadikan RFC 882 dan RFC 883 lapuk. Beberapa RFC terkini telah mengusulkan pelbagai sambungan kepada protokol teras.
Satu analogi yang sering digunakan untuk menerangkan Sistem Nama Domain adalah bahawa ia berfungsi sebagai buku telefon untuk Internet dengan menterjemahkan nama host komputer yang mesra manusia ke alamat IP. Sebagai contoh, nama domain www.example.com diterjemahkan kepada alamat 192.0.43.10 (IPv4) dan 2620:0:2 d0: 200 :: 10 (IPv6). Tidak seperti buku telefon, bagaimanapun, DNS boleh cepat dikemaskini dan ini update diedarkan, membolehkan lokasi perkhidmatan pada rangkaian kepada perubahan tanpa memberi kesan kepada pengguna akhir, yang terus menggunakan nama host yang sama. Pengguna mengambil kesempatan ini apabila mereka membaca Locator bermakna Sumber Seragam (URL) dan alamat e-mel tanpa perlu mengetahui bagaimana komputer sebenarnya menempatkan perkhidmatan.
 
== Bagaimana DNS berfungsi ==
Sistem Nama Domain mengedarkan tanggungjawab memberikan nama domain dan pemetaan nama-nama tersebut kepada alamat IP dengan menetapkan pelayan nama berwibawa untuk setiap domain. Pelayan nama berwibawa ditugaskan bertanggungjawab untuk domain tertentu, dan seterusnya boleh menetapkan pelayan nama lain yang berwibawa untuk domain sub-mereka. Mekanisme ini telah dibuat DNS diedarkan dan salah bertoleransi dan telah membantu mengelakkan keperluan untuk daftar tunggal akan sentiasa dirujuk dan dikemaskini. Selain itu, tanggungjawab untuk mengekalkan dan mengemaskini rekod induk untuk domain tersebar di kalangan banyak pendaftar nama domain, yang bersaing untuk, pengguna akhir domain pemilik perniagaan,. Domain boleh dipindahkan dari pendaftar ke pendaftar pada bila-bila masa.
 
Nama domain terdiri daripada dua atau lebih bahagian (secara teknikal ''labels'') dipisahkan oleh titik. Label disebelah kanan merupakan '''[[domain tahap atas]]''' (sebagai contoh, domain tahap atas untuk <tt>www.wikipedia.org</tt> adalah <tt>org</tt>). Setiap label di sebelah kiri menentukan subdivision atau '''subdomain''' (sebagai contoh, <tt>wikipedia.org</tt> merupakan subdomain bagi <tt>org</tt> dan <tt>www.wikipedia.org</tt> merupakan subdomain kepada <tt>wikipedia.org</tt>). Secara teori, subdivision ini boleh menurun sehingga 127 aras, dan setiap label boleh mengandungi 63 huruf, selagi keseluruhan nama domain tidak melebihi 254 huruf. Tetapi secara penggunaan sesetengah [[daftar nama domain|daftar nama domain ( ''domain name registry'' )]] mempunyai limit yang kurang dari itu.
Sistem Nama Domain juga menetapkan fungsi teknikal perkhidmatan pangkalan data ini. Ia mendefinasikan protokol DNS, spesifikasi terperinci struktur data dan pertukaran komunikasi yang digunakan dalam DNS, sebagai sebahagian daripada Internet Protocol Suite.
 
DNS mengandungi set hierarki '''pelayan DNS'''. Setiap domain atau subdomain mempunyai satu atau lebih '''pelayan DNS sahih''' ( ''authoritative DNS servers'' ) yang menerbitkan maklumat mengenai domain tersebut. Hierarki mengenai pelayan DNS sahih mempunyai padanan dengan hierarki domain.
'''Gambaran Keseluruhan'''
---------------------------------------------------------------------------------------------------------------------
Internet mengekalkan dua ruang nama utama, hierarki nama domain [1] dan Protokol Internet (IP) ruang alamat. [2] Sistem Nama Domain mengekalkan hierarki nama domain dan menyediakan perkhidmatan penterjemahan antara ia dan ruang alamat. Pelayan nama internet dan protokol komunikasi melaksanakan Sistem Nama Domain. [3] pelayan DNS nama pelayan yang menyimpan rekod DNS bagi nama domain, seperti alamat (A) rekod, rekod nama pelayan (NS), dan mel penukar (MX) rekod (lihat juga menyenaraikan jenis rekod DNS); nama pelayan DNS membalas dengan jawapan kepada pertanyaan terhadap pangkalan data.
 
{{Portal sains komputer}}
'''Sejarah'''
{{Jaringan Sejagat}}
---------------------------------------------------------------------------------------------------------------------
Amalan menggunakan nama sebagai abstraksi yang mudah, lebih diingati alamat berangka hos dalam rangkaian tarikh kembali ke era ARPANET. Sebelum DNS telah dicipta pada tahun 1982, setiap komputer dalam rangkaian retrieved fail yang dipanggil HOSTS.TXT dari komputer di SRI (sekarang SRI Antarabangsa) [4] [5] HOSTS.TXT fail dipetakan nama untuk alamat berangka. Fail tuan rumah masih wujud pada kebanyakan sistem operasi moden secara lalai dan pada amnya mengandungi pemetaan "localhost" ke alamat IP 127.0.0.1. Banyak sistem operasi menggunakan nama logik resolusi yang membolehkan pentadbir untuk mengkonfigurasi keutamaan pemilihan bagi kaedah tersedia resolusi nama.
 
[[Kategori:Jaringan Sejagat]]
Pertumbuhan pesat rangkaian yang dibuat di tengah-tengah dikekalkan, tangan yang halus HOSTS.TXT fail yang tidak lestari, ia menjadi perlu untuk melaksanakan sistem yang lebih berskala mampu menyebarkan maklumat yang diperlukan secara automatik.
[[Kategori:Internet]]
 
[[af:Domeinnaamstelsel]]
Atas permintaan Jon Postel, Paul Mockapetris mencipta Sistem Nama Domain pada tahun 1983 dan menulis pelaksanaan pertama. Spesifikasi yang asal telah diterbitkan oleh Pasukan Petugas Kejuruteraan Internet di RFC 882 dan RFC 883, yang digantikan pada bulan November 1987 oleh RFC 1034 [1] dan RFC 1035. [3] Permintaan Beberapa tambahan untuk Komen telah mencadangkan lanjutan pelbagai DNS teras protokol.
[[ar:نظام أسماء النطاقات]]
 
[[ast:DNS]]
Pada tahun 1984, 4 Berkeley pelajar-Douglas Terry, Mark Painter, David Riggle, dan Songnian Zhou-menulis pelaksanaan Unix yang pertama, dipanggil Pelayan Internet Berkeley Nama Domain (BIND). [6] Pada tahun 1985, Kevin Dunlap perniagaan DEC ketara semula menulis pelaksanaan DNS. Mike Karels, Phil Almquist, dan Paul vixie telah mengekalkan BIND sejak itu. BIND telah dipindahkan kepada platform Windows NT pada awal tahun 1990-an.
[[az:DNS]]
 
[[id:Sistem Penamaan Domain]]
BIND telah diedarkan secara meluas, terutamanya pada sistem Unix, dan perisian dominan DNS digunakan di Internet. [7] Dengan menggunakan berat dan penelitian menyebabkan kod sumber terbuka, serta kaedah serangan yang semakin canggih, keselamatan kelemahan telah ditemui dalam BIND [perlu petikan]. Ini telah menyumbang kepada pembangunan beberapa pelayan nama alternatif dan program resolver. BIND versi 9 telah ditulis dari awal dan kini mempunyai rekod keselamatan yang setanding dengan perisian DNS moden lain. [Perlu petikan]
[[bn:ডোমেইন নেম সিস্টেম]]
 
[[bar:Domain Name System]]
[[bs:Domain name system]]
'''Struktur'''
[[bg:Domain Name System]]
 
[[ca:Domain Name System]]
---------------------------------------------------------------------------------------------------------------------
[[cs:Domain Name System]]
 
[[da:Domain Name System]]
'''Nama domain ruang'''
[[de:Domain Name System]]
 
[[et:Domeeninimede süsteem]]
Ruang nama domain terdiri daripada pokok yang nama domain. Setiap nod atau daun di pokok itu mempunyai sifar atau lebih rekod sumber, yang memegang maklumat yang berkaitan dengan nama domain. Pokok sub-terbahagi kepada zon yang bermula pada zon akar. Zon DNS boleh terdiri hanya satu domain, atau mungkin terdiri daripada banyak domain dan sub-domain, bergantung kepada pihak berkuasa pentadbiran yang diwakilkan kepada pengurus.
[[el:Domain Name System]]
[[en:Domain Name System]]
Sistem Nama Domain hierarki, yang dianjurkan kepada zon, setiap berkhidmat oleh pelayan nama
[[es:Domain Name System]]
Tanggungjawab pentadbiran ke atas mana-mana zon boleh dibahagikan dengan mewujudkan zon tambahan. Pihak berkuasa dikatakan diwakilkan untuk sebahagian ruang yang lama, biasanya dalam bentuk sub-domainnya, nameserver lain dan entiti pentadbiran. Zon lama terhenti menjadi berwibawa untuk zon baru.
[[eo:Domajna nomsistemo]]
Nama sintaks Domain
[[eu:Domain Name System]]
Penerangan yang pasti kaedah-kaedah untuk membentuk nama domain muncul dalam RFC 1035, RFC 1123 dan RFC 2181. Nama domain terdiri daripada satu atau lebih bahagian, ditakrifkan sebagai label, yang konvensional berkaskad, dan dihalang oleh titik, seperti example.com.
[[fa:سامانه نام دامنه]]
 
[[fr:Domain Name System]]
Label yang betul-paling menyampaikan domain top-level, sebagai contoh, www.example.com nama domain milik com domain top-level.
[[gl:Domain Name System]]
Hierarki domain yang turun dari kanan ke kiri; setiap label di sebelah kiri menyatakan dipecah bahagi, atau subdomain domain ke kanan. Sebagai contoh: contoh label menyatakan subdomain domain com dan www adalah sub domain dari example.com. Ini pokok subdivisi mungkin mempunyai sehingga 127 tahap.
[[ko:도메인 네임 시스템]]
Setiap label boleh mengandungi sehingga 63 aksara. Nama domain yang sepenuhnya tidak boleh melebihi panjang sebanyak 253 aksara dalam penentuan luar label bertitik-. [8] Dalam perwakilan perduaan dalaman DNS panjang maksimum memerlukan 255 octet simpanan. [1] Pada amalannya, beberapa domain pendaftaran mungkin mempunyai had yang pendek. [perlu petikan]
[[hi:डोमेन नाम प्रणाली]]
Nama DNS teknikal mungkin terdiri daripada representable apa-apa sifat di dalam perlapanan. Walau bagaimanapun, pembentukan yang dibenarkan nama domain dalam zon akar DNS, dan yang paling domain sub lain, menggunakan format pilihan dan set aksara. Watak-watak yang dibenarkan pada label adalah subset set aksara ASCII, dan termasuklah watak-watak melalui z, A hingga Z, digit 0 hingga 9, dan sempang. Kaedah ini dikenali sebagai kaedah LDH (huruf, angka, sempang). Nama domain ditafsirkan dalam cara kes-bebas. [9] Label tidak boleh memulakan atau menamatkan dengan sempang. [10]
[[hr:DNS]]
Satu nama host adalah nama domain yang mempunyai sekurang-kurangnya satu alamat IP yang berkaitan. Sebagai contoh, nama domain www.example.com dan example.com juga nama host, manakala domain com tidak.
[[it:Domain Name System]]
 
[[he:Domain Name System]]
 
[[kk:Атаудың домендік жүйесі]]
'''Nama domain diantarabangsakan'''
[[ltg:Muižvuordu sistema]]
 
[[lv:DNS (protokols)]]
Ciri-ciri yang dibenarkan set DNS menghalang perwakilan nama dan kata-kata banyak bahasa dalam abjad skrip asli mereka. ICANN telah meluluskan Nama-nama Domain pengantarabangsaan dalam Applications (IDNA) sistem, yang peta rentetan Unicode ke dalam set aksara yang sah DNS menggunakan Punycode. Pada tahun 2009, ICANN meluluskan pemasangan IDN kod negara domain peringkat atas. Di samping itu, pejabat pendaftaran banyak nama-nama teratas yang sedia ada domain tahap (TLD) telah menerima pakai IDNA.
[[lt:DNS]]
 
[[li:Domain Name System]]
'''Nama pelayan'''
[[hu:Domain Name System]]
 
[[ml:ഡൊമെയിൻ നെയിം സിസ്റ്റം]]
'''Rencana utama: Nameserver'''
[[nl:Domain Name System]]
 
[[ja:Domain Name System]]
Sistem Nama Domain dikekalkan oleh sistem pangkalan data teragih, yang menggunakan model client-server. Nod pangkalan data ini adalah nama pelayan. Setiap domain mempunyai sekurang-kurangnya satu pelayan DNS sahih yang menerbitkan maklumat mengenai domain tersebut dan pelayan nama mana-mana domain yang lebih rendah daripada ia. Atas hierarki disampaikan oleh mengacu pada pelayan nama akar, pelayan untuk query apabila melihat (menyelesaikan) TLD.
[[no:Domain Name System]]
 
[[nn:DNS]]
[[mhr:DNS]]
'''Nama pelayan berwibawa'''
[[pl:Domain Name System]]
 
[[pt:Domain Name System]]
Pelayan nama berwibawa adalah nama pelayan yang memberikan jawapan yang telah dikonfigurasikan oleh sumber asal, sebagai contoh, pentadbir domain atau oleh kaedah dinamik DNS, berbeza dengan jawapan yang diperolehi melalui pertanyaan biasa DNS untuk pelayan nama lain. Pelayan nama berwibawa sahaja hanya mengembalikan jawapan kepada pertanyaan mengenai nama domain yang telah dikhususkan dikonfigurasi oleh pentadbir.
[[ro:Sistem de nume de domeniu]]
 
[[ru:DNS]]
Pelayan nama berwibawa sama ada boleh menjadi pelayan induk atau pelayan hamba. Pelayan induk adalah pelayan yang menyimpan asal (master) salinan semua rekod zon. Pelayan hamba menggunakan satu mekanisme automatik mengemaskini DNS protokol komunikasi dengan tuannya untuk mengekalkan salinan serupa rekod master.
[[sah:DNS]]
 
[[sq:Domain Name Server]]
Setiap zon DNS mesti diberikan satu set pelayan nama berwibawa yang dipasang di dalam rekod NS di zon induk, dan perlu dipasang (untuk menjadi rekod yang sahih) sebagai rekod rujukan sendiri NS pada pelayan nama berwibawa.
[[simple:Domain Name System]]
 
[[sk:Domain Name System]]
Apabila nama domain yang berdaftar dengan pendaftar nama domain, pemasangan mereka di pejabat pendaftar domain domain tahap atas memerlukan tugasan pelayan nama rendah dan sekurang-kurangnya satu pelayan name menengah. Keperluan pelayan nama berbilang bertujuan untuk membuat domain masih berfungsi walaupun jika satu nama pelayan menjadi tidak boleh diakses atau tidak dapat beroperasi. [11] penetapan pelayan nama utama semata-mata ditentukan oleh keutamaan diberikan kepada pendaftar nama domain. Bagi tujuan ini, secara umumnya hanya nama domain yang berkelayakan pelayan nama diperlukan, melainkan jika pelayan yang terkandung di dalam domain yang berdaftar, di mana alamat IP yang sepadan diperlukan serta.
[[sl:DNS]]
 
[[ckb:سیستەمی ناوی پاوان]]
Pelayan nama utama adalah sering pelayan nama tuan, manakala nama pelayan menengah boleh dilaksanakan sebagai pelayan hamba.
[[sr:DNS]]
 
[[sh:DNS]]
Pelayan yang berwibawa menunjukkan status membekalkan jawapan muktamad, dianggap berwibawa, dengan menetapkan bendera perisian (protokol sedikit struktur), yang dipanggil Jawapan yang berwibawa (AA) sedikit dalam jawapan. [3] bendera ini biasanya diterbitkan semula dengan ketara dalam output DNS alat pertanyaan pentadbiran (seperti dig) untuk menunjukkan bahawa pelayan nama maklum balas adalah kuasa untuk nama domain dalam soalan. [3]
[[fi:DNS]]
 
[[sv:DNS]]
[[tl:Domain Name System]]
'''Operasi'''
[[ta:களப் பெயர் முறைமை]]
Mekanisme penyelesaian Alamat
[[te:డొమైన్ నేమ్ సిస్టం]]
 
[[th:ระบบการตั้งชื่อโดเมน]]
Resolver nama domain menentukan pelayan nama domain yang sesuai yang bertanggungjawab untuk nama domain dalam soalan dengan urutan pertanyaan yang bermula dengan label yang paling kanan (top-level) domain.
[[vi:DNS]]
 
[[tr:DNS]]
[[uk:Доменна система імен]]
Recursor DNS berunding tiga mengacu pada pelayan nama untuk menyelesaikan www.wikipedia.org alamat.
[[ur:نظام اسم ساحہ]]
Proses ini melibatkan:
[[yi:DNS]]
 
[[yo:Domain Name System]]
Pelbagai rangkaian dikonfigurasi dengan cache permulaan (dipanggil petunjuk) alamat yang diketahui mengacu pada pelayan nama akar. Fail bayangan seperti ini akan dikemas kini secara berkala oleh pentadbir dari sumber yang boleh dipercayai.
[[zh:域名系统]]
A pertanyaan kepada salah satu pelayan akar untuk mencari pelayan berwibawa untuk domain peringkat atas.
Satu pertanyaan untuk pelayan yang diperolehi TLD untuk alamat pelayan DNS yang berwibawa untuk domain peringkat kedua.
Pengulangan langkah sebelumnya untuk memproses setiap label nama domain dalam urutan, sehingga Langkah terakhir yang mengembalikan alamat IP tuan rumah dicari.
 
Rajah menggambarkan proses ini untuk www.wikipedia.org tuan rumah.
 
Mekanisme dalam bentuk mudah ini akan meletakkan beban operasi besar pada pelayan akar, dengan setiap carian untuk alamat yang bermula dengan pertanyaan salah seorang daripada mereka. Berada sebagai kritikal kerana mereka adalah untuk fungsi keseluruhan sistem, penggunaan berat seperti akan mewujudkan kesesakan dapat diatasi untuk trilion pertanyaan diletakkan setiap hari. Dalam amalan caching digunakan dalam pelayan DNS untuk mengatasi masalah ini, dan hasilnya, akar mengacu pada pelayan nama sebenarnya terlibat dengan sangat sedikit daripada jumlah trafik.
 
 
'''Pelayan nama jadisemula dan caching'''
 
 
Pada dasarnya, pelayan nama berwibawa adalah mencukupi untuk operasi Internet. Walau bagaimanapun, dengan nama pelayan operasi hanya berwibawa, setiap query DNS mesti bermula dengan pertanyaan rekursif pada zon akar Sistem Nama Domain dan setiap sistem pengguna perlu melaksanakan perisian resolver mampu operasi rekursi.
 
Untuk meningkatkan kecekapan, mengurangkan trafik DNS di seluruh Internet, dan meningkatkan prestasi dalam aplikasi pengguna akhir, Sistem Nama Domain menyokong pelayan cache DNS yang kedai keputusan query DNS untuk satu tempoh masa yang ditentukan dalam konfigurasi (masa-untuk-hidup) rekod nama domain dalam soalan. Biasanya, caching DNS server, juga dikenali sebagai cache DNS, juga melaksanakan algoritma perlu rekursi untuk menyelesaikan nama yang diberikan bermula dengan akar DNS melalui pelayan nama yang berwibawa domain disoal. Dengan fungsi ini dilaksanakan di pelayan nama, aplikasi pengguna meningkatkan kecekapan dalam reka bentuk dan operasi.
 
Gabungan caching DNS dan fungsi rekursi di pelayan nama tidak mandatori; fungsi boleh dilaksanakan secara bebas di pelayan untuk tujuan khas.
 
Pembekal perkhidmatan internet biasanya menyediakan pelayan nama rekursi dan caching untuk pelanggan mereka. Di samping itu, banyak router rangkaian rumah melaksanakan cache dan recursors yang DNS untuk meningkatkan kecekapan dalam rangkaian tempatan.
 
 
'''DNS resolver'''
 
Lihat juga: resolv.conf
 
Sebelah client-DNS dipanggil DNS resolver. Ia bertanggungjawab untuk memulakan dan susunan pertanyaan yang akhirnya membawa kepada resolusi yang penuh (terjemahan) sumber diminta, contohnya, terjemahan nama domain kepada alamat IP.
 
Query DNS boleh menjadi sama ada pertanyaan bukan rekursi atau pertanyaan rekursi:
 
Satu pertanyaan yang bukan-rekursi adalah salah satu di mana pelayan DNS menyediakan rekod untuk domain yang mana ia adalah berwibawa itu sendiri, atau ia memberikan hasil yang sebahagian tanpa menyoal pelayan lain.
Pertanyaan rekursi adalah salah satu yang pelayan DNS sepenuhnya akan menjawab pertanyaan (atau memberikan ralat) dengan pertanyaan pelayan nama lain jika diperlukan. Pelayan DNS tidak diperlukan untuk menyokong pertanyaan rekursif.
 
Resolver, atau lain pelayan DNS bertindak Recursively bagi pihak resolver itu, perundingan penggunaan perkhidmatan rekursi menggunakan bit dalam tajuk yang dicari.
 
Menyelesaikan biasanya melibatkan iterating melalui beberapa pelayan nama untuk mencari maklumat yang diperlukan. Walau bagaimanapun, sesetengah resolver berfungsi lebih hanya dengan berkomunikasi hanya dengan satu pelayan nama. Ini resolver mudah (yang dipanggil "resolver stub") bergantung kepada pelayan nama rekursi untuk melaksanakan kerja-kerja mencari maklumat untuk mereka.
 
 
'''Pekeliling jajahan dan rekod gam'''
 
 
Pelayan nama dalam delegasi dikenal pasti dengan nama, bukannya melalui alamat IP. Ini bermakna bahawa pelayan nama menyelesaikan perlu mengeluarkan satu lagi permintaan DNS untuk mencari alamat IP pelayan yang telah dirujuk. Jika nama yang diberikan dalam delegasi itu adalah subdomain domain yang delegasi yang disediakan, terdapat pergantungan bulat. Dalam kes ini nameserver menyediakan delegasi itu juga mesti menyediakan satu atau lebih alamat IP untuk nameserver sahih yang disebut dalam delegasi itu. Maklumat ini dikenali sebagai gam. Pelayan nama mewakilkan menyediakan gam ini dalam bentuk rekod dalam seksyen tambahan sambutan DNS, dan menyediakan delegasi dalam seksyen jawapan tindak balas.
 
Sebagai contoh, jika pelayan nama berwibawa untuk example.org adalah ns1.example.org, sebuah komputer yang cuba untuk menyelesaikan www.example.org 1 membuat ketetapan ns1.example.org. Yang sejak ns1 terkandung dalam example.org, ini memerlukan penyelesaian example.org pertama, yang membentangkan bergantung bulat. Untuk memecahkan pergantungan, nameserver bagi domain tahap org atas termasuk gam bersama-sama dengan delegasi untuk example.org. Yang rekod gam rekod alamat yang menyediakan alamat IP untuk ns1.example.org. Resolver menggunakan satu atau lebih alamat IP untuk query salah satu domain pelayan yang berwibawa, yang membolehkan untuk melengkapkan query DNS.
 
 
'''Caching rekod'''
 
 
Proses DNS Resolusi mengurangkan beban pada pelayan individu dengan caching rekod permintaan DNS untuk satu tempoh masa selepas jawapan. Ini memerlukan berunding rakaman dan seterusnya tempatan salinan bukan memulakan permintaan baru di hulu. Masa yang resolver cache respons DNS ditentukan oleh nilai yang dikenali sebagai masa untuk hidup (TTL) yang dikaitkan dengan rekod setiap. TTL yang ditetapkan oleh pentadbir pelayan DNS memberikan respons yang berwibawa. Tempoh kesahan mungkin berbeza daripada hanya beberapa saat ke hari atau beberapa minggu.
 
Sebagai akibat yang patut diberi perhatian senibina ini teragih dan caching, perubahan kepada rekod DNS tidak menyebarkan seluruh rangkaian serta-merta, tetapi memerlukan semua cache akan tamat dan menyegarkan selepas itu TTL. RFC 1912 menyampaikan peraturan-peraturan asas bagi menentukan nilai-nilai yang sesuai TTL.
 
 
Sesetengah resolver boleh mengatasi nilai TTL, sebagai protokol menyokong caching sehingga 68 tahun atau tidak caching pada semua. Caching negatif, iaitu caching fakta bukan kewujudan rekod, ditentukan oleh pelayan nama yang berwibawa untuk zon yang mesti termasuk Mula rekod Authority (SOA) apabila melaporkan tiada data jenis diminta wujud. Nilai bidang MINIMUM rekod SOA dan TTL SOA itu sendiri digunakan untuk menubuhkan TTL untuk jawapan yang negatif.
 
 
'''Reverse lookup'''
 
 
Lookup belakang adalah query DNS bagi nama domain apabila alamat IP dikenali. Beberapa nama domain boleh dikaitkan dengan alamat IP. DNS kedai IP alamat dalam bentuk nama domain sebagai nama khas diformat dalam penunjuk (PTR) rekod dalam infrastruktur domain top-level ARPA. Untuk IPv4, domain-addr.arpa. Bagi IPv6, domain lookup songsang ip6.arpa. Alamat IP diwakili sebagai nama dalam perwakilan-tertib oktet terbalik untuk IPv4, dan teratur perwakilan mengutil terbalik untuk IPv6.
 
Apabila melakukan lookup terbalik, pelanggan DNS menukarkan alamat ke format-format ini, dan kemudian pertanyaan nama untuk rekod PTR berikutan rantaian delegasi bagi mana-mana query DNS. Sebagai contoh, andaikan alamat IPv4 208.80.152.2 ditugaskan untuk Wikimedia. Ia diwakili sebagai nama DNS bagi terbalik seperti ini: 2.152.80.208.in-addr.arpa. Apabila DNS resolver mendapat PTR (terbalik-lookup) permintaan, ia bermula dengan pertanyaan pelayan akar (yang titik kepada pelayan Shiva untuk zon 208.in-addr.arpa). Pada pelayan Shiva, 152.80.208.in-addr.arpa yang diberikan kepada Wikimedia, jadi resolver menghantar satu lagi pertanyaan kepada nameserver Wikimedia untuk 2.152.80.208.in-addr.arpa, yang mengakibatkan suatu tindak balas yang sahih.
lookup pelanggan
 
'''DNS resolusi urutan'''
 
Pengguna biasanya tidak berhubung terus dengan resolver DNS. Sebaliknya DNS resolusi berlaku telus dalam aplikasi seperti pelayar web, klien e-mel, dan aplikasi Internet yang lain. Apabila sesuatu permohonan membuat permintaan yang memerlukan nama domain lookup, program seperti menghantar permintaan resolusi DNS resolver dalam sistem operasi tempatan, yang seterusnya mengendalikan komunikasi yang diperlukan.
 
DNS resolver hampir setiap kali akan mempunyai cache (lihat di atas) yang mengandungi lookup baru-baru ini. Jika cache boleh berikan jawapan untuk permintaan itu, resolver akan kembali nilai di dalam cache untuk program yang membuat permintaan itu. Jika cache tidak mengandungi jawapan, resolver akan menghantar permintaan kepada satu atau lebih pelayan DNS yang ditetapkan. Dalam kes pengguna rumah yang paling, yang pembekal internet perkhidmatan untuk yang mesin menghubungkan biasanya akan membekalkan ini pelayan DNS: seperti pengguna 1 sama ada akan telah dikonfigurasikan bahawa alamat pelayan manual atau dibenarkan DHCP untuk menetapkan ia; Walau bagaimanapun, di mana sistem pentadbir telah dikonfigurasikan sistem menggunakan pelayan DNS sendiri, resolver DNS mereka menunjuk kepada mengacu pada pelayan nama secara berasingan dikekalkan organisasi. Dalam sebarang keadaan, nama pelayan yang disoal itu akan mengikuti proses yang digariskan di atas, sehingga ia sama ada berjaya mendapati hasil atau tidak. Ia kemudian kembali keputusan untuk resolver DNS menganggap ia telah menemui hasilnya, resolver sewajarnya cache bahawa hasil untuk kegunaan masa depan, dan tangan hasil kembali ke perisian yang memulakan permintaan itu.
 
 
'''Resolver patah'''
 
Tahap tambahan kerumitan muncul apabila resolver melanggar peraturan protokol DNS. Beberapa ISP besar telah mengkonfigurasi pelayan DNS mereka melanggar peraturan (mungkin untuk membolehkan mereka menjalankan pada perkakasan yang kurang mahal daripada resolver patuh sepenuhnya), seperti dengan mengingkari TTLs, atau dengan menunjukkan bahawa nama domain tidak wujud semata-mata kerana salah satu pelayan namanya tidak bertindak balas. [12]
 
Sebagai peringkat akhir kerumitan, beberapa permohonan (seperti-pelayar web) juga mempunyai cache DNS mereka sendiri, untuk mengurangkan penggunaan DNS resolver perpustakaan sendiri. Amalan ini dapat menambah kesukaran tambahan apabila debugging isu DNS, kerana ia mengaburi kesegaran data, dan / atau apa data yang datang dari yang cache. Cache ini biasanya menggunakan sangat singkat caching kali pada perintah satu minit. [13]
 
Internet Explorer merupakan satu pengecualian yang ketara: versi ke IE 3.x cache DNS rekod selama 24 jam secara lalai. Internet Explorer 4.x dan versi terkemudian (sehingga ke IE 8) mengurangkan masa lalai daripada nilai kepada setengah jam, yang boleh ditukar dalam kunci registry yang sama. [14]
 
Aplikasi lain
 
Sistem yang digariskan di atas memberikan satu senario yang agak dipermudahkan. Sistem Nama Domain termasuk beberapa fungsi lain:
 
Nama host dan alamat IP tidak semestinya sepadan dengan secara satu-sama-satu. Nama host berganda mungkin sesuai dengan alamat satu IP: digabungkan dengan maya hosting, ini membolehkan sebuah mesin tunggal untuk berkhidmat banyak laman web. Alternatif, nama host tunggal boleh sesuai dengan banyak alamat IP: ini boleh memudahkan toleransi kesalahan dan agihan beban, dan juga membolehkan laman untuk menggerakkan fizikal lokasi di lancar.
Terdapat banyak kegunaan DNS selain menterjemahkan nama alamat IP. Sebagai contoh, ejen pemindahan Mail menggunakan DNS untuk mencari di mana untuk menghantar e-mel bagi sesuatu alamat tertentu. Domain untuk pemetaan penukar mel yang disediakan oleh rekod MX menempatkan satu lagi lapisan toleransi kesalahan dan agihan beban di atas nama kepada pemetaan alamat IP.
 
E-mel senarai hitam: sistem DNS digunakan untuk penyimpanan yang cekap dan pengagihan alamat IP semesta alam e-mel disenaraihitamkan. Kaedah biasa meletakkan alamat IP host subjek ke dalam domain sub-nama domain tahap yang lebih tinggi, dan menyelesaikan nama itu kepada rekod yang berlainan untuk menunjukkan positif atau negatif. Berikut adalah senarai hitam contoh hipotetikal:
102.3.4.5 disenaraihitamkan => Mencipta 5.4.3.102.blacklist.example dan memutuskan untuk 127.0.0.1
102.3.4.6 adalah tidak = 6.4.3.102.blacklist.example> tidak dijumpai, atau lalai untuk 127.0.0.2
Pelayan E-mail kemudian boleh query blacklist.example yang melalui mekanisme DNS untuk mengetahui jika tuan rumah khusus menyambung kepada mereka adalah sebagai senarai hitam. Hari ini, ramai senarai hitam itu, sama ada percuma atau berasaskan langganan, terdapat terutamanya untuk digunakan oleh pentadbir e-mel dan perisian anti-spam.
 
Rangka Kerja Dasar penghantar dan diperakui, bukan mewujudkan jenis rekod mereka sendiri, telah dibentuk untuk mengambil kesempatan daripada satu lagi jenis rekod DNS, rekod TXT.
Untuk memberikan daya tahan dalam peristiwa kegagalan komputer, beberapa pelayan DNS biasanya disediakan untuk liputan setiap domain, dan di peringkat atas, 13 pelayan akar yang kuat wujud, dengan "salinan" tambahan beberapa daripada mereka yang diedarkan ke seluruh dunia melalui Anycast.
Dinamik DNS (kadang-kadang dipanggil DDNS) membolehkan pelanggan untuk mengemaskini DNS kemasukan mereka sebagai perubahan alamat IP mereka, sebagaimana yang dilakukannya, sebagai contoh, apabila bergerak antara ISP atau telefon bimbit kawasan panas.
 
'''Protokol butir-butir'''
 
DNS utama menggunakan Panduan Datagram Protocol (UDP) pada nombor port 53 untuk melayani permintaan. [3] DNS pertanyaan terdiri daripada permintaan UDP satu daripada pelanggan, diikuti dengan jawapan UDP satu dari pelayan. Protokol Kawalan Penghantaran (TCP) digunakan apabila saiz data tindak balas melebihi 512 bait, atau untuk tugas-tugas seperti pemindahan zon. Beberapa pelaksanaan resolver menggunakan TCP untuk semua pertanyaan.
 
'''DNS sumber rekod'''
 
Maklumat lanjut: Senarai jenis rekod DNS
 
Rekod Sumber (RR) adalah elemen data asas dalam sistem nama domain. Rekod masing-masing mempunyai jenis (A, MX, dll), had tamat tempoh masa, kelas, dan beberapa jenis data khusus. Rekod sumber daripada jenis yang sama mentakrifkan satu set sumber rekod (RRset). Perintah rekod sumber dalam satu set, dikembalikan oleh resolver permohonan, undefined, tetapi sering pelayan melaksanakan bulat-robin pesanan untuk mencapai Pelayan Pengimbangan Beban Global. DNSSEC, bagaimanapun, kerja-kerja ke atas set sumber rekod yang lengkap di suatu perintah kanun.
 
Apabila dihantar melalui rangkaian IP, semua rekod yang menggunakan format biasa yang dinyatakan dalam RFC 1035: [15]
Wildcard DNS rekod
Rencana utama: Wildcard DNS rekod
 
Sistem nama domain menyokong nama domain wildcard yang nama-nama yang bermula dengan label asterisk, '*', misalnya, *. Contoh. [1] [17] DNS rekod milik untuk nama domain wildcard nyatakan kaedah-kaedah bagi menjana rekod sumber dalam satu DNS zon dengan menggantikan keseluruhan label dengan komponen yang sepadan nama pertanyaan, termasuk mana-mana keturunan tertentu. Sebagai contoh, dalam x.example zon DNS, konfigurasi berikut menyatakan bahawa semua subdomain (termasuk subdomain sebanyak subdomain) x.example menggunakan penukar mel axexample. Rekod-rekod bagi axexample yang diperlukan untuk menentukan penukar mel. Kerana ini mempunyai hasil tidak termasuk nama domain ini dan subdomain dari perlawanan wildcard, semua subdomain dari axexample mesti ditakrifkan di dalam satu kenyataan di wildcard yang berasingan.
 
Peranan rekod wildcard telah diperhalusi di RFC 4592, kerana definisi asal di RFC 1034 adalah tidak lengkap dan menyebabkan salah tafsiran oleh pelaksana. [17]
 
'''Protokol sambungan'''
 
DNS asal protokol mempunyai peruntukan yang terhad lanjutan dengan ciri-ciri baru. Pada tahun 1999, Paul vixie disiarkan dalam RFC 2671 satu mekanisme lanjutan, yang dipanggil mekanisme Tambahan untuk DNS (EDNS), yang memperkenalkan elemen protokol pilihan tanpa meningkat overhed apabila tidak digunakan. Ini telah dicapai melalui rekod OPT pseudo-sumber yang hanya wujud dalam transmisi wayar protokol, tetapi tidak dalam mana-mana fail zon. Lanjutan awal juga telah dicadangkan (EDNS0), seperti meningkatkan saiz DNS mesej dalam datagrams UDP.
 
'''Zon update dinamik'''
 
Dinamik DNS update menggunakan DNS UPDATE opcode untuk menambah atau membuang rekod sumber dinamik daripada pangkalan data zon yang dikekalkan pada pelayan DNS sahih. Ciri tersebut akan diterangkan dalam RFC 2136. Kemudahan ini amat berguna untuk mendaftarkan pelanggan rangkaian ke DNS apabila mereka boot atau menjadi selainnya yang terdapat dalam rangkaian. Sejak klien boot boleh diberikan alamat IP yang berbeza setiap kali dari pelayan DHCP, ia tidak mungkin untuk menyediakan tugasan statik DNS untuk pelanggan tersebut.
 
'''Isu-isu keselamatan'''
 
Pada mulanya, kebimbangan keselamatan tidak pertimbangan reka bentuk utama untuk perisian DNS atau mana-mana perisian untuk penempatan di Internet awal, sebagai rangkaian tidak dibuka untuk penyertaan oleh orang awam. Bagaimanapun, pengembangan Internet ke dalam sektor komersial pada tahun 1990-an menukar keperluan bagi langkah-langkah keselamatan untuk melindungi integriti data dan pengesahan pengguna.
 
Beberapa isu-isu kelemahan ditemui dan dieksploitasi oleh pengguna yang berniat jahat. Salah satu isu itu adalah keracunan cache DNS, di mana data diagihkan untuk caching resolver di bawah yang pura-pura menjadi pelayan asal berwibawa, seterusnya mencemarkan kedai data dengan maklumat yang berpotensi palsu dan masa habis tempoh panjang (masa-untuk-hidup). Selepas itu, permintaan permohonan yang sah boleh diarahkan kepada tuan rumah rangkaian yang dikendalikan dengan niat jahat.
 
Jawapan DNS secara tradisi tidak cryptographically ditandatangani, yang membawa kepada banyak kemungkinan serangan; Extensions Keselamatan Sistem Nama Domain (DNSSEC) mengubah DNS untuk menambah sokongan untuk maklumat cryptographically ditandatangani. Beberapa lanjutan telah dirangka untuk menjamin pemindahan zon sebagai.
 
Sesetengah nama domain boleh digunakan untuk mencapai kesan menipu. Sebagai contoh, paypal.com dan paypa1.com adalah nama yang berbeza, namun pengguna mungkin tidak dapat membezakan mereka dalam antara muka pengguna grafik yang bergantung kepada raut muka yang memilih pengguna. Dalam fon banyak l huruf dan angka 1 kelihatan sangat serupa atau bahkan serupa. Masalah ini adalah akut dalam sistem yang menyokong nama domain diantarabangsakan, sejak banyak kod watak dalam ISO 10646, boleh hadir sama pada skrin komputer yang biasa. Kelemahan ini sekali-sekala dieksploitasi dalam phishing. [18]
 
Teknik seperti DNS ke hadapan disahkan terbalik juga boleh digunakan untuk membantu mengesahkan keputusan DNS.
 
'''Pendaftaran nama domain'''
 
Hak untuk menggunakan nama domain yang diwakilkan oleh pendaftar nama domain yang telah diakreditasikan oleh Perbadanan Internet untuk Nama Ditugaskan dan Nombor (ICANN), organisasi yang dipertanggungkan dengan menyelia sistem nama dan nombor Internet. Sebagai tambahan kepada ICANN, setiap domain peringkat atas (TLD) dikekalkan dan perkhidmatan teknikal oleh organisasi pentadbiran, operasi pejabat pendaftaran. Registry adalah bertanggungjawab untuk mengekalkan pangkalan data nama yang didaftarkan dalam tempoh yang TLD ia mentadbir. Registry menerima maklumat pendaftaran dari setiap pendaftar nama domain yang diberi kuasa untuk menetapkan nama-nama dalam TLD sepadan dan menerbitkan maklumat menggunakan perkhidmatan khas, protokol whois.
 
ICANN menerbitkan senarai lengkap TLD pendaftaran dan pendaftar nama domain. Maklumat pendaftar yang berkaitan dengan nama domain dikekalkan dalam pangkalan data dalam talian yang boleh diakses dengan perkhidmatan WHOIS. Bagi kebanyakan lebih daripada 240 negara kod top-level domain (ccTLDs), pejabat pendaftaran domain mengekalkan maklumat WHOIS (Pendaftar, pelayan nama, tarikh luput, dll). Sebagai contoh, DENIC, Jerman NIC, memegang data domain DE. Sejak kira-kira 2001, yang paling pendaftar gTLD telah menerima pakai pendekatan apa yang dipanggil registry tebal, iaitu menyimpan data WHOIS di pejabat pendaftaran pusat bukan pangkalan data pendaftar.
 
Bagi nama domain COM dan BERSIH, model registry nipis digunakan: pejabat pendaftaran domain (contohnya VeriSign) memegang data asas WHOIS (pelayan pendaftar dan nama, dll). Seseorang itu dapat menemui WHOIS terperinci (Pendaftar, pelayan nama, tarikh luput, dll) di pendaftar.
 
 
Sesetengah pendaftar nama domain, selalunya dipanggil pusat-pusat maklumat rangkaian (NIC), juga berfungsi sebagai pendaftar kepada pengguna akhirnya. Generik utama pendaftar domain top-level, seperti BERSIH COM, ORG, domain INFO, menggunakan model pendaftaran-pendaftar yang terdiri daripada pendaftar nama domain yang banyak. [19] [20] Dalam kaedah ini pengurusan, pejabat pendaftaran hanya menguruskan pangkalan data nama domain dan hubungan dengan pendaftar. Pendaftar (pengguna nama domain) adalah pelanggan pendaftar, dalam sesetengah kes melalui lapisan tambahan penjual.
 
'''Internet Standard'''
 
Sistem Nama Domain ditakrifkan oleh Permintaan untuk Comments (RFC) dokumen-dokumen yang diterbitkan oleh Pasukan Petugas Kejuruteraan Internet (Internet standard). Berikut adalah senarai RFC yang menentukan protokol DNS.
 
• RFC 920, Domain Requirements – Specified original top-level domains
• RFC 1032, Domain Administrators Guide
• RFC 1033, Domain Administrators Operations Guide
• RFC 1034, Domain Names - Concepts and Facilities
• RFC 1035, Domain Names - Implementation and Specification
• RFC 1101, DNS Encodings of Network Names and Other Types
• RFC 1123, Requirements for Internet Hosts—Application and Support
• RFC 1178, Choosing a Name for Your Computer (FYI 5)
• RFC 1183, New DNS RR Definitions
• RFC 1591, Domain Name System Structure and Delegation (Informational)
• RFC 1912, Common DNS Operational and Configuration Errors
• RFC 1995, Incremental Zone Transfer in DNS
• RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• RFC 2100, The Naming of Hosts (Informational)
• RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
• RFC 2181, Clarifications to the DNS Specification
• RFC 2182, Selection and Operation of Secondary DNS Servers
• RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
• RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
• RFC 2671, Extension Mechanisms for DNS (EDNS0)
• RFC 2672, Non-Terminal DNS Name Redirection
• RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
• RFC 3225, Indicating Resolver Support of DNSSEC
• RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
• RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
• RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)
• RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
• RFC 4592, The Role of Wildcards in the Domain Name System
• RFC 4635, HMAC SHA TSIG Algorithm Identifiers
• RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)
• RFC 5001, DNS Name Server Identifier (NSID) Option
• RFC 5452, Measures for Making DNS More Resilient against Forged Answers
• RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
• RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
• RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
• RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
• RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
• RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale (Informational)
• RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 (Informational)
• RFC 5966, DNS Transport over TCP - Implementation Requirements
• RFC 6195, Domain Name System (DNS) IANA Considerations (BCP 42)
 
'''Keselamatan'''
 
• RFC 4033, DNS Security Introduction and Requirements
• RFC 4034, Resource Records for the DNS Security Extensions
• RFC 4035, Protocol Modifications for the DNS Security Extensions
• RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
• RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC