Ağ Uygulamaları

Hayal@

1.1. DNS
1.1.1. DNS'nin Tarihçesi
1.1.2. DNS'nin Yapısı
1.1.3. DNS Çözümlemesi
1.1.4. IP Adresinden İsim Çözümlemesi
1.1.5. DNS Önbelleği
1.2. BIND
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
1.2.1. BIND Paketinin Temini
1.2.2. BIND'in Kurulumu
1.2.3. BIND Yapılandırması
1.2.4. BIND'in Çalıştırılması
1.2.5. DNS Sorguları - NSLOOKUP
1.2.6. DNS Kayıtları
1.3. Yasal Açıklamalar
1.3.1. Telif Hakkı ve Lisans
1.3.2. Feragatname

1.1. DNS
Bilindiği üzere bir IP ağı üzerinde çeşitli servislere ulaşmak için bu servislerin çalıştığı sistemlerin IP adresi adı verilen ve 4 sayıdan oluşan akılda kalması zor ve son kullanıcılar için hemen hiçbir şey ifade etmeyen adreslerinin bilinmesi gerekmektedir. DNS servisi bu sorunu ortadan kaldırmak amacıyla tasarlanmıştır.

1.1.1. DNS'nin Tarihçesi
Yukarıda bahsedilen isimlendirme sorunu ilk olarak Internetin babası sayılan ArpaNet zamanında ortaya çıkmıştır. 1970'lerde ArpaNet günümüz ağları ile karşılaştırılamayacak kadar küçük durumdaydı ve yalnızca birkaç yüz ile ifade edilebilen sisteme hizmet veriyordu. Bu tarihlerde isimlendirme için tek noktada tutulan bir dosyanın bulunması ve diğer tüm sistemlerin bu dosyayı belli aralıklarla kendi taraflarında güncellemesi isimlendirme sorununu çözmüştü.
Adres-isim tanımlamalarını içeren HOSTS.TXT dosyası SRI tarafından SRI-NIC adında bir bilgisayar üzerinde tutulmaktaydı. Bu dosya her adrese bir isim karşılık gelecek şekilde düzenlenmişti. ArpaNet üzerindeki yeni isim tanımlamaları ve değişiklikleri SRI'ya gönderilen e-postalar aracılığı ile yapılıyor ve HOSTS.TXT'in kopyası ftp ile alınıyordu.

ArpaNet üzerinde TCP/IP kullanımına paralel olarak ortaya çıkan bağlantı patlaması, isim çözümü için bir çok sorunu da beraberinde getirdi. Öncelikle isim çakışmaları ortaya çıktı, sayı artmakta ve her bilgisayara özgün bir isim atanmasında problemler yaşanmaktaydı. Ayrıca yalnızca isim çözümlenmesi için oldukça yüksek miktarda bant genişliği harcanmakta ve buna rağmen kullanılan isim veritabanlarının uyumlu olması her zaman sağlanamamaktaydı.

Bu durumun ortaya çıkmasından sonra ArpaNet daha ölçeklenebilir bir isim çözümleme yapısı için araştırmalara başladı. Paul Mockapetris bu işle görevlendirildi. Mockapetris 1984 yılında Domain Name System (DNS)'i (Alan İsimlendirme Sistemi) tanımlayan RFC 882 ve 883'ü yayınladı. Bunlar daha sonra halen geçerli olan RFC 1034 ve 1035 tarafından güncellendiler.


1.1.2. DNS'nin Yapısı
ArpaNet döneminde ortaya çıkan güçlükler nedeniyle DNS tasarlanırken uçlardaki sistemlerin kendi bilgilerini kendilerinin güncelleyebileceği bir yapı üzerinde durulmuştur. Ortaya çıkan yapı ise en üstten başlayarak hiyerarşik bir şekilde uçlara doğru açılan dağıtık bir varitabanı mimarisidir. Uçlar birbirleri ile istemci sunucu yöntemiyle konuşurlar.
Farklı tablolar ile tek veritabanında tanımlanmış bir alan adı sistemini incelenirse yapısının hiyerarşik olduğu görülür. Her alan adı bir başka alan adının altında tanımlanmıştır. En üst seviyede bulunan bir tablo en üst seviye alan adları olan .com, net vb içerir ve bu alan adlarının ayrıntılarını içeren tabloları işaret eder. Aynı şekilde bu tablolar da kendi altlarında bulunan alan adlarını içerir ve ayrıntılarını gösteren tablolara işaret eder.

Açıklanan tablo yapısı Şekil-1 üzerinde gösterilmiştir.


Şekil-1

İlk tabloda en üst seviye alan adları tanımlanmış ve bu tabloda bulunan alt alan adlarının bilgileri ilgili tablolara işaret edilmiştir. Bu tek bir veritabanında gösterilmiş bir yapılanmadır. Bu yapıda tablolar farklı veritabanları üzerinde tutularak yönetim kolaylaştırılabilir. Bu durumda oldukça dinamik ve etkin bir mekanizma kurulmuş olur.

Dağıtık veritabanları arasında istemci-sunucu yöntemi ile bağlantı kurulur.

Az önce belirtilen en üst seviye alan adları arasında com, net, gov vb yanında ülkelerin ISO tarafından belirlenen sembolleri de tanımlanmıştır (tr, uk, fr, gr gibi).
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Yukarıdaki açıklamaların paralelinde oluşan hiyerarşik alan adı ağacı Şekil 2'de gösterilmiştir.


Şekil-2

Alan adı dağılımı en üst seviyeden başlar ve alt dallara doğru bölünür. Bir alan adının okunuşu en alttan başlayarak en üste doğru yapılır. Ağacın en altında bulunan alan adı ankara.ulak.net.tr şeklinde okunacaktır.

En üst seviye alan adlarının yönetimi InterNIC tarafından yapılmaktadır. ISO kodları ile tanımlanmış ülke adlarının yönetimi ülkelere göre değişiklik göstermektedir. Türkiye'nin ISO kodu olan tr üst seviye alan adının yönetimi Orta Doğu Teknik Üniversitesi (ODTÜ) tarafından yapılmaktadır. Dolayısıyla com, net, gov gibi alan adlarına kayıt InterNIC tarafından; com.tr, net.tr, gov.tr gibi alan adlarına kayıt ODTÜ tarafından yapılmaktadır. Alan adı kayıtlarıyla ilgili daha fazla bilgi için http://www.internic.net ve http://dns.metu.edu.tr adresleri incelenebilir.

ankara.ulak.net.tr örneğinde, ankara.ulak.net.tr alan adı UlakNet sunucuları üzerinde, ulak.net.tr alan adı ODTÜ sunucuları üzerinde, net.tr alan adı yine ODTÜ sunucuları üzerinde, tr alan adı ise root server (kök sunucusu)adı verilen en üst seviye alan adı sunucuları üzerinde tanımlanmış durumdadır. Kök sunucular, tr alan adını içeren alan adlarını çözümlemez, çözümü ODTÜ sunucularından ister. Dikkat edilmesi gereken nokta alan adları alındıktan sonra bu alan adındaki isimlendirmenin yerel olarak yapıldığıdır. Bu daha önce de değinilen yönetimin dağıtık olarak yapılabilmesini sağlar.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Bu bilgiler ışığında xxx.ankara.ulak.net.tr ya da yyy.ulak.net.tr şeklindeki bir tanımlama UlakNet'in kontrolünde, benzer şekilde abc.com.tr ya da xyz.net.tr şeklindeki bir tanımlama ise ODTÜ'nün kontrolündedir.

İncelenen alan adı ağacı maksimum 127 basamaktan oluşabilir ki bu da pratikte ulaşılması imkansıza yakın bir değerdir.


1.1.3. DNS Çözümlemesi
DNS'nin yapısı anlatılırken dağıtık bir veritabanı şeklinde oluşturulduğu ve uçların birbirbirleriyle istemci sunucu mantığı ile konuştuğunu söylenmişti. Bu işlevi yerine getiren programlara alan adı sunucu adı verilir (name server). Alan adı sunucuları alan adı ağacı üzerinde nokta ile gösterilirler.
Her alan adı sunucu bir veya birkaç alan adı bilgisini tutar ve bu alan adları için en yetkili alan adı sunucudur. Diğer alan adları için sorgularda bu alan adları için en yetkili alan adı sunucularını bulmaya çalışır.

Alan adı sunucular yerine getirdikleri kritik işlev nedeniyle genellikle yedekli olarak çalıştırılırlar. Bilgilerin tutulduğu ana veritabanı birincil alan adı sunucu olarak adlandırılır. İkincil sunucular, birincil alan adı sunucularının verilerini periyodik olarak kendi veritabanına kopyalarlar. Birincil sunucuda herhangi bir problem yaşandığında sorgulama ikincil sunucular üzerinde yapılır.

DNS çözümlemesi birkaç kademede incelenebilir. UlakNet alan adı sunucusunu kullanan bir istemcinin www.ulak.net.tr adresini sorguladığı durumda sunucu kendi veritabanında tanımlı olan bu adresi istemciye döndürecektir. Bu işlem, UlakNet alan adı sunucusu ulak.net.tr alan adı altında bulunan tanımlar için en yetkili sunucu olduğu için bu şekilde gerçekleşmiştir.

Şekil 3'te bu sorgunun nasıl gerçekleştirildiği görülmektedir.


Şekil-3

Hayal@

Görüldüğü gibi istemci www.ulak.net.tr adresini bu alan adı için en yetkili durumdaki alan adı sunucusunda sorgulamış ve bu adrese tanımlanmış IP adresi cevap olarak döndürülmüştür.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Benzer bir sorgulamayı Amerika kıtasında ns.digex.net adlı alan adı sunucuyu kullanan bir istemcinin yaptığındaki durum incelenebilir.

ns.digex.net kendisine sorulan www.ulak.net.tr için herhangi bir bilgiye sahip değildir. Bu yüzden kendi veritabanında tanımlı olan en üst seviye alan adı sunucularına (root-servers - daha sonra ayrıntılı olarak açıklanacaktır) bu adresi sorar. Bu sunucu da (a.root-servers.net) www.ulak.net.tr için kesin bilgiye sahip değildir. Ancak .tr üst seviye alan adının ns1.metu.edu.tr sunucusu tarafından kontrol edildiğini bilmektedir. Bu yüzden, ns.digex.net'e sorguyu ns1.metu.edu.tr üzerinde yapması bilgisini iletir. ns.digex.net bu kez aynı adresi ns1.metu.edu.tr üzerinde sorgulayacaktır. Ancak bu sunucu da www.ulak.net.tr için kesin adresi bilemeyecek ve sorgunun ulak.net.tr alan adı sunucusu olan ns.ulak.net.tr adresine yönlendirilmesini bildirecektir. Son olarak ns.digex.net, www.ulak.net.tr adresini ns.ulak.net.tr üzerinde sorgulayacak ve ns.ulak.net.tr kendi veritabanında www.ulak.net.tr için tanımlı olan 193.140.83.9 adresini döndürecektir. Bu bilgiye ulaşan ns.digex.net de kendi istemcisine bu bilgiyi iletecektir.

Bu sorgulama şekil 4'te gösterilmiştir.



Şekil-4

Bu analizde dikkati çekmesi gereken iki önemli nokta bulunmaktadır.

Öncelikle .tr den sorumlu gözüken ns1.metu.edu.tr'nin .net.tr için ayrı bir alan adı sunucuya yönlendirme yapmadığı, doğrudan ulak.net.tr alan adı sunucusuna yönlendirme yaptığına dikkat edilmelidir. Bu işlem,ns1.metu.edu.tr hem .tr hem de .net.tr için alan adı sunucusu olduğu için bu şekilde gerçekleşmiştir. Eğer .tr ve .net.tr farklı sunucular üzerinde tanımlı olsalardı ns.digex.net ayrıca .net.tr'den sorumlu sunucuyu da sorgulamak durumunda kalacaktı.

Dikkat edilmesi gereken diğer nokta ise istemcinin alan adı sunucuya yalnızca bir sorgu iletmesi ve tüm iş sunucu tarafından yapıldıktan sonra yalnızca cevabı almasıdır. Aynı durum ns.digex.net diğer alan adı sunuculara ulaşırken ortaya çıkmamış ve her biri ayrı ayrı sorgulanmıştır. Bunun sebebi ns.digex.net sunucusunun tekrarlı (recursive), diğer alan adı sunucularının ise tekrarlı olmayan (iterative) bir şekilde sorgulanmış olmasıdır.


1.1.4. IP Adresinden İsim Çözümlemesi
Bölüm 1.3'te isimden adres çözümlemesi incelenmiştir. Şu ana kadar anlatılan yapı tüm sistemin isimden adres çözümü için tasarlandığı izlenimini vermektedir. Ancak pratik ihtiyaçlar, IP adresinden isim çözümünü de gerekli kılmaktadır.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
Böyle bir sorgunun şu ana kadar incelenen yapı üzerinde nasıl çalışabileceğine bakalım. İsimlerin indesklenmesine göre oluşturulmuş hiyerarşik bir sistem görülmektedir. Ancak IP adreslerin bu yapı üzerinde herhangi bir hiyerarşik yapısı bulunmamaktadır. Örneğin www.ulak.net.tr adresi 193.140.83.9 IP numarası ile adreslenmişken truva.ulakbim.gov.tr adresi 193.140.83.13 IP numarası ile adreslenmiş olabilir. Bu da 193.140.83. ile başlayan IP'lerin teorik olarak tüm alan adı uzayına yayılmış olabileceğini gösterir.

Görüldüğü gibi mevcut yapıda bir IP adresinin isim karşılığını bulmak için veritabanının tümünün taranması gerekmektedir. Bu ise indeksi olmayan dağınık durumdaki milyonlarca kaydın taranması anlamına gelir ki imkansıza yakın bir uğraştır. Bu sorunun çözülebilmesi için IP adresleri için de hiyerarşik bir yapının kurulması gerektiği görülmektedir.

Bu yapıya geçmeden önce IP adreslemenin özelliklerinin hatırlanması yararlı olacaktır. IP adresleri ilk oktetten son oktete (soldan sağa doğru) en genelden en özele doğru sıralanırlar. Örneğin 193.140 hem 193.140.83.13'ü hem de 193.140.83.9'u içine alır.

Alan adları ise buna ters olarak sağdan sola doğru en genelden en özele doğru sıralanırlar. Örneğin .tr hem ulak.net.tr'yi hem de metu.edu.tr'yi içine alır.

İki gösterim de genelden özele sıralanabildiğine göre mevcut hiyerarşik yapılandırmaya IP numaraları için bir üst seviye alan adı eklenmesi mümkündür. Bu alan adı in-addr.arpa şeklinde ifade edilir. Bu üst seviye alan adı 1'den 255'e kadar çeşitli alt alanlara bölünür. Bu bölümlemeye 4 okteti tamamlayacak şekilde devam edilebilir. Bu durumda ortaya çıkan yapı şekil 5'te gösterilmiştir.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742



Üst seviye alan adları arasına arpa adında bir alan adı eklenmiştir. Bu alan adının altında in.addr şeklinde bir alan daha tanımlanmıştır. Bu alan adının altında IP numarasının ilk okteti alan adı olarak eklenmiş, bunu sırayla IP numarasının ikinci, üçüncü ve dördüncü oktetleri izlemiştir.

Görüldüğü gibi artık 193.140.83.13 ve 193.140.83.9 IP numaralarının isim karşılıklarını bulmak son derce kolaylaşmıştır. İncelenen isim sorgusuna benzer bir şekilde IP-isim sorguları da bu yapının yardımıyla yapılabilmektedir. Ancak dikkat edilmesi gereken önemli birkaç nokta bulunmaktadır.

Normal alan adı isimlendirme sisteminde isimler ağacın en altından en üstüne doğru okunur. Bu durumda IP numaraları bilinenin aksine özelden genele doğru okunacaklardır. Örneğin 193.140.83.13 IP numarasının DNS ağacı üzerinde okunuşu 13.83.140.193.in-addr.arpa şeklinde olacaktır.

Dikkat edilmesi gereken diğer bir nokta ise isimden IP'ye yapılan tanımlama ile IP'den isime yapılan tanımlama arasında herhangi bir bağlantı bulunmayışıdır. Örneğin www.ulak.net.tr adresi DNS üzerinde 193.140.83.9 olarak tanımlıyken, 193.140.83.9 IP adresinin ismi efe.ulakbim.gov.tr şeklinde tanımlı olabilir.


1.1.5. DNS Önbelleği
DNS çözümlemesinde anlatıldığı şekilde isim çözümleme işlemi ardışıl olarak alan adı sunucularının sorgulanmasını gerektirir. Bu işlem oldukça vakit alıcı bir işlem olabilir ve karşılıklı olarak sistemler üzerinde yük oluşturduğu gibi hatlar üzerinde yüksek miktarda bant genişliği harcayabilir.
Bunun engellenmesi ve sorgunun mümkün olan en kısa sürede sonuçlandırılabilmesi için alan adı sunuculara önbellek (cache) özelliği eklenmiştir. Bu sayede bir alan adı sunucu daha önce sorguladığı alan adlarını kendi belleğinde tutarak yeni sorgularda diğer alan adı sunucularını sorgulamadan doğrudan cevap verebilir. Bu yukarıda anlatılan olumsuzlukları belli bir derecede önleyecektir. Ancak burada önemli bir nokta gözden kaçırılmamalıdır.

Sorgulanan alan adında son sorgulamadan sonra değişiklik yapılmış olabilir. Bu durumda bellekte tutulan bilgi güncelliğini yitirmiştir ve istemciye hatalı bilgi geri döndürülecektir.

Bu ancak belli bir noktaya kadar kabul edilebilir bir durumdur. Alan adı tanımları normalde çok sık değiştirilen tanımlamalar değillerdir. Nadiren değitirildiklerinde de değişikliğin etkinleşmesi için bir gün gibi bir süre çoğu zaman yeterlidir. Şu halde bellekte tutulan bilgilerin bir süre sonra güncelliğini yitirdiği kabul edilmelidir. Bunu belirleyen değere daha önceki konularda da değinildiği gibi TTL (Time To Live - Yaşam Süresi) denilmektedir ve her alan adının tanımlanmasında bu alan adı için geçerli TTL değeri belirtilir. Bu alan adından sorgulanan bilgiler bellekte TTL süresince tutulduktan sonra güncelliğini yitirdiği kabul edilir. TTL'in nasıl tanımlandığı daha sonra incelenecektir.

Hayal@

1.2. BIND
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
Bu bölüme kadar olan kısımda isim çözümleme işlemi açıklanmıştı. Burada ise bir alan adı sunucunun nasıl kurulduğu ve yapılandırması ayrıntılarıyla anlatılacaktır.
BIND (Berkeley Internet Name Domain) adını geliştirildiği Berkeley üniversitesinden alan günümüz Internetinin tartışmasız en popüler alan adı sunucu yazılımıdır. Unix sistemlerinde tasarlanmış ve çalıştırılmaya başlamış olmasına rağmen bugün Microsoft NT için üretilmiş dağıtımları da mevcuttur.


1.2.1. BIND Paketinin Temini
BIND'ın geliştirilmesi Internet Yazılım Konsorsiyumu (Internet Software Consortium) tarafından yapılmaktadır ve web sayfalarından ücretsiz olarak indirilebilir.
BIND'in bu belgenin yazımı anındaki en son sürümü Kasım 1999'da yaynlanmış olan sürüm 8.2.2 yama 5'tir. http://www.isc.org/products/BIND adresinden indirilebilir.

BIND'in yaygın kullanımda olan 4. ve 8. sürümleri arasında oldukça büyük farklar bulunmaktadır. Bu belgede 8. sürüm incelenecek olup, 4. sürümünü kullananların da mümkünse bu sürüme terfi etmeleri önerilir.


1.2.2. BIND'in Kurulumu
BIND paketinin indirilmesi, derlenmesi ve kurulması örneklenerek gösterilecektir. Test makinası sparc mimari üzerinde çalışan bir Red Hat Linux'tur. Ancak Linux üzerinde dağıtım ile beraber gelen derlenmiş durumdaki BIND da kullanılabilir. Burada derlemenin verilmesindeki amaç farklı platformlardaki kullanıcılara yardımcı olmaktır.
[ilker@hornet bind]$ ftp ftp.isc.org
Connected to isrv4.pa.vix.com.
220 isrv4.pa.vix.com FTP server (Version wu-2.6.0(1) Tue Nov 30 17:39:57 PST 1999) ready.
Name (ftp.isc.org:ilker): ftp
331 Guest login ok, send your complete e-mail address as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd isc/bind/src/8.2.2-P5
250 CWD command successful.
ftp> bin
200 Type set to I.
ftp> get bind-src.tar.gz
local: bind-src.tar.gz remote: bind-src.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for bind-src.tar.gz (1251509 bytes).
226 Transfer complete.
1251509 bytes received in 30.6 secs (40 Kbytes/sec)
ftp> bye
221-You have transferred 1251509 bytes in 1 files.
221-Total traffic for this session was 1252085 bytes in 1 transfers.
221-Thank you for using the FTP service on isrv4.pa.vix.com.
221 Goodbye.

[ilker@hornet bind]$ tar -xzvf bind-src.tar.gz
... ... ...
[ilker@hornet bind]$ cd src
[ilker@hornet src]$ make depend
... ... ...
[ilker@hornet src]$ make
... ... ...
[ilker@hornet src]$ su
Password:
[root@hornet src]# make install
... ... ...
[root@hornet src]# /usr/sbin/named -v
named 8.2.2-P5 Sun Apr 23 13:45:06 EEST 2000
ilker@hornet.ulakbim.gov.tr:/home/ilker/download/bind/src/bin/named
[root@hornet src]#


Görüldüğü gibi BIND'ın kurulumu başarıyla tamamlanmıştır.

1.2.3. BIND Yapılandırması
BIND yapılandırma dosyası olarak, aksi belirtilmediği sürece /etc/named.conf dosyasını kullanır. BIND'in 4. sürümü için bu dosya /etc/named.boot dosyasıdır ve dosyaların biçemleri birbirinden hayli farklıdır bu yüzden iki dosyanın karıştırılmamasına dikkat edilmelidir.
Örnek bir named.conf dosyasını aşağıda gösterilmiştir.


// /etc/named.conf
// Ilker TEMIR - 23/04/2000
//

options {
directory "/var/named";
};

zone "." {
type hint;
file "named.root";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "rev.local";
};
zone "ulak.net.tr" {
type master;
file "zone.ulak.net.tr";
};

zone "83.140.193.in-addr.arpa" {
type master;
file "rev.193.140.83";
};


Düşünülenin aksine named.conf çoğu durumda örnekte görüldüğü kadar yalın olacaktır. Dosya içeriği aşağıda incelenecektir.
Seçenekler (options) kısmında tanımlanan dizin (directory), adres tanımlarını içeren dosyaların bulunacağı dizindir. Belirtilen tüm dosyalar buradaki dizin altında yer alacaklardır. /var/named genellikle bu amaçla en çok kullanılan dizindir.

zone "." tanımı değiştirilmemesi gereken standart bir tanımdır. DNS çözümlemesi kısmında açıklanan üst seviye alan adı sunucularını gösterir, sunucu NS çözümünü yapamadığı alanlar için burada tanımlı olan alan adı sunuculara başvuracaktır. Bu sunucu adreslerinin nereden temin edileceği ilerleyen kısımlarda açıklanacaktır.

zone "0.0.127.in-addr.arpa" tanımı loopback olarak tabir edilen bilgisayarın kendi kendine bağlanması için gereken adreslerin ters tanımlamaları için gereklidir. Bu tanım da değiştirilmeden tutulmalıdır.

zone "ulak.net.tr" tanımı ile başlayan kısım anlaşılması gereken en önemli kısımlardan biridir. Örnekte bu, ulak.net.tr şeklinde bir alan adı tanımlandığını gösterir. Type belirteci ise sunucunun alan adı için durumunu belirtir. Örnekte belirtilmiş olan master birincil isim sunucusunu göstermektedir. File belirteci ile belirtilen isim ise ulak.net.tr için adres IP tanımlamalarını içeren dosyanın adıdır. Örnekte bu dosya /var/named/zone.ulak.net.tr olmaktadır.

Zone "83.140.193.in-addr.arpa" tanımı ile başlayan kısım da bir öncekine benzer şekilde 83.140.193.in-addr.arpa alan adını tanımlamaktadır. Çözümleme kısmında açıklandığı şekilde bu alan adı 193.140.83 ağında bulunan IP adreslerinin isim karşılıklarını bulmak için kullanılacaktır.

named.conf dosyası BIND'a hangi alanlardan sorumlu olduğu ve bu alanlara ait bilgileri nerede bulacağı gibi parametreleri vermektedir. Ancak IP adres karşılıkları bu dosyada işaret edilen veri dosyalarında bulunacaktır. Belirtilen dosya adları tamamen sistem yöneticisinin tercihine kalmıştır ancak sistematik bir yol izlenmesi faydalı olacaktır.

named.conf dosyasında belirtilen dosyaların içerikleri aşağıda incelenmiştir. Belirtilen dosyaların tamamı /var/named dizini altında yer alacaktır.

named.root: Bu dosya root-server adı verilen en üst seviyede bulunan alan adı sunucularının isimlerini ve adreslerini içermektedir. Sıklıkla değişmemekle birlikte güncel hali ftp://ftp.rs.internic.net adresinden çekilebilir. Bu satırların yazıldığı tarih itibariyle bu dosya şu şekildedir:

; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; temporarily housed at ISI (IANA)
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File


rev.local: Bu dosya 127.0.0 ağına ait olan IP adreslerinin isim tanımlamalarını içermektedir. İçeriği aşağıda verilmiştir. İçeriği rev.193.140.83 dosyasının açıklanmalarında bulunabilir.

Hayal@

$TTL 86400
@ IN SOA hornet.ulak.net.tr. root.hornet.ulak.net.tr. (
2000042300 ; Serial
28800 ; Refresh
14400 ; Retry
360000 ; Expire
86400 ) ; Minimum
IN NS hornet.ulak.net.tr.

1 IN PTR localhost.


zone.ulak.net.tr: Bu dosya ulak.net.tr alan adı altında tanımlı isim adres tanımlamalarını içermektedir. İçeriği aşağıda sunulmuştur.

$TTL 86400
@ IN SOA hornet.ulak.net.tr. root.hornet.ulak.net.tr. (
2000042300 ; Serino
28800 ; Yenileme
14400 ; Tekrar
3600000 ; Süre
86400 ) ; TTL
IN NS hornet.ulak.net.tr.

ulak.net.tr. IN MX 10 efe.ulak.net.tr.
efe IN A 193.140.83.9
truva IN A 193.140.83.13
hornet IN A 193.140.83.91
www IN CNAME efe.ulak.net.tr.


İlk satırda görülen değer daha önce açıklanan TTL değeridir. Bu sunucuya ulaşan istemcilerin sorguladıkları isimleri ne kadar süreyle belleklerinde tutacaklarını gösterir. Bu değerin bilinçsiz olarak değiştirilmesi önerilmez. Çoğu durum için 24 saat uygun bir değerdir. Çok küçük olması DNS trafiğini artıracaktır. Ayrıca 0 yapmaktan kaçınılması gerekir.

İkinci satırın başında görülen @ alan adını belirten bir kısa gösterimdir, örnekte ulak.net.tr.'nin yerine geçmiştir.

@'in yanında görülen IN, tanımın Internet için bir tanım olduğunu gösterir (Internet haricinde tanımlar yapabilmek mümkün olsa da burada değinilmeyecektir).

SOA, Start Of Authority anlamına gelir ve alan adı ile ilgili genel tanımları gösterir. Daha sonra gelen hornet.ulak.net.tr. sunucunun üzerinde çalıştığı bilgisayarın adı. root.hornet.ulak.net.tr. ise ilk ., @ ile değiştirilmek kaydıyla sunucudan sorumlu kişinin e-posta adresini gösteren tanımlardır.

Sırasıyla verilen serino, yenileme, tekrar ve süre sayısal değerleri sunucu için çeşitli sayaç ve zaman kıstaslarını gösterir. Zaman birimlerinin tamamı saniyedir. Ne anlama geldikleri daha sonra incelenecektir.

Daha sonra görülen NS kaydı Name Server (alan adı sunucu) tanımıdır. Her alan adı için en az bir alan adı sunucusu bu şekilde tanımlanmalıdır.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Sonraki satırda ulak.net.tr. için tanımlanmış olan MX 10 kaydı görülmektedir. MX, Mail EXchanger'ı temsil eder ve belirtilen alan adı için posta servisinin çalıştığı bilgisayarın ismini gösterir. 10 ise tercih değeridir. Farklı tercih değerleri içinde en düşük tercih değeri seçilecektir. Buradaki örnek, ulak.net.tr alan adına giden mesajların efe.ulak.net.tr bilgisayarına yönlendirilmesini sağlar.

Farklı isimlerin yanında olan A kayıtları, adres kayıtlarını temsil eder. İsmin hangi IP numarasına karşılık geldiğini gösterir.

Son satırda görülen CNAME tanımı ise Canonical NAME'den gelir ve bilgisayarlara ikincil isim verilmesini sağlar. Örnekte görülen tanım www.ulak.net.tr adresinin efe.ulak.net.tr adresi ile aynı olmasını sağlar. A kaydına tercih edilmesinin nedeni efe.ulak.net.tr tanımı değiştiğinde onu gösteren CNAME kayıtlarının da otomatik olarak değişmesidir. Kullanımda bazı problemler yaratabildiği için kullanılması önerilmez. CNAME kullanmak yerine farklı A tanımları yapmak daha uygundur.

rev.193.140.83: Bu dosya 193.140.83 ağına ait olan IP adreslerinin isim tanımlamalarını içermektedir. İçeriği aşağıda verilmiştir.

$TTL 86400

@ IN SOA hornet.ulak.net.tr. root.hornet.ulak.net.tr. (
2000042300 ; Serino
28800 ; Yenileme
14400 ; Tekrar
360000 ; Süre
86400 ) ; TTL
IN NS hornet.ulak.net.tr.

9 IN PTR efe.ulak.net.tr.
13 IN PTR truva.ulak.net.tr.
91 IN PTR hornet.ulak.net.tr.


Görüldüğü gibi alan adı tanımları hemen hemen standarttır ve bu dosyanın da içerik olarak az önce incelenen dosyadan çok farkı yoktur. Fark yalnızca yeni ortaya çıkan PTR kaydıdır, PoinTeR (işaret, gösterge) anlamına gelir. Örnekler sırasıyla 193.140.83.9'un efe.ulak.net.tr, 193.140.83.13'ün truva.ulak.net.tr ve 193.140.83.91'in hornet.ulak.net.tr'yi adreslediğini gösterir.

Sıklıkla kullanılan temel kayıtlar iki dosyanın içeriğinin incelenmesi sırasında açıklanmıştır. Ancak burada belirtilmeyen farklı kayıtlar da mevcuttur. Bunların listesi ve açıklamaları daha sonra verilecektir.

SOA kaydında belirtilen parametreler aşağıda ayrıntılı olarak incelenmişlerdir.

Seri No:
Sunucudan bilgi alan ikincil isim sunucular tarafından kullanılır. Burada belirtilen değerin ne olduğu gerçekte çok önemli değildir. Önemli olan dosya içeriğinde değişiklik yapıldığında mutlaka artırılması gerektiğidir. İkincil isim sunucular bu değere bakarak alan adı içeriğinin değişip değişmediğine karar verirler.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
Genellikle yıl, ay, gün ve gün içinde yapılan değişiklik sayısı şeklinde kullanılır.



Yenileme:
İkincil sunucular için birincil sunucuyu ne kadar aralıkla kontrol edeceğini gösteren değerdir. Örneğimizde bu değer 8 saattir. Her 8 saatte bir ikincil sunucu birincil sunucuda değişiklik yapılıp yapılmadığını kontrol edecektir.


Tekrar:
Eğer ikincil sunucu herhangi bir nedenle birinci sunucuya ulaşmakta sorun yaşarsa tekrar denemek için ne kadar bekleyeceğini gösteren değerdir. Genellikle Yenileme süresinden daha kısa bir süredir. Örneğimizde 4 saattir.


Süre:
Bu kısım oldukça önemlidir. İkincil sunucunun birincil sunucuya ulaşamadığı durumlarda kendisinde bulunan verinin ne kadar daha doğru kabul edildiğini gösterir. Bu süreden sonra ikincil sunucu çağrılara cevap vermeyi keser. 1 haftadan kısa olması kesinlikle önerilmez. Yenileme ve Tekrar değerlerinden çok daha büyük olmalıdır.


TTL:
Daha önce açıklanan 'Yaşam Süresi' (TTL - Time to live) değeridir. İlk satırda $TTL ile belirtilenden farkı BIND 8.2.1 ile birlikte buradaki değerin yalnız negatif TTL olarak kullanılmasıdır. Negatif TTL hata veren sorgulamaların bellekte tutulması için geçerli süredir.



1.2.4. BIND'in Çalıştırılması
Daha önce açıklanan yapılandırma tamamlandıktan sonra, BIND, root kullanıcısı yetkileriyle aşağıdaki şekilde çalıştırılır.
[root@hornet /root]# /usr/sbin/ndc start
new pid is 9089
[root@hornet /root]#


Çalışıp çalışmadığını anlamak için aşağıdaki yol izlenebilir.
root@hornet /root]# ps -aux |grep named
root 9089 0.0 1.4 2568 1808 ? S 09:23 0:00 /usr/sbin/named
root 9131 1.0 0.5 1464 712 pts/2 S 09:23 0:00 grep named
[root@hornet /root]#


Görüldüğü gibi named işlemi 9089 PID ile çalışmaya başlamıştır. Herhangi bir hata verip vermediği günlük dosyalarından kontrol edilmelidir.
[root@hornet /root]# tail /var/log/messages

Apr 24 15:15:30 hornet named[9088]: starting. named 8.2.2-P5 Sun Apr 23 13:45:06 EEST 2000 ^Iilker@hornet.ulakbim.gov.tr:/home/ilker/download/bind/src/bin/named
Apr 24 15:15:30 hornet named[9088]: hint zone "" (IN) loaded (serial 0)
Apr 24 15:15:30 hornet named[9088]: master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 2000042300)
Apr 24 15:15:30 hornet named[9088]: master zone "ulak.net.tr" (IN) loaded (serial 2000042301)
Apr 24 15:15:30 hornet named[9088]: master zone "83.140.193.in-addr.arpa" (IN) loaded (serial 2000042301)
Apr 24 15:15:30 hornet named[9088]: listening on [127.0.0.1].53 (lo)
Apr 24 15:15:30 hornet named[9088]: listening on [193.140.83.91].53 (eth0)
Apr 24 15:15:30 hornet named[9088]: Forwarding source address is [0.0.0.0].1038
Apr 24 15:15:30 hornet named[9089]: Ready to answer queries.
[root@hornet /root]#


Bilgi: Sistem günlükleri farklı Unix türevlerinde farklı dizinlerde bulunabilir. /var/log/messages Linux için geçerli bir günlük dosyasıdır.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Görüldüğü gibi günlüklerde bir sorunu gösteren herhangi bir belirti bulunmamaktadır. Alan adı sunucusu sorunsuz olarak çalışmaktadır.


1.2.5. DNS Sorguları - NSLOOKUP
Nslookup alan adı sunucularını sorgulamak için oldukça etkili bir yazılımdır. Çok ayrıntılı kullanım seçenekleri mevcut olsa da burada ayrıntıya girilmeyecektir. Hemen tüm Unix sistemlerinde yüklü olarak gelmektedir ayrıca Windows NT üzerinde de yüklü olarak gelir.
Çalışan sunucunun nslookup yardımıyla sorgulanması aşağıda gösterilmiştir.

[root@hornet named]# nslookup - 0
Default Server: hornet.ulak.net.tr
Address: 0.0.0.0

> set type=soa
> ulak.net.tr
Server: hornet.ulak.net.tr
Address: 0.0.0.0

ulak.net.tr
origin = hornet.ulak.net.tr
mail addr = root.hornet.ulak.net.tr
serial = 2000042301
refresh = 28800 (8H)
retry = 14400 (4H)
expire = 3600000 (5w6d16h)
minimum ttl = 86400 (1D)
ulak.net.tr nameserver = hornet.ulak.net.tr
hornet.ulak.net.tr internet address = 193.140.83.91
> set type=a
> truva.ulak.net.tr
Server: hornet.ulak.net.tr
Address: 0.0.0.0

Name: truva.ulak.net.tr
Address: 193.140.83.13

> www.ulak.net.tr
Server: hornet.ulak.net.tr
Address: 0.0.0.0

Name: efe.ulak.net.tr
Address: 193.140.83.9
Aliases: www.ulak.net.tr

> set type=ptr
> 9.83.140.193.in-addr.arpa
Server: hornet.ulak.net.tr
Address: 0.0.0.0

9.83.140.193.in-addr.arpa name = efe.ulak.net.tr
83.140.193.in-addr.arpa nameserver = hornet.ulak.net.tr
hornet.ulak.net.tr internet address = 193.140.83.91


İlk satırda görülen, nslookup komutunun alan adı sunucu olarak kendi çalıştığı makinayı kullanacak şekilde

Hayal@

İlk satırda görülen, nslookup komutunun alan adı sunucu olarak kendi çalıştığı makinayı kullanacak şekilde çalıştırılmasıdır. Sorgu tipi SOA'ya değiştirilerek (açılışta varsayılan sorgu tipi A kaydı sorgusudur) ulak.net.tr alan adı için SOA kaydı incelenmiştir. Tüm değerler daha önce tanımlananlarla uyum içerisindedirler. Daha sonra sorgu türü A kaydına çevrilmiş ve truva.ulak.net.tr için IP adresi bulunmuştur. Veritabanında CNAME olarak tanımlanmış olan www.ulak.net.tr için yapılan A kaydı sorgulaması bu adresin takma ad olarak tanımlandığı efe.ulak.net.tr adresini döndürmüştür. Son olarak yapılan PTR sorgulamasıyla da 193.140.83.9'un ters (reverse) tanımı bulunmuştur. Bu da daha önce tanımlanan efe.ulak.net.tr şeklindedir.

Nslookup sorguları genişletilerek devam edilirse;

> set type=a
> www.metu.edu.tr.
Server: hornet.ulak.net.tr
Address: 0.0.0.0

Non-authoritative answer:
Name: www.metu.edu.tr
Address: 144.122.199.13


www.metu.edu.tr alan adı için ilgili adres döndürülecektir. DNS tanımlarında Türkiye ile herhangi bir tanım olmadığı halde bu işlem nasıl yapılmıştır.
Daha önce açıklandığı şekilde root-server kullanılarak .tr alan adından sorumlu sunucular bulunmuş ve ardışıl sorgulama ile adrese ulaşılmıştır.

Sorgulamaya aşağıdaki şekilde devam edilsin.

> set norecurse
> www.bilkent.edu.tr.
Server: hornet.ulak.net.tr
Address: 0.0.0.0

Name: www.bilkent.edu.tr
Served by:
- ns1.metu.EDU.tr
144.122.199.90
EDU.tr
- ns2.metu.EDU.tr
144.122.199.93
EDU.tr
- ns.ulak.net.tr

EDU.tr
- firat.bcc.bilkent.EDU.tr
139.179.10.13
EDU.tr

> www.metu.edu.tr.
Server: hornet.ulak.net.tr
Address: 0.0.0.0

Non-authoritative answer:
Name: www.metu.edu.tr
Address: 144.122.199.13

> www.ulakbim.gov.tr.
Server: hornet.ulak.net.tr
Address: 0.0.0.0

Name: www.ulak.net.tr
Served by:
- NS1.METU.EDU.tr
144.122.199.90
tr
- NS2.METU.EDU.tr
144.122.199.93
tr
- MUNNARI.OZ.AU
128.250.1.21
tr
- NS.RIPE.NET
193.0.0.193
tr
- NS1-AUTH.SPRINTLINK.NET
206.228.179.10
tr
- NS.UU.NET
137.39.1.3
tr


set norecurse komutu daha önce açıkladığımız tekrarlı sorgulama modunu iptal etmiştir. Bu komuttan sonraki sorgular tekrarlı olarak yapılmayacaktır.
Tekrarlı sorgu kapatıldıktan sonra bu kez www.bilkent.edu.tr için sorgulama yapılmış ancak sunucu cevap olarak .edu.tr'ler için geçerli sunucuları döndürmüştür.

www.ulakbim.gov.tr alan adı sorgulandığında ise .tr'ler için geçerli sunucular dönmüş ancak www.metu.edu.tr için IP karşılığı döndürülmeye devam etmiştir. Bu nasıl olmaktadır?

Öncelikle tekrarlı sorguyu kapatmadan önce www.metu.edu.tr için sorgulama yapıldığı hatırlanmalıdır. Bu sorgulama sırasında sunucumuz bu adres için yaptığı tüm sorguları belleğinde saklamaktadır. Bunlar .tr alan adı sunucuları, .edu.tr alan adı sunucuları, .metu.edu.tr alan adı sunucuları ve www.metu.edu.tr adresinin IP numarasıdır. Bu yüzden .edu.tr altında bulunan www.bilkent.edu.tr sorgulaması yapıldığında bu alan adı hakkında en fazla bilgiye sahip olan .edu.tr alan adı sunucuları, .gov.tr altında bulunan www.ulakbim.gov.tr sorgulaması yapıldığında ise en fazla bilgiye sahip olan .tr alan adı sunucuları döndürülmüştür. www.metu.edu.tr adresi ise bellekten doğrudan cevaplanmıştır.


1.2.6. DNS Kayıtları
Geçerli DNS kayıtlarına daha önce de değinilmişti. Bu kayıtlar örneklerde belirtilenlerden sayıca daha fazladır. Burada daha önce açıklananlarla birlikte ayrıntıya girilmeden açıklanacaklardır. Halen deneysel durumda olan kayıtlara burada değinilmeyecektir. Tam listesi RFC1035'ten bulunabilir.

A:
Adres kaydıdır. İsme karşılık gelen 32 bitlik IP numaras tanımlanır.
Örnek:

marine.ulakbim.gov.tr. IN A 193.140.83.27
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742




CNAME:
Takma ad kaydıdır. Takma ad tanımlanır.
Örnek:

ilker.ulakbim.gov.tr. IN CNAME truva.ulakbim.gov.tr.




HINFO:
Bilgi kaydıdır, işlemci işletim sistemi tanımlanır.
Örnek:

truva.ulakbim.gov.tr. IN HINFO Ultra10 Solaris




MD:
Kullanımdan kalkmıştır. Yerine MX kaydı kullanılır.


MF:
Kullanımdan kalkmıştır. Yerine MX kaydı kullanılır.


MX:
Posta sunucu kaydı. Alan adı için ilgili posta sunucusunu tanımlar.
Örnek:

ulakbim.gov.tr. IN MX 10 efe.ulakbim.gov.tr.




NS:
Alan adı sunucu kaydı. Alan için alan adı sunucularını tanımlar.
Örnek:

ulakbim.gov.tr. IN NS efe.ulakbim.gov.tr
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742




PTR:
İşaret kaydı. Ters tanımlamada ismi tanımlar.
Örnek:

9.83.140.193.in-addr.arpa IN PTR efe.ulakbim.gov.tr.




SOA:
Sunucunun genel özelliklerini tanımlayan kayıttır. Seri No, yenileme, tekrar, süre ve TTL değerlerini alır.
Örnek:

ulakbim.gov.tr. IN SOA efe.ulakbim.gov.tr. root.ulakbim.gov.tr. (
2000042401 ; Serino
28800 ; Yenileme
14400 ; Tekrar
3600000 ; Süre
86400 ) ; TTL




TXT:
Bilgi kaydı. Kayıt hakkında bilgiyi tanımlar.
Örnek:

ulakbim.gov.tr. IN TXT "Ulusal Akademik Ag ve Bilgi Merkezi"




WKS:
Servis kaydı. Çalışan servisleri tanımlar.
Örnek:

truva.ulakbim.gov.tr. IN WKS TCP (ftp, ssh, telnet, smtp)

Hayal@

1.3. Yasal Açıklamalar
1.3.1. Telif Hakkı ve Lisans
Bu belgenin, BIND 8 ile DNS NASIL, 1.0 sürümünün telif hakkı © 2000 İlker Temir'e aittir. Bu belgeyi, Free Software Foundation tarafından yayınlanmış bulunan GNU Özgür Belgeleme Lisansının 1.1 ya da daha sonraki sürümünün koşullarına bağlı kalarak kopyalayabilir, dağıtabilir ve/veya değiştirebilirsiniz. Bu Lisansın bir kopyasını http://www.gnu.org/copyleft/fdl.html adresinde bulabilirsiniz.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
Linux, Linus Torvalds adına kayıtlı bir ticarî isimdir.


1.3.2. Feragatname
Bu belgedeki bilgilerin kullanımından doğacak sorumluluklar, ve olası zararlardan belge yazarı sorumlu tutulamaz. Bu belgedeki bilgileri uygulama sorumluluğu uygulayana aittir.
Tüm telif hakları aksi özellikle belirtilmediği sürece sahibine aittir. Belge içinde geçen herhangi bir terim bir ticarî isim ya da kuruma itibar kazandırma olarak algılanmamalıdır. Bir ürün ya da markanın kullanılmış olması ona onay verildiği anlamında görülmemelidir.

Hayal@

İçindekiler

2.1. Giriş
2.2. DNS Nedir?
2.2.1. Resolving (Çözümleme): Aranılan bir kaydı bulma işlemi
2.2.2. Authoritive Nameserving (Yetkili İsim Sunumu)
2.3. Önceden Kurulması Gerekli Yazılımlar
2.4. Dnscache Programının Kurulması
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
2.5. Tiny-dns Kurulumu
2.6. /service/tinydns/root/data Dosyasının Biçemi
2.7. Bölge (zone) Transferi
2.8. axfrdns-get (Bölge Transfer İstemcisi)
2.9. DjbDNS Komutları
2.9.1. dnscache
2.9.2. tinydns
2.9.3. walldns
2.9.4. dnsq
2.9.5. dnsqr
2.9.6. dnsfilter
2.9.7. axfrdns
2.9.8. dnstrace
2.9.9. dnstracesort
2.9.10. axfr-get
2.10. Yardımcı Bilgiler
2.10.1. Aynı veriyi içeren 5 web sunucusu için yük dengelemesini nasıl yaparım?
2.10.2. Değişik istemcileri değişik sunuculara nasıl yönlendirebilirim?
2.10.3. Aynı ağda bulunun bir dnscache o ağ için tanımlı yetkili isim sunucusunu nasıl bulacak?
2.10.4. djbDNS çalışmadı...
2.11. Kaynaklar
2.12. Yasal Açıklamalar
2.12.1. Telif Hakkı ve Lisans
2.12.2. Feragatname

2.1. Giriş
BIND, the Buggy Internet Name Daemon is like Microsoft Windows. The damn thing doesn't work. Every version has been brimming with bugs.

--D.J.Bernstein (http://cr.yp.to/djbdns/ad/unbind.html)
Bu belgede şu an Unix dünyasında bulunan en güvenli dns sunucusu olan djbDNS ve kurulumu anlatılacaktır.

DjbDNS D.J.Bernstein tarafından yazılmıştır. Kendisi aynı zamanda qmail, tcpserver, publicfile, daemontools gibi çeşitli sistem yazılımları yazmıştır. Sanırım üssteki ifadeye katılmamak mümkün değil.DjbDNS gerek üniversite gerekse ticari şirketler tarafından rahatça kullanılabilir.Bind tek başına SPOI (Single Point of InSecuritness ) lakabını yeterince hakketmektedir. Ayrıca djbdns dns sistemi için yeni istemci kitaplıklarını da sunmaktadır. http://cr.yp.to/djbdns/ad/library.html adresinden gerekli bilgiler edinebilir.

OpenBSD üzerine kurulacak basit bir makinada djbdns 2-3 sene kesintisiz hizmet verebilir. OpenBSD'yi merak ediyorsanız http://www.enderunix.org/documents/o...tallation.html adresinde TÜRKÇE kurulum kılavuzundan yaralanarak bu işletim sistemine bir giriş yapabilirsiniz.

Bilindiği üzere şu anda dünya üzerinde en çok kullanılan dns sunucu yazılımı olan Bind paketinde bir çok güvenlik açığı bulunmaktadır. Bunların ortaya çıkması sadece zaman meselesidir. Nitekim şu an kullanılan bind sürümünde bile birkaç açığın var olduğu ve bunun Internet'te istismar edildiği konuşulmaktadır. Söylenti bile olsa bind'i kullanmak zorunda olan sistem yöneticileri ne demek istediğimi anlayacaklardır. Securityfocus.com adresinde de djbdns kurulumu anlatılmaktadır. Zaten djbdns ile biz boyle tanıştık. Sendmail'den Qmail'e çekilen zorlukları bind'tan djbdns'e geçerken yaşamayacaksınız. Bind ile djbdns'nin karşılaştırmasını http://cr.yp.to/djbdns/ad/easeofuse.html adresinde bulabilirsiniz.

Hayal@

2.2. DNS Nedir?
Domain Name System [DNS] (Alan Adı Sistemi) dağıtık yapıda bir veritabanıdır. Bu sistem makina isimlerini IPv4 (ya da ipv6) adreslere ya da IPv4 adresleri makina isimlerine çevirmeye yarar. Ayrıca bir alan için gerekli eposta sunucusunun adreslerini ya da alanadı sunucularının hangi IP adreslerinde bulunduğunu daha teknik bir ifade ile RR(Resource Records)'ları tutar. DNS yapısı gereği hızlı olmalıdır. Bu yüzden yapılan sorgulamalar eğer 512 bayttan küçük ise ya da yapılan işlem asıl DNS sunucusu ile yardımcı DNS sunucusu arasında bölge transferi değilse UDP üzerinden yapılacaktır. DNS sisteminin yazarları DNS için gerekli bilgileri diğer Internet araçlarında olduğu gibi RFC'lerde tanımlamışlardır (RFC 1034 ve 1035). Bu belgelere bakarsanız içinde bir kaç kod ve bölge soayalarının nasıl yazılacağını bulursunuz.
BIND'de (Berkeley Internet Name Daemon) yazılırken bu kriterler dikkate alınmıştır. Fakat bu sistemde gereksiz karmaşıklıkta kodlar ve bunun getirdiği güvenlik problemleri vardır. Fakat djbdns bu karmaşadan uzak ve güvenli bir yazılımdır. Bunun sonucu olarakta "two-thumbs-up bir daemon" olmaya bizce hak kazanmıştır. Hatta bizce bind 9.1.X ve ileriki sürümlerinde kullanılan "Dns-sec sistemi" bile bind için bir çözüm olmaktan çok uzaktır. Sonuçta temel yani "daemon Internet"in ilk zamanlarından kalmıştır. Şu an IPv4'te yaşanılan güvenlik sorunları da aynı sebepten oluşmaktadır.

Bu yüzden köklü bir değişim olması gerekliliği savunulmuş ve IPv6 ortaya atılmıştır. Bind içinde benzer model söz konusu olmadıkçca djbdns popüleritesini sürdürecektir. (Haklı bir popülerite !!!).

Genel olarak dns yazılımlarının yaptığı iki vazife vardır. Bind kullananlar eğer çok profesyenel değillerse ya da bu konu ile alakalı kitap okunmamışsa bu iki olguyu karıştırabilmektedirler. Bunlar:


2.2.1. Resolving (Çözümleme): Aranılan bir kaydı bulma işlemi
Mesela http://www.yildiz.edu.tr/ adresine karşılık gelen IPv4 adresinin 193.140.1.1 olmasının bulunması. Çözümleme yapan yazılımlar iki çeşit işlem yaparlar; ardışık çözümeme ve ardışık olmayan çözümleme. Sorgularda gönderilen RD (recursion required - ardışık gerekli) bitlerine göre sorgunun türü belirlenir. Ardışık olmayan sorgulara cevap veren sunucular cevap olarak ardışık isim sunucuları verirler.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
Sonuç olarak yapılan bir sorgu ardışık ise http://www.yildiz.edu.tr/ için doğrudan 193.140.1.1 IP'si ya da "makina bulunamadı" cevabı verilebilir. Fakat ardışık olmayan bir sorguda cevabı bulmak için başka bir isim sunucusunun IP'sini verebilir. Ardışık olmayan sorgular aynı zamanda yinelemeli sorgular olarak daa bilinirler.


2.2.2. Authoritive Nameserving (Yetkili İsim Sunumu)
Bir alan hakkında bilgi bulunduran sunucudur. Mesela yildiz.edu.tr alanının MX, NS, A (Bunlar - Resource Record - Özkaynak Kaydı olarak bilinir) kayıtlarının tutulduğu isim sunucusudur.

CANLI BIR ÖRNEK
Bir sorgu nasıl yapılır. Mesela http://www.yildiz.edu.tr/ adresinin IPv4 karşılığı nedir? Bunun için çözümleyici ya da sizin bilgisayarınız Internet'te birkaç yetkili isim sunucusunu gezmek zorundadır. İlk başta " . " sunucularından tr TLD'si için yetkili isim sunucu IP'si bulunur. Bunun IP'si (ki bu IP'nin makina ismi ülkemiz için ns1.metu.edu.tr ya da ns2.metu.edu.tr'dir) alındıktan sonra bu yetkili isim sunucuya "edu.tr." i barındıran yetkili isim sunucu IP'si sorulacak ve bu işlem böylece devam edecektir ve sonuç olarak 193.140.1.1 adresini sizin makinanız ya da /etc/resolv.conf dosyanızda bulunan çözümleyicinin yildiz.edu.tr'nin yetkili isim sunucusundan aldığı bilgilere göre belleğinde belli bir müddet tutacaktır. Bu süreye TTL (time to live - yaşam süresi) denir. Bu süre boyunca çözümleyici gerekli bilgileri belleğinde saklayacaktır. DjbDNS için aksi belirtilmezse bu süre 42 dakikadır. Kurulacak göre bu süre 5 saniye de yapılabilir. (Nitekim birden fazla www sunucunuz var ve bunlar arasında döner turnuva kullanarak yük dengelemesi yapmak istersek bu saniye değeri kullanılacaktır).

Hayal@

2.3. Önceden Kurulması Gerekli Yazılımlar
DjbDNS'i kullanmak için önceden kurulması gereken birkaç yazılım vardır. Bunlar yine D.J. Bernstein tarafından yazılmışlardır. Bunlar kullanılması istenen sisteme göre değişir. Genel olarak sistem eğer sadece asıl sunucu olacaksa daemontools kurulması yeterli olacaktır. Daemontools sisteminizde çalışan servisleri gözetleyen bir yazılımdır. Fakat sadece gözetlemekle kalmaz eğer yapılandırma dizininde bulunan bir servis çalışmıyor ise bunları tekrar başlatır. Bu yazılım ile benzer vazifeleri yapan birkaç yazılım daha vardır. Mesela "mon" örnek verilebilir.
Kurulumu:


$ wget daemontools-0.70.tar.gz
$ tar zxvf daemontools-0.70.tar.gz
$ cd daemontools-0.70
# make setup check
# mkdir /service
# svscan /service &


Bundan sonra asıl yazılımımız olan djbdns sisteme kurulur.


$ wget djbdns-1.05.tar.gz
$ tar zxvf djbdns-1.05.tar.gz
$ cd djbdns-1.05
# make setup check


Eğer kurulacak olan sistemde ikinci bir sunucu; yani bir yardımcı sunucu olacaksa bölge transferi gerekecektir. Bunun için gerekli olan yazılımlar Ucspi (tcpserver ) ve axfrdns olacaktır. Bu yazılımlarda üstte anlatıldığı şekilde kurulabilir.

2.4. Dnscache Programının Kurulması
Dnscache yukarıda anlatılan yazılımlardan çözümleyici kısmına girmektedir. Yani /etc/resolv.conf dosyasına yazılacak IP şimdi kuracağımız yazılımın çalıştığı bir makinaya ait olmalıdır. Burada kuracağımız dnscache aslında dnscache'in kurulması olası iki çeşidinden birisi olacaktır. Bunlar "harici dnscache" ve "dahili dnscache" olarak adlandırılır. Biz burada Internet'de ya da ağımızda bulunan başka bir makinanın sorgularını işleme yetisine sahip olan "harici dnscache" kuracağız. Eğer evinizden dial-up bağlanan bir kullanıcı iseniz sisteminizde dahili bir dnscache kuracabilir ve /etc/resolv.conf dosyanıza 127.0.0.1 adresini yazabilirsiniz. Dahili denmesinin sebebi 127.0.0.1 arayüzüne kurulması ve dnscache'in kendini o ip'nin 53. portuna bağlamasıdır. Haricinin farkı ise sadece dnscache'in 127.0.0.1'den farklı ve diğer makinaların ulaşabileceği bir IP olmasıdır.
Ek olarak dnscache kurulmadan önce hangi kullanıcı olarak çalışacağı ve hangi kullanıcı olarak günlük kayıtlarının tutulacağı belirtilmelidir. Genel olarak sisteminize giriş yapması ihtimali olmayan (kabuğu /bin/false olan) iki kullanıcı ekleyin. Bunlardan biri dnscache diğeride günlük kayıtlarını hesap olan dnslog olabilir. Bir de programımızın çalışacağı dizin belirlenmelidir. Genel olarak /etc/dnscachex (x = external -> harici) kullanılmaktadır. Şimdi yazılımı kurabiliriz.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742


Harici dnscache
# dnscache-conf dnscache dnslog /etc/dnscachex 192.168.1.1
# ln -s /etc/dnscachex /service
# echo "192.168.1.1" > /etc/resolv.conf


İlk satırın açılımı:

dnscache-conf ÇALIŞTIRMA-KULLANICISI GÜNLÜK-KAYIT-KULLANICISI IP-ADRESİ
şeklindedir. İkinci satır ise dnscache'i açılışta çalıştırmak içindir.


Dahili dnscache
# dnscache-conf dnscache dnslog /etc/dnscache
# ln -s /etc/dnscache /service
# echo "127.0.0.1" > /etc/resolv.conf
# touch /etc/dnscachex/root/ip/193.140.1


Dikkat ederseniz ilk satırda IP belirtmedik. Öntanımlı değeri 127.0.0.1'dir

Öntanımlı olarak dnscache bütün sorguları reddeder. Son satırda 193.140.1 dosyası ile ağ için sorgu yapılmasına izin veriyoruz.

dnscache'in çalışıp çalışmadığını sorgulamak için dnsqr komutu kullanılabilir. Yapılan sorgularda önemli olan satır answer satırıdır.


# dnsqr a yildiz.edu.tr
1 yildiz.edu.tr:
166 bytes, 1+1+3+3 records, response, noerror
query: 1 yildiz.edu.tr
answer: yildiz.edu.tr 30218 A 193.140.1.1 (answer ile başlayan kısım bizim aradığımız cevaptır.}
authority: yildiz.edu.tr 86391 NS ana.cc.yildiz.edu.tr
authority: yildiz.edu.tr 86391 NS ns.ulak.net.tr
authority: yildiz.edu.tr 86391 NS vm4381.ce.yildiz.edu.tr
additional: ana.cc.yildiz.edu.tr 86391 A 193.140.1.1
additional: ns.ulak.net.tr 62760 A 193.140.83.251
additional: vm4381.ce.yildiz.edu.tr 86391 A 193.140.2.1




Artık elimizde çalışan bir çözümleyici var. Ek olarak istersek bellek büyüklüğünü 100MB ram harcayacak şekilde ayarlayabiliriz. Bunun için:

# echo 100000000 > /etc/dnscachex/env/CACHESIZE
# echo 104857600 > /etc/dnscachex/env/DATALIMIT


yapılması gerekir. Tabii bundan sonra svc -t /service/dnscache ile programımızı yeniden başlatmak gerekecektir.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
Şimdi sıra alanımız için yetkili isim sunucu olacak olan tiny-dns programını kurmaya geldi.

Hayal@

2.5. Tiny-dns Kurulumu
Tiny-dns yukarıda da anlatıldığı üzere bizim alanımız için yetkili isim sunucu olacak. (Aynı zamanda yetkili tersinir isim sunucumuz olacak - ipv4-->hostname...)
Önce sistemimize tiny-dns kullanıcısını (tinydns) ekleyelim. Ayrıca sistem günlük kayıtlarını tutması için dnslog kullanıcısı da eğer daha önce dnscache kurulmadıysa eklenmelidir.

Dikkat
Dikkat edilmesi gereken bir nokta, dnscache ile tinydns aynı IP'yi dinleyemez. Bu yüzden tiny-dns'i 192.168.1.2'nin 53. portuna bağlayacağız. (IP-ALIASING artık bütün *NIX'lerde vardır). Eğer elinizde sadece bir Internet IP adresi varsa bu IP'yi tiny-dns için kullanın ve yerel 192.168.1.1 IP'sini de dnscache için kullanın.


Tiny-dns yapılandırması

# tinydns-conf tinydns dnslog /etc/tinydns 192.168.1.2 {ya da bir Internet IP'si}
# ln -s /etc/tinydns /service {5 saniye sonra çalışır olacak}


Sıra tinydns'e makina ismi ve tersinir kayıtların girilmesine geldi. Bu aşamada iki seçeneğiniz var. Ya data dosyasını elle düzenleyeceksiniz ya da /etc/tinydns/root dizini altında bulunan add* betiklerini kullanacaksınız. Burada bizim tavsiyemiz data dosyasına girdilerin add* betikleri yardımıyla girilmesi yönünde olacaktır. Böylece her ne kadar data dosyasının yapılandırması bind'a göre son derece kolay ve anlaşılır olsa da ufak hatalar yapılabilme olasılığının olmasıdır. Fakat add* betikleri ile bu baş ağrıtıcı hataların oluşturduğu problemlerden kurtulmuş olursunuz.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Sırasıyla yildiz.edu.tr için dns kayıtlarını girelim ve yetkili isim sunucumuzu kuralım.


# cd /etc/tinydns/root
# ./add-ns yildiz.edu.tr 193.140.1.1
# ./add-ns 1.140.193.in-addr-arpa 193.140.1.1
# ./add-host ogis.yildiz.edu.tr 193.140.1.3
# ./add-alias www2.yildiz.edu.tr 193.140.1.3
# ./add-mx yildiz.edu.tr 193.140.1.1
# ./add-mx yildiz.edu.tr 193.140.1.5
# ./add-childdns ece.yildiz.edu.tr 193.140.1.15
# make



*.yildiz.edu.tr için yetkili isim sunucusu 193.140.1.1 olacak; SOA

tersinir yetkili isim sunucusu 193.140.1.1 olacak

Sanırım bayağı zor anlaşılacak birşey
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

DAHA ÖNCEDEN TANIMLANMIŞ bir IP'ye takma isim ekliyoruz

bir numaralı mx (eposta sunucusu) olarak 193.140.1.1 ekleniyor

ikinci sırada gelen yildiz.edu.tr eposta sunucusu

alt alanlar için isim sunucusu

tindns-data komutu çalıştırılır

Bu noktada önemli birşey var. add-ns ve add-mx betiklerini kullanırken dikkat ederseniz isim sunucuların makina isimlerini vermedik. Bu iki betik öntanımlı olarak a.ns ... b.ns makina isimlerini atarlar. Eğer Internic'te ya da daha doğru ifadesiyle registrar'ınızda isim sunucusu makina ismi olarak farklı bir isim olabilir. İşte bu noktada iki makina ismi de aynı olmalıdır.add-ns ve add-mx yine aynı dizinde, /etc/tinydns/root/ dizini altında bulunan data dosyasını düzenler. Burada metin düzenleyicinizle bu dosyayı açıp gerekli değişiklikleri yapmalısınız. Örnek olarak ulak.net.tr'de yildiz.edu.tr isim sunucusunun makina ismi ana.cc.yildiz.edu.tr olarak tanımlıdır. data dosyasında bu değişiklik yapılmalıdır.

Sıra geldi data dosyasındaki bilgileri data.cdb olarak yanitinydns'in yapılandırma dosyası olarak kaydetmeye. Yine ayni dizinde dikkat ederseniz bir Makefile vardır. Yapılması gereken tek şey bu dizinde make komutunu çalıştırmaktır. Make komutunun yazılması ile birlikte tiny-dns hizmet vermeye hazır olacaktır. Make komutu Makefile dosyasından da anlaşılacağı üzere tinydns-data programını kullanarak data.cdb'yi oluşturur. Kısacası tinydns-data, data dosyasını okur ve tinydns'in hızlı bir şekilde ulaşabileceği data.cdb dosyasını oluştururr. Ayrıca tinydns-data otomatik olarak data.cdb'yi günceller. Böylece data dosyasında yapılan bir değişiklik tinydns'i bir daha başlatmadan doğrudan data.cdb dosyasını günceller. data.cdb güncellenirken sistem çökse bile sistem yeniden başladığında data.cdb dosyasında bir problem yaşamaz. Tam bir ya hep ya hiç mantığıyla ya da veri aktarımı mantığı ile çalışır.

Aşağıda data dosyasının içeriği verilmiştir. Bu dosyayı üstte add-* betikleri ile yapılandırabileceğiniz gibi elle de yapılandırabilirsiniz.


.yildiz.edu.tr:193.140.1.1:a:259200
.1.140.193.in-addr.arpa:193.140.1.1:a:259200
=www.yildiz.edu.tr:193.140.1.1:86400
.1.140.193.in-addr.arpa:193.140.1.1:a:259200
=ogis.yildiz.edu.tr:193.140.1.3:86400
+www2.yildiz.edu.tr:193.140.1.3:86400
@yildiz.edu.tr:193.140.1.3:a::86400
@yildiz.edu.tr:193.140.1.5:b::86400
&ece.yildiz.edu.tr:193.140.1.15:86400


yildiz.edu.tr için yetkili isim sunucusu nokta ile başlıyor

www.yildiz.edu.tr için host kaydı

*.1.140.193 için yetkili isim sunucusu

ogis.yildiz.edu.tr için makina kaydı

Bir takma ad (alias) kaydı. Takma ad kayıtları + ile başlar.

yildiz.edu.tr için mx kaydı. Öncelikler harflerle ifade ediliyor.

yildiz.edu.tr için ikinci mx kaydı. @ ile başlıyor.

ece.yildiz.edu.tr için gelen sorguları 193.140.1.15 IP'sine yönlendir.


Bu arada istenirse daemontools paketi ile gelen svstat ile tinydns çalışıyor mu çalışmıyor mu kontrol edilebilir.


# svstat /service/tinydns

Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Ya da günlük kayıt dosyalarına bakabiliriz.


# tail -f /service/tinydns/log/current


ile gerçek zamanlı olarak işlemler gözlenebilir.

Bir de tinydns'in verisini kontrol edelim. Bunun için dnscache için kullandığımız komuta benzer bir komut olan dnsq komutunu kullanacağız.

# dnsq a yildiz.edu.tr 193.140.1.1
1 yildiz.edu.tr:
127 bytes, 1+1+2+2 records, response, authoritative, weird ra, noerror
query: 1 yildiz.edu.tr
answer: yildiz.edu.tr 86400 A 193.140.1.1 {Önemli olan kısım burası}
authority: yildiz.edu.tr 86400 NS smurf.cc.yildiz.edu.tr
authority: yildiz.edu.tr 86400 NS bigblue.ce.yildiz.edu.tr
additional: smurf.cc.yildiz.edu.tr 86400 A 193.140.1.1
additional: bigblue.ce.yildiz.edu.tr 86400 A 193.140.2.1

Dikkat
tinydns'i sorgulamak için dnsq
dnscache'i sorgulamak için dnsqr kullanılır.

Hayal@

2.6. /service/tinydns/root/data Dosyasının Biçemi
Yukarıda da belirtildiği gibi data dosyasından tinydns'in okuyabileceği biçeme (data.cdb) dönüştürülür. Peki data dosyasının biçemi nasıldır:
.fqdn:ip:x:ttl:timestamp:lo


Teker teker yukarıdaki ifadenin ne anlamlara geldiğini açıklayayım.
.fqdn
Girdiyi simgeler. Bu girdi yetkili bir isim sunucusunun başlangıçı (SOA = Start Of Authority) olabilir. Nitekim data dosyasinda "." ile başlayanlar SOA kaydını belirtir. Üstteki örneğimize bakarsak en üst iki satir "." ile başlamaktadır. Bunlar SOA'ları oluşturur. "." dan başka karakterler de vardır:
. ile başlayanlar SOA'yı belirtir.Mutlaka olmalıdır.
@ ile başlayan satır bunun bir mx girdisi olduğunu gösterir.
= ile başlayanlar A kayıtları için kullanilir. Aynı zamanda tinydns-data ters kayıtlarından olan PTR girdisi içindir.
+ ile başlayanlar add-alias betiği oluşturulur. Yine bu işaret tinydns-data'ya A kaydı oluşturmasını soyler, fakat PTR kaydı girilmez. Eğer aynı IP için iki tane = kullanırsanız hata alırsınız (data dosyasını elle değiştirerek ya da add-host ile).
& ile başlayan satırlar alt dns sunucusu girmek içindir. Mesela elek.yildiz.edu.tr 'nin kendi dns sunucusunun olmasını istiyorsunuz. Bunun için add-childdns komutunu kullanırız.


ip
Girdisi yapılacak fqdn'nin çözümleneceği IP'yi belirler. Mesela:

&ece.yildiz.edu.tr:193.140.1.15:86400


ifadesindeki ikinci segman IP'dir ve kendisinden önce gelen ifadenin (&ece.yildiz.edu.tr) IP'sini belirler.



x
mx ve ns kayıtlarında işe yaramaktadır. Bu önceliği belirlemek için kullanılır ve sorgulara buna göre verilir. Şöyleki eğer buraya "a" ya da "b" girerseniz dnsq ile size dönecek cevap eğer ns kaydı sözkonusu ise a.ns.yildiz.edu.tr olur. Eğer girilen değer b ise bu ikincil isim sunucusunu gösterir ve b.ns.yildiz.edu.tr olarak gösterilir. Yine mx kayıtları içinde a.mx.yildiz.edu.tr ve b.mx.yildiz.edu.tr kullanılır. Eğer bu tarz gösterim yapmak istemiyorsanız. Bu kısma doğrudan "dns1.yildiz.edu.tr" ya da "dns2.yildiz.edu.tr" girebilirsiniz. Ya da aynı şekilde "mx1.yildiz.edu.tr" ve de "mx2.yildiz.edu.tr".
Aklınıza şu soru gelebilir. Eğer bu kısma ben kendim makina isimlerimi girersem öncelik sırası ne olacak. Burada ilk giren ilk sunulur ilkesi esas alınır. Yani dosyada hangisi üstte ise önceliğe o sahiptir.



ttl
Kurduğumuz yetkili isim sunucuyu sorgulayan sunucuların belleklerinde bu girdiyi kaç saniye(**) tutacağını belirler. ns ve mx sunucular için burada öntanımlı değer 3 gün (259200 saniye) iken diğer girdiler için 1 gündür (86400 saniye).


timestamp
Adındanda anlaşılacağı üzere dosyanın ne zaman değiştirildiğini gösterir. " add-* " scriptleri bu kısma dokunmazlar.


lo
Bu kısım aşağıda da anlatıldığı üzere "Değişik istemcileri değişik sunuculara nasıl yönlendirebilirim? " sorusunun cevabı olmaktadır.


EK: 3 kısımda anlatılanları somutlaştırmak için örnek bir data dosyasından alıntı yapayım:


.yildiz.edu.tr:193.140.1.1:dns1.yildiz.edu.tr:2592 00
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742


Böyle bir girdide tinydns-data komutu iki şey yapar. İlk başta dns1.yildiz.edu.tr için 193.140.1.1'i gösteren A kaydı oluşturulur. Daha sonra bunun SOA olduğunu belirtilen kısım data.cdb'ye yazılır.


@yildiz.edu.tr:193.140.1.3:mx1.yildiz.edu.tr::8640 0


Bu örnekte ise ilk başta A kaydı sonra da mx kaydı oluşturulur.

Hayal@

2.7. Bölge (zone) Transferi
Bölge (Zone) Transferi Nedir?
Asıl ya da birincil DNS sunucunuzda yaptığınız değişiklikleri ikincil ya da yardımcı sunucularınıza kopyalamanız gerekmektedir. Aslında bunun için bir çok değişik araç mevcuttur. Bunun için öntanımlı kabuğu ssh olan rsync bile kullanılabilir. Böylece dosyanın tamamının kopyalanması yerine artan dosyaların sondaki ekleri kopyalanabilir. Ya da isterseniz doğrudan data.cdb dosyasını elle kopyalayabilirsiniz.
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742

Fakat bu iş için en aklı başında çözüm axfrdns kullanmaktır. Bunun için öncellikle:

DNS sunucusunun hesap ismi: "axfrdns". Diğer bütün djbdns programlarında olduğu gibi program kendini bu hesap adı altında belirtilen dizine chroot yapar. İşte bu djbdns programını güvenli kılan en önemli etkenlerden biridir.
DNS günlük kaydı kullanıcısı: dnslog
axfrdns'in çalışacağı dizin /etc/axfrdns
tinydns dizini: /etc/tinydns
Sonra sırasıyla:


# axfrdns-conf axfrdns dnslog /etc/axfrdns /etc/tinydns 193.140.1.1 {Bu ip tinydns ip'si ile aynı olabilir.Çünkü axfrdns zone transferi için 512 bytetan büyük dosyları transfer eder bu yüzden tcp kullanılır fakat tinydns udp kullanır.}
# cd /etc/axfrdns
# echo "193.140.1.:allow,AXFR="yildiz.edu.tr/1.140.193.in-addr.arpa" > /etc/axfrdns/tcp {193.140.1'deki makinalara reverse ve normal zone'larının transferine izin ver }
# make
# ln -s /etc/axfrnds /service {axfrdns'i çalıştıralım}

Hayal@

2.8. axfrdns-get (Bölge Transfer İstemcisi)
Eğer birincil sunucu olarak bir BIND sunucu kullanacaksanız ikincil isim sunucu olarak axfr-get programını kullanmalısınız. Ya da diğer bir birincil tinydns sunucusundan bölge transferinde bulunmak için kullanılabilir. Eğer iki sunucu da (birincil ve ikincil) tinydns ise scp ya da rsync ile doğrudan ana sunucudan data.cdb'yi ikincil sunucunun /etc/tinydns/root/ dizinine kopyalayabilirsiniz. Eğer rsync hususunda bir bilgi almak isterseniz http://www.freebsddiary.org/ adresini ziyaret edebilir ya da "man rsync" ile kılavuz sayfasından bilgi alabilirsiniz.
Axfrdns-get kısaca şöyle çalışır:


# tcpclient yetkili-isim-sunucu-IP 53 axfrdns-get yildiz.edu.tr fn fn.tmp


Burada eğer axfrdns-get çeşitli sorguları yaparak alan için birincil sunucuyu bulacak ve eğer birincil sunucuda bölge transferi için axfrdns-get komutunun çalıştığı sunucuya izin verilmişse birincil sunucudan çektiği yildiz.edu.tr hakkındaki bilgileri fn.tmp olarak yazacaktır. Eğer bölge transfer işlemi başarı ile tamamlanırsa dosya adı otamatik olarak fn olarak değiştirilecektir. Bu fn dosyası da tinydns-data biçeminde olacaktır. Yani daha önce gördüğümüz data dosyası ile aynı biçemde olacaktır.

Genel olarak axfrdns-get programının getirdiği dosyalarda aynı kayda ait birden fazla girdi olacaktır. Dosyayı "sort -u" komutu ile sıralayabilirsiniz.


Uyarı
axfrdns-get için daha önceden tcpclient programını kurmuş olmanız gerekmektedir. Zaten sisteminiz tcpserver kurulu ise tcpclient otomatik gelecektir.

2.9. DjbDNS Komutları
Şu an kadar anlatılanlar neyin nasıl yapılacağı hususunda genel bir bilgi vermek içindi. Bu bölümde anlatılacak olanlar djbdns ile gelen programların (hepsinin) teker teker kısaca bir açıklaması olacak. DjbDNS ile gelen bir çok komut var. Bunların aklınızda biraz daha kolay yer etmesi ve bu belgenin bir başvuru belgesi kabul edilmesi için bu tarz bir uygulama yapıyorum.

2.9.1. dnscache
Kısaca çözümleyici olarak kullanılmaktadır. Çözülen her isteği aynı zamanda bellekleyerek cevap verme süresinin azalmasını sağlar. Ağ ortamından gelen isteklere cevap verecek şekilde ayarlanabileceği gibi yerel çözümleyici olarakta kullanılabilir.

2.9.2. tinydns
Yetkili bir isim sunucusudur. UDP altında çalışır. Örnek vermek gerekirse yildiz.edu.tr alanı için gelebilecek tüm sorgulara cevap verecek şekilde ayarlanabilir. 512 byte ve üzeri isteklere cevap vermez. Bunun sebebi sadece UDP altında çalışması ve DNS yapılandırmasının bu şekilde olmasıdır.

Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
2.9.3. walldns
WallDNS tersinir bir DNS duvarıdır. Yani sisteminiz gerisindeki Internet IP'ye sahip makinaların isimlerini saklamakta kullanılabilir. Güvenlik duvarı mantığı ile örtüşür. Bazı ftp sunucuları kendine gelen istekleri kabul etmek için mutlaka ters kaydın o makina için tanımlı olmasını isterler. Bu durumlar için walldns kullanılabilir.

2.9.4. dnsq
tinydns gibi yetkili isim sunucularını sorgulamak için kullanılır.

# dnsq type FQDN server
# dnsq MX yildiz.edu.tr 193.140.1.1


193.140.1.1 sunucusuna yildiz.edu.tr için kayıtlı mx kayıdını sorar.


2.9.5. dnsqr
Bu komut dnsq'ya benzer fakat yetkili isim sunucusu sorgulaması yerine dnscache gibi depoları sorgulamaya yarar.

#dnqr ns http://www.yildiz.edu.tr/


Depoya yildiz.edu.tr'nin ns kaydını sorar.


2.9.6. dnsfilter
Bu komut dnsname gibidir. Fakat aynı anda çoklu sorgulama yapabilir. dnsname sadece bulduğu ilk girdiyi listeler.

# dnsfilter
193.140.1.1 {Bizim girdimiz}
193.140.1.1=smurf.cc.yildiz.edu.tr
193.140.1.3 {Bizim girdimiz}
193.140.1.3=ogis.cc.yildiz.edu.tr



2.9.7. axfrdns
Bölge transferi için kullanılır. Çeşitli ikincil isim sunucular için bölge transfer sunucusu olarak vazife yapar. Tinydns'in çalıştığı IP'de çalışabilir. TCP kullanır.

2.9.8. dnstrace
Belirtilen kök isim sunucusundan başlayarak ( r ) bir alan altında ( fqdn ) istenenen tipte ( t ) sorguları bulur ve ilişki kurduğu bütün sunucuları standart çıktıya yazar. Fakat karmaşık bir biçemde.

# dnstrace t fqdn r
# dnstrace any www.yildiz.edu.tr a.root-servers.net > yildiz &



2.9.9. dnstracesort
dnstrace komutunun çıktısını okuyabilieceğimiz şekilde listeler.

# dnstracesort < yildiz | less


Ya da doğrudan:


# dnstrace any www.yildiz.edu.tr a.root-servers.net | dnstracesort | less



2.9.10. axfr-get
İkincil sunucularda kullanılmak üzere tasarlanmıştır. Birincil sunucudan bölge transferinde kullanılır.
Ayrıca birkaç da betik vardır: dnsmx, dnsip, dnsname

Hayal@

2.10. Yardımcı Bilgiler
Bu bölümde şahsımın ilgisini çeken birkaç noktayı anlatacağım:

2.10.1. Aynı veriyi içeren 5 web sunucusu için yük dengelemesini nasıl yaparım?
Aslında dns tabanlı yük dengelemesine tam manasıyla sıcak bakmasam da djbdns ile yük dengelemesi yapılabiliyor. Eğer Linux altında gerçek bir yük dengelemesi ya da Yüksek Kullanılabilirlik arıyorsanız http://www.linux-vs.org/ ya da adreslerine bakın derim. Neyse biz konumuza dönelim. Amacımıza ulaşmak için TTL ile oynayacağız. Her bir www sunucumuzun girdisi için 5 saniye bir TTL tanımlayacağız. Böylece karşı tarafta depolanan sorguların yaşam süresi 5 saniye olacak. Gelen her bir istek için djbdns'te döner turnuva yaparak bu 5 sunucu arasında tercihini yaparak karşı taraftaki çözümleyiciye bildirecektir. /etc/tinydns/root/data dosyasına

+www.yildiz.edu.tr:193.140.1.1:5
+www.yildiz.edu.tr:193.140.1.2:5
+www.yildiz.edu.tr:193.140.1.1:5
......


yazılır. /etc/tinydns/root/ dizininde make komutu çalıştırarak tinydns-data komutunun data dosyasındaki bilgileri data.cdb gibi cdb biçeminde saklaması sağlanır.


2.10.2. Değişik istemcileri değişik sunuculara nasıl yönlendirebilirim?
Diyelim ki üniversiteniz ya da şirketiniz içinden gelen sorgulara yani intranetinizden gelen sorgulara http://www.yildiz.edu.tr/ için 193.140.1.1 Internet'ten gelen http://www.yildiz.edu.tr/ sorguları için 192.193.140.1.2...5 arası cevapların verilmesini istiyorsunuz. Bunun için /etc/tinydns/root/data dosyasına farklı iki konum tanımlarız. IN ve EX gibi 1 ya da 2 byte uzunluğunda (maximum 2 byte uzunluğunda) tanımlamalar yaparız. Şöyleki:

%IN:193.140.1
%EX
+www.yildiz.edu.tr:193.140.1.1:5::IN
Kaynak: Wardom http://www.wardom.com.tr/showthread.php?t=21742
+www.yildiz.edu.tr:193.140.1.2:5::EX
+www.yildiz.edu.tr:193.140.1.3:5::EX
...




2.10.3. Aynı ağda bulunun bir dnscache o ağ için tanımlı yetkili isim sunucusunu nasıl bulacak?
Normalde aşağıdaki bir düzenleme yapılmazsa yerel olarak bulunabilecek bir cevap için bütün Internet'i gezmesi gerekecektir. Bu durumu önlemek için:

# cd /etc/dnscachex/root/servers
# echo "193.140.1.1" > yildiz.edu.tr
# echo "193.140.1.1" > 1.140.193.in-addr.arpa


ile bu sorunu çözebilirsiniz.


2.10.4. djbDNS çalışmadı...
Bu kısım çok önemli (!!!). Diyelimki djbdns'i kurdunuz ve herşeyin tam olarak çalışıp çalışmadığından emin olmak için sisteminizi yeniden başlattınız. Fakat o ne... Djbdns çalışmadı!!! ve şu şekil bir hata veriyor:

svscan: warning: unable to start supervise dnscache: file does not exist


Burada bulunamayan ve svscan'in dnscache'i çalışmamasını sağlayan /usr/local/bin altında daemontools komutlarının bulunmaması.

Buradaki çözüm: /usr/local/etc/rc.d/djbdns.sh gibi bir dosya oluşturup, chmod 755 djbdns.sh ile çalıştırılabilir hale getirip şu satırları djbdns.sh'a eklemektir.

#!/bin/sh
export PATH="$PATH:/usr/local/bin"
svscan /service &

2.11. Kaynaklar
DJBDNS SOURCE
http://cr.yp.to/


DJBDNS HOMEPAGE
http://www.djbdns.org/
http://djbdns.enderunix.org/ (Resmi olarak djbdns.org'un yansısını tutmaktayız.)

Ayrıca bu sayfalarda djbdns için yapılmış birkaç yama bulabilirsiniz. Örnek olarak bir deponun dnscache ile birden çok IP'ye bağlanması verilebilir.



DJBDNS FAQ
http://cr.yp.to/djbdns/faq/


DjbDNS ve BIND Karşılaştırması
http://cr.yp.to/djbdns/ad/easeofuse.html
Bu belgeye resmi djb sitesi vasıtasıyla da ulaşabilirsiniz: http://www.djbdns.org



DjbDNS'in tinydns paketini web'den yönetmek için python ile yazılmış bir araç
http://www.linuxis.net/twa


Gerrit Pape'in yazdığı djbdns kılavuz sayfaları
Djbdns ile manual page gelmemektedir: ftp://ftp.innominate.org/gpa/djb/


dnscache için döner turnuva yamasi
Bu yama dnscache içindir. tinydns için döner turnuva desteği paketle gelmektedir.
http://www.legend.co.uk/djb/dns/round-robin.patch