Memahami Lebih Dalam Tentang DNS

Assalamu'alaikum wr.wb

Hallo guys disini saya akan memosting pengertian tentang DNS

lets cekidot !!

A. Pengertian
          Domain Name System (DNS) adalah hirarkis sistem penamaan desentralisasi untuk komputer, jasa, atau sumber daya yang terhubung ke Internet atau jaringan pribadi. Ini asosiasi berbagai informasi dengan nama domain ditugaskan untuk masing-masing entitas yang berpartisipasi.

B. Latar belakang 

            DNS di gunakan untuk mempermudah penamaan alamat pada internet

C. Maksud dan tujuan
            Untuk memahami lebih dalam tentang DNS.

D. Alat dan bahan 

•     Referensi tentang DNS
•      Laptop

E. Tahap Pelaksanaan

DNS

              

                Domain Name System (DNS) adalah hirarkis sistem penamaan desentralisasi untuk komputer, jasa, atau sumber daya yang terhubung ke Internet atau jaringan pribadi. Ini asosiasi berbagai informasi dengan nama domain ditugaskan untuk masing-masing entitas yang berpartisipasi. Paling mencolok, itu menterjemahkan lebih mudah menghafal nama domain ke numerik alamat IP yang dibutuhkan untuk tujuan menemukan dan mengidentifikasi layanan komputer dan perangkat dengan protokol jaringan yang mendasarinya. Dengan menyediakan, didistribusikan di seluruh dunia layanan direktori , Domain Name System merupakan komponen penting dari fungsi Internet, dan telah digunakan sejak tahun 1980-an.

Delegasi tanggung jawab menetapkan nama domain dan pemetaan nama-nama ke sumber daya internet dengan menunjuk Domain Name System server nama otoritatif untuk setiap domain. Administrator jaringan dapat mendelegasikan otoritas atas sub-domain dari ruang nama yang dialokasikan untuk server nama lainnya. Mekanisme ini menyediakan didistribusikan dan kesalahan layanan toleran dan dirancang untuk menghindari satu database pusat yang besar.
Domain Name System juga menentukan fungsi teknis dari basis data layanan yang pada intinya. Ini mendefinisikan protokol DNS, spesifikasi rinci dari struktur data dan pertukaran komunikasi data yang digunakan dalam DNS, sebagai bagian dari Internet Protocol Suite . Secara historis, layanan direktori lainnya sebelumnya DNS tidak terukur ke direktori besar atau global mereka awalnya didasarkan pada file teks, jelas yang HOSTS.TXT penyelesai.
Internet memelihara dua pokok ruang nama , hirarki nama domain ^[1] dan Internet Protocol (IP) ruang alamat . ^[2] The Domain Name System mempertahankan hirarki nama domain dan menyediakan layanan terjemahan antara itu dan ruang alamat. Internet nama server dan komunikasi protokol mengimplementasikan Domain Name System. ^[3] Nama Sebuah DNS server adalah server yang menyimpan catatan DNS untuk domain; server nama DNS merespon dengan jawaban query terhadap database-nya.
Jenis yang paling umum dari catatan yang disimpan dalam database DNS adalah untuk mulai dari Authority (SOA), alamat IP (A dan AAAA), SMTP email penukar (MX), nama server (NS), pointer untuk reverse DNS lookup (PTR), dan nama domain alias (CNAME). Meskipun tidak dimaksudkan untuk menjadi database tujuan umum, DNS dapat menyimpan catatan untuk jenis data baik untuk pencarian otomatis, seperti DNSSEC catatan, atau untuk permintaan manusia seperti orang yang bertanggung jawab (RP) catatan. Sebagai database tujuan umum, DNS juga telah digunakan dalam memerangi email yang tidak diminta (spam) dengan menyimpan daftar blackhole real-time . Database DNS secara tradisional disimpan secara terstruktur file zona .

Fungsi

Sebuah analogi yang sering digunakan untuk menjelaskan Sistem Nama Domain adalah bahwa ia berfungsi sebagai buku telepon untuk Internet dengan menerjemahkan komputer yang ramah manusia hostname menjadi alamat IP. Misalnya, nama domain www.example.com diterjemahkan ke alamat 93.184.216.119 ( IPv4 ) dan 2606: 2800: 220: 6d: 26bf: 1447: 1097: aa7 ( IPv6 ). Tidak seperti buku telepon, DNS dapat dengan cepat diperbarui, memungkinkan lokasi layanan pada jaringan untuk berubah tanpa mempengaruhi pengguna akhir, yang terus menggunakan nama host yang sama. Pengguna mengambil keuntungan dari ini ketika mereka menggunakan bermakna Uniform Resource Locator (URL), dan alamat e-mail tanpa harus mengetahui bagaimana komputer benar-benar menempatkan layanan.
Selain itu, DNS mencerminkan partisi administrasi. ^[4] Untuk zona dioperasikan oleh registry , juga dikenal sebagai akhiran publik zona, informasi administrasi sering dilengkapi dengan registri RDAP dan WHOIS layanan. data yang dapat digunakan untuk mendapatkan wawasan tentang, dan melacak tanggung jawab untuk, host diberikan di Internet. ^[5]
Fungsi penting dan di mana-mana dari DNS adalah peran sentral dalam layanan Internet terdistribusi seperti layanan cloud dan jaringan pengiriman konten . ^[6] Ketika pengguna mengakses layanan Internet didistribusikan menggunakan URL, nama domain dari URL diterjemahkan ke alamat IP dari server yang proksimal ke pengguna. Fungsi utama dari DNS dieksploitasi di sini adalah bahwa pengguna yang berbeda secara bersamaan dapat menerima terjemahan yang berbeda untuk nama domain yang sama, titik kunci dari perbedaan dari tradisional "buku telepon" pandangan DNS. Proses ini menggunakan DNS untuk menetapkan server proksimal pengguna adalah kunci untuk memberikan waktu respon lebih cepat di Internet dan banyak digunakan oleh sebagian besar layanan Internet utama hari ini. ^[7]

Sejarah

Menggunakan sederhana, nama yang lebih mudah diingat di tempat alamat numerik sebuah host tanggal kembali ke ARPANET era. Stanford Research Institute (sekarang SRI International ) mempertahankan file teks bernama HOSTS.TXT yang dipetakan nama host ke alamat numerik komputer di ARPANET. ^{[8] [9]} Pemeliharaan alamat numerik, yang disebut Daftar Bilangan Ditugaskan, ditangani oleh Jon Postel di University of Southern California 's Information Sciences Institute (ISI), yang timnya bekerja sama dengan SRI. ^[10]
Alamat ditugaskan secara manual. Untuk meminta nama host dan alamat dan menambahkan komputer ke file induk, pengguna menghubungi SRI Pusat Informasi Jaringan (NIC), disutradarai oleh Elizabeth Feinler , melalui telepon selama jam kerja. ^[11]
Pada awal 1980-an, mempertahankan, meja host terpusat menjadi lambat dan berat dan jaringan muncul diperlukan suatu sistem penamaan otomatis untuk menangani masalah-masalah teknis dan personil. Postel diarahkan tugas menempa kompromi antara lima proposal bersaing solusi untuk Paul Mockapetris . Mockapetris bukannya menciptakan Domain Name System. ^[12]
The Internet Engineering Task Force diterbitkan spesifikasi asli dalam RFC 882 dan RFC 883 pada bulan November 1983. ^{[13] [14]}
Pada tahun 1984, empat UC Berkeley mahasiswa, Douglas Terry, Mark Painter, David Riggle, dan Songnian Zhou, menulis pertama Unix pelaksanaan server nama untuk Berkeley Internet Name Domain, sering disebut sebagai BIND . ^[15] Pada tahun 1985, Kevin Dunlap dari Desember substansial direvisi pelaksanaan DNS. Mike Karels , Phil Almquist, dan Paul Vixie mempertahankan BIND sejak saat itu. ^[16] Pada awal 1990-an, BIND porting ke Windows NT platform yang. Itu didistribusikan secara luas, terutama pada sistem Unix, dan masih DNS perangkat lunak yang paling banyak digunakan di Internet. ^[16]
Pada bulan November tahun 1987, RFC 1034 ^[1] dan RFC 1035 ^[3] menggantikan 1983 spesifikasi DNS. Beberapa tambahan Permintaan Komentar telah mengusulkan tambahan dari protokol inti DNS. ^[17]

Struktur

Domain nama ruang

Ruang nama domain terdiri dari pohon struktur data . Setiap node atau daun di pohon memiliki label dan nol atau catatan sumber daya lebih (RR), yang memegang informasi yang terkait dengan nama domain. Nama domain sendiri terdiri dari label, mungkin digabungkan dengan nama node induknya di sebelah kanan, dipisahkan oleh sebuah titik. ^[18] 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 pilihan administratif manajer zona. DNS juga dapat dipartisi sesuai dengan kelas; kelas terpisah dapat dianggap sebagai array dari pohon namespace paralel. ^[19]

Hirarkis Sistem Nama Domain Internet kelas, disusun dalam zona, masing-masing dilayani oleh server nama

tanggung jawab administratif atas zona apapun dapat dibagi dengan menciptakan zona tambahan. Otoritas atas zona baru dikatakan didelegasikan ke server nama yang ditunjuk. Zona induk berhenti menjadi otoritatif untuk zona baru. ^[19]

Domain nama sintaks

Deskripsi definitif aturan untuk membentuk nama domain muncul dalam RFC 1035 , RFC 1123 , dan RFC 2181 . Sebuah nama domain terdiri dari satu atau lebih bagian, secara teknis disebut label, yang konvensional concatenated, dan dibatasi oleh titik, seperti example.com.
Paling kanan label menyampaikan domain top-level ; misalnya, nama domain www.example.com milik top-level domain com.
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 subdomain dari example.com. Pohon ini subdivisi mungkin harus sampai 127 tingkat.
Sebuah label mungkin berisi nol sampai 63 karakter. Label null, panjang nol, dicadangkan untuk zona akar. Nama domain lengkap tidak boleh melebihi panjang 253 karakter dalam representasi tekstual. ^[1] Dalam representasi biner internal DNS panjang maksimum membutuhkan 255 oktet penyimpanan, karena juga menyimpan panjang nama. ^[3]
Meskipun nama domain dapat secara teoritis terdiri dari setiap representable karakter dalam oktet, nama host menggunakan format dan karakter yang disukai set. Karakter yang diizinkan dalam label mereka adalah bagian dari ASCII set karakter, terdiri dari 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 diinterpretasikan dalam kasus-independen cara. ^[20] Label mungkin tidak memulai atau mengakhiri dengan tanda hubung. ^[21] Aturan tambahan mengharuskan nama domain tingkat atas tidak harus semua-numerik. ^[21]

Nama domain internasional

Set terbatas karakter ASCII diizinkan di DNS dicegah representasi nama dan kata-kata dari berbagai bahasa dalam huruf asli mereka atau script. Untuk membuat ini mungkin, ICANN menyetujui internasionalisasi Nama Domain Aplikasi (IDNA) sistem, dimana aplikasi pengguna, seperti web browser, peta Unicode string ke dalam karakter DNS yang valid set menggunakan Punycode . Pada tahun 2009 ICANN menyetujui pemasangan internasionalisasi nama domain kode negara top-level domain (ccTLD s) . Selain itu, banyak pendaftar nama domain tingkat atas yang ada ( TLD s ) telah mengadopsi sistem IDNA.

Nama server

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

Otoritatif name server

Server nama otoritatif adalah server nama yang hanya memberikan jawaban untuk pertanyaan DNS dari data yang telah dikonfigurasi oleh sumber asli, misalnya, administrator domain atau dengan metode DNS dinamis, berbeda dengan jawaban yang diperoleh melalui permintaan ke server nama lain yang hanya memelihara cache data.
Server nama otoritatif dapat menjadi master server atau server slave. Sebuah server master adalah server yang menyimpan asli (master) salinan dari semua catatan zona. Sebuah server slave menggunakan mekanisme update otomatis khusus dalam protokol DNS dalam komunikasi dengan tuannya untuk menjaga salinan identik dari catatan master.
Setiap zona DNS harus diberi satu set server nama otoritatif. Ini set server disimpan di zona domain induk dengan name server (NS) catatan.
Server otoritatif menunjukkan statusnya penyediaan jawaban yang pasti, dianggap otoritatif, dengan menetapkan bendera protokol, disebut Resmi Jawaban (AA) bit dalam responnya. ^[3] Bendera ini biasanya direproduksi menonjol dalam output dari alat query administrasi DNS, seperti menggali , untuk menunjukkan bahwa nama server menanggapi adalah otoritas untuk nama domain yang bersangkutan. ^[3]

Operasi

Artikel ini membutuhkan tambahan kutipan untuk verifikasi . Harap membantu memperbaiki artikel ini dengan menambahkan kutipan ke sumber terpercaya . Tag ini ditantang dan dihapus. (September 2014) ( Pelajari bagaimana dan kapan untuk menghapus pesan template ini )

Mekanisme resolusi alamat

Domain nama resolvers menentukan server nama domain yang bertanggung jawab untuk nama domain yang dimaksud dengan urutan pertanyaan dimulai dengan label domain paling kanan (top-level).

Sebuah DNS recursor berkonsultasi tiga server nama untuk menyelesaikan www.wikipedia.org alamat.

Untuk operasi yang tepat dari nama domain resolver, sebuah host jaringan dikonfigurasi dengan cache awal (petunjuk) dari alamat yang dikenal dari server nama root. Petunjuk diperbarui secara berkala oleh administrator dengan mengambil dataset dari sumber yang dapat dipercaya.
Dengan asumsi resolver telah ada catatan cache untuk mempercepat proses, proses penyelesaian dimulai dengan permintaan ke salah satu server root. Dalam operasi yang khas, root server tidak menjawab secara langsung, tapi merespon dengan rujukan ke server yang lebih otoritatif, misalnya, permintaan untuk "www.wikipedia.org" disebut server org. resolver sekarang query server disebut, dan iteratif ulangi proses ini sampai menerima jawaban otoritatif. diagram menggambarkan proses ini untuk www.wikipedia.org tuan rumah.
Mekanisme ini akan menempatkan beban lalu lintas besar di root server, jika setiap resolusi di Internet akan membutuhkan mulai dari akar. Dalam prakteknya caching digunakan di server DNS untuk off-beban root server, dan sebagai hasilnya, server nama akar sebenarnya terlibat dalam hanya sebagian kecil dari semua permintaan.

Rekursif dan caching name server

Secara teori, nama server otoritatif yang cukup untuk pengoperasian Internet. Namun, dengan hanya otoritatif nama server operasi, setiap DNS query harus mulai dengan pertanyaan rekursif di zona akar dari Domain Name System dan setiap sistem pengguna harus menerapkan perangkat lunak resolver mampu operasi rekursif.
Untuk meningkatkan efisiensi, mengurangi lalu lintas DNS di Internet, dan meningkatkan kinerja dalam aplikasi pengguna akhir, Domain Name System mendukung cache DNS server yang menyimpan hasil query DNS untuk jangka waktu yang ditentukan dalam konfigurasi (time-to-live) dari nama domain record yang bersangkutan. Biasanya, server caching DNS seperti juga menerapkan algoritma rekursif yang diperlukan untuk menyelesaikan nama yang diberikan dimulai dengan akar DNS melalui ke server nama otoritatif domain tanya. Dengan fungsi ini dilaksanakan di server nama, 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, banyak router jaringan rumah menerapkan cache DNS dan recursor untuk meningkatkan efisiensi di jaringan lokal.

DNS resolvers

Sisi klien DNS yang disebut resolver DNS. Sebuah penyelesai bertanggung jawab untuk memulai dan sekuensing permintaan yang akhirnya menyebabkan resolusi penuh (terjemahan) dari sumber daya dicari, misalnya, terjemahan dari nama domain ke alamat IP. Query DNS individu dapat berupa non-rekursif, rekursif, atau berulang, atau kombinasi dari ini. ^[1]

• Untuk metode query non-rekursif, klien DNS resolver query server DNS yang memberikan catatan untuk domain yang itu berwibawa itu sendiri, atau memberikan hasil parsial tanpa query server lain. Dalam kasus penyelesai caching DNS , query non-rekursif dari lokal cache DNS memberikan hasil dan mengurangi beban pada server DNS hulu dengan caching catatan permintaan DNS untuk jangka waktu setelah respons awal dari server DNS hulu.
• Untuk pendekatan permintaan rekursif, klien DNS resolver akan query DNS server tunggal, yang kemudian dapat query (sebagai klien itu sendiri) server DNS lain atas nama pemohon. Misalnya, sederhana "stub resolver" berjalan pada router rumah biasanya akan membuat query rekursif ke server DNS untuk pengguna ISP . Sebuah query rekursif adalah salah satu yang server DNS akan sepenuhnya menjawab query (atau memberikan kesalahan) dengan query server nama lain yang diperlukan. Dalam operasi yang khas, klien akan mengeluarkan permintaan rekursif ke caching DNS server rekursif, yang kemudian akan mengeluarkan pertanyaan non-rekursif untuk menentukan jawaban dan mengirim jawaban tunggal kembali ke klien. Resolver, atau server DNS lain bertindak secara rekursif atas nama resolver, melakukan negosiasi penggunaan layanan recursive menggunakan bit dalam header permintaan. server DNS tidak diperlukan untuk mendukung permintaan rekursif.
• Untuk prosedur permintaan berulang, klien DNS resolver akan query rantai dari satu atau lebih server DNS. Setiap server akan merujuk klien ke server berikutnya dalam rantai tersebut, sampai server saat sepenuhnya dapat menyelesaikan permintaan. Misalnya, resolusi kemungkinan www.example.com akan query akar global, maka server .com, dan akhirnya .example.com.

Dependensi melingkar dan catatan lem

Nama server di delegasi diidentifikasi oleh nama, bukan berdasarkan alamat IP. Ini berarti bahwa server nama menyelesaikan harus mengeluarkan permintaan DNS lain untuk mengetahui alamat IP dari server yang telah disebut. Jika nama yang diberikan dalam delegasi adalah subdomain dari domain yang delegasi yang disediakan, ada ketergantungan melingkar .
Dalam hal ini, nama server menyediakan delegasi juga harus menyediakan satu atau lebih alamat IP untuk server nama otoritatif yang disebutkan dalam delegasi. Informasi ini disebut lem. The mendelegasikan nama server menyediakan lem ini dalam bentuk catatan di bagian tambahan dari respon DNS, dan memberikan delegasi di bagian otoritas 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. Sejak ns1 terkandung dalam example.org, ini memerlukan penyelesaian example.org pertama, yang menyajikan ketergantungan melingkar. Untuk memecahkan ketergantungan, nama server untuk top level domain org termasuk lem bersama dengan delegasi untuk example.org. Catatan lem adalah catatan alamat yang menyediakan alamat IP untuk ns1.example.org. resolver menggunakan satu atau lebih alamat IP ini untuk query salah satu server otoritatif domain, yang memungkinkan untuk menyelesaikan permintaan DNS.

Rekam caching

Proses Resolusi DNS mengurangi beban pada setiap server dengan caching catatan permintaan DNS untuk jangka waktu setelah tanggapan. Ini memerlukan rekaman lokal dan konsultasi berikutnya dari copy bukan memulai permintaan baru hulu. Waktu yang resolver sebuah cache respon DNS ditentukan oleh nilai yang disebut waktu untuk hidup (TTL) yang terkait dengan setiap record. TTL diatur oleh administrator dari server DNS yang memberikan respon otoritatif. Masa berlaku dapat bervariasi dari hanya detik untuk hari atau bahkan minggu.
Sebagai konsekuensi penting dari ini didistribusikan dan caching arsitektur, perubahan catatan DNS tidak menyebarkan seluruh jaringan segera, tetapi membutuhkan semua cache berakhir dan menyegarkan setelah TTL. RFC 1912 menyampaikan aturan dasar untuk menentukan nilai TTL yang sesuai.
Beberapa resolvers dapat mengganti nilai TTL, sebagai protokol mendukung caching hingga 68 tahun atau tidak caching sama sekali. Caching negatif , yaitu caching dari fakta tidak adanya catatan, ditentukan oleh server nama otoritatif untuk zona yang harus menyertakan Mulai dari Authority (SOA) record ketika melaporkan tidak ada data jenis diminta ada. Nilai bidang minimum dari catatan SOA dan TTL dari SOA itu sendiri digunakan untuk mendirikan TTL untuk jawaban negatif.

Reverse lookup

Artikel utama: Terbalik DNS lookup

Sebuah lookup reverse adalah permintaan dari DNS untuk nama domain ketika alamat IP diketahui. nama domain beberapa mungkin terkait dengan alamat IP. Toko DNS alamat IP dalam bentuk nama domain sebagai diformat khusus nama dalam pointer (PTR) catatan dalam infrastruktur top-level domain arpa . Untuk IPv4, domain adalah in-addr.arpa. Untuk IPv6, domain lookup reverse ip6.arpa. Alamat IP direpresentasikan sebagai nama di oktet representasi reverse-memerintahkan untuk IPv4, dan reverse-memerintahkan representasi menggigit untuk IPv6.
Ketika melakukan reverse lookup, klien DNS mengubah alamat ke format ini sebelum query nama untuk catatan PTR berikut rantai delegasi sebagai untuk setiap permintaan DNS. Misalnya, dengan asumsi alamat IPv4 208.80.152.2 ditugaskan untuk Wikimedia, diwakili sebagai nama DNS dalam urutan terbalik: 2.152.80.208.in-addr.arpa. Ketika DNS resolver mendapat pointer (PTR) permintaan, dimulai dengan query root server, yang titik ke server dari Amerika Registry untuk Nomor Internet (ARIN) untuk zona 208.in-addr.arpa. ARIN server delegasi 152.80.208.in-addr.arpa untuk Wikimedia yang resolver mengirimkan permintaan yang lain untuk 2.152.80.208.in-addr.arpa, yang menghasilkan respon otoritatif.

Klien lookup

DNS urut resolusi

Pengguna umumnya tidak berkomunikasi langsung dengan DNS resolver. Sebaliknya resolusi DNS berlangsung transparan dalam aplikasi seperti web browser , e-mail klien , dan aplikasi internet lainnya. Ketika sebuah aplikasi membuat permintaan yang memerlukan nama domain lookup, program tersebut mengirimkan permintaan resolusi ke penyelesai DNS di sistem operasi lokal, yang pada gilirannya menangani komunikasi diperlukan.
DNS resolver akan hampir selalu memiliki cache (lihat di atas) yang berisi pencarian baru-baru ini. Jika cache dapat memberikan jawaban terhadap permintaan, resolver akan kembali nilai dalam cache untuk program yang membuat permintaan. Jika cache tidak berisi jawaban, 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 ini: user tersebut akan baik telah mengkonfigurasi alamat server secara manual atau diizinkan DHCP untuk mengaturnya; Namun, di mana sistem administrator telah mengkonfigurasi sistem untuk menggunakan server DNS mereka sendiri, DNS resolvers mereka menunjuk ke terpisah dipertahankan server nama organisasi. Dalam hal apapun, nama server sehingga query akan mengikuti proses yang disebutkan di atas , sampai baik berhasil menemukan hasil atau tidak. Kemudian kembali hasilnya kepada resolver DNS; asumsi itu telah menemukan hasilnya, resolver sepatutnya cache hasil bahwa untuk penggunaan masa depan, dan tangan hasilnya kembali ke software yang diprakarsai permintaan.

Rusak resolvers

Beberapa ISP besar telah dikonfigurasi server DNS mereka melanggar aturan, misalnya dengan tidak mematuhi TTLs, atau dengan menunjukkan bahwa nama domain tidak ada hanya karena salah satu server namanya tidak merespon. ^[22]
Beberapa aplikasi, seperti web browser, menjaga DNS internal cache untuk menghindari pencarian ulang melalui jaringan. Praktek ini dapat menambah kesulitan tambahan ketika debugging masalah DNS, karena mengaburkan sejarah data tersebut. Cache ini biasanya menggunakan waktu caching sangat pendek - di urutan satu menit. ^[23]
Internet Explorer merupakan pengecualian: versi hingga IE Cache 3.x catatan DNS selama 24 jam secara default. Internet Explorer 4.x dan versi (hingga IE 8) mengurangi waktu default keluar nilai sampai setengah jam, yang dapat diubah dengan memodifikasi konfigurasi default. ^[24]
Google Chrome memicu pesan kesalahan tertentu untuk masalah DNS. Ketika server DNS down atau rusak, Google Chrome mengembalikan pesan kesalahan. ^[25]

Aplikasi lain

Domain Name System meliputi beberapa fungsi dan fitur lainnya.
Hostname dan alamat IP tidak diperlukan untuk mencocokkan dalam hubungan satu-ke-satu. Beberapa nama host yang diwakili melalui alamat IP tunggal, yang berguna dalam virtual hosting , di mana banyak situs web yang disajikan dari sebuah host. Atau, sebuah nama host dapat mengatasi beberapa alamat IP untuk memfasilitasi toleransi kesalahan dan distribusi beban untuk beberapa contoh server di suatu perusahaan atau Internet global.
DNS berfungsi tujuan lain selain menerjemahkan nama ke alamat IP. Misalnya, agen mail transfer menggunakan DNS untuk mencari mail server yang terbaik untuk memberikan e-mail . Domain ke mail exchanger pemetaan yang disediakan oleh catatan MX dapat menyajikan lapisan tambahan toleransi kesalahan dan distribusi beban.
DNS digunakan untuk penyimpanan yang efisien dan distribusi alamat IP dari host email daftar hitam. Sebuah metode yang umum adalah untuk menempatkan alamat IP dari host subjek ke dalam sub-domain dari nama domain tingkat yang lebih tinggi, dan untuk menyelesaikan nama itu untuk catatan yang menunjukkan positif atau indikasi negatif.
Sebagai contoh:

• Alamat 102.3.4.5 yang hitam. Menunjuk ke 5.4.3.102.blacklist.example, yang memutuskan untuk 127.0.0.1.
• Alamat 102.3.4.6 tidak masuk daftar hitam dan poin untuk 6.4.3.102.blacklist.example. hostname ini adalah baik tidak dikonfigurasi, atau memutuskan untuk 127.0.0.2.

server E-mail dapat query blacklist.example untuk mengetahui apakah host tertentu yang menghubungkan kepada mereka adalah dalam daftar hitam. Banyak dari blacklist tersebut, baik berbasis langganan atau bebas biaya, tersedia untuk digunakan oleh administrator email dan software anti-spam.
The Sender Policy Framework dan DomainKeys dirancang untuk mengambil keuntungan dari DNS tipe record lain, data TXT , tetapi telah ditetapkan jenis catatan tertentu.
Untuk memberikan ketahanan dalam hal komputer atau jaringan kegagalan, beberapa server DNS biasanya disediakan untuk cakupan dari setiap domain. Pada tingkat atas DNS global, tiga belas kelompok server nama akar ada, dengan tambahan "salinan" dari mereka didistribusikan di seluruh dunia melalui anycast menangani.
Dynamic DNS (DDNS) update server DNS dengan alamat IP klien on-the-fly, misalnya, ketika bergerak antara ISP atau mobile hot spot , atau ketika perubahan alamat IP secara administratif.

Format pesan DNS

Protokol DNS menggunakan dua jenis pesan DNS, permintaan dan balasan, dan mereka berdua memiliki format yang sama. Setiap pesan terdiri dari header dan empat bagian: pertanyaan, jawaban, otoritas, dan ruang tambahan. Sebuah kolom header (bendera) mengontrol isi dari empat bagian tersebut. ^[1]
Bagian header berisi bidang-bidang berikut: Identifikasi, Flags, Jumlah pertanyaan, Jumlah jawaban, Jumlah catatan sumber daya otoritas (RR), dan Jumlah RRS tambahan. Bidang identifikasi dapat digunakan untuk mencocokkan jawaban dengan pertanyaan. Bidang bendera terdiri dari beberapa sub-bidang. Yang pertama adalah satu bit yang menunjukkan jika pesan adalah query (0) atau balasan (1). Sub-bidang kedua terdiri dari empat bit; jika nilai 1, paket ini adalah balasan; jika 2, paket ini adalah status; jika nilai adalah 0, paket ini adalah permintaan. Sebuah sub-bidang single-bit menunjukkan jika server DNS otoritatif untuk nama host bertanya. sub-bidang lain single-bit menunjukkan jika klien ingin mengirim permintaan rekursif ( "RD"). Single-bit sub-kolom berikutnya menunjukkan jika server DNS membalas mendukung rekursi ( "RA"), karena tidak semua server DNS dikonfigurasi untuk melakukan tugas ini. sub-bidang lain menunjukkan jika permintaan itu dipotong untuk beberapa alasan ( "TC"), dan sub-bidang empat-bit menunjukkan status. Bagian pertanyaan berisi nama domain dan jenis catatan (A, AAAA, MX, TXT, dll) sedang diselesaikan. Nama domain ini dibagi menjadi label diskrit yang bersambung; setiap label diawali oleh panjang label itu. Bagian jawaban memiliki catatan sumber daya dari nama bertanya. Sebuah nama domain dapat terjadi pada beberapa catatan jika memiliki beberapa alamat IP yang terkait. ^[26]

Protokol transport

DNS terutama menggunakan User Datagram Protocol (UDP) pada nomor port 53 untuk melayani permintaan. ^[3] query DNS terdiri dari permintaan UDP tunggal dari klien diikuti oleh jawaban UDP tunggal dari server. The Transmission Control Protocol (TCP) digunakan ketika ukuran data jawaban melebihi 512 byte, atau untuk tugas-tugas seperti transfer zona . Beberapa implementasi resolver menggunakan TCP untuk semua pertanyaan.

Catatan sumber daya DNS

Domain Name System menentukan satu set berbagai jenis catatan sumber daya (RR), yang merupakan elemen informasi dasar dari sistem nama domain. Setiap record memiliki tipe (nama dan nomor), waktu berakhirnya ( waktu untuk hidup ), kelas, dan jenis-spesifik data. Catatan sumber daya dari jenis yang sama dijelaskan sebagai catatan sumber daya set (RRset). Urutan catatan sumber daya dalam satu set, yang dikembalikan oleh penyelesai untuk aplikasi, tidak terdefinisi, tetapi sering server menerapkan round-robin memesan untuk mencapai load balancing . The Domain Name System Extensions Security (DNSSEC), bagaimanapun, bekerja pada set lengkap catatan sumber daya dalam rangka kanonik.
Ketika dikirim melalui Internet Protocol jaringan, semua catatan menggunakan format umum yang ditentukan dalam RFC 1035 : ^[27]

resource record (RR) bidang

Bidang	Deskripsi	Panjang ( oktet )
NAMA	Nama node yang merekam ini berkaitan	Variabel
MENGETIK	Jenis RR dalam bentuk numerik (misalnya, 15 untuk MX RRS)	2
KELAS	kode kelas	2
TTL	Hitungan detik yang RR tetap berlaku (maksimal adalah 2 31 -1, yaitu sekitar 68 tahun)	4
RDLENGTH	Panjang lapangan RDATA	2
RDATA	Data tambahan RR-spesifik	Variabel, sesuai RDLENGTH

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

Catatan DNS wildcard

Sistem nama domain mendukung catatan DNS wildcard yang menentukan nama yang dimulai dengan label tanda bintang, '*', misalnya, * .example. ^{[1] [29]} catatan DNS milik nama domain wildcard menetapkan aturan untuk menghasilkan catatan sumber daya dalam zona DNS tunggal dengan menggantikan seluruh label dengan komponen pencocokan nama query, termasuk keturunan tertentu. Misalnya, dalam konfigurasi berikut, yang x.example zona DNS menetapkan bahwa semua subdomain, termasuk subdomain dari subdomain, dari x.example menggunakan mail exchanger (MX) axexample. A record untuk axexample diperlukan untuk menentukan alamat IP mail exchanger. Karena ini memiliki hasil tidak termasuk nama domain ini dan subdomainnya dari pertandingan wildcard, catatan MX tambahan untuk axexample subdomain, serta catatan MX karakter pengganti untuk semua subdomainnya, juga harus didefinisikan di zona DNS.

 x.example.  MX 10 axexample.
 * .x.example.  MX 10 axexample.
 * .axexample.  MX 10 axexample.
 axexample.  MX 10 axexample.
 axexample.  AAAA 2001: db8 :: 1

Peran catatan wildcard diperhalus dalam RFC 4592 , karena definisi asli dalam RFC 1034 tidak lengkap dan mengakibatkan salah tafsir oleh pelaksana. ^[29]

Ekstensi protokol

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

Update zona dinamis

Update DNS dinamis menggunakan UPDATE DNS opcode untuk menambah atau menghapus catatan sumber daya secara dinamis dari database zona dipertahankan pada server DNS otoritatif. Fitur ini dijelaskan dalam RFC 2136 . Fasilitas ini berguna untuk mendaftarkan klien jaringan ke DNS saat mereka boot atau menjadi dinyatakan tersedia pada jaringan. Sejak klien booting dapat diberi alamat IP yang berbeda setiap kali dari DHCP server, tidak mungkin untuk memberikan tugas DNS statis untuk klien tersebut.

Masalah keamanan

Awalnya, masalah keamanan tidak pertimbangan desain utama untuk perangkat lunak DNS atau perangkat lunak untuk penyebaran di Internet awal, sebagai jaringan itu tidak terbuka untuk partisipasi oleh masyarakat umum. Namun, perluasan Internet ke sektor komersial di tahun 1990-an mengubah persyaratan untuk langkah-langkah keamanan untuk melindungi integritas data dan otentikasi pengguna.
Beberapa isu kerentanan ditemukan dan dieksploitasi oleh pengguna jahat. Salah satu isu tersebut adalah DNS cache keracunan , di mana data didistribusikan ke resolvers caching dengan dalih menjadi server asal berwibawa, sehingga mencemari menyimpan data dengan informasi yang berpotensi palsu dan kali kedaluwarsa panjang (time-to-live). Selanjutnya, permintaan aplikasi yang sah dapat diarahkan ke host jaringan dioperasikan dengan niat jahat.
tanggapan DNS secara tradisional tidak cryptographically ditandatangani, menyebabkan banyak kemungkinan serangan; yang Domain Name System Extensions Security (DNSSEC) memodifikasi DNS untuk menambahkan dukungan untuk respon cryptographically ditandatangani. DNSCurve telah diusulkan sebagai alternatif untuk DNSSEC. Ekstensi lain, seperti TSIG , menambahkan dukungan untuk otentikasi kriptografi antara rekan-rekan yang terpercaya dan biasanya digunakan untuk mengotorisasi transfer zona atau memperbarui operasi dinamis.
Beberapa nama domain dapat digunakan untuk mencapai efek spoofing. Misalnya, paypal.com dan paypa1.com adalah nama yang berbeda, namun pengguna mungkin tidak dapat membedakan mereka dalam antarmuka pengguna grafis tergantung pada pilihan pengguna jenis huruf . Dalam banyak font huruf l dan angka 1 terlihat sangat mirip atau bahkan identik. Masalah ini akut pada sistem yang mendukung nama domain internasional , karena banyak kode karakter di ISO 10646 mungkin muncul identik pada layar komputer biasa. Kerentanan ini kadang-kadang dimanfaatkan dalam phishing . ^[30]
Teknik seperti reverse DNS maju-dikonfirmasi juga dapat digunakan untuk membantu memvalidasi hasil DNS.

Pendaftaran nama domain

Hak untuk menggunakan nama domain didelegasikan oleh pendaftar nama domain yang diakreditasi oleh Internet Corporation untuk Ditugaskan Nama dan Nomor (ICANN) atau organisasi lain seperti OpenNIC , yang bertugas mengawasi nama dan nomor sistem Internet. Selain ICANN, setiap domain tingkat atas (TLD) service dan pemeliharaan teknis oleh organisasi administrasi, operasi registry. Sebuah registri bertanggung jawab untuk operasi database nama dalam zona otoritatif, meskipun istilah ini paling sering digunakan untuk TLDs. Sebuah pendaftar adalah orang atau organisasi yang meminta pendaftaran domain. ^[17] registri menerima informasi pendaftaran dari masing-masing nama domain registrar, yang berwenang (terakreditasi) untuk menetapkan nama-nama di zona yang sesuai dan menerbitkan informasi menggunakan WHOIS protokol. Pada tahun 2015, penggunaan RDAP sedang dipertimbangkan. ^[31]
ICANN menerbitkan daftar lengkap TLDs, pendaftar TLD, dan nama domain pendaftar. Informasi pendaftar terkait dengan nama domain dipertahankan dalam sebuah database online dapat diakses dengan layanan WHOIS. Untuk sebagian besar dari lebih dari 290 domain kode negara top-level (ccTLD), pendaftar domain menjaga WHOIS (Pendaftar, nama server, tanggal kadaluwarsa, dll) informasi. Misalnya, DENIC , Jerman NIC, memegang data domain DE. Sejak sekitar tahun 2001, sebagian besar top-level domain generik (gTLD) pendaftar telah mengadopsi disebut pendekatan registry tebal ini, yaitu menjaga data WHOIS di pendaftar pusat bukannya database registrar.
Untuk COM dan nama domain NET, model registry tipis digunakan. Domain registry (misalnya VeriSign ) menyimpan data WHOIS dasar (yaitu, registrar dan nama server, dll) Satu dapat menemukan WHOIS rinci (pendaftar, nama server, tanggal kadaluwarsa, dll) di pendaftar.
Beberapa pendaftar nama domain, sering disebut pusat informasi jaringan (NIC), juga berfungsi sebagai pendaftar ke pengguna akhir. Generik tingkat atas domain pendaftar utama, seperti untuk domain COM, NET, ORG, INFO, menggunakan model registry-registrar yang terdiri dari banyak pendaftar nama domain. ^[32] Dalam metode ini manajemen, registri hanya mengelola nama domain database dan hubungan dengan pendaftar. Para pendaftar (pengguna nama domain) adalah pelanggan dari registrar, dalam beberapa kasus melalui lapisan tambahan reseller.

Dokumen RFC

Standar

Domain Name System didefinisikan oleh permintaan untuk komentar (RFC) dokumen yang dipublikasikan oleh Internet Engineering Task Force ( standar Internet ). Berikut ini adalah daftar RFC yang mendefinisikan protokol DNS.

• RFC 1034 , Nama Domain - Konsep dan Fasilitas
• RFC 1035 , Nama Domain - Implementasi dan Spesifikasi
• RFC 1123 , Persyaratan untuk Internet Host-Aplikasi dan Dukungan
• RFC 1995 , Incremental Zona Transfer DNS
• RFC 1996 , A Mekanisme Pemberitahuan Prompt dari Zona Perubahan (DNS NOTIFY)
• RFC 2136 , pembaruan dinamis dalam sistem nama domain (DNS UPDATE)
• RFC 2181 , Klarifikasi ke DNS Spesifikasi
• RFC 2308 , Caching negatif dari DNS Query (DNS NCACHE)
• RFC 2671 , Perpanjangan Mekanisme untuk DNS (EDNS0)
• RFC 2672 , Non-Terminal DNS Nama Redirection
• RFC 2845 , Kunci Rahasia Transaksi Authentication untuk DNS (TSIG)
• RFC 3225 , Menunjukkan Resolver Dukungan dari DNSSEC
• RFC 3226 , DNSSEC dan IPv6 A6 menyadari Server / resolver persyaratan ukuran pesan
• RFC 3597 , Penanganan diketahui DNS Resource Record (RR) Jenis
• RFC 4343 , Domain Name System (DNS) Kasus Ketidakpekaan Klarifikasi
• RFC 4592 , Peran Wildcard di Domain Name System
• RFC 4635 , HMAC SHA TSIG Algoritma Identifier
• RFC 5001 , DNS Name Server Identifier (NSID) Option
• RFC 5452 , Langkah-langkah untuk Membuat DNS Lebih Tangguh terhadap Answers Ditempa
• RFC 5890 , Nama internasionalisasi Domain untuk Aplikasi (IDNA): Definisi dan Dokumen Kerangka
• RFC 5891 , Nama internasionalisasi Domain Aplikasi (IDNA): Protokol
• RFC 5892 , Kode Unicode Tempat dan internasionalisasi Nama Domain untuk Aplikasi (IDNA)
• RFC 5893 , Kanan-ke-kiri Script untuk internasionalisasi Nama Domain untuk Aplikasi (IDNA)
• RFC 7766 , DNS Transportasi melalui TCP - Persyaratan Implementasi

Keamanan

• RFC 4033 , DNS Keamanan Pendahuluan dan Persyaratan
• RFC 4034 , Resource Records untuk Ekstensi DNS Security
• RFC 4035 , Protokol Modifikasi untuk Ekstensi DNS Security
• RFC 4509 , Penggunaan SHA-256 di DNSSEC Delegasi Signor (DS) Resource Records
• RFC 4470 , minimal Menutupi NSEC Records dan DNSSEC On-line Penandatanganan
• RFC 5011 , Automated Update dari DNS Security (DNSSEC) Trust Anchors
• RFC 5155 , DNS Security (DNSSEC) Hashed dikonfirmasi Denial of Keberadaan
• RFC 5702 , Penggunaan SHA-2 Algoritma dengan RSA di DNSKEY dan RRSIG Resource Records untuk DNSSEC
• RFC 5910 , Domain Name System (DNS) Keamanan Extensions Pemetaan untuk Extensible Provisioning Protocol (EPP)
• RFC 5933 , Penggunaan GOST Signature Algoritma di DNSKEY dan Sumber Daya RRSIG Records untuk DNSSEC
• RFC 7858 , Spesifikasi DNS lebih Transport Layer Security (TLS)

Eksperimental

• RFC 1183 , DNS New Definisi RR

Praktik Terbaik Saat Ini

• RFC 2182 , seleksi dan Operasi DNS Server Secondary (BCP 16)
• RFC 2317 , Classless IN-ADDR.ARPA delegasi (BCP 20)
• RFC 5625 , DNS Proxy Pedoman Pelaksanaan (BCP 152)
• RFC 6895 , Domain Name System (DNS) Pertimbangan IANA (BCP 42)
• RFC 7720 , DNS Akar Name Service Protocol dan Persyaratan Deployment (BCP 40)

Informasi

RFC ini adalah penasihat di alam, tetapi dapat memberikan informasi yang berguna meskipun mendefinisikan tidak standar atau BCP. ( RFC 1796 )

• RFC 1178 , Memilih Nama untuk Komputer Anda (FYI 5)
• RFC 1591 , Struktur dan Delegasi Domain Name System
• RFC 1912 , DNS Kesalahan umum Operasional dan Konfigurasi
• RFC 2100 , The Penamaan Host
• RFC 3696 , Teknik Aplikasi untuk Pemeriksaan dan Transformasi Nama
• RFC 4892 , Persyaratan untuk Mekanisme Mengidentifikasi Name Server Instance
• RFC 5894 , Nama internasionalisasi Domain untuk Aplikasi (IDNA): Latar Belakang, Penjelasan, dan Rasional
• RFC 5895 , Karakter Pemetaan untuk internasionalisasi Nama Domain Aplikasi (IDNA) 2008
• RFC 7626 , Pertimbangan DNS Privasi
• RFC 7706 , Penurunan Waktu Akses ke Root Server dengan Running Satu di Loopback

Tidak diketahui

RFC ini memiliki status resmi diketahui , namun karena usia mereka tidak jelas diberi label seperti itu.

• RFC 920 , Persyaratan Domain - Ditentukan domain asli top-level
• RFC 1032 , Administrator Domain Gratis
• RFC 1033 , Administrator Domain Gratis Operasi
• RFC 1101 , Pengkodean DNS Nama Jaringan dan Jenis Lainnya 

 referensi : https://translate.google.co.id/translate?hl=id&sl=en&u=https://en.wikipedia.org/wiki/Domain_Name_System&prev=search

 Sekian dari saya, saya ucapkan banyak terima kasih.
 Wassalamu'alaikum.wr.wb