At 05:51 24/10/00, Yulian Firdaus H wrote:
>Quoting S. Detta Harvianto on Tue, Oct 24, 2000 at 05:10:18AM +0700:
>
> > Nah sembari saya nunggu tanggapan, saya coba baca - baca di :
> > http://www.securityfocus.com/focus/sun/articles/dnscache.html
> > dan menghapus semua direktori dnscache, lalu setting ulang sesuai petunjuk
> > disana.
> > Mungkin ini yang dimaksud mas Yulian ?
>
>ini sih menghilangkan cache, sama seperti menghapus cachedir squid
>dan kembali melakukan squid -z
Bukan yang menghilangkan dnscache tersebut, mas Yulian ... 8)
Tapi cara - cara yang ada di dalam artikel tersebut.
>karena dibind di localhost/127.0.0.1 berarti ini adalah local cache
>berarti tinydns anda nggak akan eksis di network
>
>seharusnya
>dnscache (local cache) dibind di 127.0.0.1
>dnscachex (network cache) dibind di 192.168.0.1
Nah istilah tersebut yang membuat saya bingung ...
dnscache --> localhost cache
dnscachex --> network cache
Kalau menurut saya, itu hanya istilah kan ? Yang penting dimana dnscache
bind, localhost atau IP address server ? Juga isi dari
/var/djbdns/dnscache/root/servers root saja atau ada 0.168.192.in-addr.arpa
(isinya kosong, karena misalkan tinydns tidak terpasang)
Dari setting yang sudah saya buat, dan saya mengarahkan nameserver ke
192.168.0.1 di /etc/resolv.conf, saya lihat dnscache sudah men-cache
permintaan dns dari localhost (koneksi internet masih dari localhost)
Katakanlah squid sudah saya configurasi supaya pake dnscache, dan resolv
sesuai dengan /etc/resolv.conf :
nameserver 192.168.0.1
nameserver 202.134.0.155
Jadi logika saya :
client (192.168.0.5) ---> 192.168.0.1 ---> 127.0.0.1 ---> 202.134.0.155
|
| | |
+--- ns, proxy server
-----+ +-- internet --+
1. Permintaan dari client untuk dns tertentu (misal via web,
www.linux.or.id), akan diteruskan oleh squid menuju ke dnscache
(192.168.0.1). Jika tidak ada maka ditanya ke tinydns (127.0.0.1). Karena
tinydns tidak berhak menjawab query dari client, maka query diteruskan ke
ns 202.134.0.155
2. Permintaan dari clien untuk dns linux.detta.net (akses via ftp), maka
akan dilihat dnscache, ada atau tidak. Jika tidak ada maka, query
diteruskan ke tinydns. Tinydns ternyata berhak menjawab query ini,
detta.net, dan menjawabnya ke client. Tentu saja melalui 192.168.0.1 yang
otomatis di cache oleh dnscache.
Nah .. berarti tinydns eksis dong di network.
# echo "127.0.0.1" > /var/djbdns/dnscache/root/servers/detta.net
# cp /var/djbdns/dnscache/root/servers/detta.net
/var/djbdns/dnscache/root/servers/0.168.192.in-addr.arpa
Dari setting di atas kelihatan kalau dnscache 'megang' domain detta.net dan
diarahkan ke tinydns yang sudah di bind ke 127.0.0.1 . Dari baris kedua
dikatakan bahwa untuk network 192.168.0 ada ns yang menjawab query, yaitu
tinydns (bind di 127.0.0.1)
Ini masih asumsi dari logika saya .. entah bagaimana implementasi nantinya
di network saya (baru akan saya coba malam ini)
> > 1. nameserver di set ke 127.0.0.1 atau 192.168.0.1 ? Kalau 127.0.0.1 saya
> > lihat tinydns yang cache dns di ../tinydns/log/main/current. Kalau
> > 192.168.0.1, malah dnscache yang cache di ..dnscache/log/main/current
> > (akses internet baru dari localhost)
>
>cukup ke localhost 127.0.0.1 (dnscache dibind di ipaddress ini)
Aduh, kok jadi ruwet ...
Maksudnya kalau dnscache bind di 192.168.0.1 dan tinydns di localhost, maka
mana yang sebaiknya diset di nameservernya ? localhost atau 192.168.0.1 ?
Dugaan saya pasti di 192.168.0.1, soalnya dari artikel sudah ditegaskan :
...
"That being said, djbdns was designed with security in mind. Each major
portion of what is traditionally considered part of name service has been
split out in to a variety of daemons and auxiliary programs. The dnscache
program itself serves only as a caching DNS server, providing name
resolution for outbound requests. Designed with lessons learned from the
cache poisoning problems BIND and other name servers had, it is immune to
cache poisoning. The tinydns is a basic name server, which responds to
incoming requests for domains or IP's it is authoritative for. It never
caches any information, and will not respond to inverse queries, zone
transfers, and a variety of other problematic query types."
...
Soalnya kalau saya set di localhost, maka tinydns yang cache dnsnya,
padahal sudah diterangkan di artikel tsb. kalau "... tinydns never caches
any information ..."
> > 2. apakah benar kalau saya edit /etc/hosts
> > 127.0.0.1 localhost
> > 192.168.0.1 linux.detta.net linux
>
>bisa saja, tidak terlalu berpengaruh
Mungkinkah akan berpengaruh jika saya pasang Apache ?
>bisa, cuma alokasi binding ip dns harus tepat
>localhost: 127.0.0.1 dnscache
>ip ISP: 100.100.100.3 tinydns dan axfrdns
>ip internal: 192.168.0.1 dnscachex
Ok .. yang saya tangkap dnscache bind di localhost dan dnscachex nangani
dnscache external.
Lalu tinydns ? Apakah tinydns bertindak sebagai secondary ns dari ISP dan
memakai axfrdns untuk zone transfer ? Lalu bagaimana setting tinydns di ns
100.100.100.3 ? disesuaikan atau independent ?
Sebelumnya maaf ... soalnya saya masih belum mempelajari sampai disini
(axfrdns, tinydns primary dan secondary ns)
>kurang tahu, tapi biasanya saya nggak make dnsserver_program, cukup
>internalnya
>squid yang nyari dnsserver melalui /etc/resolv.conf (isi resolv.conf-nya
>sendiri adalah 127.0.0.1)
Semisal dnscache (katakanlah nameserver) sudah diset ulang .. apakah perlu
saya bangun squid mulai dari awal ? Jadi disesuaikan konfigurasi waktu
compile dan menghapus direktory cache dan membuat lagi yang baru (squid -z) ?
Thanks ...
NB : maaf kalau jadi panjang emailnya ... 8)
"Powered by ... open mind !"
-- detta --
--------------------------------------------------------------------------
Utk berhenti langganan, kirim email ke [EMAIL PROTECTED]
Dapatkan FAQ milis dg mengirim email kosong ke [EMAIL PROTECTED]
Informasi arsip di http://www.linux.or.id/milis.php3
Pengelola dapat dihubungi lewat [EMAIL PROTECTED]
