Sistem Penamaan Domain / Domain Name System (Dns)
Domain Name System (DNS)
Barusan main ke wikipedia.org nemu bacaan perihal DNS pas banget buat persiapan LKS, sekalian aja iseng - iseng saya upload disini semoga nanti gampang kalo mau nyari lagi.
DNS (Domain Name System) ialah sebuah sistem yang menyimpan warta perihal nama host maupun nama domain dalam bentuk basis data tersebar (distributed database) di dalam jaringan komputer, misalkan: Internet. DNS menyediakan alamat IP untuk setiap nama host dan mendata setiap server transmisi surat (mail exchange server) yang mendapatkan surat elektronik (email) untuk setiap domain.
DNS menyediakan servis yang cukup penting untuk Internet, bilamana perangkat keras komputer dan jaringan bekerja dengan alamat IP untuk mengerjakan kiprah ibarat pengalamatan dan penjaluran (routing), insan pada umumnya lebih menentukan untuk memakai nama host dan nama domain, misalnya ialah penunjukan sumber universal (URL) dan alamat e-mail. DNS menghubungkan kebutuhan ini.
Sejarah singkat DNS
Penggunaan nama sebagai pengabstraksi alamat mesin di sebuah jaringan komputer yang lebih dikenal oleh insan mengalahkan TCP/IP, dan kembali ke zaman ARPAnet. Dahulu, setiap komputer di jaringan komputer memakai file HOSTS.TXT dari SRI (sekarang SIR International), yang memetakan sebuah alamat ke sebuah nama (secara teknis, file ini masih ada - sebagian besar sistem operasi modern menggunakannya baik secara baku maupun melalui konfigurasi, sanggup melihat Hosts file untuk menyamakan sebuah nama host menjadi sebuah alamat IP sebelum melaksanakan pencarian via DNS). Namun, sistem tersebut diatas mewarisi beberapa keterbatasan yang mencolok dari sisi prasyarat, setiap dikala sebuah alamat komputer berubah, setiap sistem yang hendak berafiliasi dengan komputer tersebut harus melaksanakan update terhadap file Hosts.
Dengan berkembangnya jaringan komputer, membutuhkan sistem yang sanggup dikembangkan: sebuah sistem yang sanggup mengganti alamat host hanya di satu tempat, host lain akan mempelajari perubaha tersebut secara dinamis. Inilah DNS.
Paul Mockapetris menemukan DNS di tahun 1983; spesifikasi orisinil muncul di RFC 882 dan 883. Tahun 1987, penerbitan RFC 1034 dan RFC 1035 menciptakan update terhadap spesifikasi DNS. Hal ini menciptakan RFC 882 dan RFC 883 tidak berlaku lagi. Beberapa RFC terkini telah memproposikan beberapa perhiasan dari protokol inti DNS.
Teori kerja DNS
3 Komponen Inti dari DNS
Pengelola dari sistem DNS terdiri dari tiga komponen:
* DNS resolver, sebuah acara klien yang berjalan di komputer pengguna, yang menciptakan permintaan DNS dari acara aplikasi.
* recursive DNS server, yang melaksanakan pencarian melalui DNS sebagai tanggapan ajakan dari resolver, dan mengembalikan tanggapan kepada para resolver tersebut
* authoritative DNS server yang memperlihatkan tanggapan terhadap ajakan dari recursor, baik dalam bentuk sebuah jawaban, maupun dalam bentuk delegasi (misalkan: mereferensikan ke authoritative DNS server lainnya)
Pengertian beberapa bab dari nama domain
Sebuah nama domain biasanya terdiri dari dua bab atau lebih (secara teknis disebut label), dipisahkan dengan titik.
* Label paling kanan menyatakan top-level domain - domain tingkat atas/tinggi (misalkan, alamat www.wikipedia.org mempunyai top-level domain org).
* Setiap label di sebelah kirinya menyatakan sebuah sub-divisi atau subdomain dari domain yang lebih tinggi. Catatan: "subdomain" menyatakan ketergantungan relatif, bukan absolut. Contoh: wikipedia.org merupakan subdomain dari domain org, dan id.wikipedia.org sanggup membentuk subdomain dari domain wikipedia.org (pada prakteknya, id.wikipedia.org sesungguhnya mewakili sebuah nama host - lihat dibawah). Secara teori, pembagian ibarat ini sanggup mencapai kedalaman 127 level, dan setiap label sanggup terbentuk hingga dengan 63 karakter, selama total nama domain tidak melebihi panjang 255 karakter. Tetapi secara praktek, beberapa pendaftar nama domain (domain name registry) mempunyai batas yang lebih sedikit.
* Terakhir, bab paling kiri dari bab nama domain (biasanya) menyatakan nama host. Sisa dari nama domain menyatakan cara untuk membangun jalur logis untuk warta yang dibutuhkan; nama host ialah tujuan bahwasanya dari nama sistem yang dicari alamat IP-nya. Contoh: nama domain www.wikipedia.org mempunyai nama host "www".
DNS mempunyai kumpulan hirarki dari DNS servers. Setiap domain atau subdomain mempunyai satu atau lebih authoritative DNS Servers (server DNS otorisatif) yang mempublikasikan informas perihal domain tersebut dan nama-nama server dari setiap domain di-"bawah"-nya. Pada puncak hirarki, terdapat root servers- induk server nama: server yang ditanyakan ketika mencari (menyelesaikan/resolving) dari sebuah nama domain tertinggi (top-level domain).
Sebuah contoh dari teori rekursif DNS
Sebuah contoh mungkin sanggup memperjelas proses ini. Andaikan ada aplikasi yang memerlukan pencarian alamat IP dari www.wikipedia.org. Aplikasi tersebut bertanya ke DNS recursor lokal.
* Sebelum dimulai, recursor harus mengetahui dimana sanggup menemukan root nameserver; eksekutif dari recursive DNS server secara manual mengatur (dan melaksanakan update secara berkala) sebuah file dengan nama root hints zone (panduan akar DNS) yang menyatakan alamat-alamt IP dari para server tersebut.
* Proses dimulai oleh recursor yang bertanya kepada para root server tersebut - misalkan: server dengan alamat IP "198.41.0.4" - pertanyaan "apakah alamat IP dari www.wikipedia.org?"
* Root server menjawab dengan sebuah delegasi, arti kasarnya: "Saya tidak tahu alamat IP dari www.wikipedia.org, tapi saya "tahu" bahwa server DNS di 204.74.112.1 mempunyai warta perihal domain org."
* Recursor DNS lokal kemudian bertanya kepada server DNS (yaitu: 204.74.112.1) pertanyaan yang sama ibarat yang diberikan kepada root server. "apa alamat IP dari www.wikipedia.org?". (umumnya) akan didapatkan tanggapan yang sejenis, "saya tidak tahu alamat dari www.wikipedia.org, tapi saya "tahu" bahwa server 207.142.131.234 mempunyai warta dari domain wikipedia.org."
* Akhirnya, pertanyaan beralih kepada server DNS ketiga (207.142.131.234), yang menjawab dengan alamat IP yang dibutuhkan. Proses ini memakai pencarian rekursif (recursion / recursive searching).
Pengertian registrasi domain dan glue records
Membaca contoh diatas, Anda mungkin bertanya: "bagaimana caranya DNS server 204.74.112.1 tahu alamat IP mana yang diberikan untuk domain wikipedia.org?" Pada awal proses, kita mencatat bahwa sebuah DNS recursor mempunyai alamat IP dari para root server yang (kurang-lebih) didata secara explisit (hard coded). Mirip dengan hal tersebut, server nama (name server) yang otoritatif untuk top-level domain mengalami perubahan yang jarang.
Namun, server nama yang memperlihatkan tanggapan otorisatif bagi nama domain yang umum mengalami perubahan yang cukup sering. Sebagai bab dari proses registrasi sebuah nama domain (dan beberapa waktu sesudahnya), pendaftar memperlihatkan registrasi dengan server nama yang akan mengotorisasikan nama domain tersebut; maka ketika mendaftar wikipedia.org, domain tersebut terhubung dengan server nama gunther.bomis.com dan zwinger.wikipedia.org di pendaftar .org. Kemudian, dari contoh di atas, ketika server dikenali sebagai 204.74.112.1 mendapatkan sebuah permintaan, DNS server memindai daftar domain yang ada, mencari wikipedia.org, dan mengembalikan server nama yang terhubung dengan domain tersebut.
Biasanya, server nama muncul menurut urutan nama, selain menurut alamat IP. Hal ini menjadikan string lain dari ajakan DNS untuk menuntaskan nama dari server nama; ketika sebuah alamat IP dari server nama mendapatkan sebuah registrasi di zona induk, para programmer jaringan komputer menamakannya sebuah glue record (daftar lekat???)
DNS dalam praktek
Ketika sebuah aplikasi (misalkan web broswer), hendak mencari alamat IP dari sebuah nama domain, aplikasi tersebut tidak harus mengikuti seluruh langkah yang disebutkan dalam teori diatas. Kita akan melihat dulu konsep caching, kemudian mengertikan operasi DNS di "dunia nyata".
Caching dan masa hidup (caching and time to live)
Karena jumlah ajakan yang besar dari sistem ibarat DNS, perancang DNS menginginkan penyediaan prosedur yang sanggup mengurangi beban dari masing-masing server DNS. Rencana mekanisnya menyarankan bahwa ketika sebuah DNS resolver (klien) mendapatkan sebuah tanggapan DNS, warta tersebut akan di cache untuk jangka waktu tertentu. Sebuah nilai (yang di-set oleh eksekutif dari server DNS yang memperlihatkan jawaban) menyebutnya sebagai time to live (masa hidup), atau TTL yang mendefinisikan periode tersebut. Saat tanggapan masuk ke dalam cache, resolver akan mengacu kepada tanggapan yang disimpan di cache tersebut; hanya ketika TTL usai (atau dikala eksekutif mengosongkan tanggapan dari memori resolver secara manual) maka resolver menghubungi server DNS untuk warta yang sama.
Waktu propagasi (propagation time)Satu akhir penting dari arsitektur tersebar dan cache ialah perubahan kepada suatu DNS tidak selalu efektif secara pribadi dalam skala besar/global. Contoh berikut mungkin akan menjelaskannya: Jika seorang eksekutif telah mengatur TTL selama 6 jam untuk host www.wikipedia.org, kemudian mengganti alamat IP dari www.wikipedia.org pada pk 12:01, eksekutif harus mempertimbangkan bahwa ada (paling tidak) satu individu yang menyimpan cache tanggapan dengan nilai usang pada pk 12:00 yang tidak akan menghubungi server DNS hingga dengan pk 18:00. Periode antara pk 12:00 dan pk 18:00 dalam contoh ini disebut sebagai waktu propagasi (propagation time), yang sanggup didefiniskan sebagai periode waktu yang berawal antara dikala terjadi perubahan dari data DNS, dan berakhir setelah waktu maksimum yang telah ditentukan oleh TTL berlalu. Ini akan mengarahkan kepada pertimbangan logis yang penting ketika menciptakan perubahan kepada DNS: tidak semua akan melihat hal yang sama ibarat yang Anda lihat. RFC1537 sanggup membantu klarifikasi ini.
DNS di dunia nyata
Di dunia nyata, user tidak berhadapan pribadi dengan DNS resolver - mereka berhadapan dengan acara ibarat web brower (Mozilla Firefox, Safari, Opera, Internet Explorer, Netscape, Konqueror dan lain-lain dan klien mail (Outlook Express, Mozilla Thunderbird dan lain-lain). Ketika user melaksanakan acara yang meminta pencarian DNS (umumnya, nyaris semua acara yang memakai Internet), acara tersebut mengirimkan ajakan ke DNS Resolver yang ada di dalam sistem operasi.
DNS resolver akan selalu mempunyai cache (lihat diatas) yang mempunyai isi pencarian terakhir. Jika cache sanggup memperlihatkan tanggapan kepada ajakan DNS, resolver akan memakai nilai yang ada di dalam cache kepada acara yang memerlukan. Kalau cache tidak mempunyai jawabannya, resolver akan mengirimkan ajakan ke server DNS tertentu. Untuk kebanyakan pengguna di rumah, Internet Service Provider(ISP) yang menghubungkan komputer tersebut biasanya akan menyediakan server DNS: pengguna tersebut akan mendata alamat server secara manual atau memakai DHCP untuk melaksanakan pendataan tersebut. Jika eksekutif sistem telah mengkonfigurasi sistem untuk memakai server DNS mereka sendiri, DNS resolver umumnya akan mengacu ke server nama mereka. Server nama ini akan mengikuti proses yang disebutkan di Teori DNS, baik mereka menemukan jawabannya maupun tidak. Hasil pencarian akan diberikan kepada DNS resolver; diasumsikan telah ditemukan jawaban, resolver akan menyimpan kesudahannya di cache untuk penggunaan berikutnya, dan memperlihatkan kesudahannya kepada software yang meminta pencarian DNS tersebut.
Sebagai bab tamat dari kerumitan ini, beberapa aplikasi ibarat web browser juga mempunyai DNS cache mereka sendiri, tujuannya ialah untuk mengurangi penggunaan acuan DNS resolver, yang akan meningkatkan kesulitan untuk melaksanakan debug DNS, yang menjadikan kerancuan data yang lebih akurat. Cache ibarat ini umumnya mempunyai masa yang singkat dalam hitungan 1 menit.
Penerapan DNS lainnya
Sistem yang dijabarkan diatas memperlihatkan skenario yang disederhanakan. DNS mencakup beberapa fungsi lainnya:
* Nama host dan alamat IP tidak berarti terhubung secara satu-banding-satu. Banyak nama host yang diwakili melalui alamat IP tunggal: adonan dengan pengasuhan maya (virtual hosting), hal ini memungkinkan satu komputer untuk malayani beberapa situs web. Selain itu, sebuah nama host sanggup mewakili beberapa alamat IP: ini akan membantu toleransi kesalahan (fault tolerance dan penyebaran beban (load distribution), juga membantu suatu situs berpindah dari satu lokasi fisik ke lokasi fisik lainnya secara mudah.
* Ada cukup banyak kegunaan DNS selain menerjemahkan nama ke alamat IP. Contoh:, distributor pemindahan surat Mail transfer agents(MTA) memakai DNS untuk mencari tujuan pengiriman E-mail untuk alamat tertentu. Domain yang menginformasikan pemetaan exchange disediakan melalui rekod MX (MX record) yang meningkatkan lapisan perhiasan untuk toleransi kesalahan dan penyebaran beban selain dari fungsi pemetaan nama ke alamat IP.
* Kerangka Peraturan Pengiriman (Sender Policy Framework) secara kontroversi memakai laba jenis rekod DNS, dikenal sebagai rekod TXT.
* Menyediakan keluwesan untuk kegagalan komputer, beberapa server DNS memperlihatkan dukungan untuk setiap domain. Tepatnya, tigabelas server akar (root servers) dipakai oleh seluruh dunia. Program DNS maupun sistem operasi mempunyai alamat IP dari seluruh server ini. Amerika Serikat memiliki, secara angka, semua kecuali tiga dari server akar tersebut. Namun, dikarenakan banyak server akar menerapkan anycast, yang memungkinkan beberapa komputer yang berbeda sanggup menyebarkan alamat IP yang sama untuk mengirimkan satu jenis services melalui area geografis yang luas, banyak server yang secara fisik (bukan sekedar angka) terletak di luar Amerika Serikat.
DNS menggunanakn TCP dan UDP di port komputer 53 untuk melayani ajakan DNS. Nyaris semua ajakan DNS berisi ajakan UDP tunggal dari klien yang dikuti oleh tanggapan UDP tunggal dari server. Umumnya TCP ikut terlibat hanya ketika ukuran data tanggapan melebihi 512 byte, atau untuk pertukaaran zona DNS zone transfer
Jenis-jenis catatan DNS
Beberapa kelompok penting dari data yang disimpan di dalam DNS ialah sebagai berikut:
* A record atau catatan alamat memetakan sebuah nama host ke alamat IP 32-bit (untuk IPv4).
* AAAA record atau catatan alamat IPv6 memetakan sebuah nama host ke alamat IP 128-bit (untuk IPv6).
* CNAME record atau catatan nama kanonik menciptakan alias untuk nama domain. Domain yang di-alias-kan mempunyai seluruh subdomain dan rekod DNS ibarat aslinya.
* [MX record]]' atau catatan pertukaran surat memetakan sebuah nama domain ke dalam daftar mail exchange server untuk domain tersebut.
* PTR record atau catatan penunjuk memetakan sebuah nama host ke nama kanonik untuk host tersebut. Pembuatan rekod PTR untuk sebuah nama host di dalam domain in-addr.arpa yang mewakili sebuah alamat IP menerapkan pencarian balik DNS (reverse DNS lookup) untuk alamat tersebut. Contohnya (saat penulisan / penerjemahan artikel ini), www.icann.net mempunyai alamat IP 192.0.34.164, tetapi sebuah rekod PTR memetakan ,,164.34.0.192.in-addr.arpa ke nama kanoniknya: referrals.icann.org.
* NS record atau catatan server nama memetakan sebuah nama domain ke dalam satu daftar dari server DNS untuk domain tersebut. Pewakilan bergantung kepada rekod NS.
* SOA record atau catatan otoritas awal (Start of Authority) mengacu server DNS yang mengediakan otorisasi warta perihal sebuah domain Internet.
* SRV record ialah catatan lokasi secara umum.
* Catatan TXT mengijinkan eksekutif untuk memasukan data acak ke dalam catatan DNS; catatan ini juga dipakai di spesifikasi Sender Policy Framework.
Jenis catatan lainnya semata-mata untuk penyediaan warta (contohnya, catatan LOC memperlihatkan letak lokasi fisik dari sebuah host, atau data ujicoba (misalkan, catatan WKS memperlihatkan sebuah daftar dari server yang memperlihatkan servis yang dikenal (well-known service) ibarat HTTP atau POP3 untuk sebuah domain.
Nama domain yang diinternasionalkan
Nama domain harus memakai satu sub-kumpulan dari huruf ASCII, hal ini mencegah beberapa bahasa untuk memakai nama maupun kata lokal mereka. ICANN telah menyetujui Punycode yang berbasiskan sistem IDNA, yang memetakan string Unicode ke huruf set yang valid untuk DNS, sebagai bentuk penyelesaian untuk persoalan ini, dan beberapa registries sudah mengadopsi metode IDNS ini.
Perangkat lunak DNS
Beberapa jenis perangakat lunak DNS menerapkan metode DNS, beberapa diantaranya:
* BIND (Berkeley Internet Name Domain)
* djbdns (Daniel J. Bernstein's DNS)
* MaraDNS
* QIP (Lucent Technologies)
* NSD (Name Server Daemon)
* PowerDNS
* Microsoft DNS (untuk edisi server dari Windows 2000 dan Windows 2003)
Utiliti berorientasi DNS termasuk:
* dig (the domain information groper)
Pengguna legal dari domain
Tidak satupun individu di dunia yang "memiliki" nama domain kecuali Network Information Centre (NIC), atau pendaftar nama domain (domain name registry). Sebagian besar dari NIC di dunia mendapatkan biaya tahunan dari para pengguna legal dengan tujuan bagi si pengguna legal memakai nama domain tersebut. Makara sejenis perjanjian sewa-menyewa terjadi, bergantung kepada syarat dan ketentuan pendaftar. Bergantung kepada beberpa peraturan penamaan dari para pendaftar, pengguna legal dikenal sebagai "pendaftar" (registrants) atau sebagai "pemegang domain" (domain holders)
ICANN memegang daftar lengkap untuk pendaftar domain di seluruh dunia. Siapapun sanggup menemukan pengguna legal dari sebuah domain dengan mencari melalui basis data WHOIS yang disimpan oleh beberpa pendaftar domain.
Di (lebih kurang) 240 country code top-level domains (ccTLDs), pendaftar domain memegang sebuah contoh WHOIS (pendaftar dan nama server). Contohnya, IDNIC, NIC Indonesia, memegang warta otorisatif WHOIS untuk nama domain .ID.
Namun, beberapa pendaftar domain, ibarat VeriSign, memakai model pendaftar-pengguna. Untuk nama domain .COM dan .NET, pendaftar domain, VeriSign memegang warta dasar WHOIS )pemegang domain dan server nama). Siapapun sanggup mencari detil WHOIS (Pemegang domain, server nama, tanggal berlaku, dan lain sebagainya) melalui pendaftar.
Sejak sekitar 2001, kebanyakan pendaftar gTLD (.ORG, .BIZ, .INFO) telah mengadopsi metode penfatar "tebal", menyimpan otoritatif WHOIS di beberapa pendaftar dan bukan pendaftar itu saja.
Itu lah klarifikasi perihal Domain Name System jadi sebelum kita berguru konfigurasi perihal DNS ada baiknya kita mengetahui teorinya dulu setelah ini kita akan lanjut ke konfigurasi DNS memakai bind pada debian 5.
Barusan main ke wikipedia.org nemu bacaan perihal DNS pas banget buat persiapan LKS, sekalian aja iseng - iseng saya upload disini semoga nanti gampang kalo mau nyari lagi.
DNS (Domain Name System) ialah sebuah sistem yang menyimpan warta perihal nama host maupun nama domain dalam bentuk basis data tersebar (distributed database) di dalam jaringan komputer, misalkan: Internet. DNS menyediakan alamat IP untuk setiap nama host dan mendata setiap server transmisi surat (mail exchange server) yang mendapatkan surat elektronik (email) untuk setiap domain.
DNS menyediakan servis yang cukup penting untuk Internet, bilamana perangkat keras komputer dan jaringan bekerja dengan alamat IP untuk mengerjakan kiprah ibarat pengalamatan dan penjaluran (routing), insan pada umumnya lebih menentukan untuk memakai nama host dan nama domain, misalnya ialah penunjukan sumber universal (URL) dan alamat e-mail. DNS menghubungkan kebutuhan ini.
Sejarah singkat DNS
Penggunaan nama sebagai pengabstraksi alamat mesin di sebuah jaringan komputer yang lebih dikenal oleh insan mengalahkan TCP/IP, dan kembali ke zaman ARPAnet. Dahulu, setiap komputer di jaringan komputer memakai file HOSTS.TXT dari SRI (sekarang SIR International), yang memetakan sebuah alamat ke sebuah nama (secara teknis, file ini masih ada - sebagian besar sistem operasi modern menggunakannya baik secara baku maupun melalui konfigurasi, sanggup melihat Hosts file untuk menyamakan sebuah nama host menjadi sebuah alamat IP sebelum melaksanakan pencarian via DNS). Namun, sistem tersebut diatas mewarisi beberapa keterbatasan yang mencolok dari sisi prasyarat, setiap dikala sebuah alamat komputer berubah, setiap sistem yang hendak berafiliasi dengan komputer tersebut harus melaksanakan update terhadap file Hosts.
Dengan berkembangnya jaringan komputer, membutuhkan sistem yang sanggup dikembangkan: sebuah sistem yang sanggup mengganti alamat host hanya di satu tempat, host lain akan mempelajari perubaha tersebut secara dinamis. Inilah DNS.
Paul Mockapetris menemukan DNS di tahun 1983; spesifikasi orisinil muncul di RFC 882 dan 883. Tahun 1987, penerbitan RFC 1034 dan RFC 1035 menciptakan update terhadap spesifikasi DNS. Hal ini menciptakan RFC 882 dan RFC 883 tidak berlaku lagi. Beberapa RFC terkini telah memproposikan beberapa perhiasan dari protokol inti DNS.
Teori kerja DNS
3 Komponen Inti dari DNS
Pengelola dari sistem DNS terdiri dari tiga komponen:
* DNS resolver, sebuah acara klien yang berjalan di komputer pengguna, yang menciptakan permintaan DNS dari acara aplikasi.
* recursive DNS server, yang melaksanakan pencarian melalui DNS sebagai tanggapan ajakan dari resolver, dan mengembalikan tanggapan kepada para resolver tersebut
* authoritative DNS server yang memperlihatkan tanggapan terhadap ajakan dari recursor, baik dalam bentuk sebuah jawaban, maupun dalam bentuk delegasi (misalkan: mereferensikan ke authoritative DNS server lainnya)
Pengertian beberapa bab dari nama domain
Sebuah nama domain biasanya terdiri dari dua bab atau lebih (secara teknis disebut label), dipisahkan dengan titik.
* Label paling kanan menyatakan top-level domain - domain tingkat atas/tinggi (misalkan, alamat www.wikipedia.org mempunyai top-level domain org).
* Setiap label di sebelah kirinya menyatakan sebuah sub-divisi atau subdomain dari domain yang lebih tinggi. Catatan: "subdomain" menyatakan ketergantungan relatif, bukan absolut. Contoh: wikipedia.org merupakan subdomain dari domain org, dan id.wikipedia.org sanggup membentuk subdomain dari domain wikipedia.org (pada prakteknya, id.wikipedia.org sesungguhnya mewakili sebuah nama host - lihat dibawah). Secara teori, pembagian ibarat ini sanggup mencapai kedalaman 127 level, dan setiap label sanggup terbentuk hingga dengan 63 karakter, selama total nama domain tidak melebihi panjang 255 karakter. Tetapi secara praktek, beberapa pendaftar nama domain (domain name registry) mempunyai batas yang lebih sedikit.
* Terakhir, bab paling kiri dari bab nama domain (biasanya) menyatakan nama host. Sisa dari nama domain menyatakan cara untuk membangun jalur logis untuk warta yang dibutuhkan; nama host ialah tujuan bahwasanya dari nama sistem yang dicari alamat IP-nya. Contoh: nama domain www.wikipedia.org mempunyai nama host "www".
DNS mempunyai kumpulan hirarki dari DNS servers. Setiap domain atau subdomain mempunyai satu atau lebih authoritative DNS Servers (server DNS otorisatif) yang mempublikasikan informas perihal domain tersebut dan nama-nama server dari setiap domain di-"bawah"-nya. Pada puncak hirarki, terdapat root servers- induk server nama: server yang ditanyakan ketika mencari (menyelesaikan/resolving) dari sebuah nama domain tertinggi (top-level domain).
Sebuah contoh dari teori rekursif DNS
Sebuah contoh mungkin sanggup memperjelas proses ini. Andaikan ada aplikasi yang memerlukan pencarian alamat IP dari www.wikipedia.org. Aplikasi tersebut bertanya ke DNS recursor lokal.
* Sebelum dimulai, recursor harus mengetahui dimana sanggup menemukan root nameserver; eksekutif dari recursive DNS server secara manual mengatur (dan melaksanakan update secara berkala) sebuah file dengan nama root hints zone (panduan akar DNS) yang menyatakan alamat-alamt IP dari para server tersebut.
* Proses dimulai oleh recursor yang bertanya kepada para root server tersebut - misalkan: server dengan alamat IP "198.41.0.4" - pertanyaan "apakah alamat IP dari www.wikipedia.org?"
* Root server menjawab dengan sebuah delegasi, arti kasarnya: "Saya tidak tahu alamat IP dari www.wikipedia.org, tapi saya "tahu" bahwa server DNS di 204.74.112.1 mempunyai warta perihal domain org."
* Recursor DNS lokal kemudian bertanya kepada server DNS (yaitu: 204.74.112.1) pertanyaan yang sama ibarat yang diberikan kepada root server. "apa alamat IP dari www.wikipedia.org?". (umumnya) akan didapatkan tanggapan yang sejenis, "saya tidak tahu alamat dari www.wikipedia.org, tapi saya "tahu" bahwa server 207.142.131.234 mempunyai warta dari domain wikipedia.org."
* Akhirnya, pertanyaan beralih kepada server DNS ketiga (207.142.131.234), yang menjawab dengan alamat IP yang dibutuhkan. Proses ini memakai pencarian rekursif (recursion / recursive searching).
Pengertian registrasi domain dan glue records
Membaca contoh diatas, Anda mungkin bertanya: "bagaimana caranya DNS server 204.74.112.1 tahu alamat IP mana yang diberikan untuk domain wikipedia.org?" Pada awal proses, kita mencatat bahwa sebuah DNS recursor mempunyai alamat IP dari para root server yang (kurang-lebih) didata secara explisit (hard coded). Mirip dengan hal tersebut, server nama (name server) yang otoritatif untuk top-level domain mengalami perubahan yang jarang.
Namun, server nama yang memperlihatkan tanggapan otorisatif bagi nama domain yang umum mengalami perubahan yang cukup sering. Sebagai bab dari proses registrasi sebuah nama domain (dan beberapa waktu sesudahnya), pendaftar memperlihatkan registrasi dengan server nama yang akan mengotorisasikan nama domain tersebut; maka ketika mendaftar wikipedia.org, domain tersebut terhubung dengan server nama gunther.bomis.com dan zwinger.wikipedia.org di pendaftar .org. Kemudian, dari contoh di atas, ketika server dikenali sebagai 204.74.112.1 mendapatkan sebuah permintaan, DNS server memindai daftar domain yang ada, mencari wikipedia.org, dan mengembalikan server nama yang terhubung dengan domain tersebut.
Biasanya, server nama muncul menurut urutan nama, selain menurut alamat IP. Hal ini menjadikan string lain dari ajakan DNS untuk menuntaskan nama dari server nama; ketika sebuah alamat IP dari server nama mendapatkan sebuah registrasi di zona induk, para programmer jaringan komputer menamakannya sebuah glue record (daftar lekat???)
DNS dalam praktek
Ketika sebuah aplikasi (misalkan web broswer), hendak mencari alamat IP dari sebuah nama domain, aplikasi tersebut tidak harus mengikuti seluruh langkah yang disebutkan dalam teori diatas. Kita akan melihat dulu konsep caching, kemudian mengertikan operasi DNS di "dunia nyata".
Caching dan masa hidup (caching and time to live)
Karena jumlah ajakan yang besar dari sistem ibarat DNS, perancang DNS menginginkan penyediaan prosedur yang sanggup mengurangi beban dari masing-masing server DNS. Rencana mekanisnya menyarankan bahwa ketika sebuah DNS resolver (klien) mendapatkan sebuah tanggapan DNS, warta tersebut akan di cache untuk jangka waktu tertentu. Sebuah nilai (yang di-set oleh eksekutif dari server DNS yang memperlihatkan jawaban) menyebutnya sebagai time to live (masa hidup), atau TTL yang mendefinisikan periode tersebut. Saat tanggapan masuk ke dalam cache, resolver akan mengacu kepada tanggapan yang disimpan di cache tersebut; hanya ketika TTL usai (atau dikala eksekutif mengosongkan tanggapan dari memori resolver secara manual) maka resolver menghubungi server DNS untuk warta yang sama.
Waktu propagasi (propagation time)Satu akhir penting dari arsitektur tersebar dan cache ialah perubahan kepada suatu DNS tidak selalu efektif secara pribadi dalam skala besar/global. Contoh berikut mungkin akan menjelaskannya: Jika seorang eksekutif telah mengatur TTL selama 6 jam untuk host www.wikipedia.org, kemudian mengganti alamat IP dari www.wikipedia.org pada pk 12:01, eksekutif harus mempertimbangkan bahwa ada (paling tidak) satu individu yang menyimpan cache tanggapan dengan nilai usang pada pk 12:00 yang tidak akan menghubungi server DNS hingga dengan pk 18:00. Periode antara pk 12:00 dan pk 18:00 dalam contoh ini disebut sebagai waktu propagasi (propagation time), yang sanggup didefiniskan sebagai periode waktu yang berawal antara dikala terjadi perubahan dari data DNS, dan berakhir setelah waktu maksimum yang telah ditentukan oleh TTL berlalu. Ini akan mengarahkan kepada pertimbangan logis yang penting ketika menciptakan perubahan kepada DNS: tidak semua akan melihat hal yang sama ibarat yang Anda lihat. RFC1537 sanggup membantu klarifikasi ini.
DNS di dunia nyata
Di dunia nyata, user tidak berhadapan pribadi dengan DNS resolver - mereka berhadapan dengan acara ibarat web brower (Mozilla Firefox, Safari, Opera, Internet Explorer, Netscape, Konqueror dan lain-lain dan klien mail (Outlook Express, Mozilla Thunderbird dan lain-lain). Ketika user melaksanakan acara yang meminta pencarian DNS (umumnya, nyaris semua acara yang memakai Internet), acara tersebut mengirimkan ajakan ke DNS Resolver yang ada di dalam sistem operasi.
DNS resolver akan selalu mempunyai cache (lihat diatas) yang mempunyai isi pencarian terakhir. Jika cache sanggup memperlihatkan tanggapan kepada ajakan DNS, resolver akan memakai nilai yang ada di dalam cache kepada acara yang memerlukan. Kalau cache tidak mempunyai jawabannya, resolver akan mengirimkan ajakan ke server DNS tertentu. Untuk kebanyakan pengguna di rumah, Internet Service Provider(ISP) yang menghubungkan komputer tersebut biasanya akan menyediakan server DNS: pengguna tersebut akan mendata alamat server secara manual atau memakai DHCP untuk melaksanakan pendataan tersebut. Jika eksekutif sistem telah mengkonfigurasi sistem untuk memakai server DNS mereka sendiri, DNS resolver umumnya akan mengacu ke server nama mereka. Server nama ini akan mengikuti proses yang disebutkan di Teori DNS, baik mereka menemukan jawabannya maupun tidak. Hasil pencarian akan diberikan kepada DNS resolver; diasumsikan telah ditemukan jawaban, resolver akan menyimpan kesudahannya di cache untuk penggunaan berikutnya, dan memperlihatkan kesudahannya kepada software yang meminta pencarian DNS tersebut.
Sebagai bab tamat dari kerumitan ini, beberapa aplikasi ibarat web browser juga mempunyai DNS cache mereka sendiri, tujuannya ialah untuk mengurangi penggunaan acuan DNS resolver, yang akan meningkatkan kesulitan untuk melaksanakan debug DNS, yang menjadikan kerancuan data yang lebih akurat. Cache ibarat ini umumnya mempunyai masa yang singkat dalam hitungan 1 menit.
Penerapan DNS lainnya
Sistem yang dijabarkan diatas memperlihatkan skenario yang disederhanakan. DNS mencakup beberapa fungsi lainnya:
* Nama host dan alamat IP tidak berarti terhubung secara satu-banding-satu. Banyak nama host yang diwakili melalui alamat IP tunggal: adonan dengan pengasuhan maya (virtual hosting), hal ini memungkinkan satu komputer untuk malayani beberapa situs web. Selain itu, sebuah nama host sanggup mewakili beberapa alamat IP: ini akan membantu toleransi kesalahan (fault tolerance dan penyebaran beban (load distribution), juga membantu suatu situs berpindah dari satu lokasi fisik ke lokasi fisik lainnya secara mudah.
* Ada cukup banyak kegunaan DNS selain menerjemahkan nama ke alamat IP. Contoh:, distributor pemindahan surat Mail transfer agents(MTA) memakai DNS untuk mencari tujuan pengiriman E-mail untuk alamat tertentu. Domain yang menginformasikan pemetaan exchange disediakan melalui rekod MX (MX record) yang meningkatkan lapisan perhiasan untuk toleransi kesalahan dan penyebaran beban selain dari fungsi pemetaan nama ke alamat IP.
* Kerangka Peraturan Pengiriman (Sender Policy Framework) secara kontroversi memakai laba jenis rekod DNS, dikenal sebagai rekod TXT.
* Menyediakan keluwesan untuk kegagalan komputer, beberapa server DNS memperlihatkan dukungan untuk setiap domain. Tepatnya, tigabelas server akar (root servers) dipakai oleh seluruh dunia. Program DNS maupun sistem operasi mempunyai alamat IP dari seluruh server ini. Amerika Serikat memiliki, secara angka, semua kecuali tiga dari server akar tersebut. Namun, dikarenakan banyak server akar menerapkan anycast, yang memungkinkan beberapa komputer yang berbeda sanggup menyebarkan alamat IP yang sama untuk mengirimkan satu jenis services melalui area geografis yang luas, banyak server yang secara fisik (bukan sekedar angka) terletak di luar Amerika Serikat.
DNS menggunanakn TCP dan UDP di port komputer 53 untuk melayani ajakan DNS. Nyaris semua ajakan DNS berisi ajakan UDP tunggal dari klien yang dikuti oleh tanggapan UDP tunggal dari server. Umumnya TCP ikut terlibat hanya ketika ukuran data tanggapan melebihi 512 byte, atau untuk pertukaaran zona DNS zone transfer
Jenis-jenis catatan DNS
Beberapa kelompok penting dari data yang disimpan di dalam DNS ialah sebagai berikut:
* A record atau catatan alamat memetakan sebuah nama host ke alamat IP 32-bit (untuk IPv4).
* AAAA record atau catatan alamat IPv6 memetakan sebuah nama host ke alamat IP 128-bit (untuk IPv6).
* CNAME record atau catatan nama kanonik menciptakan alias untuk nama domain. Domain yang di-alias-kan mempunyai seluruh subdomain dan rekod DNS ibarat aslinya.
* [MX record]]' atau catatan pertukaran surat memetakan sebuah nama domain ke dalam daftar mail exchange server untuk domain tersebut.
* PTR record atau catatan penunjuk memetakan sebuah nama host ke nama kanonik untuk host tersebut. Pembuatan rekod PTR untuk sebuah nama host di dalam domain in-addr.arpa yang mewakili sebuah alamat IP menerapkan pencarian balik DNS (reverse DNS lookup) untuk alamat tersebut. Contohnya (saat penulisan / penerjemahan artikel ini), www.icann.net mempunyai alamat IP 192.0.34.164, tetapi sebuah rekod PTR memetakan ,,164.34.0.192.in-addr.arpa ke nama kanoniknya: referrals.icann.org.
* NS record atau catatan server nama memetakan sebuah nama domain ke dalam satu daftar dari server DNS untuk domain tersebut. Pewakilan bergantung kepada rekod NS.
* SOA record atau catatan otoritas awal (Start of Authority) mengacu server DNS yang mengediakan otorisasi warta perihal sebuah domain Internet.
* SRV record ialah catatan lokasi secara umum.
* Catatan TXT mengijinkan eksekutif untuk memasukan data acak ke dalam catatan DNS; catatan ini juga dipakai di spesifikasi Sender Policy Framework.
Jenis catatan lainnya semata-mata untuk penyediaan warta (contohnya, catatan LOC memperlihatkan letak lokasi fisik dari sebuah host, atau data ujicoba (misalkan, catatan WKS memperlihatkan sebuah daftar dari server yang memperlihatkan servis yang dikenal (well-known service) ibarat HTTP atau POP3 untuk sebuah domain.
Nama domain yang diinternasionalkan
Nama domain harus memakai satu sub-kumpulan dari huruf ASCII, hal ini mencegah beberapa bahasa untuk memakai nama maupun kata lokal mereka. ICANN telah menyetujui Punycode yang berbasiskan sistem IDNA, yang memetakan string Unicode ke huruf set yang valid untuk DNS, sebagai bentuk penyelesaian untuk persoalan ini, dan beberapa registries sudah mengadopsi metode IDNS ini.
Perangkat lunak DNS
Beberapa jenis perangakat lunak DNS menerapkan metode DNS, beberapa diantaranya:
* BIND (Berkeley Internet Name Domain)
* djbdns (Daniel J. Bernstein's DNS)
* MaraDNS
* QIP (Lucent Technologies)
* NSD (Name Server Daemon)
* PowerDNS
* Microsoft DNS (untuk edisi server dari Windows 2000 dan Windows 2003)
Utiliti berorientasi DNS termasuk:
* dig (the domain information groper)
Pengguna legal dari domain
Tidak satupun individu di dunia yang "memiliki" nama domain kecuali Network Information Centre (NIC), atau pendaftar nama domain (domain name registry). Sebagian besar dari NIC di dunia mendapatkan biaya tahunan dari para pengguna legal dengan tujuan bagi si pengguna legal memakai nama domain tersebut. Makara sejenis perjanjian sewa-menyewa terjadi, bergantung kepada syarat dan ketentuan pendaftar. Bergantung kepada beberpa peraturan penamaan dari para pendaftar, pengguna legal dikenal sebagai "pendaftar" (registrants) atau sebagai "pemegang domain" (domain holders)
ICANN memegang daftar lengkap untuk pendaftar domain di seluruh dunia. Siapapun sanggup menemukan pengguna legal dari sebuah domain dengan mencari melalui basis data WHOIS yang disimpan oleh beberpa pendaftar domain.
Di (lebih kurang) 240 country code top-level domains (ccTLDs), pendaftar domain memegang sebuah contoh WHOIS (pendaftar dan nama server). Contohnya, IDNIC, NIC Indonesia, memegang warta otorisatif WHOIS untuk nama domain .ID.
Namun, beberapa pendaftar domain, ibarat VeriSign, memakai model pendaftar-pengguna. Untuk nama domain .COM dan .NET, pendaftar domain, VeriSign memegang warta dasar WHOIS )pemegang domain dan server nama). Siapapun sanggup mencari detil WHOIS (Pemegang domain, server nama, tanggal berlaku, dan lain sebagainya) melalui pendaftar.
Sejak sekitar 2001, kebanyakan pendaftar gTLD (.ORG, .BIZ, .INFO) telah mengadopsi metode penfatar "tebal", menyimpan otoritatif WHOIS di beberapa pendaftar dan bukan pendaftar itu saja.
Itu lah klarifikasi perihal Domain Name System jadi sebelum kita berguru konfigurasi perihal DNS ada baiknya kita mengetahui teorinya dulu setelah ini kita akan lanjut ke konfigurasi DNS memakai bind pada debian 5.