Sistem Nama Domain
Domain Name System (DNS) adalah suatu sistem hirarki penamaan dibangun pada database terdistribusi untuk komputer, jasa, atau sumber daya apapun yang terhubung ke Internet atau jaringan pribadi. Yang paling penting, menerjemahkan nama domain berarti bagi manusia ke pengidentifikasi numerik yang terkait dengan peralatan jaringan untuk tujuan mencari dan menangani perangkat ini di seluruh dunia.
Sebuah analogi yang sering digunakan untuk menjelaskan Sistem Nama Domain adalah bahwa ia berfungsi sebagai "buku telepon" untuk Internet dengan menerjemahkan manusia-komputer ramah nama host menjadi alamat IP. Sebagai contoh, www.example.com menerjemahkan nama domain ke alamat 192.0.32.10 (IPv4) dan 2620:0:2 d0: 200:: 10 (IPv6).
Domain Name System memungkinkan untuk menetapkan nama domain ke kelompok sumber daya Internet dan pengguna dalam cara yang berarti, independen dari lokasi fisik masing-masing entitas. Karena ini, World Wide Web (WWW) hyperlink dan informasi kontak dapat tetap internet konsisten dan konstan bahkan jika internet saat ini routing yang mengubah pengaturan atau peserta menggunakan perangkat mobile. Internet nama domain lebih mudah diingat daripada alamat IP seperti 208.77.188.166 (IPv4) atau 2001: DB8: 1f70:: 999: de8: 7648:6 e8 (IPv6). Pengguna memanfaatkan ini ketika mereka membacakan Uniform Resource Locators bermakna (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 untuk 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 toleransi kesalahan dan telah membantu menghindari kebutuhan untuk mendaftar pusat tunggal untuk terus-menerus berkonsultasi dan diperbarui.
Secara umum, Sistem Nama Domain juga menyimpan jenis informasi lainnya, seperti daftar mail server yang menerima email untuk domain yang diberikan internet. Dengan menyediakan, di seluruh dunia didistribusikan kata kunci layanan berbasis redirection, Sistem Nama Domain adalah komponen penting dari fungsi Internet.
Pengenal lainnya seperti tag RFID, UPCs, karakter Internasional di alamat email dan nama host, dan berbagai pengenal lainnya semua bisa berpotensi menggunakan DNS. [1] [2]
Domain Name System juga menentukan fungsi teknis dari layanan database. Ini mendefinisikan protokol DNS, definisi rinci tentang struktur data dan pertukaran komunikasi yang digunakan dalam DNS, sebagai bagian dari Internet Protocol Suite.
Ikhtisar
Internet mempertahankan dua ruang nama utama, hirarki nama domain [3] dan Internet Protocol (IP) sistem alamat [4]. Domain Name System mempertahankan namespace domain dan menyediakan layanan terjemahan antara dua ruang nama. Nama server Internet dan protokol komunikasi melaksanakan Domain Name System [5]. Sebuah server nama DNS 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.
[Sunting] Sejarah
Praktek menggunakan nama sebagai abstraksi, sederhana lebih mudah diingat alamat numerik host pada sebuah jaringan tanggal kembali ke era ARPANET. Sebelum DNS diciptakan pada tahun 1983, setiap komputer pada jaringan diambil file bernama HOSTS.TXT dari komputer di SRI (sekarang SRI International) [6]. [7] File HOSTS.TXT nama dipetakan ke alamat numerik. Sebuah host file masih ada pada sistem operasi paling modern dengan default dan umumnya berisi pemetaan dari 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 mampu otomatis 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 dalam RFC 882 dan RFC 883, yang digantikan pada November 1987 oleh RFC 1034 [3] dan RFC 1035. [5] Permintaan tambahan untuk Komentar Beberapa telah mengusulkan berbagai ekstensi ke DNS inti protokol.
Pada tahun 1984, empat Berkeley mahasiswa-Douglas Terry, Mark Painter, David Riggle, dan Songnian Zhou-menulis implementasi Unix yang pertama, yang disebut Berkeley Internet Nama Domain (BIND) Server [8] Pada tahun 1985, Kevin Dunlap dari Desember signifikan ulang. menulis implementasi DNS. Mike Karels, Phil Almquist, dan Paul Vixie telah mempertahankan BIND sejak saat itu. BIND adalah porting ke platform Windows NT pada awal 1990-an.
BIND didistribusikan secara luas, terutama pada sistem Unix, dan merupakan perangkat lunak DNS yang dominan digunakan di Internet [9] Dengan menggunakan berat dan pengawasan yang dihasilkan dari open source kodenya, serta metode serangan semakin canggih. Keamanan, banyak kekurangan ditemukan di BIND [rujukan?]. Hal ini memberikan kontribusi terhadap pengembangan sejumlah server nama alternatif dan program resolver. BIND versi 9 ditulis dari awal dan sekarang memiliki catatan keamanan yang sebanding dengan software DNS modern lainnya [rujukan?].
[Sunting] Struktur
[Sunting] 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 dapat terdiri dari banyak domain dan sub-domain, tergantung pada kewenangan administratif yang diwakilkan kepada manajer.
Sistem hirarki nama domain, disusun dalam zona, masing-masing dilayani oleh server nama
Tanggung jawab administratif atas setiap zona dapat dibagi dengan membuat zona tambahan. Otoritas dikatakan didelegasikan untuk sebagian dari ruang lama, biasanya dalam bentuk sub-domain, nameserver ke yang lain dan entitas administratif. Zona lama berhenti menjadi otoritatif untuk zona baru.
[Sunting] Domain sintaks nama
Uraian definitif aturan-aturan untuk membentuk nama domain muncul di 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, seperti example.com.
Label paling kanan menyampaikan domain top-level, misalnya, www.example.com nama domain milik com domain top-level.
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 eksternal spesifikasi bertitik-label [10] Dalam representasi biner internal DNS panjang maksimum 255 oktet memerlukan penyimpanan.. [3] Dalam praktek, beberapa pendaftar domain mungkin memiliki batas singkat [rujukan?].
Nama DNS teknis dapat terdiri dari setiap karakter representable dalam oktet. Namun, perumusan diperbolehkan nama domain di zona DNS root, dan sebagian besar sub domain lain, menggunakan format pilihan dan set karakter. Karakter diperbolehkan dalam label adalah subset dari set karakter ASCII, 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-cara yang independen. Label tidak dapat mulai atau berakhir dengan tanda hubung. [11]
Sebuah nama host adalah nama domain yang memiliki minimal satu alamat IP yang terkait. Sebagai contoh, nama domain example.com www.example.com dan juga nama host, sedangkan domain com adalah tidak.
[Sunting] nama domain internasionalisasi
Set karakter yang diijinkan dari DNS mencegah representasi nama dan kata-kata dari berbagai bahasa dalam huruf asli mereka atau script. ICANN telah menyetujui Internasionalisasi Nama Domain pada Aplikasi (IDNA) sistem, yang memetakan string Unicode ke karakter set DNS yang valid menggunakan Punycode. Pada tahun 2009 ICANN menyetujui pemasangan kode negara IDN top-level domain. Selain itu, pendaftar banyak dari top-level domain nama yang ada (TLD) s telah mengadopsi IDNA.
[Sunting] Nama server
Domain Name System dikelola oleh sistem database terdistribusi, yang menggunakan model klien-server. Node database ini adalah server nama. Setiap domain memiliki setidaknya satu server otoritatif DNS yang mempublikasikan informas tentang domain tersebut dan nama server dari setiap domain bawahan untuk itu. Bagian atas hirarki adalah dilayani oleh nameserver root, server untuk query saat mencari (menyelesaikan) TLD.
[Sunting] server nama Resmi
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 nama. 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 update otomatis dari protokol DNS di komunikasi dengan tuannya 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 registrar nama domain instalasi mereka di registri domain dari domain tingkat atas membutuhkan penugasan nama server primer dan paling tidak satu server nama sekunder. Persyaratan server nama multiple bertujuan untuk membuat domain masih fungsional bahkan jika salah satu server nama menjadi tidak dapat diakses atau dioperasi [12]. Penunjukan nama server 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 alamat IP yang sesuai 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, yang dianggap otoritatif, dengan menetapkan bendera perangkat lunak (sedikit struktur protokol), yang disebut Jawaban Resmi (AA) bit dalam responnya [5] Bendera ini biasanya direproduksi mencolok pada output. dari query DNS alat administrasi (seperti menggali) untuk menunjukkan bahwa nama server menanggapi adalah otoritas untuk nama domain yang bersangkutan. [5]
[Sunting] server nama Rekursif dan caching
Pada prinsipnya, server nama otoritatif yang cukup untuk operasi Internet. Namun, dengan hanya otoritatif operasi nama server, setiap query DNS harus mulai dengan query rekursif di zona akar dari Domain Name System dan masing-masing pengguna sistem harus mengimplementasikan software resolver mampu operasi rekursif.
Untuk meningkatkan efisiensi, mengurangi lalu lintas DNS di Internet, dan meningkatkan kinerja aplikasi pengguna akhir, Domain Name System DNS cache server mendukung 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 dilaksanakan di nama server, aplikasi pengguna mendapatkan efisiensi dalam desain dan operasi.
Kombinasi caching DNS dan fungsi rekursif di server namanya tidak wajib; fungsi dapat diimplementasikan secara independen di server untuk tujuan khusus.
Penyedia layanan Internet biasanya menyediakan server nama rekursif dan caching untuk pelanggan mereka. Selain itu, router jaringan rumah banyak menerapkan cache DNS dan recursor untuk meningkatkan efisiensi dalam jaringan lokal.
[Sunting] DNS resolver
Lihat juga: resolv.conf
Sisi-klien dari DNS disebut DNS resolver. Hal ini bertanggung jawab untuk memulai dan sekuensing permintaan yang pada akhirnya mengarah pada resolusi penuh (terjemahan) dari sumber daya dicari, misalnya, terjemahan dari nama domain menjadi alamat IP.
Sebuah query DNS dapat berupa permintaan non-rekursif atau query rekursif:
Sebuah query non-rekursif adalah satu di mana server DNS menyediakan sebuah rekor bagi domain yang otoritatif 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 rekursif menggunakan bit dalam header permintaan.
Menyelesaikan biasanya memerlukan iterasi melalui beberapa server nama untuk menemukan informasi yang dibutuhkan. Namun, beberapa fungsi resolver lebih sederhana dengan hanya berkomunikasi dengan server nama tunggal. Ini resolver sederhana (disebut "resolver rintisan") bergantung pada server nama rekursif untuk melakukan pekerjaan mencari informasi bagi mereka.
[Sunting] Operasi
[Sunting] Alamat mekanisme resolusi
Domain resolver nama menentukan server nama domain yang tepat yang bertanggung jawab untuk nama domain yang dimaksud dengan urutan pertanyaan dimulai dengan label paling kanan (tingkat atas) domain.
Sebuah DNS recursor berkonsultasi tiga nameserver untuk menyelesaikan alamat www.wikipedia.org.
Proses ini memerlukan:
Sebuah host network dikonfigurasi dengan cache awal (disebut petunjuk) dari alamat yang dikenal dari nameserver root. Seperti file petunjuk diperbarui secara periodik oleh administrator dari sumber yang dapat dipercaya.
Sebuah query ke salah satu root server untuk menemukan server otoritatif untuk top-level domain.
Sebuah permintaan ke server TLD diperoleh untuk alamat server DNS otoritatif untuk domain tingkat kedua.
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 awal dengan query salah satu dari mereka. Menjadi sama pentingnya dengan mereka adalah untuk fungsi keseluruhan sistem, gunakan berat seperti akan menciptakan hambatan dapat diatasi untuk ditempatkan triliunan pertanyaan setiap hari. Dalam prakteknya cache digunakan dalam DNS server untuk mengatasi masalah ini, dan sebagai hasilnya, akar nameserver sebenarnya terlibat dengan sangat sedikit dari total lalu lintas.
[Sunting] Edaran dependensi dan lem catatan
Nama server dalam delegasi diidentifikasi berdasarkan nama, selain berdasarkan alamat IP. Ini berarti bahwa nama server harus menyelesaikan masalah lain permintaan DNS untuk mengetahui alamat IP dari server yang telah dirujuk. Jika nama 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 dalam bagian tambahan dari respon DNS, dan memberikan delegasi pada bagian jawaban dari respon.
Misalnya, jika server nama otoritatif untuk example.org adalah ns1.example.org, komputer mencoba untuk menyelesaikan www.example.org pertama menyelesaikan ns1.example.org. Karena ns1 terkandung dalam example.org, ini memerlukan menyelesaikan example.org pertama, yang menyajikan ketergantungan melingkar. Untuk memecahkan ketergantungan, nameserver untuk domain tingkat atas termasuk org 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 DNS query.
[Sunting] caching Rekam
Karena volume besar permintaan DNS dihasilkan untuk Internet publik, para desainer ingin menyediakan mekanisme untuk mengurangi beban pada server DNS individu. Untuk tujuan ini, proses resolusi DNS memungkinkan untuk caching catatan untuk jangka waktu setelah jawaban. Hal ini memerlukan rekaman lokal dan konsultasi berikutnya salinan, bukan memulai permintaan baru hulu. Waktu yang penyelesai sebuah cache respon DNS adalah ditentukan oleh nilai yang disebut waktu untuk hidup (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 untuk sampai 68 tahun atau tidak ada cache sama sekali. Caching negatif, yaitu caching fakta non-eksistensi dari sebuah record, ditentukan oleh server nama otoritatif untuk zona yang harus mencakup Start Otoritas (SOA) record ketika melaporkan tidak ada data dari jenis yang diminta ada. Nilai bidang MINIMUM dari catatan SOA dan TTL dari SOA itu sendiri digunakan untuk menetapkan TTL untuk jawaban negatif.
[Sunting] reverse lookup
Sebuah reverse lookup adalah query dari DNS untuk nama domain ketika alamat IP 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 DNS query. 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.
[Sunting] Klien pencarian
Resolusi DNS urutan
Pengguna umumnya tidak berkomunikasi secara langsung dengan DNS resolver. Sebaliknya resolusi DNS berlangsung transparan dalam program-program aplikasi seperti web browser, klien e-mail, dan aplikasi Internet lainnya. Bila aplikasi yang membuat permintaan yang memerlukan nama domain lookup, program tersebut mengirimkan permintaan ke DNS resolusi resolver dalam sistem operasi lokal, yang pada gilirannya menangani komunikasi yang diperlukan.
DNS resolver akan 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 membuat permintaan. Jika cache tidak memiliki jawabannya, resolver akan mengirimkan permintaan ke satu atau lebih server DNS yang ditunjuk. Dalam kasus kebanyakan pengguna di rumah, penyedia layanan Internet yang menghubungkan komputer tersebut biasanya akan menyediakan server DNS: pengguna tersebut akan memiliki dikonfigurasi alamat server secara manual atau diizinkan DHCP untuk mengatur itu, namun, dimana administrator sistem telah mengkonfigurasi sistem untuk menggunakan server DNS mereka sendiri, mereka menunjuk ke DNS resolver nameserver dipelihara secara terpisah dari organisasi. Dalam hal apapun, sehingga query server nama akan mengikuti proses yang diuraikan 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 berikutnya, dan tangan hasilnya kembali kepada software yang meminta pencarian DNS tersebut.
[Sunting] resolver Patah
Tambahan tingkat kompleksitas muncul ketika resolver melanggar aturan dari protokol DNS. Sejumlah ISP besar telah dikonfigurasi server DNS mereka untuk melanggar aturan (mungkin untuk memungkinkan mereka untuk berjalan di hardware yang lebih murah daripada penyelesai sepenuhnya kompatibel), seperti dengan TTLs tidak patuh, atau dengan menunjukkan bahwa nama domain tidak ada hanya karena salah satu server nama tidak merespon [13].
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 [rujukan?].
Internet Explorer merupakan pengecualian: versi hingga 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. [14]
[Sunting] 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. Beberapa hostname mungkin sesuai dengan alamat IP tunggal: gabungan dengan virtual hosting, ini memungkinkan satu komputer untuk malayani beberapa 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 mengirimkan 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 Blacklists: Sistem DNS digunakan untuk penyimpanan yang efisien dan distribusi alamat IP blacklist host e-mail. Metode yang biasa adalah dengan memasukkan 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. Sebuah contoh hipotetis menggunakan blacklist.example,
102.3.4.5-blacklist => 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 to 127.0.0.2
E-mail server kemudian dapat permintaan blacklist.example melalui mekanisme DNS untuk mengetahui apakah suatu host tertentu menghubungkan kepada mereka adalah di blacklist. Saat ini banyak dari daftar hitam tersebut, baik gratis atau berbasis langganan, tersedia terutama untuk digunakan oleh administrator email dan software anti-spam.
Software Update: banyak anti-virus dan perangkat lunak komersial sekarang menggunakan sistem DNS untuk menyimpan nomor versi update software terbaru sehingga komputer klien tidak perlu terhubung 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 lain jenis rekod DNS, dikenal sebagai rekod TXT.
Untuk memberikan ketahanan dalam peristiwa kegagalan komputer, beberapa server DNS biasanya disediakan untuk cakupan setiap domain, dan pada tingkat atas, tiga belas root server yang sangat kuat ada, dengan tambahan "salinan" dari beberapa dari mereka didistribusikan di seluruh dunia melalui anycast.
Dynamic DNS (DDNS kadang-kadang disebut) memungkinkan klien untuk memperbarui entri DNS sebagai perubahan alamat IP mereka, seperti halnya, misalnya, ketika bergerak antara ISP atau hot spot ponsel.
[Sunting] 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. 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, diketahui memiliki implementasi penyelesai yang menggunakan TCP untuk semua pertanyaan, bahkan ketika UDP akan cukup.
[Sunting] DNS catatan sumber daya
Informasi lebih lanjut: Daftar jenis catatan DNS
Sebuah Resource Record (RR) adalah elemen data dasar dalam sistem nama domain. Setiap record memiliki tipe (A, MX, dll), batas waktu berakhirnya, kelas, dan beberapa tipe data spesifik. Sumber Daya catatan dari jenis yang sama mendefinisikan satu set catatan sumber daya. Urutan catatan sumber daya dalam satu set, dikembalikan oleh penyelesai untuk aplikasi, tidak terdefinisi, tetapi sering server menerapkan round-robin memesan untuk mencapai load balancing. DNSSEC, bagaimanapun, bekerja pada catatan sumber daya set lengkap dalam urutan kanonik.
Saat dikirim melalui jaringan IP, semua catatan umum menggunakan format yang ditetapkan dalam RFC 1035: [15]
RR (Resource catatan) bidang Lapangan Keterangan Panjang (oktet)
NAMA Nama node yang merekam ini berkaitan (variabel)
JENIS Jenis RR dalam bentuk numerik (misalnya 15 untuk MX RR) 2
CLASS Kelas kode 2
TTL Count detik yang RR tetap berlaku (maksimum adalah 231-1, yaitu sekitar 68 tahun.) 4
RDLENGTH Panjang bidang RDATA 2
RDATA Tambahan RR-data spesifik (variabel)
NAMA adalah nama domain berkualifikasi lengkap dari simpul dalam pohon. Pada kawat, nama dapat dipersingkat menggunakan kompresi label jika ujung nama domain disebutkan sebelumnya dalam paket dapat digantikan untuk akhir dari nama domain saat ini.
TYPE adalah tipe record. Hal ini menunjukkan format data dan memberikan sedikit digunakan. Sebagai contoh, catatan A digunakan untuk menerjemahkan dari nama domain ke sebuah alamat IPv4, NS record daftar nama server yang bisa menjawab pencarian pada zona DNS, dan MX record menentukan mail server yang digunakan untuk menangani email untuk domain tertentu di alamat e-mail (lihat juga Daftar jenis catatan DNS).
RDATA adalah data tipe spesifik relevansi, seperti alamat IP untuk catatan alamat, atau prioritas dan nama host untuk MX. Jenis catatan terkenal dapat menggunakan kompresi label dalam bidang RDATA, tetapi "tidak diketahui" jenis catatan tidak boleh (RFC 3597).
KELAS dari sebuah record set ke IN (Internet) untuk catatan DNS yang umum yang melibatkan nama host internet, server, atau alamat IP. Selain itu, Chaos kelas (CN) dan Hesiod (HS) ada [16]. Setiap kelas adalah ruang nama independen dengan delegasi berpotensi berbeda zona DNS.
Selain catatan sumber daya didefinisikan dalam sebuah 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).
[Sunting] Wildcard DNS record
Artikel utama: Wildcard DNS record
Sistem nama domain mendukung nama domain wildcard yang nama-nama yang dimulai dengan label tanda bintang, '*', misalnya, *. contoh [3] [17] DNS record milik nama domain wildcard menetapkan aturan untuk menghasilkan catatan sumber daya dalam tunggal. zona DNS dengan menggantikan seluruh label dengan komponen pencocokan nama query, termasuk keturunan tertentu. Misalnya, 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 telah hasil dari tidak termasuk ini nama domain dan subdomain dari pertandingan wildcard, semua subdomain dari axexample harus didefinisikan dalam sebuah pernyataan terpisah wildcard.
Peran catatan wildcard diperhalus dalam RFC 4592, karena definisi asli dalam RFC 1034 tidak lengkap dan mengakibatkan salah tafsir oleh pelaksana. [17]
[Sunting] Protokol ekstensi
DNS asli protokol telah membatasi ketentuan perpanjangan dengan fitur-fitur baru. Pada tahun 1999, Paulus Vixie dipublikasikan 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 UDP datagram.
[Sunting] update zona Dinamis
Dynamic DNS update menggunakan opcode UPDATE DNS untuk menambah atau menghapus catatan sumber daya secara dinamis dari basis data yang dikelola zona 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 boot dapat diberikan alamat IP yang berbeda setiap kali dari server DHCP, tidak mungkin untuk memberikan tugas statis DNS untuk klien tersebut.
[Sunting] Masalah keamanan
DNS awalnya tidak didesain dengan keamanan dalam pikiran, dan dengan demikian memiliki sejumlah masalah keamanan.
Salah satu kelas dari kerentanan adalah DNS cache keracunan, yang trik server DNS untuk percaya telah menerima informasi otentik ketika, dalam kenyataannya, tidak.
Tanggapan DNS tradisional tidak cryptographically ditandatangani, yang mengarah ke kemungkinan serangan banyak, Nama Domain Extensions Sistem Keamanan (DNSSEC) memodifikasi DNS untuk menambahkan dukungan untuk respon cryptographically ditandatangani. Ada berbagai ekstensi untuk mendukung informasi zona mentransfer mengamankan juga.
Bahkan dengan enkripsi, server DNS dapat menjadi terganggu oleh virus (atau dalam hal ini karyawan yang tidak puas) yang akan menyebabkan alamat IP dari server yang akan diarahkan ke alamat berbahaya dengan TTL panjang. Ini bisa memiliki pengaruh luas untuk berpotensi jutaan pengguna Internet jika sibuk server DNS cache data IP yang buruk. Hal ini akan membutuhkan manual membersihkan semua cache DNS yang terkena dampak seperti yang dipersyaratkan oleh TTL panjang (sampai 68 tahun).
Beberapa nama domain dapat spoof lain, mirip yang tampak nama domain. Misalnya, "paypal.com" dan "paypa1.com" adalah nama-nama berbeda, namun pengguna mungkin tidak dapat membedakan ketika jenis huruf pengguna (font) tidak jelas membedakan huruf l dan angka 1. Masalah ini lebih serius dalam sistem yang mendukung nama domain internasional, karena banyak kode karakter dalam ISO 10646, mungkin muncul identik pada layar komputer khas. Kerentanan ini kadang-kadang dimanfaatkan dalam phishing. [18]
Teknik seperti reverse DNS maju yang dikonfirmasi juga dapat digunakan untuk membantu memvalidasi hasil DNS.
[Sunting] registrasi nama Domain
Hak untuk menggunakan nama domain didelegasikan oleh pendaftar nama domain yang diakreditasi oleh Internet untuk Corporation Ditugaskan Nama dan Nomor (ICANN), organisasi yang bertugas mengawasi sistem nama dan nomor dari Internet. Selain ICANN, setiap domain tingkat atas (TLD) service dan pemeliharaan 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 masing-masing registrar nama domain yang berwenang untuk menetapkan nama di TLD yang sesuai dan menerbitkan informasi menggunakan layanan khusus, protokol whois.
ICANN menerbitkan daftar lengkap pendaftar TLD dan pendaftar nama domain. Informasi pendaftar terkait dengan nama domain dipertahankan dalam sebuah database online dapat diakses dengan layanan WHOIS. Untuk sebagian besar dari lebih dari 240 kode negara top-level domain (ccTLDs), pendaftar domain menjaga WHOIS (Pendaftar, nama server, tanggal kadaluwarsa, dll) informasi. Misalnya, DENIC, Jerman NIC, memegang data domain DE. Sejak sekitar 2001, kebanyakan pendaftar gTLD telah mengadopsi pendekatan yang disebut registri tebal, yaitu menjaga data WHOIS di pusat registries bukan database registrasi.
Untuk nama domain COM dan NET, model tipis registri digunakan: registry domain (misalnya VeriSign) memegang dasar WHOIS (pendaftar dan nama server, dll) data. Satu dapat menemukan WHOIS rinci (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 pendaftar-registri yang terdiri dari pendaftar nama domain banyak [19] [20] Dalam metode 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.
[Sunting] standar Internet
Domain Name System didefinisikan oleh Request for Comments (RFC) dokumen yang diterbitkan oleh Internet Engineering Task Force (standar Internet). Berikut ini adalah daftar RFC yang mendefinisikan protokol DNS.
RFC 920, Persyaratan Domain - Ditentukan asli top-level domain
RFC 1032, Administrator Domain Gratis
RFC 1033, Administrator Domain Operasi Gratis
RFC 1034, Nama Domain - Konsep dan Fasilitas
RFC 1035, Nama Domain - Pelaksanaan dan Spesifikasi
RFC 1101, Encodings DNS dari Nama Jaringan dan Jenis Lain
RFC 1123, Persyaratan untuk Aplikasi Host-Internet dan Dukungan
RFC 1178, Memilih Nama untuk Komputer Anda (FYI 5)
RFC 1183, New DNS RR Definisi
RFC 1591, Domain Name System Struktur dan Delegasi (Informational)
RFC 1912, DNS Kesalahan Umum Operasional dan Konfigurasi
RFC 1995, Tambahan Zona Transfer dalam DNS
RFC 1996, Sebuah Mekanisme Pemberitahuan Perubahan Zona Prompt (DNS NOTIFY)
RFC 2100, The Penamaan Host (Informational)
RFC 2136, Dynamic Updates dalam sistem nama domain (DNS UPDATE)
RFC 2181, Klarifikasi dengan Spesifikasi DNS
RFC 2182, Seleksi dan Operasi Server Secondary DNS
RFC 2308, Caching Negatif Pertanyaan DNS (DNS NCACHE)
RFC 2317, Classless IN-ADDR.ARPA delegasi (BCP 20)
RFC 2671, Ekstensi Mekanisme untuk DNS (EDNS0)
RFC 2672, Kamas Terminal DNS Redirection Nama
RFC 2845, Otentikasi Transaksi Rahasia Kunci untuk DNS (TSIG)
RFC 3225, Mengindikasikan resolver Dukungan DNSSEC
RFC 3226, DNSSEC dan persyaratan IPv6 pesan A6 server / menyadari ukuran resolver
RFC 3597, Penanganan Sumber Daya Rekam DNS Unknown (RR) Jenis
RFC 3696, Aplikasi Teknik untuk Memeriksa dan Transformasi Nama (Informational)
RFC 4343, Domain Name System (DNS) Kasus Klarifikasi Ketidakpekaan
RFC 4592, Peran Wildcard dalam Domain Name System
RFC 4635, HMAC SHA TSIG Algoritma Identifier
RFC 4892, Persyaratan Mekanisme Mengidentifikasi Instance Name Server (Informational)
RFC 5001, DNS Name Server Identifier (NSID) Opsi
RFC 5395, Domain Name System (DNS) IANA Pertimbangan (BCP 42)
RFC 5452, Langkah-langkah untuk Membuat DNS Daya Tahan Lebih Tinggi melawan Jawaban Ditempa
RFC 5625, Pedoman Pelaksanaan Proxy DNS (BCP 152)
RFC 5890, internasionalisasi Nama Domain untuk Aplikasi (IDNA): Definisi dan Kerangka Dokumen
RFC 5891, internasionalisasi Nama Domain di Aplikasi (IDNA): Protokol
RFC 5892, Poin Kode Unicode dan internasionalisasi Nama Domain untuk Aplikasi (IDNA)
RFC 5893, Kanan-ke-Kiri Script untuk Nama Domain internasionalisasi untuk Aplikasi (IDNA)
RFC 5894, internasionalisasi Nama Domain untuk Aplikasi (IDNA): Latar Belakang, Penjelasan, dan Pemikiran (Informational)
RFC 5895, Pemetaan Karakter untuk Nama Domain internasionalisasi dalam Aplikasi (IDNA) 2008 (Informational)
[Sunting] Keamanan
RFC 4033, DNS Keamanan Pendahuluan dan Persyaratan
RFC 4034, Sumber Daya Records untuk Extensions Keamanan DNS
RFC 4035, Protokol Modifikasi untuk Ekstensi Keamanan DNS
RFC 4509, Penggunaan SHA-256 di DNSSEC Delegasi Signor (DS) Sumber Rekaman
RFC 4470, minimal Menutupi Rekaman NSEC dan DNSSEC On-line Penandatanganan
RFC 5011, Pembaruan Otomatis dari DNS (DNSSEC) Keamanan Jangkar Kepercayaan
RFC 5155, DNS Keamanan (DNSSEC) hash Denial dikonfirmasi Kehidupan
RFC 5702, Penggunaan Algoritma SHA-2 dengan RSA di Resource Records DNSKEY dan RRSIG untuk DNSSEC
RFC 5910, Domain Name System (DNS) Ekstensi Keamanan Pemetaan untuk Extensible Provisioning Protocol (EPP)
RFC 5933, Penggunaan Algoritma Signature GOST di Resource Records DNSKEY dan RRSIG untuk DNSSEC
Lihat juga
Peta internet 1024.jpg Ilmu Komputer Portal
Alternatif DNS akar
Perbandingan perangkat lunak server DNS
Cache DNS keracunan
DNS pembajakan
DNS perangkat lunak manajemen
Dynamic DNS
Internet Provider Keamanan
IPv6 kehancuran dan membolehkan akses DNS
Daftar jenis catatan DNS
Microsoft DNS
Round robin DNS
Split-cakrawala DNS
[Sunting] Referensi
^ Mockapetris, Paulus (2004/01/02). "Membiarkan DNS lepas". CircleID. "RFID tag, kode UPC, Internasional karakter di alamat email dan nama host, dan berbagai pengenal lainnya semua bisa masuk ke DNS [...] - sudah siap untuk membawa pengidentifikasi sewenang-wenang."
^ Mockapetris, Paulus (April 1989). "RFC 1101: DNS Encoding Nama Jaringan dan Jenis Lain". h. 1. "DNS adalah extensible dan dapat digunakan untuk sejumlah hampir tak terbatas jenis data, ruang nama, dll"
^ Abcd RFC 1034, Nama Domain - Konsep dan Fasilitas, P. Mockapetris, Internet Masyarakat (November 1987)
^ RFC 781, Internet Protocol - Protokol Program DARPA Internet Spesifikasi, Information Sciences Institute, J. Postel (ed.), Internet Society (September 1981)
^ ABCDE RFC 1035, Nama Domain - Pelaksanaan dan Spesifikasi, P. Mockapetris, Internet Masyarakat (November 1987)
^ RFC 3467, Peran Domain Name System (DNS), JC Klensin, J. Klensin (Februari 2003)
^ Cricket Liu, Paulus Albitz (2006). DNS dan BIND (ed 5.). O'Reilly. h. 3.
^ Douglas Brian Terry, Mark Painter, David W. Riggle dan Songnian Zhou, Berkeley Internet Nama Domain Server, Prosiding Konferensi Musim Panas USENIX, Salt Lake City, Utah, Juni 1984, halaman 23-31.
^ "DNS Server Survey".
^ RFC 2181, Klarifikasi dengan Spesifikasi DNS, R. Elz, R. Bush (Juli 1997)
^ RFC 3696, Aplikasi Teknik untuk Memeriksa dan Transformasi Nama, JC Klensin, J. Klensin
^ "Nama Server definisi pada techterms.com".
^ "Penyedia mengabaikan DNS TTL?". Slashdot. 2005. Diakses 2009-01-03.
^ "Bagaimana Internet Explorer menggunakan cache untuk entri DNS host". Microsoft Corporation. 2004. Diakses 2010-07-25.
^ RFC 5395, Domain Name System (DNS) IANA Pertimbangan, D. Eastlake 3 (November 2008), Bagian 3
^ RFC 5395, Domain Name System (DNS) Pertimbangan IANA, D. Eastlake 3 (November 2008), hal 11
^ Ab RFC 4592, Peran Wildcard dalam Domain Name System, E. Lewis (Juli 2006)
^ APWG. "Phishing Survei Global: Domain Name Penggunaan dan Tren 1H2010." 2010/10/15 apwg.org
^ Terakreditasi ICANN registrar
^ VeriSign COM dan NET registri
Ikhtisar
Internet mempertahankan dua ruang nama utama, hirarki nama domain [3] dan Internet Protocol (IP) sistem alamat [4]. Domain Name System mempertahankan namespace domain dan menyediakan layanan terjemahan antara dua ruang nama. Nama server Internet dan protokol komunikasi melaksanakan Domain Name System [5]. Sebuah server nama DNS 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.
[Sunting] Sejarah
Praktek menggunakan nama sebagai abstraksi, sederhana lebih mudah diingat alamat numerik host pada sebuah jaringan tanggal kembali ke era ARPANET. Sebelum DNS diciptakan pada tahun 1983, setiap komputer pada jaringan diambil file bernama HOSTS.TXT dari komputer di SRI (sekarang SRI International) [6]. [7] File HOSTS.TXT nama dipetakan ke alamat numerik. Sebuah host file masih ada pada sistem operasi paling modern dengan default dan umumnya berisi pemetaan dari 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 mampu otomatis 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 dalam RFC 882 dan RFC 883, yang digantikan pada November 1987 oleh RFC 1034 [3] dan RFC 1035. [5] Permintaan tambahan untuk Komentar Beberapa telah mengusulkan berbagai ekstensi ke DNS inti protokol.
Pada tahun 1984, empat Berkeley mahasiswa-Douglas Terry, Mark Painter, David Riggle, dan Songnian Zhou-menulis implementasi Unix yang pertama, yang disebut Berkeley Internet Nama Domain (BIND) Server [8] Pada tahun 1985, Kevin Dunlap dari Desember signifikan ulang. menulis implementasi DNS. Mike Karels, Phil Almquist, dan Paul Vixie telah mempertahankan BIND sejak saat itu. BIND adalah porting ke platform Windows NT pada awal 1990-an.
BIND didistribusikan secara luas, terutama pada sistem Unix, dan merupakan perangkat lunak DNS yang dominan digunakan di Internet [9] Dengan menggunakan berat dan pengawasan yang dihasilkan dari open source kodenya, serta metode serangan semakin canggih. Keamanan, banyak kekurangan ditemukan di BIND [rujukan?]. Hal ini memberikan kontribusi terhadap pengembangan sejumlah server nama alternatif dan program resolver. BIND versi 9 ditulis dari awal dan sekarang memiliki catatan keamanan yang sebanding dengan software DNS modern lainnya [rujukan?].
[Sunting] Struktur
[Sunting] 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 dapat terdiri dari banyak domain dan sub-domain, tergantung pada kewenangan administratif yang diwakilkan kepada manajer.
Sistem hirarki nama domain, disusun dalam zona, masing-masing dilayani oleh server nama
Tanggung jawab administratif atas setiap zona dapat dibagi dengan membuat zona tambahan. Otoritas dikatakan didelegasikan untuk sebagian dari ruang lama, biasanya dalam bentuk sub-domain, nameserver ke yang lain dan entitas administratif. Zona lama berhenti menjadi otoritatif untuk zona baru.
[Sunting] Domain sintaks nama
Uraian definitif aturan-aturan untuk membentuk nama domain muncul di 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, seperti example.com.
Label paling kanan menyampaikan domain top-level, misalnya, www.example.com nama domain milik com domain top-level.
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 eksternal spesifikasi bertitik-label [10] Dalam representasi biner internal DNS panjang maksimum 255 oktet memerlukan penyimpanan.. [3] Dalam praktek, beberapa pendaftar domain mungkin memiliki batas singkat [rujukan?].
Nama DNS teknis dapat terdiri dari setiap karakter representable dalam oktet. Namun, perumusan diperbolehkan nama domain di zona DNS root, dan sebagian besar sub domain lain, menggunakan format pilihan dan set karakter. Karakter diperbolehkan dalam label adalah subset dari set karakter ASCII, 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-cara yang independen. Label tidak dapat mulai atau berakhir dengan tanda hubung. [11]
Sebuah nama host adalah nama domain yang memiliki minimal satu alamat IP yang terkait. Sebagai contoh, nama domain example.com www.example.com dan juga nama host, sedangkan domain com adalah tidak.
[Sunting] nama domain internasionalisasi
Set karakter yang diijinkan dari DNS mencegah representasi nama dan kata-kata dari berbagai bahasa dalam huruf asli mereka atau script. ICANN telah menyetujui Internasionalisasi Nama Domain pada Aplikasi (IDNA) sistem, yang memetakan string Unicode ke karakter set DNS yang valid menggunakan Punycode. Pada tahun 2009 ICANN menyetujui pemasangan kode negara IDN top-level domain. Selain itu, pendaftar banyak dari top-level domain nama yang ada (TLD) s telah mengadopsi IDNA.
[Sunting] Nama server
Domain Name System dikelola oleh sistem database terdistribusi, yang menggunakan model klien-server. Node database ini adalah server nama. Setiap domain memiliki setidaknya satu server otoritatif DNS yang mempublikasikan informas tentang domain tersebut dan nama server dari setiap domain bawahan untuk itu. Bagian atas hirarki adalah dilayani oleh nameserver root, server untuk query saat mencari (menyelesaikan) TLD.
[Sunting] server nama Resmi
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 nama. 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 update otomatis dari protokol DNS di komunikasi dengan tuannya 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 registrar nama domain instalasi mereka di registri domain dari domain tingkat atas membutuhkan penugasan nama server primer dan paling tidak satu server nama sekunder. Persyaratan server nama multiple bertujuan untuk membuat domain masih fungsional bahkan jika salah satu server nama menjadi tidak dapat diakses atau dioperasi [12]. Penunjukan nama server 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 alamat IP yang sesuai 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, yang dianggap otoritatif, dengan menetapkan bendera perangkat lunak (sedikit struktur protokol), yang disebut Jawaban Resmi (AA) bit dalam responnya [5] Bendera ini biasanya direproduksi mencolok pada output. dari query DNS alat administrasi (seperti menggali) untuk menunjukkan bahwa nama server menanggapi adalah otoritas untuk nama domain yang bersangkutan. [5]
[Sunting] server nama Rekursif dan caching
Pada prinsipnya, server nama otoritatif yang cukup untuk operasi Internet. Namun, dengan hanya otoritatif operasi nama server, setiap query DNS harus mulai dengan query rekursif di zona akar dari Domain Name System dan masing-masing pengguna sistem harus mengimplementasikan software resolver mampu operasi rekursif.
Untuk meningkatkan efisiensi, mengurangi lalu lintas DNS di Internet, dan meningkatkan kinerja aplikasi pengguna akhir, Domain Name System DNS cache server mendukung 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 dilaksanakan di nama server, aplikasi pengguna mendapatkan efisiensi dalam desain dan operasi.
Kombinasi caching DNS dan fungsi rekursif di server namanya tidak wajib; fungsi dapat diimplementasikan secara independen di server untuk tujuan khusus.
Penyedia layanan Internet biasanya menyediakan server nama rekursif dan caching untuk pelanggan mereka. Selain itu, router jaringan rumah banyak menerapkan cache DNS dan recursor untuk meningkatkan efisiensi dalam jaringan lokal.
[Sunting] DNS resolver
Lihat juga: resolv.conf
Sisi-klien dari DNS disebut DNS resolver. Hal ini bertanggung jawab untuk memulai dan sekuensing permintaan yang pada akhirnya mengarah pada resolusi penuh (terjemahan) dari sumber daya dicari, misalnya, terjemahan dari nama domain menjadi alamat IP.
Sebuah query DNS dapat berupa permintaan non-rekursif atau query rekursif:
Sebuah query non-rekursif adalah satu di mana server DNS menyediakan sebuah rekor bagi domain yang otoritatif 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 rekursif menggunakan bit dalam header permintaan.
Menyelesaikan biasanya memerlukan iterasi melalui beberapa server nama untuk menemukan informasi yang dibutuhkan. Namun, beberapa fungsi resolver lebih sederhana dengan hanya berkomunikasi dengan server nama tunggal. Ini resolver sederhana (disebut "resolver rintisan") bergantung pada server nama rekursif untuk melakukan pekerjaan mencari informasi bagi mereka.
[Sunting] Operasi
[Sunting] Alamat mekanisme resolusi
Domain resolver nama menentukan server nama domain yang tepat yang bertanggung jawab untuk nama domain yang dimaksud dengan urutan pertanyaan dimulai dengan label paling kanan (tingkat atas) domain.
Sebuah DNS recursor berkonsultasi tiga nameserver untuk menyelesaikan alamat www.wikipedia.org.
Proses ini memerlukan:
Sebuah host network dikonfigurasi dengan cache awal (disebut petunjuk) dari alamat yang dikenal dari nameserver root. Seperti file petunjuk diperbarui secara periodik oleh administrator dari sumber yang dapat dipercaya.
Sebuah query ke salah satu root server untuk menemukan server otoritatif untuk top-level domain.
Sebuah permintaan ke server TLD diperoleh untuk alamat server DNS otoritatif untuk domain tingkat kedua.
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 awal dengan query salah satu dari mereka. Menjadi sama pentingnya dengan mereka adalah untuk fungsi keseluruhan sistem, gunakan berat seperti akan menciptakan hambatan dapat diatasi untuk ditempatkan triliunan pertanyaan setiap hari. Dalam prakteknya cache digunakan dalam DNS server untuk mengatasi masalah ini, dan sebagai hasilnya, akar nameserver sebenarnya terlibat dengan sangat sedikit dari total lalu lintas.
[Sunting] Edaran dependensi dan lem catatan
Nama server dalam delegasi diidentifikasi berdasarkan nama, selain berdasarkan alamat IP. Ini berarti bahwa nama server harus menyelesaikan masalah lain permintaan DNS untuk mengetahui alamat IP dari server yang telah dirujuk. Jika nama 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 dalam bagian tambahan dari respon DNS, dan memberikan delegasi pada bagian jawaban dari respon.
Misalnya, jika server nama otoritatif untuk example.org adalah ns1.example.org, komputer mencoba untuk menyelesaikan www.example.org pertama menyelesaikan ns1.example.org. Karena ns1 terkandung dalam example.org, ini memerlukan menyelesaikan example.org pertama, yang menyajikan ketergantungan melingkar. Untuk memecahkan ketergantungan, nameserver untuk domain tingkat atas termasuk org 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 DNS query.
[Sunting] caching Rekam
Karena volume besar permintaan DNS dihasilkan untuk Internet publik, para desainer ingin menyediakan mekanisme untuk mengurangi beban pada server DNS individu. Untuk tujuan ini, proses resolusi DNS memungkinkan untuk caching catatan untuk jangka waktu setelah jawaban. Hal ini memerlukan rekaman lokal dan konsultasi berikutnya salinan, bukan memulai permintaan baru hulu. Waktu yang penyelesai sebuah cache respon DNS adalah ditentukan oleh nilai yang disebut waktu untuk hidup (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 untuk sampai 68 tahun atau tidak ada cache sama sekali. Caching negatif, yaitu caching fakta non-eksistensi dari sebuah record, ditentukan oleh server nama otoritatif untuk zona yang harus mencakup Start Otoritas (SOA) record ketika melaporkan tidak ada data dari jenis yang diminta ada. Nilai bidang MINIMUM dari catatan SOA dan TTL dari SOA itu sendiri digunakan untuk menetapkan TTL untuk jawaban negatif.
[Sunting] reverse lookup
Sebuah reverse lookup adalah query dari DNS untuk nama domain ketika alamat IP 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 DNS query. 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.
[Sunting] Klien pencarian
Resolusi DNS urutan
Pengguna umumnya tidak berkomunikasi secara langsung dengan DNS resolver. Sebaliknya resolusi DNS berlangsung transparan dalam program-program aplikasi seperti web browser, klien e-mail, dan aplikasi Internet lainnya. Bila aplikasi yang membuat permintaan yang memerlukan nama domain lookup, program tersebut mengirimkan permintaan ke DNS resolusi resolver dalam sistem operasi lokal, yang pada gilirannya menangani komunikasi yang diperlukan.
DNS resolver akan 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 membuat permintaan. Jika cache tidak memiliki jawabannya, resolver akan mengirimkan permintaan ke satu atau lebih server DNS yang ditunjuk. Dalam kasus kebanyakan pengguna di rumah, penyedia layanan Internet yang menghubungkan komputer tersebut biasanya akan menyediakan server DNS: pengguna tersebut akan memiliki dikonfigurasi alamat server secara manual atau diizinkan DHCP untuk mengatur itu, namun, dimana administrator sistem telah mengkonfigurasi sistem untuk menggunakan server DNS mereka sendiri, mereka menunjuk ke DNS resolver nameserver dipelihara secara terpisah dari organisasi. Dalam hal apapun, sehingga query server nama akan mengikuti proses yang diuraikan 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 berikutnya, dan tangan hasilnya kembali kepada software yang meminta pencarian DNS tersebut.
[Sunting] resolver Patah
Tambahan tingkat kompleksitas muncul ketika resolver melanggar aturan dari protokol DNS. Sejumlah ISP besar telah dikonfigurasi server DNS mereka untuk melanggar aturan (mungkin untuk memungkinkan mereka untuk berjalan di hardware yang lebih murah daripada penyelesai sepenuhnya kompatibel), seperti dengan TTLs tidak patuh, atau dengan menunjukkan bahwa nama domain tidak ada hanya karena salah satu server nama tidak merespon [13].
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 [rujukan?].
Internet Explorer merupakan pengecualian: versi hingga 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. [14]
[Sunting] 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. Beberapa hostname mungkin sesuai dengan alamat IP tunggal: gabungan dengan virtual hosting, ini memungkinkan satu komputer untuk malayani beberapa 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 mengirimkan 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 Blacklists: Sistem DNS digunakan untuk penyimpanan yang efisien dan distribusi alamat IP blacklist host e-mail. Metode yang biasa adalah dengan memasukkan 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. Sebuah contoh hipotetis menggunakan blacklist.example,
102.3.4.5-blacklist => 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 to 127.0.0.2
E-mail server kemudian dapat permintaan blacklist.example melalui mekanisme DNS untuk mengetahui apakah suatu host tertentu menghubungkan kepada mereka adalah di blacklist. Saat ini banyak dari daftar hitam tersebut, baik gratis atau berbasis langganan, tersedia terutama untuk digunakan oleh administrator email dan software anti-spam.
Software Update: banyak anti-virus dan perangkat lunak komersial sekarang menggunakan sistem DNS untuk menyimpan nomor versi update software terbaru sehingga komputer klien tidak perlu terhubung 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 lain jenis rekod DNS, dikenal sebagai rekod TXT.
Untuk memberikan ketahanan dalam peristiwa kegagalan komputer, beberapa server DNS biasanya disediakan untuk cakupan setiap domain, dan pada tingkat atas, tiga belas root server yang sangat kuat ada, dengan tambahan "salinan" dari beberapa dari mereka didistribusikan di seluruh dunia melalui anycast.
Dynamic DNS (DDNS kadang-kadang disebut) memungkinkan klien untuk memperbarui entri DNS sebagai perubahan alamat IP mereka, seperti halnya, misalnya, ketika bergerak antara ISP atau hot spot ponsel.
[Sunting] 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. 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, diketahui memiliki implementasi penyelesai yang menggunakan TCP untuk semua pertanyaan, bahkan ketika UDP akan cukup.
[Sunting] DNS catatan sumber daya
Informasi lebih lanjut: Daftar jenis catatan DNS
Sebuah Resource Record (RR) adalah elemen data dasar dalam sistem nama domain. Setiap record memiliki tipe (A, MX, dll), batas waktu berakhirnya, kelas, dan beberapa tipe data spesifik. Sumber Daya catatan dari jenis yang sama mendefinisikan satu set catatan sumber daya. Urutan catatan sumber daya dalam satu set, dikembalikan oleh penyelesai untuk aplikasi, tidak terdefinisi, tetapi sering server menerapkan round-robin memesan untuk mencapai load balancing. DNSSEC, bagaimanapun, bekerja pada catatan sumber daya set lengkap dalam urutan kanonik.
Saat dikirim melalui jaringan IP, semua catatan umum menggunakan format yang ditetapkan dalam RFC 1035: [15]
RR (Resource catatan) bidang Lapangan Keterangan Panjang (oktet)
NAMA Nama node yang merekam ini berkaitan (variabel)
JENIS Jenis RR dalam bentuk numerik (misalnya 15 untuk MX RR) 2
CLASS Kelas kode 2
TTL Count detik yang RR tetap berlaku (maksimum adalah 231-1, yaitu sekitar 68 tahun.) 4
RDLENGTH Panjang bidang RDATA 2
RDATA Tambahan RR-data spesifik (variabel)
NAMA adalah nama domain berkualifikasi lengkap dari simpul dalam pohon. Pada kawat, nama dapat dipersingkat menggunakan kompresi label jika ujung nama domain disebutkan sebelumnya dalam paket dapat digantikan untuk akhir dari nama domain saat ini.
TYPE adalah tipe record. Hal ini menunjukkan format data dan memberikan sedikit digunakan. Sebagai contoh, catatan A digunakan untuk menerjemahkan dari nama domain ke sebuah alamat IPv4, NS record daftar nama server yang bisa menjawab pencarian pada zona DNS, dan MX record menentukan mail server yang digunakan untuk menangani email untuk domain tertentu di alamat e-mail (lihat juga Daftar jenis catatan DNS).
RDATA adalah data tipe spesifik relevansi, seperti alamat IP untuk catatan alamat, atau prioritas dan nama host untuk MX. Jenis catatan terkenal dapat menggunakan kompresi label dalam bidang RDATA, tetapi "tidak diketahui" jenis catatan tidak boleh (RFC 3597).
KELAS dari sebuah record set ke IN (Internet) untuk catatan DNS yang umum yang melibatkan nama host internet, server, atau alamat IP. Selain itu, Chaos kelas (CN) dan Hesiod (HS) ada [16]. Setiap kelas adalah ruang nama independen dengan delegasi berpotensi berbeda zona DNS.
Selain catatan sumber daya didefinisikan dalam sebuah 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).
[Sunting] Wildcard DNS record
Artikel utama: Wildcard DNS record
Sistem nama domain mendukung nama domain wildcard yang nama-nama yang dimulai dengan label tanda bintang, '*', misalnya, *. contoh [3] [17] DNS record milik nama domain wildcard menetapkan aturan untuk menghasilkan catatan sumber daya dalam tunggal. zona DNS dengan menggantikan seluruh label dengan komponen pencocokan nama query, termasuk keturunan tertentu. Misalnya, 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 telah hasil dari tidak termasuk ini nama domain dan subdomain dari pertandingan wildcard, semua subdomain dari axexample harus didefinisikan dalam sebuah pernyataan terpisah wildcard.
Peran catatan wildcard diperhalus dalam RFC 4592, karena definisi asli dalam RFC 1034 tidak lengkap dan mengakibatkan salah tafsir oleh pelaksana. [17]
[Sunting] Protokol ekstensi
DNS asli protokol telah membatasi ketentuan perpanjangan dengan fitur-fitur baru. Pada tahun 1999, Paulus Vixie dipublikasikan 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 UDP datagram.
[Sunting] update zona Dinamis
Dynamic DNS update menggunakan opcode UPDATE DNS untuk menambah atau menghapus catatan sumber daya secara dinamis dari basis data yang dikelola zona 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 boot dapat diberikan alamat IP yang berbeda setiap kali dari server DHCP, tidak mungkin untuk memberikan tugas statis DNS untuk klien tersebut.
[Sunting] Masalah keamanan
DNS awalnya tidak didesain dengan keamanan dalam pikiran, dan dengan demikian memiliki sejumlah masalah keamanan.
Salah satu kelas dari kerentanan adalah DNS cache keracunan, yang trik server DNS untuk percaya telah menerima informasi otentik ketika, dalam kenyataannya, tidak.
Tanggapan DNS tradisional tidak cryptographically ditandatangani, yang mengarah ke kemungkinan serangan banyak, Nama Domain Extensions Sistem Keamanan (DNSSEC) memodifikasi DNS untuk menambahkan dukungan untuk respon cryptographically ditandatangani. Ada berbagai ekstensi untuk mendukung informasi zona mentransfer mengamankan juga.
Bahkan dengan enkripsi, server DNS dapat menjadi terganggu oleh virus (atau dalam hal ini karyawan yang tidak puas) yang akan menyebabkan alamat IP dari server yang akan diarahkan ke alamat berbahaya dengan TTL panjang. Ini bisa memiliki pengaruh luas untuk berpotensi jutaan pengguna Internet jika sibuk server DNS cache data IP yang buruk. Hal ini akan membutuhkan manual membersihkan semua cache DNS yang terkena dampak seperti yang dipersyaratkan oleh TTL panjang (sampai 68 tahun).
Beberapa nama domain dapat spoof lain, mirip yang tampak nama domain. Misalnya, "paypal.com" dan "paypa1.com" adalah nama-nama berbeda, namun pengguna mungkin tidak dapat membedakan ketika jenis huruf pengguna (font) tidak jelas membedakan huruf l dan angka 1. Masalah ini lebih serius dalam sistem yang mendukung nama domain internasional, karena banyak kode karakter dalam ISO 10646, mungkin muncul identik pada layar komputer khas. Kerentanan ini kadang-kadang dimanfaatkan dalam phishing. [18]
Teknik seperti reverse DNS maju yang dikonfirmasi juga dapat digunakan untuk membantu memvalidasi hasil DNS.
[Sunting] registrasi nama Domain
Hak untuk menggunakan nama domain didelegasikan oleh pendaftar nama domain yang diakreditasi oleh Internet untuk Corporation Ditugaskan Nama dan Nomor (ICANN), organisasi yang bertugas mengawasi sistem nama dan nomor dari Internet. Selain ICANN, setiap domain tingkat atas (TLD) service dan pemeliharaan 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 masing-masing registrar nama domain yang berwenang untuk menetapkan nama di TLD yang sesuai dan menerbitkan informasi menggunakan layanan khusus, protokol whois.
ICANN menerbitkan daftar lengkap pendaftar TLD dan pendaftar nama domain. Informasi pendaftar terkait dengan nama domain dipertahankan dalam sebuah database online dapat diakses dengan layanan WHOIS. Untuk sebagian besar dari lebih dari 240 kode negara top-level domain (ccTLDs), pendaftar domain menjaga WHOIS (Pendaftar, nama server, tanggal kadaluwarsa, dll) informasi. Misalnya, DENIC, Jerman NIC, memegang data domain DE. Sejak sekitar 2001, kebanyakan pendaftar gTLD telah mengadopsi pendekatan yang disebut registri tebal, yaitu menjaga data WHOIS di pusat registries bukan database registrasi.
Untuk nama domain COM dan NET, model tipis registri digunakan: registry domain (misalnya VeriSign) memegang dasar WHOIS (pendaftar dan nama server, dll) data. Satu dapat menemukan WHOIS rinci (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 pendaftar-registri yang terdiri dari pendaftar nama domain banyak [19] [20] Dalam metode 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.
[Sunting] standar Internet
Domain Name System didefinisikan oleh Request for Comments (RFC) dokumen yang diterbitkan oleh Internet Engineering Task Force (standar Internet). Berikut ini adalah daftar RFC yang mendefinisikan protokol DNS.
RFC 920, Persyaratan Domain - Ditentukan asli top-level domain
RFC 1032, Administrator Domain Gratis
RFC 1033, Administrator Domain Operasi Gratis
RFC 1034, Nama Domain - Konsep dan Fasilitas
RFC 1035, Nama Domain - Pelaksanaan dan Spesifikasi
RFC 1101, Encodings DNS dari Nama Jaringan dan Jenis Lain
RFC 1123, Persyaratan untuk Aplikasi Host-Internet dan Dukungan
RFC 1178, Memilih Nama untuk Komputer Anda (FYI 5)
RFC 1183, New DNS RR Definisi
RFC 1591, Domain Name System Struktur dan Delegasi (Informational)
RFC 1912, DNS Kesalahan Umum Operasional dan Konfigurasi
RFC 1995, Tambahan Zona Transfer dalam DNS
RFC 1996, Sebuah Mekanisme Pemberitahuan Perubahan Zona Prompt (DNS NOTIFY)
RFC 2100, The Penamaan Host (Informational)
RFC 2136, Dynamic Updates dalam sistem nama domain (DNS UPDATE)
RFC 2181, Klarifikasi dengan Spesifikasi DNS
RFC 2182, Seleksi dan Operasi Server Secondary DNS
RFC 2308, Caching Negatif Pertanyaan DNS (DNS NCACHE)
RFC 2317, Classless IN-ADDR.ARPA delegasi (BCP 20)
RFC 2671, Ekstensi Mekanisme untuk DNS (EDNS0)
RFC 2672, Kamas Terminal DNS Redirection Nama
RFC 2845, Otentikasi Transaksi Rahasia Kunci untuk DNS (TSIG)
RFC 3225, Mengindikasikan resolver Dukungan DNSSEC
RFC 3226, DNSSEC dan persyaratan IPv6 pesan A6 server / menyadari ukuran resolver
RFC 3597, Penanganan Sumber Daya Rekam DNS Unknown (RR) Jenis
RFC 3696, Aplikasi Teknik untuk Memeriksa dan Transformasi Nama (Informational)
RFC 4343, Domain Name System (DNS) Kasus Klarifikasi Ketidakpekaan
RFC 4592, Peran Wildcard dalam Domain Name System
RFC 4635, HMAC SHA TSIG Algoritma Identifier
RFC 4892, Persyaratan Mekanisme Mengidentifikasi Instance Name Server (Informational)
RFC 5001, DNS Name Server Identifier (NSID) Opsi
RFC 5395, Domain Name System (DNS) IANA Pertimbangan (BCP 42)
RFC 5452, Langkah-langkah untuk Membuat DNS Daya Tahan Lebih Tinggi melawan Jawaban Ditempa
RFC 5625, Pedoman Pelaksanaan Proxy DNS (BCP 152)
RFC 5890, internasionalisasi Nama Domain untuk Aplikasi (IDNA): Definisi dan Kerangka Dokumen
RFC 5891, internasionalisasi Nama Domain di Aplikasi (IDNA): Protokol
RFC 5892, Poin Kode Unicode dan internasionalisasi Nama Domain untuk Aplikasi (IDNA)
RFC 5893, Kanan-ke-Kiri Script untuk Nama Domain internasionalisasi untuk Aplikasi (IDNA)
RFC 5894, internasionalisasi Nama Domain untuk Aplikasi (IDNA): Latar Belakang, Penjelasan, dan Pemikiran (Informational)
RFC 5895, Pemetaan Karakter untuk Nama Domain internasionalisasi dalam Aplikasi (IDNA) 2008 (Informational)
[Sunting] Keamanan
RFC 4033, DNS Keamanan Pendahuluan dan Persyaratan
RFC 4034, Sumber Daya Records untuk Extensions Keamanan DNS
RFC 4035, Protokol Modifikasi untuk Ekstensi Keamanan DNS
RFC 4509, Penggunaan SHA-256 di DNSSEC Delegasi Signor (DS) Sumber Rekaman
RFC 4470, minimal Menutupi Rekaman NSEC dan DNSSEC On-line Penandatanganan
RFC 5011, Pembaruan Otomatis dari DNS (DNSSEC) Keamanan Jangkar Kepercayaan
RFC 5155, DNS Keamanan (DNSSEC) hash Denial dikonfirmasi Kehidupan
RFC 5702, Penggunaan Algoritma SHA-2 dengan RSA di Resource Records DNSKEY dan RRSIG untuk DNSSEC
RFC 5910, Domain Name System (DNS) Ekstensi Keamanan Pemetaan untuk Extensible Provisioning Protocol (EPP)
RFC 5933, Penggunaan Algoritma Signature GOST di Resource Records DNSKEY dan RRSIG untuk DNSSEC
Lihat juga
Peta internet 1024.jpg Ilmu Komputer Portal
Alternatif DNS akar
Perbandingan perangkat lunak server DNS
Cache DNS keracunan
DNS pembajakan
DNS perangkat lunak manajemen
Dynamic DNS
Internet Provider Keamanan
IPv6 kehancuran dan membolehkan akses DNS
Daftar jenis catatan DNS
Microsoft DNS
Round robin DNS
Split-cakrawala DNS
[Sunting] Referensi
^ Mockapetris, Paulus (2004/01/02). "Membiarkan DNS lepas". CircleID. "RFID tag, kode UPC, Internasional karakter di alamat email dan nama host, dan berbagai pengenal lainnya semua bisa masuk ke DNS [...] - sudah siap untuk membawa pengidentifikasi sewenang-wenang."
^ Mockapetris, Paulus (April 1989). "RFC 1101: DNS Encoding Nama Jaringan dan Jenis Lain". h. 1. "DNS adalah extensible dan dapat digunakan untuk sejumlah hampir tak terbatas jenis data, ruang nama, dll"
^ Abcd RFC 1034, Nama Domain - Konsep dan Fasilitas, P. Mockapetris, Internet Masyarakat (November 1987)
^ RFC 781, Internet Protocol - Protokol Program DARPA Internet Spesifikasi, Information Sciences Institute, J. Postel (ed.), Internet Society (September 1981)
^ ABCDE RFC 1035, Nama Domain - Pelaksanaan dan Spesifikasi, P. Mockapetris, Internet Masyarakat (November 1987)
^ RFC 3467, Peran Domain Name System (DNS), JC Klensin, J. Klensin (Februari 2003)
^ Cricket Liu, Paulus Albitz (2006). DNS dan BIND (ed 5.). O'Reilly. h. 3.
^ Douglas Brian Terry, Mark Painter, David W. Riggle dan Songnian Zhou, Berkeley Internet Nama Domain Server, Prosiding Konferensi Musim Panas USENIX, Salt Lake City, Utah, Juni 1984, halaman 23-31.
^ "DNS Server Survey".
^ RFC 2181, Klarifikasi dengan Spesifikasi DNS, R. Elz, R. Bush (Juli 1997)
^ RFC 3696, Aplikasi Teknik untuk Memeriksa dan Transformasi Nama, JC Klensin, J. Klensin
^ "Nama Server definisi pada techterms.com".
^ "Penyedia mengabaikan DNS TTL?". Slashdot. 2005. Diakses 2009-01-03.
^ "Bagaimana Internet Explorer menggunakan cache untuk entri DNS host". Microsoft Corporation. 2004. Diakses 2010-07-25.
^ RFC 5395, Domain Name System (DNS) IANA Pertimbangan, D. Eastlake 3 (November 2008), Bagian 3
^ RFC 5395, Domain Name System (DNS) Pertimbangan IANA, D. Eastlake 3 (November 2008), hal 11
^ Ab RFC 4592, Peran Wildcard dalam Domain Name System, E. Lewis (Juli 2006)
^ APWG. "Phishing Survei Global: Domain Name Penggunaan dan Tren 1H2010." 2010/10/15 apwg.org
^ Terakreditasi ICANN registrar
^ VeriSign COM dan NET registri
Sumber : Dari Wikipedia, ensiklopedia bebas
0 komentar