Anda di halaman 1dari 24

TUGAS TELEMATIKA

“DOMAIN NAME SYSTEM (DNS)”

Dosen : Drs. Tri Kuntoro Priyambodo, M.Sc

Oleh :

Rajim Laymond.S

09/292172/PPA/03044

PROGRAM STUDI S2 ILMU KOMPUTER


FAKULTAS MIPA
UNIVERSITAS GADJAH MADA
YOGYAKARTA
2010
DNS (Domain Name System)

DNS (Domain Name System) 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.

2
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.

Teori bekerja DNS

Pengelola dari sistem DNS terdiri dari tiga komponen:

1. DNS resolver, sebuah program klien yang berjalan di komputer pengguna,


yang membuat permintaan DNS dari program aplikasi.
2. Recursive DNS server, yang melakukan pencarian melalui DNS sebagai
tanggapan permintaan dari resolver, dan mengembalikan jawaban kepada para
resolver tersebut
3. 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)

Pengertian nama domain

Sebuah nama domain biasanya terdiri dari dua bagian atau lebih (secara teknis disebut
label), dipisahkan dengan titik.

1. Label paling kanan menyatakan top-level domain - domain tingkat atas/tinggi


(misalkan, alamat www.wikipedia.org memiliki top-level domain org).
2. 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.

3
3. 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).

Contoh 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.

1. 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.
2. 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?
3. 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."
4. 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."

4
5. 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).

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.

Cara Kerja DNS

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".

5
1. 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.

2. 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.

3. Penerapan DNS di dunia nyata


Di dunia nyata, user tidak berhadapan langsung dengan DNS resolver -
mereka berhadapan dengan program seperti web brower (Mozilla Firefox,

6
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.

4. 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:

7
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

8
Komponen-komponen penting yang dicatat dalam DNS

Beberapa komponen penting dari data yang disimpan di dalam DNS adalah
sebagai berikut :

1. A record atau catatan alamat memetakan sebuah nama host ke alamat


IP 32-bit (untuk IPv4).
2. AAAA record atau catatan alamat IPv6 memetakan sebuah nama host
ke alamat IP 128-bit (untuk IPv6).
3. CNAME record atau catatan nama kanonik membuat alias untuk
nama domain. Domain yang di-alias-kan memiliki seluruh subdomain
dan rekod DNS seperti aslinya.
4. [MX record] atau catatan pertukaran surat memetakan sebuah nama
domain ke dalam daftar mail exchange server untuk domain tersebut.
5. 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.
6. 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.
7. SOA record atau catatan otoritas awal (Start of Authority) mengacu
server DNS yang mengediakan otorisasi informasi tentang sebuah
domain Internet.
8. SRV record adalah catatan lokasi secara umum.
9. Catatan TXT mengijinkan administrator untuk memasukan data acak
ke dalam catatan DNS; catatan ini juga digunakan di spesifikasi Sender
Policy Framework.

9
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.

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.

Perangkat lunak DNS

Beberapa jenis perangakat lunak DNS menerapkan metode DNS, beberapa


diantaranya:

1. BIND (Berkeley Internet Name Domain)


2. jbdns (Daniel J. Bernstein's DNS)
3. MaraDNS
4. QIP (Lucent Technologies)
5. NSD (Name Server Daemon)
6. PowerDNS
7. Microsoft DNS (untuk edisi server dari Windows 2000 dan Windows
2003)

8. dig (the domain information groper)

10
Pengguna legal dari domain

1. Pendaftar (registrant)

Tidak satupun individu di dunia yang "memiliki" nama domain kecuali


Network Information Centre (NIC), atau pendaftar nama domain (domain
name registry). Sebagian besar dari NIC di dunia menerima biaya tahunan dari
para pengguna legal dengan tujuan bagi si pengguna legal menggunakan nama
domain tersebut. Jadi sejenis perjanjian sewa-menyewa terjadi, bergantung
kepada syarat dan ketentuan pendaftar. Bergantung kepada beberpa peraturan
penamaan dari para pendaftar, pengguna legal dikenal sebagai "pendaftar"
(registrants) atau sebagai "pemegang domain" (domain holders)

ICANN memegang daftar lengkap untuk pendaftar domain di seluruh


dunia. Siapapun dapat menemukan pengguna legal dari sebuah domain dengan
mencari melalui basis data WHOIS yang disimpan oleh beberpa pendaftar
domain.

Di (lebih kurang) 240 country code top-level domains (ccTLDs),


pendaftar domain memegang sebuah acuan WHOIS (pendaftar dan nama
server). Contohnya, IDNIC, NIC Indonesia, memegang informasi otorisatif
WHOIS untuk nama domain .ID.

Namun, beberapa pendaftar domain, seperti VeriSign, menggunakan


model pendaftar-pengguna. Untuk nama domain .COM dan .NET, pendaftar
domain, VeriSign memegang informasi dasar WHOIS )pemegang domain dan
server nama). Siapapun dapat mencari detil WHOIS (Pemegang domain,
server nama, tanggal berlaku, dan lain sebagainya) melalui pendaftar.

Sejak sekitar 2001, kebanyakan pendaftar gTLD (.ORG, .BIZ, .INFO)


telah mengadopsi metode penfatar "tebal", menyimpan otoritatif WHOIS di
beberapa pendaftar dan bukan pendaftar itu saja.

2. Kontak Administratif (Administrative Contact)

Satu pemegang domain biasanya menunjuk kontak administratif untuk


menangani nama domain. Fungsi manajemen didelegasikan ke kontak
administratif yang mencakup (diantaranya):

11
- keharusan untuk mengikuti syarat dari pendaftar domain dengan tujuan
memiliki hak untuk menggunakan nama domain
- otorisasi untuk melakukan update ke alamat fisik, alamat email dan
nomor telepon dan lain sebagainya via WHOIS

3. Kontak Teknis (Technical Contact)


Satu kontak teknis menangani server nama dari sebuah nama domain.
Beberapa dari banyak fungsi kontak teknis termasuk:
- Memastikan bahwa konfigurasi dari nama domain mengikuti syarat dari
pendaftar domain
- Update zona domain
- Menyediakan fungsi 24x7 untuk ke server nama (yang membuat nama
domain bisa diakses)
4. Kontak Pembayaran (Billing Contact).
Tidak perlu dijelaskan, pihak ini adalah yang menerima tagihan dari NIC.
5. Server Nama (Name Servers)
Disebut sebagai server nama otoritatif yang mengasuh zona nama
domain dari sebuah nama domain.

12
Materi Tambahan
Konfigurasi BIND di RedHat (DNS under Linux)
Installing BIND on RedHat
Requirements
- RedHat Linux 9
- BIND 9.2.1
This tutorial describes the steps for configuring BIND 9.2.1 on RedHat Linux 9. It
should be valid for other versions of BIND as well as some different distros of Linux.
I will be going over setting it up as a primary and secondary name server. This tutorial
spans three parts. In part 1 I will go over installing BIND and verifying the service
will start on boot-up. The first thing we will need to do is determine if BIND is
already installed on your system. The method I use is to check through the RPM
Package Manager. This will not work if you downloaded the BIND source code and
compiled it.
Type the following at the command prompt:
rpm -qa | grep -i bind

rpm -qa | grep -i caching

If BIND is installed you should get something similar to this (ignore ypbind...it is
unrelated to BIND) and you will want to skip to part 2 of this tutorial.

If BIND is not installed you will get something similar to the below image and you
should keep reading.

We need to install BIND and have a few options here. We can download the source
code and compile it, but we won't take that route. We will want to install the RPM's to
keep things simple. There are a couple sources we can get the RPM's from: download
them or use the RedHat 9 CD's. If you don't have the RedHat 9 CD's then you will
need to download the BIND RPM's
Download and Install the BIND RPM's.
We want to download the following files:
bind-9.2.1-16.i386.rpm

bind-devel-9.2.1-16.i386.rpm

13
bind-utils-9.2.1-16.i386.rpm

caching-nameserver-7.2-7.noarch.rpm

Download by wget
Issue these commands one at a time.
wget ftp://mirror.mcs.anl.gov/pub/redhat/redhat/linux/9/en/os/i386/RedHat/RPMS/bind-9.2.1-
16.i386.rpm

wget ftp://mirror.mcs.anl.gov/pub/redhat/redhat/linux/9/en/os/i386/RedHat/RPMS/bind-devel-
9.2.1-16.i386.rpm

wget ftp://mirror.mcs.anl.gov/pub/redhat/redhat/linux/9/en/os/i386/RedHat/RPMS/bind-utils-
9.2.1-16.i386.rpm

wget ftp://mirror.mcs.anl.gov/pub/redhat/redhat/linux/9/en/os/i386/RedHat/RPMS/caching-
nameserver-7.2-7.noarch.rpm

You should get something similar to the following for each file you download.

When you are done, do a directory list (ls) and you should have all four files.

Now that you have the RPM's it is time to actually install them. Go to the installation
part.

Installing the BIND RPM's


Whichever path you chose, whether downloading the RPM's or installing from CD,
you should be in the same directory where they are located. To install the RPM's you
issue the following command.
rpm -ivh bind-*.rpm caching-nameserver-7.2-7.noarch.rpm

You should get something a screen similar to the following.

14
To verify the RPM's installed successfully, issue the following commands.
rpm -qa | grep -i bind

rpm -qa | grep -i caching

BIND should now be installed and you should get a screen similar to the following.

Now we need to make sure the BIND service starts upon boot-up. To do this we will
use chkconfig and tell the OS to start named (BIND) to start on runlevels 3 and 5. For
more information about runlevels and the Linux boot process visit this site
http://www.siliconvalleyccie.com/linux-hn/runlevels.htm.
Issue the following commands to chkconfig to turn named (BIND) on for runlevels 3
and 5. Then we will verify they have been turned on.
chkconfig --levels 35 named on

chkconfig --list | grep -i named

I should also mention instead of using chkconfig you could have used the RedHat
Text Mode Setup Utility. From the command line type setup and press enter. Scroll
down to System Services and press enter. Scroll down to named and press the
spacebar to put a check on it. Press tab, enter, tab, tab, enter. You should be back to
the prompt. Verify that named will boot-up. Note: If you didn't install X Windows,
runlevel 5 may not be turned on. This is ok because runlevel 5 is Multi-User GUI
mode.
Everything looks good. Now we will start BIND and verify it is running.
/etc/init.d/named start

ps aux | grep -i named

15
That's all for part 1. In part 2 I will cover setting up BIND as a primary name server
for a single zone.
Now we will configure BIND to be a primary name server for a single zone. I will use
the fictitous domain somefakedomain.com as an example. We will add the hostnames
www, ftp, and mail. We will also have BIND respond if no hostname is specified in a
query (i.e. somefakedomain.com).
BIND stores its configuration data in named.conf which is located in the /etc
directory. This file contains the names of the zones and location of the zone data files
that it is responsible for answering queries for. The zone data files are stored by
default at /var/named (although you can change this path if you wish). Before you can
make any changes I will assume you know which text editor you will be using. I
prefer pico, but for this tutorial I will use vi since it has a better chance of being
installed by default.
Switch over to the /etc directory and open the named.conf file.
cd /etc

vi named.conf

You should see something that looks like the following.

Scroll through the file and take a look at the contents. Locate the localhost zone.
zone "localhost" IN {

type master;

file "localhost.zone";

allow-update { none; };

};

Move the cursor on the blank like below the }; and press the i key. The i key puts vi
in insert mode (you should see -- INSERT -- at the botton of vi). Press the enter key
once then type in the following. Note: the spacing in front of type, file, and allow-
update are tabs, so press the tab key on each of those lines.
zone "somefakedomain.com" IN {

16
type master;

file "somefakedomain.com.zone";

allow-update { none; };

};

Be sure to put a blank line underneath the }; when you are done. It always helps to
keep your files neat and clean. Now we will save the file. Press ESC and vi should
leave insert mode (-- INSERT -- at the bottom of vi should disappear). Now type :wq
and enter. vi should write our changes and exit back to the prompt.

We have told BIND that we handle the somefakedomain.com domain and the zone
data is in the somefakedomain.com.zone file located at /var/named. Now we have to
create the somefakedomain.com.zone file.
Switch over to /var/named and make a copy of the localhost.zone file and save it as
somefakedomain.com.zone. This will give us a template to work with so we don't
have to type as much. It also saves us from changing the file's owner, group, and
permissions.
cd /var/named

cp localhost.zone somefakedomain.com.zone

vi somefakedomain.com.zone

You should get something that looks like this.

Put vi in insert mode and alter the zone file so it looks like the data below. Use tabs
between items. Where I use 192.168.1.200 you should replace with your public IP
address (don't use local LAN IP's).
$TTL 86400

17
$ORIGIN somefakedomain.com.

@ IN SOA ns1.somefakedomain.com. admin.somefakedomain.com. (

2004042601 ; serial

21600 ; refresh

3600 ; retry

604800 ; expires

86400 ) ; minimum

IN NS ns1.somefakedomain.com.

IN MX 10 mail.somefakedomain.com.

IN A 192.168.1.200

ns1 IN A 192.168.1.200

wwwIN A 192.168.1.200

ftp IN A 192.168.1.200

mail IN A 192.168.1.200

Let's briefly go over the values (if you want more details on the contents of a zone file
visit).
"ns1.somefakedomain.com." is the name server responsible for somefakedomain.com.
When you register a domain name the registrar asks you for the name servers names
and IP's. We have given our name server the name ns1 (i.e. name server 1). So if we
were to register somefakedomain.com, we would use ns1.somefakedomain.com for
the name and the IP address of the machine we have designated as our DNS server.
"admin.somefakedomain.com." is the email address of the administrator in charge of
the zone. You replace the @ symbol in the email address with a period. So
admin@somefakedomain.com becomes admin.somefakedomain.com.
The "IN NS ns1.somefakedomain.com." means we are declaring
ns1.somefakedomain.com to be a name server.
With "IN MX 10 mail.somefakedomain.com." we are declaring a mail exchange (or
mail server) with a priority of 10. Since we only use one mail server the priority has
no effect.
The "IN A 192.168.1.200" means we are declaring a host (with no hostname, so it
means somefakedomain.com) and it's IP is 192.168.1.200. Any queries on just
somefakedomain.com will resolve to 192.168.1.200. This is is useful when you
configure your web server to work on somefakedomain.com or
www.somefakedomain.com. They both point to the same thing and will return the
same web site.
The rest of the entries mean we are declaring hosts ns1, www, ftp, and mail
(ns1.somefakedomain.com, www.somefakedomain.com, ftp.somefakedomain.com,

18
and mail.somefakedomain.com). Since they all share the same IP, each of those
services will run from the same machine. If you had the mail server running on a
different machine then you would substitute that machines IP address in place of
192.168.1.200. The same goes for the rest of the hosts.
When you are done editing the zone file, it should look like this.

Save it and close out of vi. Press ESC to get out of insert mode, type :wq and press
enter. You should be back to the command prompt.
Now we need to tell named (BIND) to load the zone and answer any queries that
come in.
/etc/init.d/named reload

Now we can test our domain using nslookup.


nslookup

server 127.0.0.1

somefakedomain.com

www.somefakedomain.com

mail.somefakedomain.com

You should see something similar to the following screen.

19
Everything looks good. BIND is resolving our somefakedomain.com. When you are
done, type exit and press enter.
If you purchased a real domain name then you shouldn't have any trouble configuring
BIND to respond to any queries for it. If you have a firewall running such as iptables,
make sure you have port 53 open. If you use a hardware firewall or router, open port
53 and port forward any requests for port 53 to the correct machine on your LAN.
Make sure all IP's you use in your zone files are the public IP addresses accessible
from the Internet. And you will need static IP addresses. Dynamic IP addresses from
providers such as Charter or Adelphia won't work. You may have the same IP for a
long time but it eventually change. At that time you will have to contact your domain
name registrar and have them change your DNS server IP address. You might want to
contact your ISP and see if they offer static IP's. If they do you might be paying more
for your Internet service. It might be time to migrate your server to a co-location.
If you need to add additional domains, just follow the same steps and you shouldn't
have any problems. If you want to configure a secondary name server (backup DNS)
then continue on to part 3 of this tutorial.
Now we will configure BIND to be a secondary name server for a single zone. We
will use the same fictitous domain somefakedomain.com from before. Before we do
anything for the secondary zone we should edit our primary zone file and add the
secondary server. All name servers for our zone should have a NS entry and the
hostname defined. Using the steps from before, open your zone file in vi and add the
NS for your secondary name server below the primary. Also add the hostname under
hosts and modify the serial to a new value. Be sure to use the public IP address of
your second system in place of the 192.168.1.201 I use in the example. Save your
changes. This is what your zone file should resemble on the primary name server.

20
Next we need to edit the /etc/named.conf to inform BIND to send a copy of our zone
to the secondary name server. Open named.conf in vi and modify the zone entry.
Include allow-transfer { 192.168.1.201; }; and save your changes. Your named.conf
should look similar to this

.
Now we will configure the secondary name server. Make sure BIND is installed and
running. Refer to part 1 of this tutorial if you are in doubt or need a refresher.
Open /etc/named.conf and enter this below the localhost zone.
zone "somefakedomain.com" IN {

type slave;

file "somefakedomain.com.zone";

masters { 192.168.1.200; };

};

Be sure to replace 192.168.1.200 with the public IP address of your primary server.
Save named.conf and yours should look similar to this.

21
That's it! Now all you have to do is reload the zone on the primary server. Issue this
command..
rndc reload

Now if you check your system log you should see the zone being transferred to the
secondary server.
cat /var/log/messages

Go into /var/named on the secondary server and list the directory. You should see a
copy of the zone file somefakedomain.com.zone.
cd /var/named

ls

If you view the contents of the zone it should look similar to that of the master copy.

22
cat somefakedomain.com.zone

This concludes the Configuring BIND on RedHat (DNS under Linux) tutorial.

Kesimpulan :

Pada dasarnya semua ISP (Internet Service Provider) atau penyedia layanan
sambungan internet seperti indosat, Telkomsel, Telkom, dan sebagainya
menggunakan atau mempunyai DNS Server tersendiri.

Domain Name System (DNS) adalah Distribute Database System yang


digunakan untuk pencarian nama komputer (name resolution) di jaringan yang
menggunakan TCP/IP. DNS merupakan sebuah aplikasi service yang biasa digunakan
di internet seperti web browser atau e-mail yang menerjemahkan sebuah domain ke IP
address.

DNS adalah Server yang menyimpan alamat Domain dan IP (Internet


Protocol) address, 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.

Gambaran antara IP dan Domain adalah seperti dibawah :


rajim-macbook:~ rajim$ nslookup
> google.com
Server: 114.127.253.84
Address: 114.127.253.84#53

Non-authoritative answer:
Name: google.com
Address: 74.125.19.147
Name: google.com
Address: 74.125.19.99

23
Name: google.com
Address: 74.125.19.103
Name: google.com
Address: 74.125.19.104
>

> ugm.ac.id
Server: 114.127.253.84
Address: 114.127.253.84#53

Non-authoritative answer:
Name: ugm.ac.id
Address: 175.111.88.8
>
> 175.111.88.8
Server: 114.127.253.84
Address: 114.127.253.84#53

Non-authoritative answer:
8.88.111.175.in-addr.arpa name = host-175-111-88-8.ugm.ac.id.

Perintah diatas adalah kita melakukan query ke name server untuk melakukan
pengecekan ip address nya domain google.com dan domain ugm.ac.id dan sebaliknya,
kita meminta agar name server melakukan pengecekan ip address 175.111.88.8
memakai nama host apa/

Jadi DNS adalah server yang akan menterjemaahkan alamat domain/URL


yang bisa kita baca dan menjadi sebuah alamat IP yang dikenali oleh jaringan
Komputer. DNS adalah penghubung antra Domain dan IP address, bahasa umum
penghubung pengalamatan “manusia” dengan pengalamatan “mesin”. Bayangkan jika
tidak ada Server yang mengelola pengalamatan ini, pasti kita semua akan tidak
mampu mengingat semua alamat internet (IP) yang dalam bentuk angka.

Referensi :

1. google.com
2. id.wikipedia.org/wiki/Sistem_Penamaan_Domain
3. ilmukomputer.org

24