assalamu'alaikum wr.wb
sudah lama tidak menulis di blog ini..
bingung mo nulis apa ,jadinya ya nulis ini..;)
mungkin lain waktu sya sempatkan untuk lebih banyak mengurus
blog ini lagi, Insya Allah..
sekian terima kasih..
wassalaamu'alaikum wr.wb
Sabtu, 27 Maret 2010
Sabtu, 07 November 2009
Selasa, 29 September 2009
Transmission Control Protocol/Internet Protocol
Dari Wikipedia bahasa Indonesia, ensiklopedia bebas
Langsung ke: navigasi, cari
TCP/IP (singkatan dari Transmission Control Protocol/Internet Protocol) adalah standar komunikasi data yang digunakan oleh komunitas internet dalam proses tukar-menukar data dari satu komputer ke komputer lain di dalam jaringan Internet. Protokol ini tidaklah dapat berdiri sendiri, karena memang protokol ini berupa kumpulan protokol (protocol suite). Protokol ini juga merupakan protokol yang paling banyak digunakan saat ini. Data tersebut diimplementasikan dalam bentuk perangkat lunak (software) di sistem operasi. Istilah yang diberikan kepada perangkat lunak ini adalah TCP/IP stack
Protokol TCP/IP dikembangkan pada akhir dekade 1970-an hingga awal 1980-an sebagai sebuah protokol standar untuk menghubungkan komputer-komputer dan jaringan untuk membentuk sebuah jaringan yang luas (WAN). TCP/IP merupakan sebuah standar jaringan terbuka yang bersifat independen terhadap mekanisme transport jaringan fisik yang digunakan, sehingga dapat digunakan di mana saja. Protokol ini menggunakan skema pengalamatan yang sederhana yang disebut sebagai alamat IP (IP Address) yang mengizinkan hingga beberapa ratus juta komputer untuk dapat saling berhubungan satu sama lainnya di Internet. Protokol ini juga bersifat routable yang berarti protokol ini cocok untuk menghubungkan sistem-sistem berbeda (seperti Microsoft Windows dan keluarga UNIX) untuk membentuk jaringan yang heterogen.
Protokol TCP/IP selalu berevolusi seiring dengan waktu, mengingat semakin banyaknya kebutuhan terhadap jaringan komputer dan Internet. Pengembangan ini dilakukan oleh beberapa badan, seperti halnya Internet Society (ISOC), Internet Architecture Board (IAB), dan Internet Engineering Task Force (IETF). Macam-macam protokol yang berjalan di atas TCP/IP, skema pengalamatan, dan konsep TCP/IP didefinisikan dalam dokumen yang disebut sebagai Request for Comments (RFC) yang dikeluarkan oleh IETF.
Daftar isi
[sembunyikan]
1 Arsitektur
2 Pengalamatan
3 Konsep dasar
3.1 Layanan
3.2 Request for Comments
3.3 Bagaimanakah bentuk arsitektur dari TCP/IP itu ?
4 Lihat pula
[sunting] Arsitektur
Arsitektur TCP/IP diperbandingkan dengan DARPA Reference Model dan OSI Reference Model
Arsitektur TCP/IP tidaklah berbasis model referensi tujuh lapis OSI, tetapi menggunakan model referensi DARPA. Seperti diperlihatkan dalam diagram, TCP/IP merngimplemenasikan arsitektur berlapis yang terdiri atas empat lapis. Empat lapis ini, dapat dipetakan (meski tidak secara langsung) terhadap model referensi OSI. Empat lapis ini, kadang-kadang disebut sebagai DARPA Model, Internet Model, atau DoD Model, mengingat TCP/IP merupakan protokol yang awalnya dikembangkan dari proyek ARPANET yang dimulai oleh Departemen Pertahanan Amerika Serikat.
Setiap lapisan yang dimiliki oleh kumpulan protokol (protocol suite) TCP/IP diasosiasikan dengan protokolnya masing-masing. Protokol utama dalam protokol TCP/IP adalah sebagai berikut:
Protokol lapisan aplikasi: bertanggung jawab untuk menyediakan akses kepada aplikasi terhadap layanan jaringan TCP/IP. Protokol ini mencakup protokol Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Telnet, Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP), dan masih banyak protokol lainnya. Dalam beberapa implementasi stack protokol, seperti halnya Microsoft TCP/IP, protokol-protokol lapisan aplikasi berinteraksi dengan menggunakan antarmuka Windows Sockets (Winsock) atau NetBIOS over TCP/IP (NetBT).
Protokol lapisan antar-host: berguna untuk membuat komunikasi menggunakan sesi koneksi yang bersifat connection-oriented atau broadcast yang bersifat connectionless. Protokol dalam lapisan ini adalah Transmission Control Protocol (TCP) dan User Datagram Protocol (UDP).
Protokol lapisan internetwork: bertanggung jawab untuk melakukan pemetaan (routing) dan enkapsulasi paket-paket data jaringan menjadi paket-paket IP. Protokol yang bekerja dalam lapisan ini adalah Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), dan Internet Group Management Protocol (IGMP).
Protokol lapisan antarmuka jaringan: bertanggung jawab untuk meletakkan frame-frame jaringan di atas media jaringan yang digunakan. TCP/IP dapat bekerja dengan banyak teknologi transport, mulai dari teknologi transport dalam LAN (seperti halnya Ethernet dan Token Ring), MAN dan WAN (seperti halnya dial-up modem yang berjalan di atas Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), serta Asynchronous Transfer Mode (ATM)).
[sunting] Pengalamatan
Protokol TCP/IP menggunakan dua buah skema pengalamatan yang dapat digunakan untuk mengidentifikasikan sebuah komputer dalam sebuah jaringan atau jaringan dalam sebuah internetwork, yakni sebagai berikut:
Pengalamatan IP: yang berupa alamat logis yang terdiri atas 32-bit (empat oktet berukuran 8-bit) yang umumnya ditulis dalam format www.xxx.yyy.zzz. Dengan menggunakan subnet mask yang diasosiasikan dengannya, sebuah alamat IP pun dapat dibagi menjadi dua bagian, yakni Network Identifier (NetID) yang dapat mengidentifikasikan jaringan lokal dalam sebuah internetwork dan Host identifier (HostID) yang dapat mengidentifikasikan host dalam jaringan tersebut. Sebagai contoh, alamat 205.116.008.044 dapat dibagi dengan menggunakan subnet mask 255.255.255.000 ke dalam Network ID 205.116.008.000 dan Host ID 44. Alamat IP merupakan kewajiban yang harus ditetapkan untuk sebuah host, yang dapat dilakukan secara manual (statis) atau menggunakan Dynamic Host Configuration Protocol (DHCP) (dinamis).
Fully qualified domain name (FQDN): Alamat ini merupakan alamat yang direpresentasikan dalam nama alfanumerik yang diekspresikan dalam bentuk., di mana mengindentifikasikan jaringan di mana sebuah komputer berada, dan mengidentifikasikan sebuah komputer dalam jaringan. Pengalamatan FQDN digunakan oleh skema penamaan domain Domain Name System (DNS). Sebagai contoh, alamat FQDN id.wikipedia.org merepresentasikan sebuah host dengan nama "id" yang terdapat di dalam domain jaringan "wikipedia.org". Nama domain wikipedia.org merupakan second-level domain yang terdaftar di dalam top-level domain .org, yang terdaftar dalam root DNS, yang memiliki nama "." (titik). Penggunaan FQDN lebih bersahabat dan lebih mudah diingat ketimbang dengan menggunakan alamat IP. Akan tetapi, dalam TCP/IP, agar komunikasi dapat berjalan, FQDN harus diterjemahkan terlebih dahulu (proses penerjemahan ini disebut sebagai resolusi nama) ke dalam alamat IP dengan menggunakan server yang menjalankan DNS, yang disebut dengan Name Server atau dengan menggunakan berkas hosts (/etc/hosts atau %systemroot%\system32\drivers\etc\hosts) yang disimpan di dalam mesin yang bersangkutan.
[sunting] Konsep dasar
Artikel ini perlu dirapikan agar memenuhi standar Wikipedia
Merapikan artikel bisa berupa membagi artikel ke dalam paragraf atau wikifikasi artikel. Setelah dirapikan, tolong hapus pesan ini.
[sunting] Layanan
Berikut ini adalah layanan tradisional yang dapat berjalan di atas protokol TCP/IP:
Pengiriman berkas (file transfer). File Transfer Protocol (FTP) memungkinkan pengguna komputer yang satu untuk dapat mengirim ataupun menerima berkas ke sebuah host di dalam jaringan. Metode otentikasi yang digunakannya adalah penggunaan nama pengguna (user name) dan [[password]], meskipun banyak juga FTP yang dapat diakses secara anonim (anonymous), alias tidak berpassword. (Keterangan lebih lanjut mengenai FTP dapat dilihat pada RFC 959.)
Remote login. Network terminal Protocol (telnet) memungkinkan pengguna komputer dapat melakukan log in ke dalam suatu komputer di dalam suatu jaringan secara jarak jauh. Jadi hal ini berarti bahwa pengguna menggunakan komputernya sebagai perpanjangan tangan dari komputer jaringan tersebut. (Keterangan lebih lanjut mengenai Telnet dapat dilihat pada RFC 854 dan RFC 855.)
Computer mail. Digunakan untuk menerapkan sistem surat elektronik. (Keterangan lebih lanjut mengenai e-mail dapat dilihat pada RFC 821 RFC 822.)
Network File System (NFS). Pelayanan akses berkas-berkas yang dapat diakses dari jarak jauh yang memungkinkan klien-klien untuk mengakses berkas pada komputer jaringan, seolah-olah berkas tersebut disimpan secara lokal. (Keterangan lebih lanjut mengenai NFS dapat dilihat RFC 1001 dan RFC 1002.)
Remote execution. Memungkinkan pengguna komputer untuk menjalankan suatu program tertentu di dalam komputer yang berbeda. Biasanya berguna jika pengguna menggunakan komputer yang terbatas, sedangkan ia memerlukan sumber yg banyak dalam suatu sistem komputer.
Ada beberapa jenis remote execution, ada yang berupa perintah-perintah dasar saja, yaitu yang dapat dijalankan dalam system komputer yang sama dan ada pula yg menggunakan sistem Remote Procedure Call (RPC), yang memungkinkan program untuk memanggil subrutin yang akan dijalankan di sistem komputer yg berbeda. (sebagai contoh dalam Berkeley UNIX ada perintah rsh dan rexec.)
Name server yang berguna sebagai penyimpanan basis data nama host yang digunakan pada Internet (Keterangan lebih lanjut dapat dilihat pada RFC 822 dan RFC 823 yang menjelaskan mengenai penggunaan protokol name server yang bertujuan untuk menentukan nama host di Internet.)
[sunting] Request for Comments
RFC (Request For Comments) merupakan standar yang digunakan dalam Internet, meskipun ada juga isinya yg merupakan bahan diskusi ataupun omong kosong belaka. Diterbitkan oleh IAB yang merupakan komite independen yang terdiri atas para peneliti dan profesional yang mengerti teknis, kondisi dan evolusi Internet. Sebuah surat yg mengikuti nomor RFC menunjukan status RFC :
S: Standard, standar resmi bagi internet
DS: Draft standard, protokol tahap akhir sebelum disetujui sebagai standar
PS: Proposed Standard, protokol pertimbangan untuk standar masa depan
I: Informational, berisikan bahan-bahan diskusi yg sifatnya informasi
E: Experimental, protokol dalam tahap percobaan tetapi bukan pada jalur standar.
H: Historic, protokol-protokol yg telah digantikan atau tidak lagi dipertimbankan utk standarisasi.
[sunting] Bagaimanakah bentuk arsitektur dari TCP/IP itu ?
Dikarenakan TCP/IP adalah serangkaian protokol di mana setiap protokol melakukan sebagian dari keseluruhan tugas komunikasi jaringan, maka tentulah implementasinya tak lepas dari arsitektur jaringan itu sendiri. Arsitektur rangkaian protokol TCP/IP mendifinisikan berbagai cara agar TCP/IP dapat saling menyesuaikan.
Karena TCP/IP merupakan salah satu lapisan protokol Model OSI, berarti bahwa hierarki TCP/IP merujuk kepada 7 lapisan OSI tersebut. Tiga lapisan teratas biasa dikenal sebagai "upper level protocol" sedangkan empat lapisan terbawah dikenal sebagai "lower level protocol". Tiap lapisan berdiri sendiri tetapi fungsi dari masing-masing lapisan bergantung dari keberhasilan operasi layer sebelumnya. Sebuah lapisan pengirim hanya perlu berhubungan dengan lapisan yang sama di penerima (jadi misalnya lapisan data link penerima hanya berhubungan dengan lapisan data link pengirim) selain dengan satu layer di atas atau di bawahnya (misalnya lapisan network berhubungan dengan lapisan transport di atasnya atau dengan lapisan data link di bawahnya).
Model dengan menggunakan lapisan ini merupakan sebuah konsep yang penting karena suatu fungsi yang rumit yang berkaitan dengan komunikasi dapat dipecahkan menjadi sejumlah unit yang lebih kecil. Tiap lapisan bertugas memberikan layanan tertentu pada lapisan diatasnya dan juga melindungi lapisan diatasnya dari rincian cara pemberian layanan tersebut. Tiap lapisan harus transparan sehingga modifikasi yang dilakukan atasnya tidak akan menyebabkan perubahan pada lapisan yang lain. Lapisan menjalankan perannya dalam pengalihan data dengan mengikuti peraturan yang berlaku untuknya dan hanya berkomunikasi dengan lapisan yang setingkat. Akibatnya sebuah layer pada satu sistem tertentu hanya akan berhubungan dengan lapisan yang sama dari sistem yang lain. Proses ini dikenal sebagai Peer process. Dalam keadaan sebenarnya tidak ada data yang langsung dialihkan antar lapisan yang sama dari dua sistem yang berbeda ini. Lapisan atas akan memberikan data dan kendali ke lapisan dibawahnya sampai lapisan yang terendah dicapai. Antara dua lapisan yang berdekatan terdapat interface (antarmuka). Interface ini mendifinisikan operasi dan layanan yang diberikan olehnya ke lapisan lebih atas. Tiap lapisan harus melaksanakan sekumpulan fungsi khusus yang dipahami dengan sempurna. Himpunan lapisan dan protokol dikenal sebagai "arsitektur jaringan".
Dari Wikipedia bahasa Indonesia, ensiklopedia bebas
Langsung ke: navigasi, cari
TCP/IP (singkatan dari Transmission Control Protocol/Internet Protocol) adalah standar komunikasi data yang digunakan oleh komunitas internet dalam proses tukar-menukar data dari satu komputer ke komputer lain di dalam jaringan Internet. Protokol ini tidaklah dapat berdiri sendiri, karena memang protokol ini berupa kumpulan protokol (protocol suite). Protokol ini juga merupakan protokol yang paling banyak digunakan saat ini. Data tersebut diimplementasikan dalam bentuk perangkat lunak (software) di sistem operasi. Istilah yang diberikan kepada perangkat lunak ini adalah TCP/IP stack
Protokol TCP/IP dikembangkan pada akhir dekade 1970-an hingga awal 1980-an sebagai sebuah protokol standar untuk menghubungkan komputer-komputer dan jaringan untuk membentuk sebuah jaringan yang luas (WAN). TCP/IP merupakan sebuah standar jaringan terbuka yang bersifat independen terhadap mekanisme transport jaringan fisik yang digunakan, sehingga dapat digunakan di mana saja. Protokol ini menggunakan skema pengalamatan yang sederhana yang disebut sebagai alamat IP (IP Address) yang mengizinkan hingga beberapa ratus juta komputer untuk dapat saling berhubungan satu sama lainnya di Internet. Protokol ini juga bersifat routable yang berarti protokol ini cocok untuk menghubungkan sistem-sistem berbeda (seperti Microsoft Windows dan keluarga UNIX) untuk membentuk jaringan yang heterogen.
Protokol TCP/IP selalu berevolusi seiring dengan waktu, mengingat semakin banyaknya kebutuhan terhadap jaringan komputer dan Internet. Pengembangan ini dilakukan oleh beberapa badan, seperti halnya Internet Society (ISOC), Internet Architecture Board (IAB), dan Internet Engineering Task Force (IETF). Macam-macam protokol yang berjalan di atas TCP/IP, skema pengalamatan, dan konsep TCP/IP didefinisikan dalam dokumen yang disebut sebagai Request for Comments (RFC) yang dikeluarkan oleh IETF.
Daftar isi
[sembunyikan]
1 Arsitektur
2 Pengalamatan
3 Konsep dasar
3.1 Layanan
3.2 Request for Comments
3.3 Bagaimanakah bentuk arsitektur dari TCP/IP itu ?
4 Lihat pula
[sunting] Arsitektur
Arsitektur TCP/IP diperbandingkan dengan DARPA Reference Model dan OSI Reference Model
Arsitektur TCP/IP tidaklah berbasis model referensi tujuh lapis OSI, tetapi menggunakan model referensi DARPA. Seperti diperlihatkan dalam diagram, TCP/IP merngimplemenasikan arsitektur berlapis yang terdiri atas empat lapis. Empat lapis ini, dapat dipetakan (meski tidak secara langsung) terhadap model referensi OSI. Empat lapis ini, kadang-kadang disebut sebagai DARPA Model, Internet Model, atau DoD Model, mengingat TCP/IP merupakan protokol yang awalnya dikembangkan dari proyek ARPANET yang dimulai oleh Departemen Pertahanan Amerika Serikat.
Setiap lapisan yang dimiliki oleh kumpulan protokol (protocol suite) TCP/IP diasosiasikan dengan protokolnya masing-masing. Protokol utama dalam protokol TCP/IP adalah sebagai berikut:
Protokol lapisan aplikasi: bertanggung jawab untuk menyediakan akses kepada aplikasi terhadap layanan jaringan TCP/IP. Protokol ini mencakup protokol Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Telnet, Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP), dan masih banyak protokol lainnya. Dalam beberapa implementasi stack protokol, seperti halnya Microsoft TCP/IP, protokol-protokol lapisan aplikasi berinteraksi dengan menggunakan antarmuka Windows Sockets (Winsock) atau NetBIOS over TCP/IP (NetBT).
Protokol lapisan antar-host: berguna untuk membuat komunikasi menggunakan sesi koneksi yang bersifat connection-oriented atau broadcast yang bersifat connectionless. Protokol dalam lapisan ini adalah Transmission Control Protocol (TCP) dan User Datagram Protocol (UDP).
Protokol lapisan internetwork: bertanggung jawab untuk melakukan pemetaan (routing) dan enkapsulasi paket-paket data jaringan menjadi paket-paket IP. Protokol yang bekerja dalam lapisan ini adalah Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), dan Internet Group Management Protocol (IGMP).
Protokol lapisan antarmuka jaringan: bertanggung jawab untuk meletakkan frame-frame jaringan di atas media jaringan yang digunakan. TCP/IP dapat bekerja dengan banyak teknologi transport, mulai dari teknologi transport dalam LAN (seperti halnya Ethernet dan Token Ring), MAN dan WAN (seperti halnya dial-up modem yang berjalan di atas Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), serta Asynchronous Transfer Mode (ATM)).
[sunting] Pengalamatan
Protokol TCP/IP menggunakan dua buah skema pengalamatan yang dapat digunakan untuk mengidentifikasikan sebuah komputer dalam sebuah jaringan atau jaringan dalam sebuah internetwork, yakni sebagai berikut:
Pengalamatan IP: yang berupa alamat logis yang terdiri atas 32-bit (empat oktet berukuran 8-bit) yang umumnya ditulis dalam format www.xxx.yyy.zzz. Dengan menggunakan subnet mask yang diasosiasikan dengannya, sebuah alamat IP pun dapat dibagi menjadi dua bagian, yakni Network Identifier (NetID) yang dapat mengidentifikasikan jaringan lokal dalam sebuah internetwork dan Host identifier (HostID) yang dapat mengidentifikasikan host dalam jaringan tersebut. Sebagai contoh, alamat 205.116.008.044 dapat dibagi dengan menggunakan subnet mask 255.255.255.000 ke dalam Network ID 205.116.008.000 dan Host ID 44. Alamat IP merupakan kewajiban yang harus ditetapkan untuk sebuah host, yang dapat dilakukan secara manual (statis) atau menggunakan Dynamic Host Configuration Protocol (DHCP) (dinamis).
Fully qualified domain name (FQDN): Alamat ini merupakan alamat yang direpresentasikan dalam nama alfanumerik yang diekspresikan dalam bentuk
[sunting] Konsep dasar
Artikel ini perlu dirapikan agar memenuhi standar Wikipedia
Merapikan artikel bisa berupa membagi artikel ke dalam paragraf atau wikifikasi artikel. Setelah dirapikan, tolong hapus pesan ini.
[sunting] Layanan
Berikut ini adalah layanan tradisional yang dapat berjalan di atas protokol TCP/IP:
Pengiriman berkas (file transfer). File Transfer Protocol (FTP) memungkinkan pengguna komputer yang satu untuk dapat mengirim ataupun menerima berkas ke sebuah host di dalam jaringan. Metode otentikasi yang digunakannya adalah penggunaan nama pengguna (user name) dan [[password]], meskipun banyak juga FTP yang dapat diakses secara anonim (anonymous), alias tidak berpassword. (Keterangan lebih lanjut mengenai FTP dapat dilihat pada RFC 959.)
Remote login. Network terminal Protocol (telnet) memungkinkan pengguna komputer dapat melakukan log in ke dalam suatu komputer di dalam suatu jaringan secara jarak jauh. Jadi hal ini berarti bahwa pengguna menggunakan komputernya sebagai perpanjangan tangan dari komputer jaringan tersebut. (Keterangan lebih lanjut mengenai Telnet dapat dilihat pada RFC 854 dan RFC 855.)
Computer mail. Digunakan untuk menerapkan sistem surat elektronik. (Keterangan lebih lanjut mengenai e-mail dapat dilihat pada RFC 821 RFC 822.)
Network File System (NFS). Pelayanan akses berkas-berkas yang dapat diakses dari jarak jauh yang memungkinkan klien-klien untuk mengakses berkas pada komputer jaringan, seolah-olah berkas tersebut disimpan secara lokal. (Keterangan lebih lanjut mengenai NFS dapat dilihat RFC 1001 dan RFC 1002.)
Remote execution. Memungkinkan pengguna komputer untuk menjalankan suatu program tertentu di dalam komputer yang berbeda. Biasanya berguna jika pengguna menggunakan komputer yang terbatas, sedangkan ia memerlukan sumber yg banyak dalam suatu sistem komputer.
Ada beberapa jenis remote execution, ada yang berupa perintah-perintah dasar saja, yaitu yang dapat dijalankan dalam system komputer yang sama dan ada pula yg menggunakan sistem Remote Procedure Call (RPC), yang memungkinkan program untuk memanggil subrutin yang akan dijalankan di sistem komputer yg berbeda. (sebagai contoh dalam Berkeley UNIX ada perintah rsh dan rexec.)
Name server yang berguna sebagai penyimpanan basis data nama host yang digunakan pada Internet (Keterangan lebih lanjut dapat dilihat pada RFC 822 dan RFC 823 yang menjelaskan mengenai penggunaan protokol name server yang bertujuan untuk menentukan nama host di Internet.)
[sunting] Request for Comments
RFC (Request For Comments) merupakan standar yang digunakan dalam Internet, meskipun ada juga isinya yg merupakan bahan diskusi ataupun omong kosong belaka. Diterbitkan oleh IAB yang merupakan komite independen yang terdiri atas para peneliti dan profesional yang mengerti teknis, kondisi dan evolusi Internet. Sebuah surat yg mengikuti nomor RFC menunjukan status RFC :
S: Standard, standar resmi bagi internet
DS: Draft standard, protokol tahap akhir sebelum disetujui sebagai standar
PS: Proposed Standard, protokol pertimbangan untuk standar masa depan
I: Informational, berisikan bahan-bahan diskusi yg sifatnya informasi
E: Experimental, protokol dalam tahap percobaan tetapi bukan pada jalur standar.
H: Historic, protokol-protokol yg telah digantikan atau tidak lagi dipertimbankan utk standarisasi.
[sunting] Bagaimanakah bentuk arsitektur dari TCP/IP itu ?
Dikarenakan TCP/IP adalah serangkaian protokol di mana setiap protokol melakukan sebagian dari keseluruhan tugas komunikasi jaringan, maka tentulah implementasinya tak lepas dari arsitektur jaringan itu sendiri. Arsitektur rangkaian protokol TCP/IP mendifinisikan berbagai cara agar TCP/IP dapat saling menyesuaikan.
Karena TCP/IP merupakan salah satu lapisan protokol Model OSI, berarti bahwa hierarki TCP/IP merujuk kepada 7 lapisan OSI tersebut. Tiga lapisan teratas biasa dikenal sebagai "upper level protocol" sedangkan empat lapisan terbawah dikenal sebagai "lower level protocol". Tiap lapisan berdiri sendiri tetapi fungsi dari masing-masing lapisan bergantung dari keberhasilan operasi layer sebelumnya. Sebuah lapisan pengirim hanya perlu berhubungan dengan lapisan yang sama di penerima (jadi misalnya lapisan data link penerima hanya berhubungan dengan lapisan data link pengirim) selain dengan satu layer di atas atau di bawahnya (misalnya lapisan network berhubungan dengan lapisan transport di atasnya atau dengan lapisan data link di bawahnya).
Model dengan menggunakan lapisan ini merupakan sebuah konsep yang penting karena suatu fungsi yang rumit yang berkaitan dengan komunikasi dapat dipecahkan menjadi sejumlah unit yang lebih kecil. Tiap lapisan bertugas memberikan layanan tertentu pada lapisan diatasnya dan juga melindungi lapisan diatasnya dari rincian cara pemberian layanan tersebut. Tiap lapisan harus transparan sehingga modifikasi yang dilakukan atasnya tidak akan menyebabkan perubahan pada lapisan yang lain. Lapisan menjalankan perannya dalam pengalihan data dengan mengikuti peraturan yang berlaku untuknya dan hanya berkomunikasi dengan lapisan yang setingkat. Akibatnya sebuah layer pada satu sistem tertentu hanya akan berhubungan dengan lapisan yang sama dari sistem yang lain. Proses ini dikenal sebagai Peer process. Dalam keadaan sebenarnya tidak ada data yang langsung dialihkan antar lapisan yang sama dari dua sistem yang berbeda ini. Lapisan atas akan memberikan data dan kendali ke lapisan dibawahnya sampai lapisan yang terendah dicapai. Antara dua lapisan yang berdekatan terdapat interface (antarmuka). Interface ini mendifinisikan operasi dan layanan yang diberikan olehnya ke lapisan lebih atas. Tiap lapisan harus melaksanakan sekumpulan fungsi khusus yang dipahami dengan sempurna. Himpunan lapisan dan protokol dikenal sebagai "arsitektur jaringan".
Perangkat Keras Akses Internet
Modem
Modem adalah singkatan dari modulator-demodulator yaitu alat yang digunakan untuk menghantar dan menerima data dari sebuah PC ke PC lainnya melalui kabel telephone. Modem adalah alat yang bertugas untuk menukar data dari bentuk digital ke analog dan sebaliknya. Dengan adanya modem pengguna PC dapat terkoneksi dengan dunia internet.. Modulator merupakan bagian yang mengubah sinyal informasi kedalam sinyal pembawa (Carrier) dan siap untuk dikirimkan, sedangkan Demodulator adalah bagian yang memisahkan sinyal informasi (yang berisi data atau pesan) dari sinyal pembawa (carrier) yang diterima sehingga informasi tersebut dapat diterima dengan baik. Modem merupakan penggabungan kedua-duanya, artinya modem adalah alat komunikasi dua arah. Setiap perangkat komunikasi jarak jauh dua-arah umumnya menggunakan bagian yang disebut "modem", seperti VSAT, Microwave Radio, dan lain sebagainya, namun umumnya istilah modem lebih dikenal sebagai Perangkat keras yang sering digunakan untuk komunikasi pada komputer.
Data dari komputer yang berbentuk sinyal digital diberikan kepada modem untuk diubah menjadi sinyal analog. Sinyal analog tersebut dapat dikirimkan melalui beberapa media telekomunikasi seperti telepon dan radio.
Setibanya di modem tujuan, sinyal analog tersebut diubah menjadi sinyal digital kembali dan dikirimkan kepada komputer. Terdapat dua jenis modem secara fisiknya, yaitu modem eksternal dan modem internal.
Jenis modem
Modem terbagi atas:
1. Modem analog
2. Modem ADSL
3. Modem kabel
4. Modem CDMA
5. Modem 3GP
6. Modem GSM
Webcam
Webcam (singkatan dari web camera) adalah sebutan bagi kamera real-time (bermakna keadaan pada saat ini juga) yang gambarnya bisa diakses atau dilihat melalui World Wide Web, program instant messaging, atau aplikasi video call. Istilah "webcam" juga merujuk kepada jenis kamera yang digunakan untuk keperluan ini.
Webcam biasanya berresolusi sebesar 352x288 / 640x480 piksel. Namun ada yang kualitasnya hingga 1 Megapiksel.
Sekarang hampir semua kamera digital dan HP bisa dijadikan sebagai kamera web (webcam).Banyak manfaat menggunakan webcam yaitu di antaranya kita dapat langsung bertatap muka dengan lawan bicara kita di komputer yang berbeda,dan kita juga bissa mengetahui aktivitas lawan bicara kita itu di komputer pada saat itu juga.
Headset
Headset adalah gabungan headphone dan mikrofon. Ini dipergunakan untuk berkomunikasi melalui perangkat komunikasi atau komputer misalnya dengan VoIP. Teknologi headset juga sudah merambah dunia komunikasi, khususnya teknologi telpon selular. Headset diciptakan pertama kali pada tahun 1910 oleh Nathaniel Baldwin, mahasiswa Universitas Stanford. Namun penemuannya ini tidak langsung menjadi perhatian, karena layaknya penemu-penemu zaman itu, Baldwin tidak berminat untuk memproduksi temuannya secara massal. Pada Perang Dunia I, angkatan laut Amerika mengetahui penemuan Baldwin dan memesan 100 headset untuk keperluan perang. Semenjak itulah masyarakat mulai sadar dengan teknologi ini, bahkan pada 1961 headset masuk ke kokpit pesawat, pilot menyukainya karena headset ringan dan nyaman dipakai. Headset pertama kali digunakan untuk pesawat telpon adalah pada tahun 1970. Pada awal 2000, bersamaan dengan meledaknya telpon selular, headset nirkabel berbasis teknologi Bluetooth mulai popular.
Headset untuk mengakses internet digunakan untuk chating. Penggunanya yang terkoneksi ke Internet dapat melakukan pembicaraan dengan headset mikrofon dan speaker (atau sebuah headset) ke pengguna lainnya yang tergabung dalam jaringan tersebut.
Pembicaraan dapat dilakukan secara real-time tanpa terputus-putus serta suara yang didapat terasa “tebal” dan jernih. Terlebih lagi bila melakukan pembicaraan konferensi multi-partit, dengan headset saya dapat melakukannya sambil mengemil makanan dan minuman. Semuanya hanya dengan pulsa Internet lokal! Bayangkan besarnya biaya yang harus dikeluarkan jika menggunakan jalur telepon milik Telkom.
Sayangnya, teknologi ini baru bisa dimanfaatkan untuk komunikasi antarpengguna PC. Untuk menghubungi telepon biasa sepertinya sedang dalam tahap pengembangan dan saya duga nantinya fitur ini tidak gratis. Jika nantinya biaya yang kita keluarkan untuk fitur ini ternyata lebih murah dari tarif Telkom, tentu saja tidak ada alasan untuk tidak memanfaatkannya.
DNS (Domain Name System, bahasa Indonesia: Sistem Penamaan Domain) adalah sebuah sistem yang menyimpan informasi tentang 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 menerima 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 tugas seperti pengalamatan dan penjaluran (routing), manusia pada umumnya lebih memilih untuk menggunakan nama host dan nama domain, contohnya adalah 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 manusia mengalahkan TCP/IP, dan kembali ke zaman ARPAnet. Dahulu, setiap komputer di jaringan komputer menggunakan 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, dapat melihat Hosts file untuk menyamakan sebuah nama host menjadi sebuah alamat IP sebelum melakukan pencarian via DNS). Namun, sistem tersebut diatas mewarisi beberapa keterbatasan yang mencolok dari sisi prasyarat, setiap saat sebuah alamat komputer berubah, setiap sistem yang hendak berhubungan dengan komputer tersebut harus melakukan update terhadap file Hosts.
Dengan berkembangnya jaringan komputer, membutuhkan sistem yang bisa dikembangkan: sebuah sistem yang bisa 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 asli muncul di RFC 882 dan 883. Tahun 1987, penerbitan RFC 1034 dan RFC 1035 membuat update terhadap spesifikasi DNS. Hal ini membuat RFC 882 dan RFC 883 tidak berlaku lagi. Beberapa RFC terkini telah memproposikan beberapa tambahan dari protokol inti DNS.
[sunting] Teori bekerja DNS
[sunting] Para Pemain Inti
Pengelola dari sistem DNS terdiri dari tiga komponen:
DNS resolver, sebuah program klien yang berjalan di komputer pengguna, yang membuat permintaan DNS dari program aplikasi.
recursive DNS server, yang melakukan pencarian melalui DNS sebagai tanggapan permintaan dari resolver, dan mengembalikan jawaban kepada para resolver tersebut;
dan ...
authoritative DNS server yang memberikan jawaban terhadap permintaan dari recursor, baik dalam bentuk sebuah jawaban, maupun dalam bentuk delegasi (misalkan: mereferensikan ke authoritative DNS server lainnya)
[sunting] Pengertian beberapa bagian dari nama domain
Sebuah nama domain biasanya terdiri dari dua bagian 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 memiliki 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 dapat membentuk subdomain dari domain wikipedia.org (pada prakteknya, id.wikipedia.org sesungguhnya mewakili sebuah nama host - lihat dibawah). Secara teori, pembagian seperti ini dapat mencapai kedalaman 127 level, dan setiap label dapat terbentuk sampai dengan 63 karakter, selama total nama domain tidak melebihi panjang 255 karakter. Tetapi secara praktek, beberapa pendaftar nama domain (domain name registry) memiliki batas yang lebih sedikit.
Terakhir, bagian paling kiri dari bagian nama domain (biasanya) menyatakan nama host. Sisa dari nama domain menyatakan cara untuk membangun jalur logis untuk informasi yang dibutuhkan; nama host adalah tujuan sebenarnya dari nama sistem yang dicari alamat IP-nya. Contoh: nama domain www.wikipedia.org memiliki nama host "www".
DNS memiliki kumpulan hirarki dari DNS servers. Setiap domain atau subdomain memiliki satu atau lebih authoritative DNS Servers (server DNS otorisatif) yang mempublikasikan informas tentang 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).
[sunting] Sebuah contoh dari teori rekursif DNS
Sebuah contoh mungkin dapat 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 dapat menemukan root nameserver; administrator dari recursive DNS server secara manual mengatur (dan melakukan 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 memiliki informasi tentang domain org."
Recursor DNS lokal kemudian bertanya kepada server DNS (yaitu: 204.74.112.1) pertanyaan yang sama seperti yang diberikan kepada root server. "apa alamat IP dari www.wikipedia.org?". (umumnya) akan didapatkan jawaban yang sejenis, "saya tidak tahu alamat dari www.wikipedia.org, tapi saya "tahu" bahwa server 207.142.131.234 memiliki informasi dari domain wikipedia.org."
Akhirnya, pertanyaan beralih kepada server DNS ketiga (207.142.131.234), yang menjawab dengan alamat IP yang dibutuhkan.
Proses ini menggunakan pencarian rekursif (recursion / recursive searching).
[sunting] Pengertian pendaftaran 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 memiliki 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 memberikan jawaban otorisatif bagi nama domain yang umum mengalami perubahan yang cukup sering. Sebagai bagian dari proses pendaftaran sebuah nama domain (dan beberapa waktu sesudahnya), pendaftar memberikan pendaftaran 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 menerima 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 berdasarkan urutan nama, selain berdasarkan alamat IP. Hal ini menimbulkan string lain dari permintaan DNS untuk menyelesaikan nama dari server nama; ketika sebuah alamat IP dari server nama mendapatkan sebuah pendaftaran di zona induk, para programmer jaringan komputer menamakannya sebuah glue record (daftar lekat???)
[sunting] 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, lalu mengertikan operasi DNS di "dunia nyata".
[sunting] Caching dan masa hidup (caching and time to live)
Karena jumlah permintaan yang besar dari sistem seperti DNS, perancang DNS menginginkan penyediaan mekanisme yang bisa mengurangi beban dari masing-masing server DNS. Rencana mekanisnya menyarankan bahwa ketika sebuah DNS resolver (klien) menerima sebuah jawaban DNS, informasi tersebut akan di cache untuk jangka waktu tertentu. Sebuah nilai (yang di-set oleh administrator dari server DNS yang memberikan jawaban) menyebutnya sebagai time to live (masa hidup), atau TTL yang mendefinisikan periode tersebut. Saat jawaban masuk ke dalam cache, resolver akan mengacu kepada jawaban yang disimpan di cache tersebut; hanya ketika TTL usai (atau saat administrator mengosongkan jawaban dari memori resolver secara manual) maka resolver menghubungi server DNS untuk informasi yang sama.
[sunting] Waktu propagasi (propagation time)
Satu akibat penting dari arsitektur tersebar dan cache adalah perubahan kepada suatu DNS tidak selalu efektif secara langsung dalam skala besar/global. Contoh berikut mungkin akan menjelaskannya: Jika seorang administrator telah mengatur TTL selama 6 jam untuk host www.wikipedia.org, kemudian mengganti alamat IP dari www.wikipedia.org pada pk 12:01, administrator harus mempertimbangkan bahwa ada (paling tidak) satu individu yang menyimpan cache jawaban dengan nilai lama pada pk 12:00 yang tidak akan menghubungi server DNS sampai dengan pk 18:00. Periode antara pk 12:00 dan pk 18:00 dalam contoh ini disebut sebagai waktu propagasi (propagation time), yang bisa didefiniskan sebagai periode waktu yang berawal antara saat terjadi perubahan dari data DNS, dan berakhir sesudah waktu maksimum yang telah ditentukan oleh TTL berlalu. Ini akan mengarahkan kepada pertimbangan logis yang penting ketika membuat perubahan kepada DNS: tidak semua akan melihat hal yang sama seperti yang Anda lihat. RFC1537 dapat membantu penjelasan ini.
[sunting] DNS di dunia nyata
Di dunia nyata, user tidak berhadapan langsung dengan DNS resolver - mereka berhadapan dengan program seperti 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 melakukan aktivitas yang meminta pencarian DNS (umumnya, nyaris semua aktivitas yang menggunakan Internet), program tersebut mengirimkan permintaan ke DNS Resolver yang ada di dalam sistem operasi.
DNS resolver akan selalu memiliki cache (lihat diatas) yang memiliki isi pencarian terakhir. Jika cache dapat memberikan jawaban kepada permintaan DNS, resolver akan menggunakan nilai yang ada di dalam cache kepada program yang memerlukan. Kalau cache tidak memiliki jawabannya, resolver akan mengirimkan permintaan 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 menggunakan DHCP untuk melakukan pendataan tersebut. Jika administrator sistem telah mengkonfigurasi sistem untuk menggunakan 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 hasilnya di cache untuk penggunaan berikutnya, dan memberikan hasilnya kepada software yang meminta pencarian DNS tersebut.
Sebagai bagian akhir dari kerumitan ini, beberapa aplikasi seperti web browser juga memiliki DNS cache mereka sendiri, tujuannya adalah untuk mengurangi penggunaan referensi DNS resolver, yang akan meningkatkan kesulitan untuk melakukan debug DNS, yang menimbulkan kerancuan data yang lebih akurat. Cache seperti ini umumnya memiliki masa yang singkat dalam hitungan 1 menit.
[sunting] Penerapan DNS lainnya
Sistem yang dijabarkan diatas memberikan skenario yang disederhanakan. DNS meliputi beberapa fungsi lainnya:
Nama host dan alamat IP tidak berarti terhubung secara satu-banding-satu. Banyak nama host yang diwakili melalui alamat IP tunggal: gabungan dengan pengasuhan maya (virtual hosting), hal ini memungkinkan satu komputer untuk malayani beberapa situs web. Selain itu, sebuah nama host dapat 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:, agen pemindahan surat Mail transfer agents(MTA) menggunakan DNS untuk mencari tujuan pengiriman E-mail untuk alamat tertentu. Domain yang menginformasikan pemetaan exchange disediakan melalui rekod MX (MX record) yang meningkatkan lapisan tambahan untuk toleransi kesalahan dan penyebaran beban selain dari fungsi pemetaan nama ke alamat IP.
Kerangka Peraturan Pengiriman (Sender Policy Framework) secara kontroversi menggunakan keuntungan jenis rekod DNS, dikenal sebagai rekod TXT.
Menyediakan keluwesan untuk kegagalan komputer, beberapa server DNS memberikan perlindungan untuk setiap domain. Tepatnya, tigabelas server akar (root servers) digunakan oleh seluruh dunia. Program DNS maupun sistem operasi memiliki 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 dapat berbagi 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 permintaan DNS. Nyaris semua permintaan DNS berisi permintaan UDP tunggal dari klien yang dikuti oleh jawaban UDP tunggal dari server. Umumnya TCP ikut terlibat hanya ketika ukuran data jawaban melebihi 512 byte, atau untuk pertukaaran zona DNS zone transfer
[sunting] Jenis-jenis catatan DNS
Beberapa kelompok penting dari data yang disimpan di dalam DNS adalah 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 membuat alias untuk nama domain. Domain yang di-alias-kan memiliki seluruh subdomain dan rekod DNS seperti 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 memiliki 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 informasi tentang sebuah domain Internet.
SRV record adalah catatan lokasi secara umum.
Catatan TXT mengijinkan administrator untuk memasukan data acak ke dalam catatan DNS; catatan ini juga digunakan di spesifikasi Sender Policy Framework.
Jenis catatan lainnya semata-mata untuk penyediaan informasi (contohnya, catatan LOC memberikan letak lokasi fisik dari sebuah host, atau data ujicoba (misalkan, catatan WKS memberikan sebuah daftar dari server yang memberikan servis yang dikenal (well-known service) seperti HTTP atau POP3 untuk sebuah domain.
[sunting] Nama domain yang diinternasionalkan
Nama domain harus menggunakan satu sub-kumpulan dari karakter ASCII, hal ini mencegah beberapa bahasa untuk menggunakan nama maupun kata lokal mereka. ICANN telah menyetujui Punycode yang berbasiskan sistem IDNA, yang memetakan string Unicode ke karakter set yang valid untuk DNS, sebagai bentuk penyelesaian untuk masalah ini, dan beberapa registries sudah mengadopsi metode IDNS ini.
[sunting] 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)
Transmission Control Protocol (TCP) adalah suatu protokol yang berada di lapisan transpor (baik itu dalam tujuh lapis model referensi OSI atau model DARPA) yang berorientasi sambungan (connection-oriented) dan dapat diandalkan (reliable). TCP dispesifikasikan dalam RFC 793
[sunting] Karakteristik TCP
TCP memiliki karakteristik sebagai berikut:
Berorientasi sambungan (connection-oriented): Sebelum data dapat ditransmisikan antara dua host, dua proses yang berjalan pada lapisan aplikasi harus melakukan negosiasi untuk membuat sesi koneksi terlebih dahulu. Koneksi TCP ditutup dengan menggunakan proses terminasi koneksi TCP (TCP connection termination).
Full-duplex: Untuk setiap host TCP, koneksi yang terjadi antara dua host terdiri atas dua buah jalur, yakni jalur keluar dan jalur masuk. Dengan menggunakan teknologi lapisan yang lebih rendah yang mendukung full-duplex, maka data pun dapat secara simultan diterima dan dikirim. Header TCP berisi nomor urut (TCP sequence number) dari data yang ditransmisikan dan sebuah acknowledgment dari data yang masuk.
Dapat diandalkan (reliable): Data yang dikirimkan ke sebuah koneksi TCP akan diurutkan dengan sebuah nomor urut paket dan akan mengharapkan paket positive acknowledgment dari penerima. Jika tidak ada paket Acknowledgment dari penerima, maka segmen TCP (protocol data unit dalam protokol TCP) akan ditransmisikan ulang. Pada pihak penerima, segmen-segmen duplikat akan diabaikan dan segmen-segmen yang datang tidak sesuai dengan urutannya akan diletakkan di belakang untuk mengurutkan segmen-segmen TCP. Untuk menjamin integritas setiap segmen TCP, TCP mengimplementasikan penghitungan TCP Checksum.
Byte stream: TCP melihat data yang dikirimkan dan diterima melalui dua jalur masuk dan jalur keluar TCP sebagai sebuah byte stream yang berdekatan (kontigu). Nomor urut TCP dan nomor acknowlegment dalam setiap header TCP didefinisikan juga dalam bentuk byte. Meski demikian, TCP tidak mengetahui batasan pesan-pesan di dalam byte stream TCP tersebut. Untuk melakukannya, hal ini diserahkan kepada protokol lapisan aplikasi (dalam DARPA Reference Model), yang harus menerjemahkan byte stream TCP ke dalam "bahasa" yang ia pahami.
Memiliki layanan flow control: Untuk mencegah data terlalu banyak dikirimkan pada satu waktu, yang akhirnya membuat "macet" jaringan internetwork IP, TCP mengimplementasikan layanan flow control yang dimiliki oleh pihak pengirim yang secara terus menerus memantau dan membatasi jumlah data yang dikirimkan pada satu waktu. Untuk mencegah pihak penerima untuk memperoleh data yang tidak dapat disangganya (buffer), TCP juga mengimplementasikan flow control dalam pihak penerima, yang mengindikasikan jumlah buffer yang masih tersedia dalam pihak penerima.
Melakukan segmentasi terhadap data yang datang dari lapisan aplikasi (dalam DARPA Reference Model)
Mengirimkan paket secara "one-to-one": hal ini karena memang TCP harus membuat sebuah sirkuit logis antara dua buah protokol lapisan aplikasi agar saling dapat berkomunikasi. TCP tidak menyediakan layanan pengiriman data secara one-to-many.
TCP umumnya digunakan ketika protokol lapisan aplikasi membutuhkan layanan transfer data yang bersifat andal, yang layanan tersebut tidak dimiliki oleh protokol lapisan aplikasi tersebut. Contoh dari protokol yang menggunakan TCP adalah HTTP dan FTP.
[sunting] Segmen TCP
Segmen-segmen TCP akan dikirimkan sebagai datagram-datagram IP (datagram merupakan satuan protocol data unit pada lapisan internetwork). Sebuah segmen TCP terdiri atas sebuah header dan segmen data (payload), yang dienkapsulasi dengan menggunakan header IP dari protokol IP.
Proses enkapsulasi data protokol TCP/IP: Data aplikasi + header TCP + header IP + header network interface (Ethernet, Token Ring, dll) + trailer network interface
Sebuah segmen dapat berukuran hingga 65495 byte: 216-(ukuran header IP terkecil (20 byte)+ukuran header TCP terkecil (20 byte)). Datagram IP tersebut akan dienkapsulasi lagi dengan menggunakan header protokol network interface (lapisan pertama dalam DARPA Reference Model) menjadi frame lapisan Network Interface. Gambar berikut mengilustrasikan data yang dikirimkan ke sebuah host.
Di dalam header IP dari sebuah segmen TCP, field Source IP Address diatur menjadi alamat unicast dari sebuah antarmuka host yang mengirimkan segmen TCP yang bersangkutan. Sementara itu, field Destination IP Address juga akan diatur menjadi alamat unicast dari sebuah antarmuka host tertentu yang dituju. Hal ini dikarenakan, protokol TCP hanya mendukung transmisi one-to-one.
[sunting] Header TCP
Ukuran dari header TCP adalah bervariasi, yang terdiri atas beberapa field yang ditunjukkan dalam gambar dan tabel berikut. Ukuran TCP header paling kecil (ketika tidak ada tambahan opsi TCP) adalah 20 byte.
Format header TCP, dilengkapi dengan ukuran setiap field-nya
Nama field
Ukuran
Keterangan
Source Port
2 byte (16 bit)
Mengindikasikan sumber protokol lapisan aplikasi yang mengirimkan segmen TCP yang bersangkutan. Gabungan antara field Source IP Address dalam header IP dan field Source Port dalam field header TCP disebut juga sebagai socket sumber, yang berarti sebuah alamat global dari mana segmen dikirimkan. Lihat juga Port TCP.
Destination Port
2 byte (16 bit)
Mengindikasikan tujuan protokol lapisan aplikasi yang menerima segmen TCP yang bersangkutan. Gabungan antara field Destination IP Address dalam header IP dan field Destination Port dalam field header TCP disebut juga sebagai socket tujuan, yang berarti sebuah alamat global ke mana segmen akan dikirimkan.
Sequence Number
4 byte (32 bit)
Mengindikasikan nomor urut dari oktet pertama dari data di dalam sebuah segmen TCP yang hendak dikirimkan. Field ini harus selalu diset, meskipun tidak ada data (payload) dalam segmen.
Ketika memulai sebuah sesi koneksi TCP, segmen dengan flag SYN (Synchronization) diset ke nilai 1, field ini akan berisi nilai Initial Sequence Number (ISN). Hal ini berarti, oktet pertama dalam aliran byte (byte stream) dalam koneksi adalah ISN+1.
Acknowledgment Number
4 byte (32 bit)
Mengindikasikan nomor urut dari oktet selanjutnya dalam aliran byte yang diharapkan oleh untuk diterima oleh pengirim dari si penerima pada pengiriman selanjutnya. Acknowledgment number sangat dipentingkan bagi segmen-segmen TCP dengan flag ACK diset ke nilai 1.
Data Offset
4 bit
Mengindikasikan di mana data dalam segmen TCP dimulai. Field ini juga dapat berarti ukuran dari header TCP. Seperti halnya field Header Length dalam header IP, field ini merupakan angka dari word 32-bit dalam header TCP. Untuk sebuah segmen TCP terkecil (di mana tidak ada opsi TCP tambahan), field ini diatur ke nilai 0x5, yang berarti data dalam segmen TCP dimulai dari oktet ke 20 dilihat dari permulaan segmen TCP. Jika field Data Offset diset ke nilai maksimumnya (24=16) yakni 15, header TCP dengan ukuran terbesar dapat memiliki panjang hingga 60 byte.
Reserved
6 bit
Direservasikan untuk digunakan pada masa depan. Pengirim segmen TCP akan mengeset bit-bit ini ke dalam nilai 0.
Flags
6 bit
Mengindikasikan flag-flag TCP yang memang ada enam jumlahnya, yang terdiri atas: URG (Urgent), ACK (Acknowledgment), PSH (Push), RST (Reset), SYN (Synchronize), dan FIN (Finish).
Window
2 byte (16 bit)
Mengindikasikan jumlah byte yang tersedia yang dimiliki oleh buffer host penerima segmen yang bersangkutan. Buffer ini disebut sebagai Receive Buffer, digunakan untuk menyimpan byte stream yang datang. Dengan mengimbuhkan ukuran window ke setiap segmen, penerima segmen TCP memberitahukan kepada pengirim segmen berapa banyak data yang dapat dikirimkan dan disangga dengan sukses. Hal ini dilakukan agar si pengirim segmen tidak mengirimkan data lebih banyak dibandingkan ukuran Receive Buffer. Jika tidak ada tempat lagi di dalam Receive buffer, nilai dari field ini adalah 0. Dengan nilai 0, maka si pengirim tidak akan dapat mengirimkan segmen lagi ke penerima hingga nilai field ini berubah (bukan 0). Tujuan hal ini adalah untuk mengatur lalu lintas data atau flow control.
Checksum
2 byte (16 bit)
Mampu melakukan pengecekan integritas segmen TCP (header-nya dan payload-nya). Nilai field Checksum akan diatur ke nilai 0 selama proses kalkulasi checksum.
Urgent Pointer
2 byte (16 bit)
Menandakan lokasi data yang dianggap "urgent" dalam segmen.
Options
4 byte (32 bit)
Berfungsi sebagai penampung beberapa opsi tambahan TCP. Setiap opsi TCP akan memakan ruangan 32 bit, sehingga ukuran header TCP dapat diindikasikan dengan menggunakan field Data offset.
[sunting] Port TCP
Port TCP mampu mengindikasikan sebuah lokasi tertentu untuk menyampaikan segmen-segmen TCP yang dikirimkan yang diidentifikasi dengan TCP Port Number. Nomor-nomor di bawah angka 1024 merupakan port yang umum digunakan dan ditetapkan oleh IANA (Internet Assigned Number Authority). Tabel berikut ini menyebutkan beberapa port TCP yang telah umum digunakan.
Nomor port TCP
Keterangan
20
File Transfer Protocol/FTP (digunakan untuk saluran data)
21
File Transfer Protocol/FTP (digunakan untuk saluran kontrol)
25
Simple Mail Transfer Protocol/SMTP yang digunakan untuk mengirim e-mail
23
Telnet
80
Hypertext Transfer Protocol/HTTP yang digunakan untuk World Wide Web.
110
Post Office Protocol 3/POP3 yang digunakan untuk menerima e-mail.
139
NetBIOS over TCP session service
Port TCP merupakan hal yang berbeda dibandingkan dengan port UDP, meskipun mereka memiliki nomor port yang sama. Port TCP merepresentasikan satu sisi dari sebuah koneksi TCP untuk protokol lapisan aplikasi, sementara port UDP merepresentasikan sebuah antrean pesan UDP untuk protokol lapisan aplikasi. Selain itu, protokol lapisan aplikasi yang menggunakan port TCP dan port UDP dalam nomor yang sama juga tidak harus sama. Sebagai contoh protokol Extended Filename Server (EFS) menggunakan port TCP dengan nomor 520, dan protokol Routing Information Protocol (RIP) menggunakan port UDP juga dengan nomor 520. Jelas, dua protokol tersebut sangatlah berbeda! Karenanya, untuk menyebutkan sebuah nomor port, sebutkan juga jenis port yang digunakannya, karena hal tersebut mampu membingungkan (ambigu).
Lihat juga Port TCP dan UDP
[sunting] TCP Flag
Sebuah segmen TCP dapat memiliki flag (tanda-tanda) khusus yang mengindikasikan segmen yang bersangkutan, seperti yang disebutkan dalam tabel berikut:
Struktur flag-flag TCP
Nama flag
Keterangan
URG
Mengindikasikan bahwa beberapa bagian dari segmen TCP mengandung data yang sangat penting, dan field Urgent Pointer dalam header TCP harus digunakan untuk menentukan lokasi di mana data penting tersebut berada dalam segmen.
ACK
Mengindikasikan field Acknowledgment mengandung oktet selanjutnya yang diharapkan dalam koneksi. Flag ini selalu diset, kecuali pada segmen pertama pada pembuatan sesi koneksi TCP.
PSH
Mengindikasikan bahwa isi dari TCP Receive buffer harus diserahkan kepada protokol lapisan aplikasi. Data dalam receive buffer harus berisi sebuah blok data yang berurutan (kontigu), dilihat dari ujung paling kiri dari buffer. Dengan kata lain, sebuah segmen yang memiliki flag PSH diset ke nilai 1, tidak bolah ada satu byte pun data yang hilang dari aliran byte segmen tersebut; data tidak dapat diberikan kepada protokol lapisan aplikasi hingga segmen yang hilang tersebut datang. Normalnya, TCP Receive buffer akan dikosongkan (dengan kata lain, isi dari buffer akan diteruskan kepada protokol lapisan aplikasi) ketika buffer tersebut berisi data yang kontigu atau ketika dalam "proses perawatan". Flag PSH ini dapat mengubah hal seperti itu, dan membuat akan TCP segera mengosongkan TCP Receive buffer. Flag PSH umumnya digunakan dalam protokol lapisan aplikasi yang bersifat interaktif, seperti halnya Telnet, karena setiap penekanan tombol dalam sesi terminal virtual akan dikirimkan dengan sebuah flag PSH diset ke nilai 1. Contoh dari penggunaan lainnya dari flag ini adalah pada segmen terakhir dari berkas yang ditransfer dengan menggunakan protokol FTP. Segmen yang dikirimkan dengan flag PSH aktif tidak harus segera di-acknowledge oleh penerima.
RST
Mengindikasikan bahwa koneksi yang dibuat akan digagalkan. Untuk sebuah koneksi TCP yang sedang berjalan (aktif), sebuah segmen dengan flag RST diset ke nilai 1 akan dikirimkan sebagai respons terhadap sebuah segmen TCP yang diterima yang ternyata segmen tersebut bukan yang diminta, sehingga koneksi pun menjadi gagal. Pengiriman segmen dengan flag RST diset ke nilai 1 untuk sebuah koneksi aktif akan menutup koneksi secara paksa, sehingga data yang disimpan dalam buffer akan dibuang (dihilangkan). Untuk sebuah koneksi TCP yang sedang dibuat, segmen dengan flag RST aktif akan dikirimkan sebagai respons terhadap request pembuatan koneksi untuk mencegah percobaan pembuatan koneksi.
SYN
Mengindikasikan bahwa segmen TCP yang bersangkutan mengandung Initial Sequence Number (ISN). Selama proses pembuatan sesi koneksi TCP, TCP akan mengirimkan sebuah segmen dengan flag SYN diset ke nilai 1. Setiap host TCP lainnya akan memberikan jawaban (acknowledgment) dari segmen dengan flag SYN tersebut dengan menganggap bahwa segmen tersebut merupakan sekumpulan byte dari data. Field Acknowledgment Number dari sebuah segmen SYN diatur ke nilai ISN + 1.
FIN
Menandakan bahwa pengirim segmen TCP telah selesai dalam mengirimkan data dalam sebuah koneksi TCP. Ketika sebuah koneksi TCP akhirnya dihentikan (akibat sudah tidak ada data yang dikirimkan lagi), setiap host TCP akan mengirimkan sebuah segmen TCP dengan flag FIN diset ke nilai 1. Sebuah host TCP tidak akan mengirimkan segmen dengan flag FIN hingga semua data yang dikirimkannya telah diterima dengan baik (menerima paket acknowledgment) oleh penerima. Setiap host akan menganggap sebuah segmen TCP dengan flag FIN sebagai sekumpulan byte dari data. Ketika dua host TCP telah mengirimkan segmen TCP dengan flag FIN dan menerima acknowledgment dari segmen tersebut, maka koneksi TCP pun akan dihentikan.
[sunting] TCP Three-way handshake
Proses pembuatan koneksi (TCP Three way handshake)
Proses pembuatan koneksi TCP disebut juga dengan "Three-way Handshake". Tujuan metode ini adalah agar dapat melakukan sinkronisasi terhadap nomor urut dan nomor acknowledgement yang dikirimkan oleh kedua pihak dan saling bertukar ukuran TCP Window. Prosesnya dapat digambarkan sebagai berikut:
Host pertama (yang ingin membuat koneksi) akan mengirimkan sebuah segmen TCP dengan flag SYN diaktifkan kepada host kedua (yang hendak diajak untuk berkomunikasi).
Host kedua akan meresponsnya dengan mengirimkan segmen dengan acknowledgment dan juga SYN kepada host pertama.
Host pertama selanjutnya akan mulai saling bertukar data dengan host kedua.
TCP menggunakan proses jabat tangan yang sama untuk mengakhiri koneksi yang dibuat. Hal ini menjamin dua host yang sedang terkoneksi tersebut telah menyelesaikan proses transmisi data dan semua data yang ditransmisikan telah diterima dengan baik. Itulah sebabnya, mengapa TCP disebut dengan koneksi yang reliable.
Diperoleh dari "http://id.wikipedia.org/wiki/Transmission_Control_Protocol"
Modem
Modem adalah singkatan dari modulator-demodulator yaitu alat yang digunakan untuk menghantar dan menerima data dari sebuah PC ke PC lainnya melalui kabel telephone. Modem adalah alat yang bertugas untuk menukar data dari bentuk digital ke analog dan sebaliknya. Dengan adanya modem pengguna PC dapat terkoneksi dengan dunia internet.. Modulator merupakan bagian yang mengubah sinyal informasi kedalam sinyal pembawa (Carrier) dan siap untuk dikirimkan, sedangkan Demodulator adalah bagian yang memisahkan sinyal informasi (yang berisi data atau pesan) dari sinyal pembawa (carrier) yang diterima sehingga informasi tersebut dapat diterima dengan baik. Modem merupakan penggabungan kedua-duanya, artinya modem adalah alat komunikasi dua arah. Setiap perangkat komunikasi jarak jauh dua-arah umumnya menggunakan bagian yang disebut "modem", seperti VSAT, Microwave Radio, dan lain sebagainya, namun umumnya istilah modem lebih dikenal sebagai Perangkat keras yang sering digunakan untuk komunikasi pada komputer.
Data dari komputer yang berbentuk sinyal digital diberikan kepada modem untuk diubah menjadi sinyal analog. Sinyal analog tersebut dapat dikirimkan melalui beberapa media telekomunikasi seperti telepon dan radio.
Setibanya di modem tujuan, sinyal analog tersebut diubah menjadi sinyal digital kembali dan dikirimkan kepada komputer. Terdapat dua jenis modem secara fisiknya, yaitu modem eksternal dan modem internal.
Jenis modem
Modem terbagi atas:
1. Modem analog
2. Modem ADSL
3. Modem kabel
4. Modem CDMA
5. Modem 3GP
6. Modem GSM
Webcam
Webcam (singkatan dari web camera) adalah sebutan bagi kamera real-time (bermakna keadaan pada saat ini juga) yang gambarnya bisa diakses atau dilihat melalui World Wide Web, program instant messaging, atau aplikasi video call. Istilah "webcam" juga merujuk kepada jenis kamera yang digunakan untuk keperluan ini.
Webcam biasanya berresolusi sebesar 352x288 / 640x480 piksel. Namun ada yang kualitasnya hingga 1 Megapiksel.
Sekarang hampir semua kamera digital dan HP bisa dijadikan sebagai kamera web (webcam).Banyak manfaat menggunakan webcam yaitu di antaranya kita dapat langsung bertatap muka dengan lawan bicara kita di komputer yang berbeda,dan kita juga bissa mengetahui aktivitas lawan bicara kita itu di komputer pada saat itu juga.
Headset
Headset adalah gabungan headphone dan mikrofon. Ini dipergunakan untuk berkomunikasi melalui perangkat komunikasi atau komputer misalnya dengan VoIP. Teknologi headset juga sudah merambah dunia komunikasi, khususnya teknologi telpon selular. Headset diciptakan pertama kali pada tahun 1910 oleh Nathaniel Baldwin, mahasiswa Universitas Stanford. Namun penemuannya ini tidak langsung menjadi perhatian, karena layaknya penemu-penemu zaman itu, Baldwin tidak berminat untuk memproduksi temuannya secara massal. Pada Perang Dunia I, angkatan laut Amerika mengetahui penemuan Baldwin dan memesan 100 headset untuk keperluan perang. Semenjak itulah masyarakat mulai sadar dengan teknologi ini, bahkan pada 1961 headset masuk ke kokpit pesawat, pilot menyukainya karena headset ringan dan nyaman dipakai. Headset pertama kali digunakan untuk pesawat telpon adalah pada tahun 1970. Pada awal 2000, bersamaan dengan meledaknya telpon selular, headset nirkabel berbasis teknologi Bluetooth mulai popular.
Headset untuk mengakses internet digunakan untuk chating. Penggunanya yang terkoneksi ke Internet dapat melakukan pembicaraan dengan headset mikrofon dan speaker (atau sebuah headset) ke pengguna lainnya yang tergabung dalam jaringan tersebut.
Pembicaraan dapat dilakukan secara real-time tanpa terputus-putus serta suara yang didapat terasa “tebal” dan jernih. Terlebih lagi bila melakukan pembicaraan konferensi multi-partit, dengan headset saya dapat melakukannya sambil mengemil makanan dan minuman. Semuanya hanya dengan pulsa Internet lokal! Bayangkan besarnya biaya yang harus dikeluarkan jika menggunakan jalur telepon milik Telkom.
Sayangnya, teknologi ini baru bisa dimanfaatkan untuk komunikasi antarpengguna PC. Untuk menghubungi telepon biasa sepertinya sedang dalam tahap pengembangan dan saya duga nantinya fitur ini tidak gratis. Jika nantinya biaya yang kita keluarkan untuk fitur ini ternyata lebih murah dari tarif Telkom, tentu saja tidak ada alasan untuk tidak memanfaatkannya.
DNS (Domain Name System, bahasa Indonesia: Sistem Penamaan Domain) adalah sebuah sistem yang menyimpan informasi tentang 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 menerima 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 tugas seperti pengalamatan dan penjaluran (routing), manusia pada umumnya lebih memilih untuk menggunakan nama host dan nama domain, contohnya adalah 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 manusia mengalahkan TCP/IP, dan kembali ke zaman ARPAnet. Dahulu, setiap komputer di jaringan komputer menggunakan 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, dapat melihat Hosts file untuk menyamakan sebuah nama host menjadi sebuah alamat IP sebelum melakukan pencarian via DNS). Namun, sistem tersebut diatas mewarisi beberapa keterbatasan yang mencolok dari sisi prasyarat, setiap saat sebuah alamat komputer berubah, setiap sistem yang hendak berhubungan dengan komputer tersebut harus melakukan update terhadap file Hosts.
Dengan berkembangnya jaringan komputer, membutuhkan sistem yang bisa dikembangkan: sebuah sistem yang bisa 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 asli muncul di RFC 882 dan 883. Tahun 1987, penerbitan RFC 1034 dan RFC 1035 membuat update terhadap spesifikasi DNS. Hal ini membuat RFC 882 dan RFC 883 tidak berlaku lagi. Beberapa RFC terkini telah memproposikan beberapa tambahan dari protokol inti DNS.
[sunting] Teori bekerja DNS
[sunting] Para Pemain Inti
Pengelola dari sistem DNS terdiri dari tiga komponen:
DNS resolver, sebuah program klien yang berjalan di komputer pengguna, yang membuat permintaan DNS dari program aplikasi.
recursive DNS server, yang melakukan pencarian melalui DNS sebagai tanggapan permintaan dari resolver, dan mengembalikan jawaban kepada para resolver tersebut;
dan ...
authoritative DNS server yang memberikan jawaban terhadap permintaan dari recursor, baik dalam bentuk sebuah jawaban, maupun dalam bentuk delegasi (misalkan: mereferensikan ke authoritative DNS server lainnya)
[sunting] Pengertian beberapa bagian dari nama domain
Sebuah nama domain biasanya terdiri dari dua bagian 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 memiliki 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 dapat membentuk subdomain dari domain wikipedia.org (pada prakteknya, id.wikipedia.org sesungguhnya mewakili sebuah nama host - lihat dibawah). Secara teori, pembagian seperti ini dapat mencapai kedalaman 127 level, dan setiap label dapat terbentuk sampai dengan 63 karakter, selama total nama domain tidak melebihi panjang 255 karakter. Tetapi secara praktek, beberapa pendaftar nama domain (domain name registry) memiliki batas yang lebih sedikit.
Terakhir, bagian paling kiri dari bagian nama domain (biasanya) menyatakan nama host. Sisa dari nama domain menyatakan cara untuk membangun jalur logis untuk informasi yang dibutuhkan; nama host adalah tujuan sebenarnya dari nama sistem yang dicari alamat IP-nya. Contoh: nama domain www.wikipedia.org memiliki nama host "www".
DNS memiliki kumpulan hirarki dari DNS servers. Setiap domain atau subdomain memiliki satu atau lebih authoritative DNS Servers (server DNS otorisatif) yang mempublikasikan informas tentang 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).
[sunting] Sebuah contoh dari teori rekursif DNS
Sebuah contoh mungkin dapat 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 dapat menemukan root nameserver; administrator dari recursive DNS server secara manual mengatur (dan melakukan 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 memiliki informasi tentang domain org."
Recursor DNS lokal kemudian bertanya kepada server DNS (yaitu: 204.74.112.1) pertanyaan yang sama seperti yang diberikan kepada root server. "apa alamat IP dari www.wikipedia.org?". (umumnya) akan didapatkan jawaban yang sejenis, "saya tidak tahu alamat dari www.wikipedia.org, tapi saya "tahu" bahwa server 207.142.131.234 memiliki informasi dari domain wikipedia.org."
Akhirnya, pertanyaan beralih kepada server DNS ketiga (207.142.131.234), yang menjawab dengan alamat IP yang dibutuhkan.
Proses ini menggunakan pencarian rekursif (recursion / recursive searching).
[sunting] Pengertian pendaftaran 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 memiliki 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 memberikan jawaban otorisatif bagi nama domain yang umum mengalami perubahan yang cukup sering. Sebagai bagian dari proses pendaftaran sebuah nama domain (dan beberapa waktu sesudahnya), pendaftar memberikan pendaftaran 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 menerima 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 berdasarkan urutan nama, selain berdasarkan alamat IP. Hal ini menimbulkan string lain dari permintaan DNS untuk menyelesaikan nama dari server nama; ketika sebuah alamat IP dari server nama mendapatkan sebuah pendaftaran di zona induk, para programmer jaringan komputer menamakannya sebuah glue record (daftar lekat???)
[sunting] 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, lalu mengertikan operasi DNS di "dunia nyata".
[sunting] Caching dan masa hidup (caching and time to live)
Karena jumlah permintaan yang besar dari sistem seperti DNS, perancang DNS menginginkan penyediaan mekanisme yang bisa mengurangi beban dari masing-masing server DNS. Rencana mekanisnya menyarankan bahwa ketika sebuah DNS resolver (klien) menerima sebuah jawaban DNS, informasi tersebut akan di cache untuk jangka waktu tertentu. Sebuah nilai (yang di-set oleh administrator dari server DNS yang memberikan jawaban) menyebutnya sebagai time to live (masa hidup), atau TTL yang mendefinisikan periode tersebut. Saat jawaban masuk ke dalam cache, resolver akan mengacu kepada jawaban yang disimpan di cache tersebut; hanya ketika TTL usai (atau saat administrator mengosongkan jawaban dari memori resolver secara manual) maka resolver menghubungi server DNS untuk informasi yang sama.
[sunting] Waktu propagasi (propagation time)
Satu akibat penting dari arsitektur tersebar dan cache adalah perubahan kepada suatu DNS tidak selalu efektif secara langsung dalam skala besar/global. Contoh berikut mungkin akan menjelaskannya: Jika seorang administrator telah mengatur TTL selama 6 jam untuk host www.wikipedia.org, kemudian mengganti alamat IP dari www.wikipedia.org pada pk 12:01, administrator harus mempertimbangkan bahwa ada (paling tidak) satu individu yang menyimpan cache jawaban dengan nilai lama pada pk 12:00 yang tidak akan menghubungi server DNS sampai dengan pk 18:00. Periode antara pk 12:00 dan pk 18:00 dalam contoh ini disebut sebagai waktu propagasi (propagation time), yang bisa didefiniskan sebagai periode waktu yang berawal antara saat terjadi perubahan dari data DNS, dan berakhir sesudah waktu maksimum yang telah ditentukan oleh TTL berlalu. Ini akan mengarahkan kepada pertimbangan logis yang penting ketika membuat perubahan kepada DNS: tidak semua akan melihat hal yang sama seperti yang Anda lihat. RFC1537 dapat membantu penjelasan ini.
[sunting] DNS di dunia nyata
Di dunia nyata, user tidak berhadapan langsung dengan DNS resolver - mereka berhadapan dengan program seperti 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 melakukan aktivitas yang meminta pencarian DNS (umumnya, nyaris semua aktivitas yang menggunakan Internet), program tersebut mengirimkan permintaan ke DNS Resolver yang ada di dalam sistem operasi.
DNS resolver akan selalu memiliki cache (lihat diatas) yang memiliki isi pencarian terakhir. Jika cache dapat memberikan jawaban kepada permintaan DNS, resolver akan menggunakan nilai yang ada di dalam cache kepada program yang memerlukan. Kalau cache tidak memiliki jawabannya, resolver akan mengirimkan permintaan 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 menggunakan DHCP untuk melakukan pendataan tersebut. Jika administrator sistem telah mengkonfigurasi sistem untuk menggunakan 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 hasilnya di cache untuk penggunaan berikutnya, dan memberikan hasilnya kepada software yang meminta pencarian DNS tersebut.
Sebagai bagian akhir dari kerumitan ini, beberapa aplikasi seperti web browser juga memiliki DNS cache mereka sendiri, tujuannya adalah untuk mengurangi penggunaan referensi DNS resolver, yang akan meningkatkan kesulitan untuk melakukan debug DNS, yang menimbulkan kerancuan data yang lebih akurat. Cache seperti ini umumnya memiliki masa yang singkat dalam hitungan 1 menit.
[sunting] Penerapan DNS lainnya
Sistem yang dijabarkan diatas memberikan skenario yang disederhanakan. DNS meliputi beberapa fungsi lainnya:
Nama host dan alamat IP tidak berarti terhubung secara satu-banding-satu. Banyak nama host yang diwakili melalui alamat IP tunggal: gabungan dengan pengasuhan maya (virtual hosting), hal ini memungkinkan satu komputer untuk malayani beberapa situs web. Selain itu, sebuah nama host dapat 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:, agen pemindahan surat Mail transfer agents(MTA) menggunakan DNS untuk mencari tujuan pengiriman E-mail untuk alamat tertentu. Domain yang menginformasikan pemetaan exchange disediakan melalui rekod MX (MX record) yang meningkatkan lapisan tambahan untuk toleransi kesalahan dan penyebaran beban selain dari fungsi pemetaan nama ke alamat IP.
Kerangka Peraturan Pengiriman (Sender Policy Framework) secara kontroversi menggunakan keuntungan jenis rekod DNS, dikenal sebagai rekod TXT.
Menyediakan keluwesan untuk kegagalan komputer, beberapa server DNS memberikan perlindungan untuk setiap domain. Tepatnya, tigabelas server akar (root servers) digunakan oleh seluruh dunia. Program DNS maupun sistem operasi memiliki 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 dapat berbagi 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 permintaan DNS. Nyaris semua permintaan DNS berisi permintaan UDP tunggal dari klien yang dikuti oleh jawaban UDP tunggal dari server. Umumnya TCP ikut terlibat hanya ketika ukuran data jawaban melebihi 512 byte, atau untuk pertukaaran zona DNS zone transfer
[sunting] Jenis-jenis catatan DNS
Beberapa kelompok penting dari data yang disimpan di dalam DNS adalah 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 membuat alias untuk nama domain. Domain yang di-alias-kan memiliki seluruh subdomain dan rekod DNS seperti 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 memiliki 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 informasi tentang sebuah domain Internet.
SRV record adalah catatan lokasi secara umum.
Catatan TXT mengijinkan administrator untuk memasukan data acak ke dalam catatan DNS; catatan ini juga digunakan di spesifikasi Sender Policy Framework.
Jenis catatan lainnya semata-mata untuk penyediaan informasi (contohnya, catatan LOC memberikan letak lokasi fisik dari sebuah host, atau data ujicoba (misalkan, catatan WKS memberikan sebuah daftar dari server yang memberikan servis yang dikenal (well-known service) seperti HTTP atau POP3 untuk sebuah domain.
[sunting] Nama domain yang diinternasionalkan
Nama domain harus menggunakan satu sub-kumpulan dari karakter ASCII, hal ini mencegah beberapa bahasa untuk menggunakan nama maupun kata lokal mereka. ICANN telah menyetujui Punycode yang berbasiskan sistem IDNA, yang memetakan string Unicode ke karakter set yang valid untuk DNS, sebagai bentuk penyelesaian untuk masalah ini, dan beberapa registries sudah mengadopsi metode IDNS ini.
[sunting] 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)
Transmission Control Protocol (TCP) adalah suatu protokol yang berada di lapisan transpor (baik itu dalam tujuh lapis model referensi OSI atau model DARPA) yang berorientasi sambungan (connection-oriented) dan dapat diandalkan (reliable). TCP dispesifikasikan dalam RFC 793
[sunting] Karakteristik TCP
TCP memiliki karakteristik sebagai berikut:
Berorientasi sambungan (connection-oriented): Sebelum data dapat ditransmisikan antara dua host, dua proses yang berjalan pada lapisan aplikasi harus melakukan negosiasi untuk membuat sesi koneksi terlebih dahulu. Koneksi TCP ditutup dengan menggunakan proses terminasi koneksi TCP (TCP connection termination).
Full-duplex: Untuk setiap host TCP, koneksi yang terjadi antara dua host terdiri atas dua buah jalur, yakni jalur keluar dan jalur masuk. Dengan menggunakan teknologi lapisan yang lebih rendah yang mendukung full-duplex, maka data pun dapat secara simultan diterima dan dikirim. Header TCP berisi nomor urut (TCP sequence number) dari data yang ditransmisikan dan sebuah acknowledgment dari data yang masuk.
Dapat diandalkan (reliable): Data yang dikirimkan ke sebuah koneksi TCP akan diurutkan dengan sebuah nomor urut paket dan akan mengharapkan paket positive acknowledgment dari penerima. Jika tidak ada paket Acknowledgment dari penerima, maka segmen TCP (protocol data unit dalam protokol TCP) akan ditransmisikan ulang. Pada pihak penerima, segmen-segmen duplikat akan diabaikan dan segmen-segmen yang datang tidak sesuai dengan urutannya akan diletakkan di belakang untuk mengurutkan segmen-segmen TCP. Untuk menjamin integritas setiap segmen TCP, TCP mengimplementasikan penghitungan TCP Checksum.
Byte stream: TCP melihat data yang dikirimkan dan diterima melalui dua jalur masuk dan jalur keluar TCP sebagai sebuah byte stream yang berdekatan (kontigu). Nomor urut TCP dan nomor acknowlegment dalam setiap header TCP didefinisikan juga dalam bentuk byte. Meski demikian, TCP tidak mengetahui batasan pesan-pesan di dalam byte stream TCP tersebut. Untuk melakukannya, hal ini diserahkan kepada protokol lapisan aplikasi (dalam DARPA Reference Model), yang harus menerjemahkan byte stream TCP ke dalam "bahasa" yang ia pahami.
Memiliki layanan flow control: Untuk mencegah data terlalu banyak dikirimkan pada satu waktu, yang akhirnya membuat "macet" jaringan internetwork IP, TCP mengimplementasikan layanan flow control yang dimiliki oleh pihak pengirim yang secara terus menerus memantau dan membatasi jumlah data yang dikirimkan pada satu waktu. Untuk mencegah pihak penerima untuk memperoleh data yang tidak dapat disangganya (buffer), TCP juga mengimplementasikan flow control dalam pihak penerima, yang mengindikasikan jumlah buffer yang masih tersedia dalam pihak penerima.
Melakukan segmentasi terhadap data yang datang dari lapisan aplikasi (dalam DARPA Reference Model)
Mengirimkan paket secara "one-to-one": hal ini karena memang TCP harus membuat sebuah sirkuit logis antara dua buah protokol lapisan aplikasi agar saling dapat berkomunikasi. TCP tidak menyediakan layanan pengiriman data secara one-to-many.
TCP umumnya digunakan ketika protokol lapisan aplikasi membutuhkan layanan transfer data yang bersifat andal, yang layanan tersebut tidak dimiliki oleh protokol lapisan aplikasi tersebut. Contoh dari protokol yang menggunakan TCP adalah HTTP dan FTP.
[sunting] Segmen TCP
Segmen-segmen TCP akan dikirimkan sebagai datagram-datagram IP (datagram merupakan satuan protocol data unit pada lapisan internetwork). Sebuah segmen TCP terdiri atas sebuah header dan segmen data (payload), yang dienkapsulasi dengan menggunakan header IP dari protokol IP.
Proses enkapsulasi data protokol TCP/IP: Data aplikasi + header TCP + header IP + header network interface (Ethernet, Token Ring, dll) + trailer network interface
Sebuah segmen dapat berukuran hingga 65495 byte: 216-(ukuran header IP terkecil (20 byte)+ukuran header TCP terkecil (20 byte)). Datagram IP tersebut akan dienkapsulasi lagi dengan menggunakan header protokol network interface (lapisan pertama dalam DARPA Reference Model) menjadi frame lapisan Network Interface. Gambar berikut mengilustrasikan data yang dikirimkan ke sebuah host.
Di dalam header IP dari sebuah segmen TCP, field Source IP Address diatur menjadi alamat unicast dari sebuah antarmuka host yang mengirimkan segmen TCP yang bersangkutan. Sementara itu, field Destination IP Address juga akan diatur menjadi alamat unicast dari sebuah antarmuka host tertentu yang dituju. Hal ini dikarenakan, protokol TCP hanya mendukung transmisi one-to-one.
[sunting] Header TCP
Ukuran dari header TCP adalah bervariasi, yang terdiri atas beberapa field yang ditunjukkan dalam gambar dan tabel berikut. Ukuran TCP header paling kecil (ketika tidak ada tambahan opsi TCP) adalah 20 byte.
Format header TCP, dilengkapi dengan ukuran setiap field-nya
Nama field
Ukuran
Keterangan
Source Port
2 byte (16 bit)
Mengindikasikan sumber protokol lapisan aplikasi yang mengirimkan segmen TCP yang bersangkutan. Gabungan antara field Source IP Address dalam header IP dan field Source Port dalam field header TCP disebut juga sebagai socket sumber, yang berarti sebuah alamat global dari mana segmen dikirimkan. Lihat juga Port TCP.
Destination Port
2 byte (16 bit)
Mengindikasikan tujuan protokol lapisan aplikasi yang menerima segmen TCP yang bersangkutan. Gabungan antara field Destination IP Address dalam header IP dan field Destination Port dalam field header TCP disebut juga sebagai socket tujuan, yang berarti sebuah alamat global ke mana segmen akan dikirimkan.
Sequence Number
4 byte (32 bit)
Mengindikasikan nomor urut dari oktet pertama dari data di dalam sebuah segmen TCP yang hendak dikirimkan. Field ini harus selalu diset, meskipun tidak ada data (payload) dalam segmen.
Ketika memulai sebuah sesi koneksi TCP, segmen dengan flag SYN (Synchronization) diset ke nilai 1, field ini akan berisi nilai Initial Sequence Number (ISN). Hal ini berarti, oktet pertama dalam aliran byte (byte stream) dalam koneksi adalah ISN+1.
Acknowledgment Number
4 byte (32 bit)
Mengindikasikan nomor urut dari oktet selanjutnya dalam aliran byte yang diharapkan oleh untuk diterima oleh pengirim dari si penerima pada pengiriman selanjutnya. Acknowledgment number sangat dipentingkan bagi segmen-segmen TCP dengan flag ACK diset ke nilai 1.
Data Offset
4 bit
Mengindikasikan di mana data dalam segmen TCP dimulai. Field ini juga dapat berarti ukuran dari header TCP. Seperti halnya field Header Length dalam header IP, field ini merupakan angka dari word 32-bit dalam header TCP. Untuk sebuah segmen TCP terkecil (di mana tidak ada opsi TCP tambahan), field ini diatur ke nilai 0x5, yang berarti data dalam segmen TCP dimulai dari oktet ke 20 dilihat dari permulaan segmen TCP. Jika field Data Offset diset ke nilai maksimumnya (24=16) yakni 15, header TCP dengan ukuran terbesar dapat memiliki panjang hingga 60 byte.
Reserved
6 bit
Direservasikan untuk digunakan pada masa depan. Pengirim segmen TCP akan mengeset bit-bit ini ke dalam nilai 0.
Flags
6 bit
Mengindikasikan flag-flag TCP yang memang ada enam jumlahnya, yang terdiri atas: URG (Urgent), ACK (Acknowledgment), PSH (Push), RST (Reset), SYN (Synchronize), dan FIN (Finish).
Window
2 byte (16 bit)
Mengindikasikan jumlah byte yang tersedia yang dimiliki oleh buffer host penerima segmen yang bersangkutan. Buffer ini disebut sebagai Receive Buffer, digunakan untuk menyimpan byte stream yang datang. Dengan mengimbuhkan ukuran window ke setiap segmen, penerima segmen TCP memberitahukan kepada pengirim segmen berapa banyak data yang dapat dikirimkan dan disangga dengan sukses. Hal ini dilakukan agar si pengirim segmen tidak mengirimkan data lebih banyak dibandingkan ukuran Receive Buffer. Jika tidak ada tempat lagi di dalam Receive buffer, nilai dari field ini adalah 0. Dengan nilai 0, maka si pengirim tidak akan dapat mengirimkan segmen lagi ke penerima hingga nilai field ini berubah (bukan 0). Tujuan hal ini adalah untuk mengatur lalu lintas data atau flow control.
Checksum
2 byte (16 bit)
Mampu melakukan pengecekan integritas segmen TCP (header-nya dan payload-nya). Nilai field Checksum akan diatur ke nilai 0 selama proses kalkulasi checksum.
Urgent Pointer
2 byte (16 bit)
Menandakan lokasi data yang dianggap "urgent" dalam segmen.
Options
4 byte (32 bit)
Berfungsi sebagai penampung beberapa opsi tambahan TCP. Setiap opsi TCP akan memakan ruangan 32 bit, sehingga ukuran header TCP dapat diindikasikan dengan menggunakan field Data offset.
[sunting] Port TCP
Port TCP mampu mengindikasikan sebuah lokasi tertentu untuk menyampaikan segmen-segmen TCP yang dikirimkan yang diidentifikasi dengan TCP Port Number. Nomor-nomor di bawah angka 1024 merupakan port yang umum digunakan dan ditetapkan oleh IANA (Internet Assigned Number Authority). Tabel berikut ini menyebutkan beberapa port TCP yang telah umum digunakan.
Nomor port TCP
Keterangan
20
File Transfer Protocol/FTP (digunakan untuk saluran data)
21
File Transfer Protocol/FTP (digunakan untuk saluran kontrol)
25
Simple Mail Transfer Protocol/SMTP yang digunakan untuk mengirim e-mail
23
Telnet
80
Hypertext Transfer Protocol/HTTP yang digunakan untuk World Wide Web.
110
Post Office Protocol 3/POP3 yang digunakan untuk menerima e-mail.
139
NetBIOS over TCP session service
Port TCP merupakan hal yang berbeda dibandingkan dengan port UDP, meskipun mereka memiliki nomor port yang sama. Port TCP merepresentasikan satu sisi dari sebuah koneksi TCP untuk protokol lapisan aplikasi, sementara port UDP merepresentasikan sebuah antrean pesan UDP untuk protokol lapisan aplikasi. Selain itu, protokol lapisan aplikasi yang menggunakan port TCP dan port UDP dalam nomor yang sama juga tidak harus sama. Sebagai contoh protokol Extended Filename Server (EFS) menggunakan port TCP dengan nomor 520, dan protokol Routing Information Protocol (RIP) menggunakan port UDP juga dengan nomor 520. Jelas, dua protokol tersebut sangatlah berbeda! Karenanya, untuk menyebutkan sebuah nomor port, sebutkan juga jenis port yang digunakannya, karena hal tersebut mampu membingungkan (ambigu).
Lihat juga Port TCP dan UDP
[sunting] TCP Flag
Sebuah segmen TCP dapat memiliki flag (tanda-tanda) khusus yang mengindikasikan segmen yang bersangkutan, seperti yang disebutkan dalam tabel berikut:
Struktur flag-flag TCP
Nama flag
Keterangan
URG
Mengindikasikan bahwa beberapa bagian dari segmen TCP mengandung data yang sangat penting, dan field Urgent Pointer dalam header TCP harus digunakan untuk menentukan lokasi di mana data penting tersebut berada dalam segmen.
ACK
Mengindikasikan field Acknowledgment mengandung oktet selanjutnya yang diharapkan dalam koneksi. Flag ini selalu diset, kecuali pada segmen pertama pada pembuatan sesi koneksi TCP.
PSH
Mengindikasikan bahwa isi dari TCP Receive buffer harus diserahkan kepada protokol lapisan aplikasi. Data dalam receive buffer harus berisi sebuah blok data yang berurutan (kontigu), dilihat dari ujung paling kiri dari buffer. Dengan kata lain, sebuah segmen yang memiliki flag PSH diset ke nilai 1, tidak bolah ada satu byte pun data yang hilang dari aliran byte segmen tersebut; data tidak dapat diberikan kepada protokol lapisan aplikasi hingga segmen yang hilang tersebut datang. Normalnya, TCP Receive buffer akan dikosongkan (dengan kata lain, isi dari buffer akan diteruskan kepada protokol lapisan aplikasi) ketika buffer tersebut berisi data yang kontigu atau ketika dalam "proses perawatan". Flag PSH ini dapat mengubah hal seperti itu, dan membuat akan TCP segera mengosongkan TCP Receive buffer. Flag PSH umumnya digunakan dalam protokol lapisan aplikasi yang bersifat interaktif, seperti halnya Telnet, karena setiap penekanan tombol dalam sesi terminal virtual akan dikirimkan dengan sebuah flag PSH diset ke nilai 1. Contoh dari penggunaan lainnya dari flag ini adalah pada segmen terakhir dari berkas yang ditransfer dengan menggunakan protokol FTP. Segmen yang dikirimkan dengan flag PSH aktif tidak harus segera di-acknowledge oleh penerima.
RST
Mengindikasikan bahwa koneksi yang dibuat akan digagalkan. Untuk sebuah koneksi TCP yang sedang berjalan (aktif), sebuah segmen dengan flag RST diset ke nilai 1 akan dikirimkan sebagai respons terhadap sebuah segmen TCP yang diterima yang ternyata segmen tersebut bukan yang diminta, sehingga koneksi pun menjadi gagal. Pengiriman segmen dengan flag RST diset ke nilai 1 untuk sebuah koneksi aktif akan menutup koneksi secara paksa, sehingga data yang disimpan dalam buffer akan dibuang (dihilangkan). Untuk sebuah koneksi TCP yang sedang dibuat, segmen dengan flag RST aktif akan dikirimkan sebagai respons terhadap request pembuatan koneksi untuk mencegah percobaan pembuatan koneksi.
SYN
Mengindikasikan bahwa segmen TCP yang bersangkutan mengandung Initial Sequence Number (ISN). Selama proses pembuatan sesi koneksi TCP, TCP akan mengirimkan sebuah segmen dengan flag SYN diset ke nilai 1. Setiap host TCP lainnya akan memberikan jawaban (acknowledgment) dari segmen dengan flag SYN tersebut dengan menganggap bahwa segmen tersebut merupakan sekumpulan byte dari data. Field Acknowledgment Number dari sebuah segmen SYN diatur ke nilai ISN + 1.
FIN
Menandakan bahwa pengirim segmen TCP telah selesai dalam mengirimkan data dalam sebuah koneksi TCP. Ketika sebuah koneksi TCP akhirnya dihentikan (akibat sudah tidak ada data yang dikirimkan lagi), setiap host TCP akan mengirimkan sebuah segmen TCP dengan flag FIN diset ke nilai 1. Sebuah host TCP tidak akan mengirimkan segmen dengan flag FIN hingga semua data yang dikirimkannya telah diterima dengan baik (menerima paket acknowledgment) oleh penerima. Setiap host akan menganggap sebuah segmen TCP dengan flag FIN sebagai sekumpulan byte dari data. Ketika dua host TCP telah mengirimkan segmen TCP dengan flag FIN dan menerima acknowledgment dari segmen tersebut, maka koneksi TCP pun akan dihentikan.
[sunting] TCP Three-way handshake
Proses pembuatan koneksi (TCP Three way handshake)
Proses pembuatan koneksi TCP disebut juga dengan "Three-way Handshake". Tujuan metode ini adalah agar dapat melakukan sinkronisasi terhadap nomor urut dan nomor acknowledgement yang dikirimkan oleh kedua pihak dan saling bertukar ukuran TCP Window. Prosesnya dapat digambarkan sebagai berikut:
Host pertama (yang ingin membuat koneksi) akan mengirimkan sebuah segmen TCP dengan flag SYN diaktifkan kepada host kedua (yang hendak diajak untuk berkomunikasi).
Host kedua akan meresponsnya dengan mengirimkan segmen dengan acknowledgment dan juga SYN kepada host pertama.
Host pertama selanjutnya akan mulai saling bertukar data dengan host kedua.
TCP menggunakan proses jabat tangan yang sama untuk mengakhiri koneksi yang dibuat. Hal ini menjamin dua host yang sedang terkoneksi tersebut telah menyelesaikan proses transmisi data dan semua data yang ditransmisikan telah diterima dengan baik. Itulah sebabnya, mengapa TCP disebut dengan koneksi yang reliable.
Diperoleh dari "http://id.wikipedia.org/wiki/Transmission_Control_Protocol"
B.PERANGKAT AKSES INTERNET
Mengakses ke Internet berarti menghubungkan komputer kita dengan menggunakan media pengirim data ke jaringan Internet. Dan untuk mengakses Internet harus melalui yang dinamakan Internet Service Provider, penyedia layanan Internet. Untuk menjangkau penyedia layanan Internet diperlukan suatu media yang dapat dipakai untuk menghubungkan komputer kita ke penyedia layanan Internet. Misalnya, saluran telepon.
Menurut pengamatan saya, saat ini di Surabaya sudah ada lebih dari sepuluh penyedia layanan Internet. Sehingga kita yang di Surabaya bisa mengakses Internet melalui salah satu penyedia layanan Internet itu dengan saluran telepon, agar biayanya cukup pulsa lokal. Jangan lupa, untuk bergabung dengan penyedia layanan Internet itu sendiri ada iuran bulanannya. Besarnya tergantung pada penyedia layanan Internetnya. Tapi yang bertempat tinggal di Bojonegoro, misalnya, jelas harus dengan saluran telepon interlokal untuk dapat menghubungi penyedia layanan Internet yang ada di Surabaya, dari pada menghubungi penyedia layanan Internet yang ada di Jakarta.
Menjelajah dalam rimba raya Internet itu tidak harus menggunakan saluran telepon, dengan jalan dial up ke suatu penyedia layanan Internet. Untuk menghubungkan komputer kita ke jaringan Internet ada banyak media yang tersedia. Misalnya, ada yang dinamakan kabel ethernet seperti pada local area network (LAN). Kalau mau yang berkecepatan tinggi dapat menggunakan microwave. Tapi, kalau ingin yang murah meriah dan bebas pulsa dapat menggunakan packet radio, yang bahasa Indonesianya radio paket.
Menurut hemat saya, radio paket ini cukup menarik untuk dikembangkan sebagai media yang dapat menghubungkan komputer kita ke Internet. Teknologi komunikasi radio paket ini menggunakan media pengirim data berupa gelombang radio, bukan kabel. Biasanya, di laboratorium komputer sudah ada jaringan LAN. Komputer di laboratorium itu berfungsi sebagai gateway ke jaringan Internet. Komputer-komputer lain yang belum terintegrasi dalam jaringan LAN dapat digabung dalam jaringan radio paket, agar dapat mengakses Internet.
Perangkat-perangkat yang diperlukan untuk membangun jaringan radio paket terdiri dari komputer PC (XT ke atas), modem radio (beda dengan modem telepon), radio transceiver, dan perangkat lunak.
Modem radio yang digunakan ada dua macam. Yang pertama terminal node controller (TNC) modem. Modem ini dapat diperoleh biasanya di toko amatir radio di Jakarta atau di Bandung. Modem yang kedua biasanya bikinan sendiri, sering disebut Baycom Like modem. Modem-modem itu mempunyai kecepatan 300, 600, 1200, 9600, 19200 byte per sekon. Yang banyak diminati modem dengan kecepatan 1200 byte per sekon.
Radio transceiver yang memadai untuk jaringan radio paket adalah handy talky (HT) atau very high frequency (VHF) rig, yang pas untuk kecepatan 1200 byte per sekon.
Perangkat lunaknya menggunakan Network Operating System (NOS) oleh Phil Kam di bawah DOS. Perangkat lunak ini dapat diambil (down load) di http://www.lp.itb.ac.id/~yc1dav/
Saat ini jaringan radio paket baru dapat digunakan di kampus-kampus perguruan tinggi dan lembaga-lembaga riset teknologi, seperti ITB, UNIBRAW, UMM, BPPT, LAPAN, LIPI, LEN, dan lain-lain.
Jadi kalau ingin menikmati akses Internet yang murah dan bebas pulsa, Anda harus tinggal berdekatan dengan lembaga yang mempunyai jaringan radio paket. Perangkat-perangkat yang diperlukan komputer PC minimal XT, modem radio 1200 byte per sekon, dan HT, serta perangkat lunak komunikasinya, sudah cukup untuk menjalankan aplikasi electronic mail. Semakin besar kecepatan modem radio yang digunakan, semakin banyak data yang dapat ditransfer untuk menjalankan aplikasi tertentu. Misalnya e-mail, transfer file, news, dan telnet.
Teknologi komunikasi radio paket lebih menguntungkan untuk komunikasi jarak jauh dibandingkan dengan telepon interlokal. Dengan radio paket tidak ada ketergantungan pada perusahaan jasa telekomunikasi di Indonesia. Biaya operasional jauh lebih murah dari pada menyewa leased line telepon selama 24 jam.
Perangkat keras, perangkat lunak, dan dokumentasi praktis terbuka, dan sebagian bahkan dapat diperoleh secara gratis. Ditinjau dari teknologinya, radio paket ini dimungkinkan bekerja dengan kecepatan tinggi sekali, beberapa mega byte per sekon, untuk jarak jauh dengan biaya sangat murah. Saluran telepon yang paling baik hanya mampu dengan kecepatan sekitar 19,2 kilo byte per sekon.
Teknologi radio paket ini kurang menguntungkan untuk digunakan di dalam gedung (jarak dekat). Kemudian teknologi radio paket dengan kecepatan 1200 byte per sekon, termasuk low end, sebenarnya tidak baik untuk TCP/IP. Perlu up-grade ke 9600 byte per sekon, tidak sukar dan biayanya murah.
Apakah kita memerlukan izin untuk mengoperasikan radio paket? Jawabnya, ya. Kita harus mengantongi izin penggunaan frekuensi dari Dirjen Postel Deparpostel. Ada beberapa alternatif frekuensi yang mungkin diberikan izin penggunaannya. Misalnya frekuensi untuk amatir radio, citizen band, atau commercial band.
Mengakses ke Internet berarti menghubungkan komputer kita dengan menggunakan media pengirim data ke jaringan Internet. Dan untuk mengakses Internet harus melalui yang dinamakan Internet Service Provider, penyedia layanan Internet. Untuk menjangkau penyedia layanan Internet diperlukan suatu media yang dapat dipakai untuk menghubungkan komputer kita ke penyedia layanan Internet. Misalnya, saluran telepon.
Menurut pengamatan saya, saat ini di Surabaya sudah ada lebih dari sepuluh penyedia layanan Internet. Sehingga kita yang di Surabaya bisa mengakses Internet melalui salah satu penyedia layanan Internet itu dengan saluran telepon, agar biayanya cukup pulsa lokal. Jangan lupa, untuk bergabung dengan penyedia layanan Internet itu sendiri ada iuran bulanannya. Besarnya tergantung pada penyedia layanan Internetnya. Tapi yang bertempat tinggal di Bojonegoro, misalnya, jelas harus dengan saluran telepon interlokal untuk dapat menghubungi penyedia layanan Internet yang ada di Surabaya, dari pada menghubungi penyedia layanan Internet yang ada di Jakarta.
Menjelajah dalam rimba raya Internet itu tidak harus menggunakan saluran telepon, dengan jalan dial up ke suatu penyedia layanan Internet. Untuk menghubungkan komputer kita ke jaringan Internet ada banyak media yang tersedia. Misalnya, ada yang dinamakan kabel ethernet seperti pada local area network (LAN). Kalau mau yang berkecepatan tinggi dapat menggunakan microwave. Tapi, kalau ingin yang murah meriah dan bebas pulsa dapat menggunakan packet radio, yang bahasa Indonesianya radio paket.
Menurut hemat saya, radio paket ini cukup menarik untuk dikembangkan sebagai media yang dapat menghubungkan komputer kita ke Internet. Teknologi komunikasi radio paket ini menggunakan media pengirim data berupa gelombang radio, bukan kabel. Biasanya, di laboratorium komputer sudah ada jaringan LAN. Komputer di laboratorium itu berfungsi sebagai gateway ke jaringan Internet. Komputer-komputer lain yang belum terintegrasi dalam jaringan LAN dapat digabung dalam jaringan radio paket, agar dapat mengakses Internet.
Perangkat-perangkat yang diperlukan untuk membangun jaringan radio paket terdiri dari komputer PC (XT ke atas), modem radio (beda dengan modem telepon), radio transceiver, dan perangkat lunak.
Modem radio yang digunakan ada dua macam. Yang pertama terminal node controller (TNC) modem. Modem ini dapat diperoleh biasanya di toko amatir radio di Jakarta atau di Bandung. Modem yang kedua biasanya bikinan sendiri, sering disebut Baycom Like modem. Modem-modem itu mempunyai kecepatan 300, 600, 1200, 9600, 19200 byte per sekon. Yang banyak diminati modem dengan kecepatan 1200 byte per sekon.
Radio transceiver yang memadai untuk jaringan radio paket adalah handy talky (HT) atau very high frequency (VHF) rig, yang pas untuk kecepatan 1200 byte per sekon.
Perangkat lunaknya menggunakan Network Operating System (NOS) oleh Phil Kam di bawah DOS. Perangkat lunak ini dapat diambil (down load) di http://www.lp.itb.ac.id/~yc1dav/
Saat ini jaringan radio paket baru dapat digunakan di kampus-kampus perguruan tinggi dan lembaga-lembaga riset teknologi, seperti ITB, UNIBRAW, UMM, BPPT, LAPAN, LIPI, LEN, dan lain-lain.
Jadi kalau ingin menikmati akses Internet yang murah dan bebas pulsa, Anda harus tinggal berdekatan dengan lembaga yang mempunyai jaringan radio paket. Perangkat-perangkat yang diperlukan komputer PC minimal XT, modem radio 1200 byte per sekon, dan HT, serta perangkat lunak komunikasinya, sudah cukup untuk menjalankan aplikasi electronic mail. Semakin besar kecepatan modem radio yang digunakan, semakin banyak data yang dapat ditransfer untuk menjalankan aplikasi tertentu. Misalnya e-mail, transfer file, news, dan telnet.
Teknologi komunikasi radio paket lebih menguntungkan untuk komunikasi jarak jauh dibandingkan dengan telepon interlokal. Dengan radio paket tidak ada ketergantungan pada perusahaan jasa telekomunikasi di Indonesia. Biaya operasional jauh lebih murah dari pada menyewa leased line telepon selama 24 jam.
Perangkat keras, perangkat lunak, dan dokumentasi praktis terbuka, dan sebagian bahkan dapat diperoleh secara gratis. Ditinjau dari teknologinya, radio paket ini dimungkinkan bekerja dengan kecepatan tinggi sekali, beberapa mega byte per sekon, untuk jarak jauh dengan biaya sangat murah. Saluran telepon yang paling baik hanya mampu dengan kecepatan sekitar 19,2 kilo byte per sekon.
Teknologi radio paket ini kurang menguntungkan untuk digunakan di dalam gedung (jarak dekat). Kemudian teknologi radio paket dengan kecepatan 1200 byte per sekon, termasuk low end, sebenarnya tidak baik untuk TCP/IP. Perlu up-grade ke 9600 byte per sekon, tidak sukar dan biayanya murah.
Apakah kita memerlukan izin untuk mengoperasikan radio paket? Jawabnya, ya. Kita harus mengantongi izin penggunaan frekuensi dari Dirjen Postel Deparpostel. Ada beberapa alternatif frekuensi yang mungkin diberikan izin penggunaannya. Misalnya frekuensi untuk amatir radio, citizen band, atau commercial band.
Domain Name System
From Wikipedia, the free encyclopedia
Jump to: navigation, search
The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participants. Most importantly, it translates domain names meaningful to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide. An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, www.example.com translates to 208.77.188.166.
The Domain Name System makes it possible to assign domain names to groups of Internet users in a meaningful way, independent of each user's physical location. Because of this, World-Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). People take advantage of this when they recite meaningful URLs and e-mail addresses without having to know how the machine will actually locate them.
The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed, fault tolerant, and helped avoid the need for a single central register to be continually consulted and updated.
In general, the Domain Name System also stores other types of information, such as the list of mail servers that accept email for a given Internet domain. By providing a worldwide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet.
Other identifiers such as RFID tags, UPC codes, International characters in email addresses and host names, and a variety of other identifiers could all potentially utilize DNS.[1]
The Domain Name System also defines the technical underpinnings of the functionality of this database service. For this purpose it defines the DNS protocol, a detailed specification of the data structures and communication exchanges used in DNS, as part of the Internet Protocol Suite (TCP/IP). The DNS protocol was developed and defined in the early 1980s and published by the Internet Engineering Task Force (cf. History).
The Internet Protocol Suite
Application Layer
DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · BGP · OSPF · (more)
Link Layer
ARP · RARP · NDP · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, MPLS, DSL, ISDN, FDDI) · Device Drivers · (more)
This box: view • talk • edit
Contents
[hide]
1 History
2 Structure
2.1 The domain name space
2.2 Parts of a domain name
2.3 DNS servers
2.4 DNS resolvers
3 Operation
3.1 Address resolution mechanism
3.2 Circular dependencies and glue records
3.3 Caching and time to live
3.4 Caching time
3.5 Client lookup
3.5.1 Broken resolvers
3.6 Other applications
4 Protocol details
5 DNS resource records
5.1 Wildcard DNS records
6 Protocol extensions
7 Internationalized domain names
8 Security issues
9 Domain name registration
10 Abuse and regulation
10.1 Truth in Domain Names Act
11 Internet standards
11.1 Security
12 See also
13 References
14 External links
[edit] History
The practice of using a name as a more human-legible abstraction of a machine's numerical address on the network predates even TCP/IP. This practice dates back to the ARPAnet era. Back then, a different system was used. The DNS was invented in 1983, shortly after TCP/IP was deployed. With the older system, each computer on the network retrieved a file called HOSTS.TXT from a computer at SRI (now SRI International)[2][3][4]. The HOSTS.TXT file mapped numerical addresses to names. A hosts file still exists on most modern operating systems, either by default or through configuration, and allows users to specify an IP address (eg. 208.77.188.166) to use for a hostname (eg. www.example.net) without checking DNS. Systems based on a hosts file have inherent limitations, because of the obvious requirement that every time a given computer's address changed, every computer that seeks to communicate with it would need an update to its hosts file.
The growth of networking required a more scalable system that recorded a change in a host's address in one place only. Other hosts would learn about the change dynamically through a notification system, thus completing a globally accessible network of all hosts' names and their associated IP Addresses.
At the request of Jon Postel, Paul Mockapetris invented the Domain Name System in 1983 and wrote the first implementation. The original specifications appear in RFC 882 and RFC 883 which were superseded in November 1987 by RFC 1034[5] and RFC 1035[6]. Several additional Request for Comments have proposed various extensions to the core DNS protocols.
In 1984, four Berkeley students—Douglas Terry, Mark Painter, David Riggle and Songnian Zhou—wrote the first UNIX implementation, which was maintained by Ralph Campbell thereafter. In 1985, Kevin Dunlap of DEC significantly re-wrote the DNS implementation and renamed it BIND—Berkeley Internet Name Domain. Mike Karels, Phil Almquist and Paul Vixie have maintained BIND since then. BIND was ported to the Windows NT platform in the early 1990s.
BIND was widely distributed, especially on Unix systems, and is the dominant DNS software in use on the Internet.[7] With the heavy use and resulting scrutiny of its open-source code, as well as increasingly more sophisticated attack methods, many security flaws were discovered in BIND. This contributed to the development of a number of alternative nameserver and resolver programs. BIND itself was re-written from scratch in version 9, which has a security record comparable to other modern Internet software.
[edit] Structure
[edit] The domain name space
The hierarchical domain name system, organized into zones, each served by a name server.
The domain name space consists of a tree of domain names. Each node or leaf in the tree has zero or more resource records, which hold information associated with the domain name. The tree sub-divides into zones beginning at the root zone. A DNS zone consists of a collection of connected nodes authoritatively served by an authoritative nameserver. (Note that a single nameserver can host several zones.)
Administrative responsibility over any zone may be divided, thereby creating additional zones. Authority is said to be delegated for a portion of the old space, usually in form of sub-domains, to another nameserver and administrative entity. The old zone ceases to be authoritative for the new zone.
[edit] Parts of a domain name
A domain name usually consists of two or more parts (technically labels), which are conventionally written separated by dots, such as example.com.
The rightmost label conveys the top-level domain (for example, the address www.example.com has the top-level domain com).
Each label to the left specifies a subdivision, or subdomain of the domain above it. Note: “subdomain” expresses relative dependence, not absolute dependence. For example: example.com is a subdomain of the com domain, and www.example.com is a subdomain of the domain example.com. In theory, this subdivision can go down 127 levels. Each label can contain up to 63 octets. The whole domain name may not exceed a total length of 253 octets. [8] In practice, some domain registries may have shorter limits.
A hostname refers to a domain name that has one or more associated IP addresses (e.g., the 'www.example.com' and 'example.com' domains are both hostnames, whereas the 'com' domain is not).
[edit] DNS servers
Main article: Name server
The Domain Name System is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the name servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD).
[edit] DNS resolvers
See also: resolv.conf
The client-side of the DNS is called a DNS resolver. It is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP address.
A DNS query may be either a recursive query or a non-recursive query:
A non-recursive query is one in which the DNS server may provide a partial answer to the query (or give an error).
A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries.
The resolver (or another DNS server acting recursively on behalf of the resolver) negotiates use of recursive service using bits in the query headers.
Resolving usually entails iterating through several name servers to find the needed information. However, some resolvers function simplistically and can communicate only with a single name server. These simple resolvers rely on a recursive query to a recursive name server to perform the work of finding information for them.
[edit] Operation
[edit] Address resolution mechanism
A domain name may have several name components (e.g., ahost.ofasubnet.ofabiggernet.inadomain.example). In practice, full host names will frequently consist of just three segments: ahost.inadomain.example, and most often www.inadomain.example. For querying purposes, software interprets the name segment by segment, from right to left. At each step along the way, the program queries a corresponding DNS server to provide a pointer to the next server which it should consult.
A DNS recursor consults three nameservers to resolve the address www.wikipedia.org.
As originally envisaged, the process was as simple as:
1.the local system is pre-configured with the known addresses of the root servers in a file of root hints, which need to be updated periodically by the local administrator from a reliable source to be kept up to date with the changes which occur over time.
2.query one of the root servers to find the server authoritative for the next level down (so in the case of our simple hostname, a root server would be asked for the address of a server with detailed knowledge of the example top level domain).
3.querying this second server for the address of a DNS server with detailed knowledge of the second-level domain (inadomain.example in our example).
4.repeating the previous step to progress down the name, until the final step which would, rather than generating the address of the next DNS server, return the final address sought.
The diagram illustrates this process for the real host www.wikipedia.org.
The mechanism in this simple form has a difficulty: it places a huge operating burden on the root servers, with every search for an address starting by querying one of them. Being as critical as they are to the overall function of the system, such heavy use would create an insurmountable bottleneck for trillions of queries placed every day. In practice caching is used to overcome this problem, and, in fact, root nameservers deal with very little of the total traffic.
[edit] Circular dependencies and glue records
Name servers in delegations appear listed by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. Since this can introduce a circular dependency if the nameserver referred to is under the domain that it is authoritative of, it is occasionally necessary for the nameserver providing the delegation to also provide the IP address of the next nameserver. This record is called a glue record.
For example, assume that the sub-domain en.wikipedia.org contains further sub-domains (such as something.en.wikipedia.org) and that the authoritative name server for these lives at ns1.something.en.wikipedia.org. A computer trying to resolve something.en.wikipedia.org will thus first have to resolve ns1.something.en.wikipedia.org. Since ns1 is also under the something.en.wikipedia.org subdomain, resolving ns1.something.en.wikipedia.org requires resolving something.en.wikipedia.org which is exactly the circular dependency mentioned above. The dependency is broken by the glue record in the nameserver of en.wikipedia.org that provides the IP address of ns1.something.en.wikipedia.org directly to the requestor, enabling it to bootstrap the process by figuring out where ns1.something.en.wikipedia.org is located.
[edit] Caching and time to live
Because of the huge volume of requests generated by a system like DNS, the designers wished to provide a mechanism to reduce the load on individual DNS servers. To this end, the DNS resolution process allows for caching (i.e. the local recording and subsequent consultation of the results of a DNS query) for a given period of time after a successful answer. How long a resolver caches a DNS response (i.e. how long a DNS response remains valid) is determined by a value called the time to live (TTL). The TTL is set by the administrator of the DNS server handing out the response. The period of validity may vary from just seconds to days or even weeks.
[edit] Caching time
As a noteworthy consequence of this distributed and caching architecture, changes to DNS records do not always take effect immediately and globally. This is best explained with an example: If an administrator has set a TTL of 6 hours for the host www.wikipedia.org, and then changes the IP address to which www.wikipedia.org resolves at 12:01pm, the administrator must consider that a person who cached a response with the old IP address at 12:00noon will not consult the DNS server again until 6:00pm. The period between 12:01pm and 6:00pm in this example is called caching time, which is best defined as a period of time that begins when you make a change to a DNS record and ends after the maximum amount of time specified by the TTL expires. This essentially leads to an important logistical consideration when making changes to DNS: not everyone is necessarily seeing the same thing you're seeing. RFC 1912 helps to convey basic rules for how to set the TTL.
Note that the term "propagation", although very widely used in this context, does not describe the effects of caching well. Specifically, it implies that [1] when you make a DNS change, it somehow spreads to all other DNS servers (instead, other DNS servers check in with yours as needed), and [2] that you do not have control over the amount of time the record is cached (you control the TTL values for all DNS records in your domain, except your NS records and any authoritative DNS servers that use your domain name).
Some resolvers may override TTL values, as the protocol supports caching for up to 68 years or no caching at all. Negative caching (the non-existence of records) is determined by name servers authoritative for a zone which MUST include the Start of Authority (SOA) record when reporting no data of the requested type exists. The MINIMUM field of the SOA record and the TTL of the SOA itself is used to establish the TTL for the negative answer. RFC 2308
Many people incorrectly refer to a mysterious 48 hour or 72 hour propagation time when you make a DNS change. When one changes the NS records for one's domain or the IP addresses for hostnames of authoritative DNS servers using one's domain (if any), there can be a lengthy period of time before all DNS servers use the new information. This is because those records are handled by the zone parent DNS servers (for example, the .com DNS servers if your domain is example.com), which typically cache those records for 48 hours. However, those DNS changes will be immediately available for any DNS servers that do not have them cached. And any DNS changes on your domain other than the NS records and authoritative DNS server names can be nearly instantaneous, if you choose for them to be (by lowering the TTL once or twice ahead of time, and waiting until the old TTL expires before making the change).
[edit] Client lookup
DNS resolution sequence.
Users generally do not communicate directly with a DNS resolver. Instead DNS resolution takes place transparently in applications programs such as web browsers, e-mail clients, and other Internet applications. When an application makes a request that requires a domain name lookup, such programs send a resolution request to the DNS resolver in the local operating system, which in turn handles the communications required.
The DNS resolver will almost invariably have a cache (see above) containing recent lookups. If the cache can provide the answer to the request, the resolver will return the value in the cache to the program that made the request. If the cache does not contain the answer, the resolver will send the request to one or more designated DNS servers. In the case of most home users, the Internet service provider to which the machine connects will usually supply this DNS server: such a user will either have configured that server's address manually or allowed DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers point to separately maintained nameservers of the organization. In any event, the name server thus queried will follow the process outlined above, until it either successfully finds a result or does not. It then returns its results to the DNS resolver; assuming it has found a result, the resolver duly caches that result for future use, and hands the result back to the software which initiated the request.
[edit] Broken resolvers
An additional level of complexity emerges when resolvers violate the rules of the DNS protocol. A number of large ISPs have configured their DNS servers to violate rules (presumably to allow them to run on less-expensive hardware than a fully-compliant resolver), such as by disobeying TTLs, or by indicating that a domain name does not exist just because one of its name servers does not respond.[9]
As a final level of complexity, some applications (such as web-browsers) also have their own DNS cache, in order to reduce the use of the DNS resolver library itself. This practice can add extra difficulty when debugging DNS issues, as it obscures the freshness of data, and/or what data comes from which cache. These caches typically use very short caching times — on the order of one minute. Internet Explorer offers a notable exception: recent[update] versions cache DNS records for half an hour.[10]
[edit] Other applications
The system outlined above provides a somewhat simplified scenario. The Domain Name System includes several other functions:
Hostnames and IP addresses do not necessarily match on a one-to-one basis. Many hostnames may correspond to a single IP address: combined with virtual hosting, this allows a single machine to serve many web sites. Alternatively a single hostname may correspond to many IP addresses: this can facilitate fault tolerance and load distribution, and also allows a site to move physical location seamlessly.
There are many uses of DNS besides translating names to IP addresses. For instance, Mail transfer agents use DNS to find out where to deliver e-mail for a particular address. The domain to mail exchanger mapping provided by MX records accommodates another layer of fault tolerance and load distribution on top of the name to IP address mapping.
E-mail Blacklists: The DNS system is used for efficient storage and distribution of IP addresses of blacklisted e-mail hosts. The usual method is putting the IP address of the subject host into the sub-domain of a higher level domain name, and resolve that name to different records to indicate a positive or a negative. A hypothetical example using blacklist.com,
102.3.4.5 is blacklisted => Creates 5.4.3.102.blacklist.com and resolves to 127.0.0.1
102.3.4.6 is not => 6.4.3.102.blacklist.com is not found, or default to 127.0.0.2
E-mail servers can then query blacklist.com through the DNS mechanism to find out if a specific host connecting to them is in the blacklist. Today many of such blacklists, either free or subscription-based, are available mainly for use by email administrators and anti-spam software.
Software Updates: many anti-virus and commercial software now use the DNS system to store version numbers of the latest software updates so client computers do not need to connect to the update servers every time. For these type of applications, the cache time of the DNS records are usually shorter.
Sender Policy Framework and DomainKeys, instead of creating their own record types, were designed to take advantage of another DNS record type, the TXT record.
To provide resilience in the event of computer failure, multiple DNS servers are usually provided for coverage of each domain, and at the top level, thirteen very powerful root servers exist, with additional "copies" of several of them distributed worldwide via Anycast.
[edit] Protocol details
DNS primarily uses User Datagram Protocol (UDP) on port number 53 [11] to serve requests. DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. The Transmission Control Protocol (TCP) is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers. Some operating systems, such as HP-UX, are known to have resolver implementations that use TCP for all queries, even when UDP would suffice.
[edit] DNS resource records
Further information: List of DNS record types
A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.), a TTL, a class and some type-specific information. All resource records of the same type define a Resource Record Set (RR set). The order that resource records in a RR set are returned by the resolver to an application is undefined (the server typically uses round-robin DNS). DNSSEC, however, works on complete RR sets in a canonical order.
When sent over the Internet, all records use the common format specified in RFC 1035 shown below.
RR (Resource record) fields
Field
Description
Length (octets)
NAME
Name of the node to which this record pertains.
(variable)
TYPE
Type of RR. For example, MX is type 15.
2
CLASS
Class code.
2
TTL
Signed time in seconds that RR stays valid.
4
RDLENGTH
Length of RDATA field.
2
RDATA
Additional RR-specific data.
(variable)
The NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be shortened using label compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the current domain name.
The TYPE of the record indicates what the format of the data is, and gives a hint of its intended use; for instance, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone, and the MX record is used to translate from a name in the right-hand side of an e-mail address to the name of a machine able to handle mail for that address. See List of DNS record types for a more complete list.
The RDATA is type-specific information, such as the actual IP address for A records, or the mail host for MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types can not (see RFC 3597).
The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames, servers, or IP addresses. In addition the classes CH (Chaos) and HS (Hesiod) exist. Each class is a completely independent trees with potentially different delegation of DNS zones.
In addition to resource records defined in a zone file, the domain name system also defines several request types that are used only on the wire, such as to perform zone transfers (AXFR/IXFR) or for EDNS (OPT).
[edit] Wildcard DNS records
Main article: Wildcard DNS record
The domain name system supports wildcard domain names which are names that start with the asterisk label, '*', e.g., *.example.[5][12] DNS records belonging to wildcard domain names specify rules for generating resource records within a single DNS zone by substituting whole labels with matching components of the query name, including any specified descendants. For example, in the DNS zone x.example, the following configuration specifies that all subdomains (including subdomains of subdomains) of x.example use the mail exchanger a.x.example. The records for a.x.example are needed to specify the mail exchanger. As this has the result of excluding this domain name and its subdomains from the wildcard matches, all subdomains of a.x.example must be defined in a separate wildcard statement.
X.EXAMPLE. MX 10 A.X.EXAMPLE.
*.X.EXAMPLE. MX 10 A.X.EXAMPLE.
*.A.X.EXAMPLE. MX 10 A.X.EXAMPLE.
A.X.EXAMPLE. MX 10 A.X.EXAMPLE.
A.X.EXAMPLE. AAAA 2001:db8::1
The role of wildcard records was refined in RFC 4592, because the original definition in RFC 1034 was incomplete and resulted in misinterpretations by implementers.[12]
[edit] Protocol extensions
EDNS is an extension of the DNS protocol which drops the maximum size requirement of 512 bytes of DNS replies when transported over UDP. It adds support for expanding the space of request and response codes. It is described in RFC 2671.
[edit] Internationalized domain names
Main article: Internationalized domain name
While domain names technically have no restrictions on the characters they use and can include non-ASCII characters, the same is not true for host names.[13] Host names are the names most people see and use for things like e-mail and web browsing. Host names are restricted to a small subset of the ASCII character set known as LDH, the Letters A–Z in upper and lower case, Digits 0–9, Hyphen, and the dot to separate LDH-labels; see RFC 3696 section 2 for details. This prevented the representation of names and words of many languages natively. ICANN has approved the Punycode-based IDNA system, which maps Unicode strings into the valid DNS character set, as a workaround to this issue. Some registries have adopted IDNA.
[edit] Security issues
DNS was not originally designed with security in mind, and thus has a number of security issues.
One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has received authentic information when, in reality, it has not.
DNS responses are traditionally not cryptographically signed, leading to many attack possibilities; The Domain Name System Security Extensions (DNSSEC) modifies DNS to add support for cryptographically signed responses. There are various extensions to support securing zone transfer information as well.
Even with encryption, a DNS server could become compromised by a virus (or for that matter a disgruntled employee) that would cause IP addresses of that server to be redirected to a malicious address with a long TTL. This could have far-reaching impact to potentially millions of Internet users if busy DNS servers cache the bad IP data. This would require manual purging of all affected DNS caches as required by the long TTL (up to 68 years).
Some domain names can spoof other, similar-looking domain names. For example, "paypal.com" and "paypa1.com" are different names, yet users may be unable to tell the difference when the user's typeface (font) does not clearly differentiate the letter l and the numeral 1. This problem is much more serious in systems that support internationalized domain names, since many characters that are different, from the point of view of ISO 10646, appear identical on typical computer screens. This vulnerability is often exploited in phishing.
Techniques such as Forward Confirmed reverse DNS can also be used to help validate DNS results.
[edit] Domain name registration
The right to use a domain name is delegated by domain name registrars which are accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), the organization charged with overseeing the name and number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced technically by an administrative organization, operating a registry. A registry is responsible for maintaining the database of names registered within the TLD it administers. The registry receives registration information from each domain name registrar authorized to assign names in the corresponding TLD and publishes the information using a special service, the whois protocol.
Registries and registrars usually charge an annual fee for the service of delegating a domain name to a user and providing a default set of name servers. Often this transaction is termed a sale or lease of the domain name, and the registrant may sometimes be called an "owner", but no such legal relationship is actually associated with the transaction, only the exclusive right to use the domain name. More correctly, authorized users are known as "registrants" or as "domain holders".
ICANN publishes a complete list of TLD registries and domain name registrars in the world. One can obtain information about the registrant of a domain name by looking in the WHOIS database held by many domain registries.
For most of the more than 240 country code top-level domains (ccTLDs), the domain registries hold the authoritative WHOIS (Registrant, name servers, expiration dates, etc.). For instance, DENIC, Germany NIC, holds the authoritative WHOIS to a .DE domain name. Since about 2001, most gTLD registries (.ORG, .BIZ, .INFO) have adopted this so-called "thick" registry approach, i.e. keeping the authoritative WHOIS in the central registries instead of the registrars.
For COM and NET domain names, a "thin" registry is used: the domain registry (e.g. VeriSign) holds a basic WHOIS (registrar and name servers, etc.). One can find the detailed WHOIS (registrant, name servers, expiry dates, etc.) at the registrars.
Some domain name registries, often called network information centers (NIC), also function as registrars to end-users. The major generic top-level domain registries, such as for the COM, NET, ORG, INFO domains and others, use a registry-registrar model consisting of hundreds of domain name registrars (see lists at ICANN or VeriSign). In this method of management, the registry only manages the domain name database and the relationship with the registrars. The registrants (users of a domain name) are customers of the registrar, in some cases through additional layers of resellers.
In the process of registering a domain name and maintaining authority over the new name space created, registrars use several key pieces of information connected with a domain:
Administrative contact. A registrant usually designates an administrative contact to manage the domain name. The administrative contact usually has the highest level of control over a domain. Management functions delegated to the administrative contacts may include management of all business information, such as name of record, postal address, and contact information of the official registrant of the domain and the obligation to conform to the requirements of the domain registry in order to retain the right to use a domain name. Furthermore the administrative contact installs additional contact information for technical and billing functions.
Technical contact. The technical contact manages the name servers of a domain name. The functions of a technical contact include assuring conformance of the configurations of the domain name with the requirements of the domain registry, maintaining the domain zone records, and providing continuous functionality of the name servers (that leads to the accessibility of the domain name).
Billing contact. The party responsible for receiving billing invoices from the domain name registrar and paying applicable fees.
Name servers. Most registrars provide two or more name servers as part of the registration service. However, a registrant may specify its own authoritative name servers to host a domain's resource records. The registrar's policies govern the number of servers and the type of server information required. Some providers require a hostname and the corresponding IP address or just the hostname, which must be resolvable either in the new domain, or exist elsewhere. Based on traditional requirements (RFC 1034), typically a minimum of two servers is required.
[edit] Abuse and regulation
Critics often claim abuse of administrative power over domain names. Particularly noteworthy was the VeriSign Site Finder system which redirected all unregistered .com and .net domains to a VeriSign webpage. For example, at a public meeting with VeriSign to air technical concerns about SiteFinder [14], numerous people, active in the IETF and other technical bodies, explained how they were surprised by VeriSign's changing the fundamental behavior of a major component of Internet infrastructure, not having obtained the customary consensus. SiteFinder, at first, assumed every Internet query was for a website, and it monetized queries for incorrect domain names, taking the user to VeriSign's search site. Unfortunately, other applications, such as many implementations of email, treat a lack of response to a domain name query as an indication that the domain does not exist, and that the message can be treated as undeliverable. The original VeriSign implementation broke this assumption for mail, because it would always resolve an erroneous domain name to that of SiteFinder. While VeriSign later changed SiteFinder's behaviour with regard to email, there was still widespread protest about VeriSign's action being more in its financial interest than in the interest of the Internet infrastructure component for which VeriSign was the steward.
Despite widespread criticism, VeriSign only reluctantly removed it after the Internet Corporation for Assigned Names and Numbers (ICANN) threatened to revoke its contract to administer the root name servers. ICANN published the extensive set of letters exchanged, committee reports, and ICANN decisions [15].
There is also significant disquiet regarding the United States' political influence over ICANN. This was a significant issue in the attempt to create a .xxx top-level domain and sparked greater interest in alternative DNS roots that would be beyond the control of any single country.[16]
Additionally, there are numerous accusations of domain name "front running", whereby registrars, when given whois queries, automatically register the domain name for themselves. Recently, Network Solutions has been accused of this.[17]
[edit] Truth in Domain Names Act
Main article: Anticybersquatting Consumer Protection Act
In the United States, the "Truth in Domain Names Act" (actually the "Anticybersquatting Consumer Protection Act"), in combination with the PROTECT Act, forbids the use of a misleading domain name with the intention of attracting people into viewing a visual depiction of sexually explicit conduct on the Internet.
[edit] Internet standards
The Domain Name System is defined by Request for Comments (RFC) documents published by the Internet Engineering Task Force (Internet standards). The following is a list of RFCs that define the DNS protocol.
RFC 920, Domain Requirements - Specified original top-level domains
RFC 1032, Domain Administrators Guide
RFC 1033, Domain Administrators Operations Guide
RFC 1034, Domain Names - Concepts and Facilities
RFC 1035, Domain Names - Implementation and Specification
RFC 1101, DNS Encodings of Network Names and Other Types
RFC 1123, Requirements for Internet Hosts—Application and Support
RFC 1178, Choosing a Name for Your Computer (FYI 5)
RFC 1183, New DNS RR Definitions
RFC 1591, Domain Name System Structure and Delegation (Informational)
RFC 1912, Common DNS Operational and Configuration Errors
RFC 1995, Incremental Zone Transfer in DNS
RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
RFC 2100, The Naming of Hosts (Informational)
RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
RFC 2181, Clarifications to the DNS Specification
RFC 2182, Selection and Operation of Secondary DNS Servers
RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
RFC 2671, Extension Mechanisms for DNS (EDNS0)
RFC 2672, Non-Terminal DNS Name Redirection
RFC 3225, Indicating Resolver Support of DNSSEC
RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)
RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
RFC 4592, The Role of Wildcards in the Domain Name System
RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)
RFC 5001, DNS Name Server Identifier (NSID) Option
RFC 5395, Domain Name System (DNS) IANA Considerations (BCP 42)
[edit] Security
RFC 4033, DNS Security Introduction and Requirements
RFC 4034, Resource Records for the DNS Security Extensions
RFC 4035, Protocol Modifications for the DNS Security Extensions
[edit] See also
Dynamic DNS
Alternative DNS root
Comparison of DNS server software
Round robin DNS
Split-horizon DNS
DNS management software
DNS cache poisoning
DNS hijacking
List of DNS record types
[edit] References
1.^ Mockapetris, Paul (2004-01-02). "Letting DNS Loose". CircleID. http://www.circleid.com/posts/letting_dns_loose/.
2.^ RFC 3467 - Role of the Domain Name System (DNS)
3.^ "History of the DNS". http://www.lagunainternet.com/techsupport/history_of_dns.htm. Retrieved on 2008-04-29.
4.^ Cricket Liu, Paul Albitz. "DNS & BIND". O'Reilly (shown via Google Books). http://books.google.co.uk/books?id=zkZN52WhG8sC&pg=PA3&lpg=PA3&dq=sri+HOSTS.TXT&source=web&ots=wuZ79E-zJ2&sig=btF0Z2nclOnX_UgNj7a1f5S7Uqg&hl=en. Retrieved on 2008-04-29.
5.^ a b RFC 1034, Domain names - Concepts and Facilities, P. Mockapetris (November 1987)
6.^ RFC 1035, Domain names - Implementation and Specification, P. Mockapetris (November 1987)
7.^ http://mydns.bboy.net/survey/ DNS Server Survey
8.^ What is the maximum length of a domain name? on the IETF DNSOP working group mailing list. On the wire, in the DNS binary format, it can be at most 255 octets as per RFC 1034 section 3.1. For an all-ASCII hostname, this can be represented in traditional dot notation as 253 characters.
9.^ "Providers ignoring DNS TTL ?". Slashdot. 2005. http://ask.slashdot.org/article.pl?sid=05/04/18/198259. Retrieved on 2009-01-03.
10.^ "How Internet Explorer uses the cache for DNS host entries". Microsoft. 2004. http://support.microsoft.com/default.aspx?scid=KB;en-us;263558. Retrieved on 2006-03-07.
11.^ Mockapetris, P (November 1987). "RFC 1035: Domain Names - Implementation and Specification". http://www.ietf.org/rfc/rfc1035.txt.
12.^ a b RFC 4592, The Role of Wildcards in the Domain Name System, E. Lewis (July 2006)
13.^ The term host name is here being used to mean an FQDN for a host, such as eg. en.wikipedia.org., and not just (to use the same example) en .
While most domain names do indeed designate hosts, some domain name DNS entries may not. In this sense, a (FQDN) hostname is a type of domain name, but not all domain names are actual host names. Cf. this host name vs domain name explanation from the DNS OP IETF Working Group.
14.^ McCullagh, Declan (2003-10-03). "VeriSign fends off critics at ICANN confab". CNET News.com. http://www.news.com/2100-1038-5088128.html. Retrieved on 2007-09-22.
15.^ Internet Corporation for Assigned Names and Numbers (ICANN). "Verisign's Wildcard Service Deployment". http://www.icann.org/topics/wildcard-history.html. Retrieved on 2007-09-22.
16.^ Mueller, M (March 2004). Ruling the Root. MIT Press. ISBN 0262632985.
17.^ Slashdot | NSI Registers Every Domain Checked
From Wikipedia, the free encyclopedia
Jump to: navigation, search
The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participants. Most importantly, it translates domain names meaningful to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide. An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, www.example.com translates to 208.77.188.166.
The Domain Name System makes it possible to assign domain names to groups of Internet users in a meaningful way, independent of each user's physical location. Because of this, World-Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). People take advantage of this when they recite meaningful URLs and e-mail addresses without having to know how the machine will actually locate them.
The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed, fault tolerant, and helped avoid the need for a single central register to be continually consulted and updated.
In general, the Domain Name System also stores other types of information, such as the list of mail servers that accept email for a given Internet domain. By providing a worldwide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet.
Other identifiers such as RFID tags, UPC codes, International characters in email addresses and host names, and a variety of other identifiers could all potentially utilize DNS.[1]
The Domain Name System also defines the technical underpinnings of the functionality of this database service. For this purpose it defines the DNS protocol, a detailed specification of the data structures and communication exchanges used in DNS, as part of the Internet Protocol Suite (TCP/IP). The DNS protocol was developed and defined in the early 1980s and published by the Internet Engineering Task Force (cf. History).
The Internet Protocol Suite
Application Layer
DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · BGP · OSPF · (more)
Link Layer
ARP · RARP · NDP · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, MPLS, DSL, ISDN, FDDI) · Device Drivers · (more)
This box: view • talk • edit
Contents
[hide]
1 History
2 Structure
2.1 The domain name space
2.2 Parts of a domain name
2.3 DNS servers
2.4 DNS resolvers
3 Operation
3.1 Address resolution mechanism
3.2 Circular dependencies and glue records
3.3 Caching and time to live
3.4 Caching time
3.5 Client lookup
3.5.1 Broken resolvers
3.6 Other applications
4 Protocol details
5 DNS resource records
5.1 Wildcard DNS records
6 Protocol extensions
7 Internationalized domain names
8 Security issues
9 Domain name registration
10 Abuse and regulation
10.1 Truth in Domain Names Act
11 Internet standards
11.1 Security
12 See also
13 References
14 External links
[edit] History
The practice of using a name as a more human-legible abstraction of a machine's numerical address on the network predates even TCP/IP. This practice dates back to the ARPAnet era. Back then, a different system was used. The DNS was invented in 1983, shortly after TCP/IP was deployed. With the older system, each computer on the network retrieved a file called HOSTS.TXT from a computer at SRI (now SRI International)[2][3][4]. The HOSTS.TXT file mapped numerical addresses to names. A hosts file still exists on most modern operating systems, either by default or through configuration, and allows users to specify an IP address (eg. 208.77.188.166) to use for a hostname (eg. www.example.net) without checking DNS. Systems based on a hosts file have inherent limitations, because of the obvious requirement that every time a given computer's address changed, every computer that seeks to communicate with it would need an update to its hosts file.
The growth of networking required a more scalable system that recorded a change in a host's address in one place only. Other hosts would learn about the change dynamically through a notification system, thus completing a globally accessible network of all hosts' names and their associated IP Addresses.
At the request of Jon Postel, Paul Mockapetris invented the Domain Name System in 1983 and wrote the first implementation. The original specifications appear in RFC 882 and RFC 883 which were superseded in November 1987 by RFC 1034[5] and RFC 1035[6]. Several additional Request for Comments have proposed various extensions to the core DNS protocols.
In 1984, four Berkeley students—Douglas Terry, Mark Painter, David Riggle and Songnian Zhou—wrote the first UNIX implementation, which was maintained by Ralph Campbell thereafter. In 1985, Kevin Dunlap of DEC significantly re-wrote the DNS implementation and renamed it BIND—Berkeley Internet Name Domain. Mike Karels, Phil Almquist and Paul Vixie have maintained BIND since then. BIND was ported to the Windows NT platform in the early 1990s.
BIND was widely distributed, especially on Unix systems, and is the dominant DNS software in use on the Internet.[7] With the heavy use and resulting scrutiny of its open-source code, as well as increasingly more sophisticated attack methods, many security flaws were discovered in BIND. This contributed to the development of a number of alternative nameserver and resolver programs. BIND itself was re-written from scratch in version 9, which has a security record comparable to other modern Internet software.
[edit] Structure
[edit] The domain name space
The hierarchical domain name system, organized into zones, each served by a name server.
The domain name space consists of a tree of domain names. Each node or leaf in the tree has zero or more resource records, which hold information associated with the domain name. The tree sub-divides into zones beginning at the root zone. A DNS zone consists of a collection of connected nodes authoritatively served by an authoritative nameserver. (Note that a single nameserver can host several zones.)
Administrative responsibility over any zone may be divided, thereby creating additional zones. Authority is said to be delegated for a portion of the old space, usually in form of sub-domains, to another nameserver and administrative entity. The old zone ceases to be authoritative for the new zone.
[edit] Parts of a domain name
A domain name usually consists of two or more parts (technically labels), which are conventionally written separated by dots, such as example.com.
The rightmost label conveys the top-level domain (for example, the address www.example.com has the top-level domain com).
Each label to the left specifies a subdivision, or subdomain of the domain above it. Note: “subdomain” expresses relative dependence, not absolute dependence. For example: example.com is a subdomain of the com domain, and www.example.com is a subdomain of the domain example.com. In theory, this subdivision can go down 127 levels. Each label can contain up to 63 octets. The whole domain name may not exceed a total length of 253 octets. [8] In practice, some domain registries may have shorter limits.
A hostname refers to a domain name that has one or more associated IP addresses (e.g., the 'www.example.com' and 'example.com' domains are both hostnames, whereas the 'com' domain is not).
[edit] DNS servers
Main article: Name server
The Domain Name System is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the name servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD).
[edit] DNS resolvers
See also: resolv.conf
The client-side of the DNS is called a DNS resolver. It is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP address.
A DNS query may be either a recursive query or a non-recursive query:
A non-recursive query is one in which the DNS server may provide a partial answer to the query (or give an error).
A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries.
The resolver (or another DNS server acting recursively on behalf of the resolver) negotiates use of recursive service using bits in the query headers.
Resolving usually entails iterating through several name servers to find the needed information. However, some resolvers function simplistically and can communicate only with a single name server. These simple resolvers rely on a recursive query to a recursive name server to perform the work of finding information for them.
[edit] Operation
[edit] Address resolution mechanism
A domain name may have several name components (e.g., ahost.ofasubnet.ofabiggernet.inadomain.example). In practice, full host names will frequently consist of just three segments: ahost.inadomain.example, and most often www.inadomain.example. For querying purposes, software interprets the name segment by segment, from right to left. At each step along the way, the program queries a corresponding DNS server to provide a pointer to the next server which it should consult.
A DNS recursor consults three nameservers to resolve the address www.wikipedia.org.
As originally envisaged, the process was as simple as:
1.the local system is pre-configured with the known addresses of the root servers in a file of root hints, which need to be updated periodically by the local administrator from a reliable source to be kept up to date with the changes which occur over time.
2.query one of the root servers to find the server authoritative for the next level down (so in the case of our simple hostname, a root server would be asked for the address of a server with detailed knowledge of the example top level domain).
3.querying this second server for the address of a DNS server with detailed knowledge of the second-level domain (inadomain.example in our example).
4.repeating the previous step to progress down the name, until the final step which would, rather than generating the address of the next DNS server, return the final address sought.
The diagram illustrates this process for the real host www.wikipedia.org.
The mechanism in this simple form has a difficulty: it places a huge operating burden on the root servers, with every search for an address starting by querying one of them. Being as critical as they are to the overall function of the system, such heavy use would create an insurmountable bottleneck for trillions of queries placed every day. In practice caching is used to overcome this problem, and, in fact, root nameservers deal with very little of the total traffic.
[edit] Circular dependencies and glue records
Name servers in delegations appear listed by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. Since this can introduce a circular dependency if the nameserver referred to is under the domain that it is authoritative of, it is occasionally necessary for the nameserver providing the delegation to also provide the IP address of the next nameserver. This record is called a glue record.
For example, assume that the sub-domain en.wikipedia.org contains further sub-domains (such as something.en.wikipedia.org) and that the authoritative name server for these lives at ns1.something.en.wikipedia.org. A computer trying to resolve something.en.wikipedia.org will thus first have to resolve ns1.something.en.wikipedia.org. Since ns1 is also under the something.en.wikipedia.org subdomain, resolving ns1.something.en.wikipedia.org requires resolving something.en.wikipedia.org which is exactly the circular dependency mentioned above. The dependency is broken by the glue record in the nameserver of en.wikipedia.org that provides the IP address of ns1.something.en.wikipedia.org directly to the requestor, enabling it to bootstrap the process by figuring out where ns1.something.en.wikipedia.org is located.
[edit] Caching and time to live
Because of the huge volume of requests generated by a system like DNS, the designers wished to provide a mechanism to reduce the load on individual DNS servers. To this end, the DNS resolution process allows for caching (i.e. the local recording and subsequent consultation of the results of a DNS query) for a given period of time after a successful answer. How long a resolver caches a DNS response (i.e. how long a DNS response remains valid) is determined by a value called the time to live (TTL). The TTL is set by the administrator of the DNS server handing out the response. The period of validity may vary from just seconds to days or even weeks.
[edit] Caching time
As a noteworthy consequence of this distributed and caching architecture, changes to DNS records do not always take effect immediately and globally. This is best explained with an example: If an administrator has set a TTL of 6 hours for the host www.wikipedia.org, and then changes the IP address to which www.wikipedia.org resolves at 12:01pm, the administrator must consider that a person who cached a response with the old IP address at 12:00noon will not consult the DNS server again until 6:00pm. The period between 12:01pm and 6:00pm in this example is called caching time, which is best defined as a period of time that begins when you make a change to a DNS record and ends after the maximum amount of time specified by the TTL expires. This essentially leads to an important logistical consideration when making changes to DNS: not everyone is necessarily seeing the same thing you're seeing. RFC 1912 helps to convey basic rules for how to set the TTL.
Note that the term "propagation", although very widely used in this context, does not describe the effects of caching well. Specifically, it implies that [1] when you make a DNS change, it somehow spreads to all other DNS servers (instead, other DNS servers check in with yours as needed), and [2] that you do not have control over the amount of time the record is cached (you control the TTL values for all DNS records in your domain, except your NS records and any authoritative DNS servers that use your domain name).
Some resolvers may override TTL values, as the protocol supports caching for up to 68 years or no caching at all. Negative caching (the non-existence of records) is determined by name servers authoritative for a zone which MUST include the Start of Authority (SOA) record when reporting no data of the requested type exists. The MINIMUM field of the SOA record and the TTL of the SOA itself is used to establish the TTL for the negative answer. RFC 2308
Many people incorrectly refer to a mysterious 48 hour or 72 hour propagation time when you make a DNS change. When one changes the NS records for one's domain or the IP addresses for hostnames of authoritative DNS servers using one's domain (if any), there can be a lengthy period of time before all DNS servers use the new information. This is because those records are handled by the zone parent DNS servers (for example, the .com DNS servers if your domain is example.com), which typically cache those records for 48 hours. However, those DNS changes will be immediately available for any DNS servers that do not have them cached. And any DNS changes on your domain other than the NS records and authoritative DNS server names can be nearly instantaneous, if you choose for them to be (by lowering the TTL once or twice ahead of time, and waiting until the old TTL expires before making the change).
[edit] Client lookup
DNS resolution sequence.
Users generally do not communicate directly with a DNS resolver. Instead DNS resolution takes place transparently in applications programs such as web browsers, e-mail clients, and other Internet applications. When an application makes a request that requires a domain name lookup, such programs send a resolution request to the DNS resolver in the local operating system, which in turn handles the communications required.
The DNS resolver will almost invariably have a cache (see above) containing recent lookups. If the cache can provide the answer to the request, the resolver will return the value in the cache to the program that made the request. If the cache does not contain the answer, the resolver will send the request to one or more designated DNS servers. In the case of most home users, the Internet service provider to which the machine connects will usually supply this DNS server: such a user will either have configured that server's address manually or allowed DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers point to separately maintained nameservers of the organization. In any event, the name server thus queried will follow the process outlined above, until it either successfully finds a result or does not. It then returns its results to the DNS resolver; assuming it has found a result, the resolver duly caches that result for future use, and hands the result back to the software which initiated the request.
[edit] Broken resolvers
An additional level of complexity emerges when resolvers violate the rules of the DNS protocol. A number of large ISPs have configured their DNS servers to violate rules (presumably to allow them to run on less-expensive hardware than a fully-compliant resolver), such as by disobeying TTLs, or by indicating that a domain name does not exist just because one of its name servers does not respond.[9]
As a final level of complexity, some applications (such as web-browsers) also have their own DNS cache, in order to reduce the use of the DNS resolver library itself. This practice can add extra difficulty when debugging DNS issues, as it obscures the freshness of data, and/or what data comes from which cache. These caches typically use very short caching times — on the order of one minute. Internet Explorer offers a notable exception: recent[update] versions cache DNS records for half an hour.[10]
[edit] Other applications
The system outlined above provides a somewhat simplified scenario. The Domain Name System includes several other functions:
Hostnames and IP addresses do not necessarily match on a one-to-one basis. Many hostnames may correspond to a single IP address: combined with virtual hosting, this allows a single machine to serve many web sites. Alternatively a single hostname may correspond to many IP addresses: this can facilitate fault tolerance and load distribution, and also allows a site to move physical location seamlessly.
There are many uses of DNS besides translating names to IP addresses. For instance, Mail transfer agents use DNS to find out where to deliver e-mail for a particular address. The domain to mail exchanger mapping provided by MX records accommodates another layer of fault tolerance and load distribution on top of the name to IP address mapping.
E-mail Blacklists: The DNS system is used for efficient storage and distribution of IP addresses of blacklisted e-mail hosts. The usual method is putting the IP address of the subject host into the sub-domain of a higher level domain name, and resolve that name to different records to indicate a positive or a negative. A hypothetical example using blacklist.com,
102.3.4.5 is blacklisted => Creates 5.4.3.102.blacklist.com and resolves to 127.0.0.1
102.3.4.6 is not => 6.4.3.102.blacklist.com is not found, or default to 127.0.0.2
E-mail servers can then query blacklist.com through the DNS mechanism to find out if a specific host connecting to them is in the blacklist. Today many of such blacklists, either free or subscription-based, are available mainly for use by email administrators and anti-spam software.
Software Updates: many anti-virus and commercial software now use the DNS system to store version numbers of the latest software updates so client computers do not need to connect to the update servers every time. For these type of applications, the cache time of the DNS records are usually shorter.
Sender Policy Framework and DomainKeys, instead of creating their own record types, were designed to take advantage of another DNS record type, the TXT record.
To provide resilience in the event of computer failure, multiple DNS servers are usually provided for coverage of each domain, and at the top level, thirteen very powerful root servers exist, with additional "copies" of several of them distributed worldwide via Anycast.
[edit] Protocol details
DNS primarily uses User Datagram Protocol (UDP) on port number 53 [11] to serve requests. DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. The Transmission Control Protocol (TCP) is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers. Some operating systems, such as HP-UX, are known to have resolver implementations that use TCP for all queries, even when UDP would suffice.
[edit] DNS resource records
Further information: List of DNS record types
A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.), a TTL, a class and some type-specific information. All resource records of the same type define a Resource Record Set (RR set). The order that resource records in a RR set are returned by the resolver to an application is undefined (the server typically uses round-robin DNS). DNSSEC, however, works on complete RR sets in a canonical order.
When sent over the Internet, all records use the common format specified in RFC 1035 shown below.
RR (Resource record) fields
Field
Description
Length (octets)
NAME
Name of the node to which this record pertains.
(variable)
TYPE
Type of RR. For example, MX is type 15.
2
CLASS
Class code.
2
TTL
Signed time in seconds that RR stays valid.
4
RDLENGTH
Length of RDATA field.
2
RDATA
Additional RR-specific data.
(variable)
The NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be shortened using label compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the current domain name.
The TYPE of the record indicates what the format of the data is, and gives a hint of its intended use; for instance, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone, and the MX record is used to translate from a name in the right-hand side of an e-mail address to the name of a machine able to handle mail for that address. See List of DNS record types for a more complete list.
The RDATA is type-specific information, such as the actual IP address for A records, or the mail host for MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types can not (see RFC 3597).
The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames, servers, or IP addresses. In addition the classes CH (Chaos) and HS (Hesiod) exist. Each class is a completely independent trees with potentially different delegation of DNS zones.
In addition to resource records defined in a zone file, the domain name system also defines several request types that are used only on the wire, such as to perform zone transfers (AXFR/IXFR) or for EDNS (OPT).
[edit] Wildcard DNS records
Main article: Wildcard DNS record
The domain name system supports wildcard domain names which are names that start with the asterisk label, '*', e.g., *.example.[5][12] DNS records belonging to wildcard domain names specify rules for generating resource records within a single DNS zone by substituting whole labels with matching components of the query name, including any specified descendants. For example, in the DNS zone x.example, the following configuration specifies that all subdomains (including subdomains of subdomains) of x.example use the mail exchanger a.x.example. The records for a.x.example are needed to specify the mail exchanger. As this has the result of excluding this domain name and its subdomains from the wildcard matches, all subdomains of a.x.example must be defined in a separate wildcard statement.
X.EXAMPLE. MX 10 A.X.EXAMPLE.
*.X.EXAMPLE. MX 10 A.X.EXAMPLE.
*.A.X.EXAMPLE. MX 10 A.X.EXAMPLE.
A.X.EXAMPLE. MX 10 A.X.EXAMPLE.
A.X.EXAMPLE. AAAA 2001:db8::1
The role of wildcard records was refined in RFC 4592, because the original definition in RFC 1034 was incomplete and resulted in misinterpretations by implementers.[12]
[edit] Protocol extensions
EDNS is an extension of the DNS protocol which drops the maximum size requirement of 512 bytes of DNS replies when transported over UDP. It adds support for expanding the space of request and response codes. It is described in RFC 2671.
[edit] Internationalized domain names
Main article: Internationalized domain name
While domain names technically have no restrictions on the characters they use and can include non-ASCII characters, the same is not true for host names.[13] Host names are the names most people see and use for things like e-mail and web browsing. Host names are restricted to a small subset of the ASCII character set known as LDH, the Letters A–Z in upper and lower case, Digits 0–9, Hyphen, and the dot to separate LDH-labels; see RFC 3696 section 2 for details. This prevented the representation of names and words of many languages natively. ICANN has approved the Punycode-based IDNA system, which maps Unicode strings into the valid DNS character set, as a workaround to this issue. Some registries have adopted IDNA.
[edit] Security issues
DNS was not originally designed with security in mind, and thus has a number of security issues.
One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has received authentic information when, in reality, it has not.
DNS responses are traditionally not cryptographically signed, leading to many attack possibilities; The Domain Name System Security Extensions (DNSSEC) modifies DNS to add support for cryptographically signed responses. There are various extensions to support securing zone transfer information as well.
Even with encryption, a DNS server could become compromised by a virus (or for that matter a disgruntled employee) that would cause IP addresses of that server to be redirected to a malicious address with a long TTL. This could have far-reaching impact to potentially millions of Internet users if busy DNS servers cache the bad IP data. This would require manual purging of all affected DNS caches as required by the long TTL (up to 68 years).
Some domain names can spoof other, similar-looking domain names. For example, "paypal.com" and "paypa1.com" are different names, yet users may be unable to tell the difference when the user's typeface (font) does not clearly differentiate the letter l and the numeral 1. This problem is much more serious in systems that support internationalized domain names, since many characters that are different, from the point of view of ISO 10646, appear identical on typical computer screens. This vulnerability is often exploited in phishing.
Techniques such as Forward Confirmed reverse DNS can also be used to help validate DNS results.
[edit] Domain name registration
The right to use a domain name is delegated by domain name registrars which are accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), the organization charged with overseeing the name and number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced technically by an administrative organization, operating a registry. A registry is responsible for maintaining the database of names registered within the TLD it administers. The registry receives registration information from each domain name registrar authorized to assign names in the corresponding TLD and publishes the information using a special service, the whois protocol.
Registries and registrars usually charge an annual fee for the service of delegating a domain name to a user and providing a default set of name servers. Often this transaction is termed a sale or lease of the domain name, and the registrant may sometimes be called an "owner", but no such legal relationship is actually associated with the transaction, only the exclusive right to use the domain name. More correctly, authorized users are known as "registrants" or as "domain holders".
ICANN publishes a complete list of TLD registries and domain name registrars in the world. One can obtain information about the registrant of a domain name by looking in the WHOIS database held by many domain registries.
For most of the more than 240 country code top-level domains (ccTLDs), the domain registries hold the authoritative WHOIS (Registrant, name servers, expiration dates, etc.). For instance, DENIC, Germany NIC, holds the authoritative WHOIS to a .DE domain name. Since about 2001, most gTLD registries (.ORG, .BIZ, .INFO) have adopted this so-called "thick" registry approach, i.e. keeping the authoritative WHOIS in the central registries instead of the registrars.
For COM and NET domain names, a "thin" registry is used: the domain registry (e.g. VeriSign) holds a basic WHOIS (registrar and name servers, etc.). One can find the detailed WHOIS (registrant, name servers, expiry dates, etc.) at the registrars.
Some domain name registries, often called network information centers (NIC), also function as registrars to end-users. The major generic top-level domain registries, such as for the COM, NET, ORG, INFO domains and others, use a registry-registrar model consisting of hundreds of domain name registrars (see lists at ICANN or VeriSign). In this method of management, the registry only manages the domain name database and the relationship with the registrars. The registrants (users of a domain name) are customers of the registrar, in some cases through additional layers of resellers.
In the process of registering a domain name and maintaining authority over the new name space created, registrars use several key pieces of information connected with a domain:
Administrative contact. A registrant usually designates an administrative contact to manage the domain name. The administrative contact usually has the highest level of control over a domain. Management functions delegated to the administrative contacts may include management of all business information, such as name of record, postal address, and contact information of the official registrant of the domain and the obligation to conform to the requirements of the domain registry in order to retain the right to use a domain name. Furthermore the administrative contact installs additional contact information for technical and billing functions.
Technical contact. The technical contact manages the name servers of a domain name. The functions of a technical contact include assuring conformance of the configurations of the domain name with the requirements of the domain registry, maintaining the domain zone records, and providing continuous functionality of the name servers (that leads to the accessibility of the domain name).
Billing contact. The party responsible for receiving billing invoices from the domain name registrar and paying applicable fees.
Name servers. Most registrars provide two or more name servers as part of the registration service. However, a registrant may specify its own authoritative name servers to host a domain's resource records. The registrar's policies govern the number of servers and the type of server information required. Some providers require a hostname and the corresponding IP address or just the hostname, which must be resolvable either in the new domain, or exist elsewhere. Based on traditional requirements (RFC 1034), typically a minimum of two servers is required.
[edit] Abuse and regulation
Critics often claim abuse of administrative power over domain names. Particularly noteworthy was the VeriSign Site Finder system which redirected all unregistered .com and .net domains to a VeriSign webpage. For example, at a public meeting with VeriSign to air technical concerns about SiteFinder [14], numerous people, active in the IETF and other technical bodies, explained how they were surprised by VeriSign's changing the fundamental behavior of a major component of Internet infrastructure, not having obtained the customary consensus. SiteFinder, at first, assumed every Internet query was for a website, and it monetized queries for incorrect domain names, taking the user to VeriSign's search site. Unfortunately, other applications, such as many implementations of email, treat a lack of response to a domain name query as an indication that the domain does not exist, and that the message can be treated as undeliverable. The original VeriSign implementation broke this assumption for mail, because it would always resolve an erroneous domain name to that of SiteFinder. While VeriSign later changed SiteFinder's behaviour with regard to email, there was still widespread protest about VeriSign's action being more in its financial interest than in the interest of the Internet infrastructure component for which VeriSign was the steward.
Despite widespread criticism, VeriSign only reluctantly removed it after the Internet Corporation for Assigned Names and Numbers (ICANN) threatened to revoke its contract to administer the root name servers. ICANN published the extensive set of letters exchanged, committee reports, and ICANN decisions [15].
There is also significant disquiet regarding the United States' political influence over ICANN. This was a significant issue in the attempt to create a .xxx top-level domain and sparked greater interest in alternative DNS roots that would be beyond the control of any single country.[16]
Additionally, there are numerous accusations of domain name "front running", whereby registrars, when given whois queries, automatically register the domain name for themselves. Recently, Network Solutions has been accused of this.[17]
[edit] Truth in Domain Names Act
Main article: Anticybersquatting Consumer Protection Act
In the United States, the "Truth in Domain Names Act" (actually the "Anticybersquatting Consumer Protection Act"), in combination with the PROTECT Act, forbids the use of a misleading domain name with the intention of attracting people into viewing a visual depiction of sexually explicit conduct on the Internet.
[edit] Internet standards
The Domain Name System is defined by Request for Comments (RFC) documents published by the Internet Engineering Task Force (Internet standards). The following is a list of RFCs that define the DNS protocol.
RFC 920, Domain Requirements - Specified original top-level domains
RFC 1032, Domain Administrators Guide
RFC 1033, Domain Administrators Operations Guide
RFC 1034, Domain Names - Concepts and Facilities
RFC 1035, Domain Names - Implementation and Specification
RFC 1101, DNS Encodings of Network Names and Other Types
RFC 1123, Requirements for Internet Hosts—Application and Support
RFC 1178, Choosing a Name for Your Computer (FYI 5)
RFC 1183, New DNS RR Definitions
RFC 1591, Domain Name System Structure and Delegation (Informational)
RFC 1912, Common DNS Operational and Configuration Errors
RFC 1995, Incremental Zone Transfer in DNS
RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
RFC 2100, The Naming of Hosts (Informational)
RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
RFC 2181, Clarifications to the DNS Specification
RFC 2182, Selection and Operation of Secondary DNS Servers
RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
RFC 2671, Extension Mechanisms for DNS (EDNS0)
RFC 2672, Non-Terminal DNS Name Redirection
RFC 3225, Indicating Resolver Support of DNSSEC
RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)
RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
RFC 4592, The Role of Wildcards in the Domain Name System
RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)
RFC 5001, DNS Name Server Identifier (NSID) Option
RFC 5395, Domain Name System (DNS) IANA Considerations (BCP 42)
[edit] Security
RFC 4033, DNS Security Introduction and Requirements
RFC 4034, Resource Records for the DNS Security Extensions
RFC 4035, Protocol Modifications for the DNS Security Extensions
[edit] See also
Dynamic DNS
Alternative DNS root
Comparison of DNS server software
Round robin DNS
Split-horizon DNS
DNS management software
DNS cache poisoning
DNS hijacking
List of DNS record types
[edit] References
1.^ Mockapetris, Paul (2004-01-02). "Letting DNS Loose". CircleID. http://www.circleid.com/posts/letting_dns_loose/.
2.^ RFC 3467 - Role of the Domain Name System (DNS)
3.^ "History of the DNS". http://www.lagunainternet.com/techsupport/history_of_dns.htm. Retrieved on 2008-04-29.
4.^ Cricket Liu, Paul Albitz. "DNS & BIND". O'Reilly (shown via Google Books). http://books.google.co.uk/books?id=zkZN52WhG8sC&pg=PA3&lpg=PA3&dq=sri+HOSTS.TXT&source=web&ots=wuZ79E-zJ2&sig=btF0Z2nclOnX_UgNj7a1f5S7Uqg&hl=en. Retrieved on 2008-04-29.
5.^ a b RFC 1034, Domain names - Concepts and Facilities, P. Mockapetris (November 1987)
6.^ RFC 1035, Domain names - Implementation and Specification, P. Mockapetris (November 1987)
7.^ http://mydns.bboy.net/survey/ DNS Server Survey
8.^ What is the maximum length of a domain name? on the IETF DNSOP working group mailing list. On the wire, in the DNS binary format, it can be at most 255 octets as per RFC 1034 section 3.1. For an all-ASCII hostname, this can be represented in traditional dot notation as 253 characters.
9.^ "Providers ignoring DNS TTL ?". Slashdot. 2005. http://ask.slashdot.org/article.pl?sid=05/04/18/198259. Retrieved on 2009-01-03.
10.^ "How Internet Explorer uses the cache for DNS host entries". Microsoft. 2004. http://support.microsoft.com/default.aspx?scid=KB;en-us;263558. Retrieved on 2006-03-07.
11.^ Mockapetris, P (November 1987). "RFC 1035: Domain Names - Implementation and Specification". http://www.ietf.org/rfc/rfc1035.txt.
12.^ a b RFC 4592, The Role of Wildcards in the Domain Name System, E. Lewis (July 2006)
13.^ The term host name is here being used to mean an FQDN for a host, such as eg. en.wikipedia.org., and not just (to use the same example) en .
While most domain names do indeed designate hosts, some domain name DNS entries may not. In this sense, a (FQDN) hostname is a type of domain name, but not all domain names are actual host names. Cf. this host name vs domain name explanation from the DNS OP IETF Working Group.
14.^ McCullagh, Declan (2003-10-03). "VeriSign fends off critics at ICANN confab". CNET News.com. http://www.news.com/2100-1038-5088128.html. Retrieved on 2007-09-22.
15.^ Internet Corporation for Assigned Names and Numbers (ICANN). "Verisign's Wildcard Service Deployment". http://www.icann.org/topics/wildcard-history.html. Retrieved on 2007-09-22.
16.^ Mueller, M (March 2004). Ruling the Root. MIT Press. ISBN 0262632985.
17.^ Slashdot | NSI Registers Every Domain Checked
Thu, 21/08/2008 - 14:23 — Nurhadi
Your rating:
0
Average: 5 (1 vote)
Sumber : www.ilmukomputer.com
Diding Ardiantoro , dardiantoro@yahoo.com
1.1. Sejarah DNS
Sebelum dipergunakannya DNS, jaringan komputer menggunakan HOSTS files yang berisi informasi
dari nama komputer dan IP address-nya. Di Internet, file ini dikelola secara terpusat dan di setiap loaksi
harus di copy versi terbaru dari HOSTS files, dari sini bisa dibayangkan betapa repotnya jika ada
penambahan 1 komputer di jaringan, maka kita harus copy versi terbaru file ini ke setiap lokasi. Dengan
makin meluasnya jaringan internet, hal ini makin merepotkan, akhirnya dibuatkan sebuah solusi dimana
DNS di desain menggantikan fungsi HOSTS files, dengan kelebihan unlimited database size, dan
performace yang baik. DNS adalah sebuah aplikasi services di Internet yang menerjemahkan sebuah
domain name ke IP address. Sebagai contoh, www untuk penggunaan di Internet, lalu diketikan nama
domain, misalnya: yahoo.com maka akan di petakan ke sebuah IP mis 202.68.0.134. Jadi DNS dapat di
analogikan pada pemakaian buku telepon, dimana orang yang kita kenal berdasarkan nama untuk
menghubunginya kita harus memutar nomor telepon di pesawat telepon. Sama persis, host komputer
mengirimkan queries berupa nama komputer dan domain name server ke DNS, lalu oleh DNS dipetakan
ke IP address.
1.2. Domain Name System (DNS)
Domain Name System (DNS) adalah distribute database system yang digunakan untuk pencarian nama
komputer (name resolution) di jaringan yang mengunakan TCP/IP (Transmission Control
Protocol/Internet Protocol). DNS biasa digunakan pada aplikasi yang terhubung ke Internet seperti web
browser atau e-mail, dimana DNS membantu memetakan host name sebuah komputer ke IP address.
Selain digunakan di Internet, DNS juga dapat di implementasikan ke private network atau intranet
dimana DNS memiliki keunggulan seperti:
1. Mudah, DNS sangat mudah karena user tidak lagi direpotkan untuk mengingat IP address
sebuah komputer cukup host name (nama Komputer).
2. Konsisten, IP address sebuah komputer bisa berubah tapi host name tidak berubah.
3. Simple, user hanya menggunakan satu nama domain untuk mencari baik di Internet maupun di
Intranet.
1.3. Apa itu DNS?
DNS dapat disamakan fungsinya dengan buku telepon. Dimana setiap komputer di jaringan Internet
memiliki host name (nama komputer) dan Internet Protocol (IP) address. Secara umum, setiap client
yang akan mengkoneksikan komputer yang satu ke komputer yang lain, akan menggunakan host name.
Lalu komputer anda akan menghubungi DNS server untuk mencek host name yang anda minta tersebut
berapa IP address-nya. IP address ini yang digunakan untuk mengkoneksikan komputer anda dengan
komputer lainnya.
1.4. Struktur DNS
Domain Name Space merupakan sebuah hirarki pengelompokan domain berdasarkan nama, yang terbagi
menjadi beberapa bagian diantaranya:
Root-Level Domains
Domain ditentukan berdasarkan tingkatan kemampuan yang ada di struktur hirarki yang disebut dengan
level. Level paling atas di hirarki disebut dengan root domain. Root domain di ekspresikan berdasarkan
periode dimana lambang untuk root domain adalah (“.”).
Top-Level Domains
Pada bagian dibawah ini adalah contoh dari top-level domains:
- com Organisasi Komersial
- edu Institusi pendidikan atau universitas
- org Organisasi non-profit
- net Networks (backbone Internet)
- gov Organisasi pemerintah non militer
- mil Organisasi pemerintah militer
- num No telpon
- arpa Reverse DNS
- xx dua-huruf untuk kode negara (id:Indonesia,sg:singapura,au:australia,dll)
Top-level domains dapat berisi second-level domains dan hosts.
Second-Level Domains
Second-level domains dapat berisi host dan domain lain, yang disebut dengan subdomain. Untuk contoh:
Domain Bujangan, bujangan.com terdapat komputer (host) seperti server1.bujangan.com dan subdomain
training.bujangan.com. Subdomain training.bujangan.com juga terdapat komputer (host) seperti
client1.training.bujangan.com.
Host Names
Domain name yang digunakan dengan host name akan menciptakan fully qualified domain name
(FQDN) untuk setiap komputer. Sebagai contoh, jika terdapat fileserver1.detik.com, dimana fileserver1
adalah host name dan detik.com adalah domain name.
1.5. Bagaimana DNS itu bekerja?
Fungsi dari DNS adalah menerjemahkan nama komputer ke IP address (memetakan). Client DNS disebut
dengan resolvers dan DNS server disebut dengan name servers. Resolvers atau client mengirimkan
permintaan ke name server berupa queries. Name server akan memproses dengan cara mencek ke local
database DNS, menghubungi name server lainnya atau akan mengirimkan message failure jika ternyata
permintaan dari client tidak ditemukan.
Proses tersebut disebut dengan Forward Lookup Query, yaitu permintaan dari client dengan cara
memetakan nama komputer (host) ke IP address.
Nurhadi's blog
Login or register to post comments
Your rating:
0
Average: 5 (1 vote)
Sumber : www.ilmukomputer.com
Diding Ardiantoro , dardiantoro@yahoo.com
1.1. Sejarah DNS
Sebelum dipergunakannya DNS, jaringan komputer menggunakan HOSTS files yang berisi informasi
dari nama komputer dan IP address-nya. Di Internet, file ini dikelola secara terpusat dan di setiap loaksi
harus di copy versi terbaru dari HOSTS files, dari sini bisa dibayangkan betapa repotnya jika ada
penambahan 1 komputer di jaringan, maka kita harus copy versi terbaru file ini ke setiap lokasi. Dengan
makin meluasnya jaringan internet, hal ini makin merepotkan, akhirnya dibuatkan sebuah solusi dimana
DNS di desain menggantikan fungsi HOSTS files, dengan kelebihan unlimited database size, dan
performace yang baik. DNS adalah sebuah aplikasi services di Internet yang menerjemahkan sebuah
domain name ke IP address. Sebagai contoh, www untuk penggunaan di Internet, lalu diketikan nama
domain, misalnya: yahoo.com maka akan di petakan ke sebuah IP mis 202.68.0.134. Jadi DNS dapat di
analogikan pada pemakaian buku telepon, dimana orang yang kita kenal berdasarkan nama untuk
menghubunginya kita harus memutar nomor telepon di pesawat telepon. Sama persis, host komputer
mengirimkan queries berupa nama komputer dan domain name server ke DNS, lalu oleh DNS dipetakan
ke IP address.
1.2. Domain Name System (DNS)
Domain Name System (DNS) adalah distribute database system yang digunakan untuk pencarian nama
komputer (name resolution) di jaringan yang mengunakan TCP/IP (Transmission Control
Protocol/Internet Protocol). DNS biasa digunakan pada aplikasi yang terhubung ke Internet seperti web
browser atau e-mail, dimana DNS membantu memetakan host name sebuah komputer ke IP address.
Selain digunakan di Internet, DNS juga dapat di implementasikan ke private network atau intranet
dimana DNS memiliki keunggulan seperti:
1. Mudah, DNS sangat mudah karena user tidak lagi direpotkan untuk mengingat IP address
sebuah komputer cukup host name (nama Komputer).
2. Konsisten, IP address sebuah komputer bisa berubah tapi host name tidak berubah.
3. Simple, user hanya menggunakan satu nama domain untuk mencari baik di Internet maupun di
Intranet.
1.3. Apa itu DNS?
DNS dapat disamakan fungsinya dengan buku telepon. Dimana setiap komputer di jaringan Internet
memiliki host name (nama komputer) dan Internet Protocol (IP) address. Secara umum, setiap client
yang akan mengkoneksikan komputer yang satu ke komputer yang lain, akan menggunakan host name.
Lalu komputer anda akan menghubungi DNS server untuk mencek host name yang anda minta tersebut
berapa IP address-nya. IP address ini yang digunakan untuk mengkoneksikan komputer anda dengan
komputer lainnya.
1.4. Struktur DNS
Domain Name Space merupakan sebuah hirarki pengelompokan domain berdasarkan nama, yang terbagi
menjadi beberapa bagian diantaranya:
Root-Level Domains
Domain ditentukan berdasarkan tingkatan kemampuan yang ada di struktur hirarki yang disebut dengan
level. Level paling atas di hirarki disebut dengan root domain. Root domain di ekspresikan berdasarkan
periode dimana lambang untuk root domain adalah (“.”).
Top-Level Domains
Pada bagian dibawah ini adalah contoh dari top-level domains:
- com Organisasi Komersial
- edu Institusi pendidikan atau universitas
- org Organisasi non-profit
- net Networks (backbone Internet)
- gov Organisasi pemerintah non militer
- mil Organisasi pemerintah militer
- num No telpon
- arpa Reverse DNS
- xx dua-huruf untuk kode negara (id:Indonesia,sg:singapura,au:australia,dll)
Top-level domains dapat berisi second-level domains dan hosts.
Second-Level Domains
Second-level domains dapat berisi host dan domain lain, yang disebut dengan subdomain. Untuk contoh:
Domain Bujangan, bujangan.com terdapat komputer (host) seperti server1.bujangan.com dan subdomain
training.bujangan.com. Subdomain training.bujangan.com juga terdapat komputer (host) seperti
client1.training.bujangan.com.
Host Names
Domain name yang digunakan dengan host name akan menciptakan fully qualified domain name
(FQDN) untuk setiap komputer. Sebagai contoh, jika terdapat fileserver1.detik.com, dimana fileserver1
adalah host name dan detik.com adalah domain name.
1.5. Bagaimana DNS itu bekerja?
Fungsi dari DNS adalah menerjemahkan nama komputer ke IP address (memetakan). Client DNS disebut
dengan resolvers dan DNS server disebut dengan name servers. Resolvers atau client mengirimkan
permintaan ke name server berupa queries. Name server akan memproses dengan cara mencek ke local
database DNS, menghubungi name server lainnya atau akan mengirimkan message failure jika ternyata
permintaan dari client tidak ditemukan.
Proses tersebut disebut dengan Forward Lookup Query, yaitu permintaan dari client dengan cara
memetakan nama komputer (host) ke IP address.
Nurhadi's blog
Login or register to post comments
Langganan:
Postingan (Atom)
