Daha önceki dokümanlarda aciklandigi sekilde bir IP agi üzerinde cesitli servislere ulasmak icin bu servislerin calistigi sistemlerin 4 sayidan olusan akilda kalmasi zor ve son kullanicilar icin hemen hicbir sey ifade etmeyen adreslerinin bilinmesi gerekmektedir. Bu sorunun nasil asildigi bu dokümanda ele alinacaktir.
1 DNS`in Tarihcesi
Yukarida bahsedilen isimlendirme sorunu ilk olarak Internetin babasi sayilan ArpaNet zamaninda ortaya cikmistir. 1970`lerde ArpaNet günümüz aglari ile karsilastirilamayacak kadar kücük durumdaydi ve yalnizca birkac yüz ile ifade edilebilen sisteme hizmet veriyordu. Bu tarihlerde isimlendirme icin tek noktada tutulan bir dosyanin bulunmasi ve diger tüm sistemlerin bu dosyayi belli araliklarla kendi taraflarinda güncellemesi isimlendirme sorununu cözmüstü.
Adres-isim tanimlamalarini iceren HOSTS.TXT dosyasi SRI tarafindan SRI-NIC adinda bir bilgisayar üzerinde tutulmaktaydi. Bu dosya her adrese bir isim karsilik gelecek sekilde düzenlenmisti. ArpaNet üzerindeki yeni isim tanimlamalari ve degisiklikleri SRI`ya gönderilen e-postalar araciligi ile yapiliyor ve HOSTS.TXT`in kopyasi ftp ile aliniyordu.
ArpaNet üzerinde TCP/IP kullanimina paralel olarak ortaya cikan baglanti patlamasi, isim cözümü icin bir cok sorunu da beraberinde getirdi. öncelikle isim cakismalari ortaya cikti, sayi artmakta ve her bilgisayara özgün bir isim atanmasinda problemler yasanmaktaydi. Ayrica yalnizca isim cözümlenmesi icin oldukca yüksek miktarda bant genisligi harcanmakta ve buna ragmen kullanilan isim veritabanlarinin uyumlu olmasi her zaman saglanamamaktaydi.
Bu durumun ortaya cikmasindan sonra ArpaNet daha ölceklenebilir bir isim cözümleme yapisi icin arastirmalara basladi. Paul Mockapetris bu isle görevlendirildi. Mockapetris 1984 yilinda Domain Name System (DNS)`i tanimlayan RFC 882 ve 883`ü yayinladi. Bunlar daha sonra halen gecerli olan RFC 1034 ve 1035 tarafindan güncellendiler.
2 DNS`in Yapisi
ArpaNet döneminde ortaya cikan güclükler nedeniyle DNS tasarlanirken uclardaki sistemlerin kendi bilgilerini kendilerinin güncelleyebilecegi bir yapi üzerinde durulmustur. Ortaya cikan yapi ise en üstten baslayarak hiyerarsik bir sekilde uclara dogru acilan dagitik bir varitabani mimarisidir. Uclar birbirleri ile istemci sunucu yöntemiyle konusurlar.
Farkli tablolar ile tek veritabaninda tanimlanmis bir alan adi sistemini icenlenirse yapisinin hiyerarsik oldugu görülür. Her alan adi bir baska alan adinin altinda tanimlanmistir. En üst seviyede bulunan bir tablo en üst seviye alan adlari olan â.com`, ânet` vb icerir ve bu alan adlarinin detaylarini iceren tablolari isaret eder. Ayni sekilde bu tablolar da kendi altlarinda bulunan alan adlarini icerir ve detaylarini gösteren tablolara isaret eder.
Aciklana tablo yapisi sekil 1 üzerinde gösterilmistir.
sekil 1
İlk tabloda en üst seviye alan adlari tanimlanmis ve bu tabloda bulunan alt alan adlarinin bilgileri ilgili tablolara isaret edilmistir. Bu tek bir veritabaninda gösterilmis bir yapilanmadir. Bu yapida tablolar farkli veritabanlari üzerinde tutularak yönetim kolaylastirilabilir. Bu durumda oldukca dinamik ve etkin bir mekanizma kurulmus olur.
Dagitik veritabanlari arasinda istemci-sunucu yöntemi ile baglanti kurulur.
Az önce belirtilen en üst seviye alan adlari arasinda âcom`, ânet`, âgov` vb yaninda ülkelerin ISO tarafindan belirlenen sembolleri de tanimlanmistir (tr, uk, fr, gr gibi).
Yukaridaki aciklamalarin paralelinde olusan hiyerarsik alan adi agaci sekil 2`de gösterilmistir.
Alan adi dagilimi en üst seviyeden baslar ve alt dallara dogru bölünür. Bir alan adinin okunusu en alttan baslayarak en üste dogru yapilir. Agacin en altinda bulunan alan adi âankara.ulak.net.tr` seklinde okunacaktir.
En üst seviye alan adlarinin yönetimi InterNIC tarafindan yapilmaktadir. ISO kodlari ile tanimlanmis ülke adlarinin yönetimi ülkelere göre degisiklik göstermektedir. Türkiye`nin ISO kodu olan âtr` üst seviye alan adinin yönetimi Orta Dogu Teknik üniversitesi (ODTü) tarafindan yapilmaktadir. Dolayisiyla âcom`, ânet`, `gov` gibi alan adlarina kayit InterNIC tarafindan; âcom.tr`, ânet.tr` gibi alan adlarina kayit ODTü tarafindan yapilmaktadir. Alan adi kayitlariyla ilgili daha fazla bilgi icin http://www.internic.net ve http://dns.metu.edu.tr adresleri incelenebilir.
âankara.ulak.net.tr` örneginde, âankara.ulak.net.tr` alan adi UlakNet sunuculari üzerinde, âulak.net.tr` alan adi ODTü sunuculari üzerinde, ânet.tr` alan adi yine ODTü sunuculari üzerinde, âtr` alan adi ise root server adi verilen en üst seviye alan adi sunuculari üzerinde tanimlanmis durumdadir. Dikkat edilmesi gereken nokta alan adlari alindiktan sonra bu alan adindaki isimlendirmenin lokalde yapildigidir. Bu daha önce de deginilen yönetimin dagitik olarak yapilabilmesini saglar.
Bu bilgiler isiginda âxxx.ankara.ulak.net.tr` ya da âyyy.ulak.net.tr` seklindeki bir tanimlama UlakNet`in kontrolünde, benzer sekilde âabc.com.tr` ya da âxyz.net.tr` seklindeki bir tanimlama ise ODTü`nün kontrolündedir.
İncelenen alan adi agaci maksimum 127 basamaktan olusabilir ki bu da pratikte ulasilmasi imkansiza yakin bir degerdir.
3 DNS cözümlemesi
DNS`in yapisi anlatilirken dagitik bir veritabani seklinde olusturuldugu ve uclarin birbirbirleriyle istemci sunucu mantigi ile konustugunu söylenmisti. Bu islevi yerine getiren programlara alan adi sunucu adi verilir (name server). Alan adi sunucularini alan adi agaci üzerinde nokta ile gösterilirler.
Her alan adi sunucu bir veya birkac alan adi bilgisini tutar ve bu alan adlari icin en yetkili alan adi sunucudur. Diger alan adlari icin sorgularda bu alan adlari icin en yetkili alan adi sunucularini bulmaya calisir.
Alan adi sunucular yerine getirdikleri kritik islev nedeniyle genellikle yedekli olarak calistirilirlar. Bilgilerin tutuldugu ana veritabani birincil alan adi sunucu olarak adlandirilir. İkincil sunucualr birincil alan adi sunucularinin verilerini periyodik olarak kendi veritabanina kopyalarlar. Birincil sunucuda herhangi bir problem yasandiginda sorgulama ikinci sunucular üzerinde yapilir.
DNS cözümlemesi birkac kademede incelenebilir. UlakNet alan adi sunucusunu kullanan bir istemcinin âwww.ulak.net.tr` adresini sorguladigi durumda sunucu kendi veritabaninda tanimli olan bu adresi istemciye döndürecektir. Bu, UlakNet alan adi sunucusu âulak.net.tr` alan adi altinda bulunan tanimlar icin en yetkili sunucu oldugu icin bu sekilde gerceklesmistir.
sekil 3`te bu sorgunun nasil gerceklestirildigi görülmektedir.
sekil 3
Görüldügü gibi istemci âwww.ulak.net.tr` adresini bu alan adi icin en yetkili durumdaki alan adi sunucusunda sorgulamis ve bu adrese tanimlanmis IP adresi cevap olarak döndürülmüstür.
Benzer bir sorgulamayi Amerika kitasinda âns.digex.net` adli alan adi sunucuyu kullanan bir istemcinin yaptigi durum incelenebilir.
âns.digex.net` kendisine sorulan âwww.ulak.net.tr` icin herhangi bir bilgiye sahip degildir. Bu yüzden kendi veritabaninda tanimli olan en üst seviye alan adi sunucularina (root-servers, daha sonra detayli olarak aciklanacaktir) bu adresi sorar. Bu sunucu (a.root-servers.net) da âwww.ulak.net.tr` icin kesin bilgiye sahip degildir. Ancak â.tr` üst seviye alan adinin âns1.metu.edu.tr` sunucusu tarafindan kontrol edildigini bilmektedir. Bu yüzden, âns.digex.net`e sorguyu âns1.metu.edu.tr` üzerinde yapmasi bilgisini iletir. âns.digex.net` bu kez ayni adresi âns1.metu.edu.tr` üzerinde sorgulayacaktir. Ancak bu sunucu da âwww.ulak.net.tr` icin kesin adresi bilemeyecek ve sorgunun âulak.net.tr` alan adi sunucusu olan âns.ulak.net.tr` adresine yönlendirilmesini bildirecektir. Son olarak âns.digex.net`, âwww.ulak.net.tr` adresini âns.ulak.ne.tr` üzerinde sorgulayacak ve âns.ulak.net.tr` kendi veritabaninda âwww.ulak.net.tr` icin tanimli olan 193.140.83.9 adresini döndürecektir. Bu bilgiye ulasan âns.digex.net` de kendi istemcisine bu bilgiyi iletecektir.
Bu sorgulama sekil 4`te gösterilmistir.
Bu analizde dikkati cekmesi gereken iki önemli nokta bulunmaktadir.
öncelikle â.tr` dan sorumlu gözüken âns1.metu.edu.tr`nin â.net.tr` icin ayri bir alan adi sunucuya yönlendirme yapmadigi, dogrudan âulak.net.tr` alan adi sunucusuna yönlendirme yaptigina dikkat edilmelidir. Bu âns1.metu.edu.tr` hem â.tr` hem de â.net.tr` icin alan adi sunucusu oldugu icin bu sekilde gerceklesmistir. Eger â.tr` ve â.net.tr` farkli sunucular üzerinde tanimli olsalardi âns.digex.net` ayrica â.net.tr`den sorumlu sunucuyu da sorgulamak durumunda kalacakti.
Dikkat edilmesi gereken diger nokta ise istemcinin alan adi sunucuya yalnizca bir sorgu iletmesi ve tüm is sunucu tarafindan yapildiktan sonra yalnizca cevabi almasidir. Ayni durum âns.digex.net` diger alan adi sunuculara ulasirken ortaya cikmamis ve her biri ayri ayri sorgulanmistir. Bunun sebebi âns.digex.net` sunucusunun tekrarli (recursive), diger alan adi sunucularinin ise tekrarli olmayan (iterative) bir sekilde sorgulanmis olmasidir.
4 IP`den İsim cözümlemesi
Bölüm 3`te isimden adres cözümlemesi incelenmistir. su ana kadar anlatilan yapi tüm sistemin isimden adres cözümü icin tasarlandigi izlenimini vermektedir. Ancak pratik ihtiyaclar, IP adresinden isim cözümünü de gerekli kilmaktadir.
Böyle bir sorgunun su ana kadar incelenen yapi üzerinde nasil calisabilecegine bakalim. İsimlerin indesklenmesine göre olusturulmus hiyerarsik bir sistem görülmektedir. Ancak IP adreslerin bu yapi üzerinde herhangi bir hiyerarsik yapisi bulunmamaktadir. örnegin âwww.ulak.net.tr` adresi 193.140.83.9 IP numarasi ile adreslenmisken âtruva.ulakbim.gov.tr` adresi 193.140.83.13 IP numarasi ile adreslenmis olabilir. Bu da 193.140.83. ile baslayan IP`lerin teorik olarak tüm alan adi uzayina yayilmis olabilecegini gösterir.
Görüldügü gibi mevcut yapida bir IP adresinin isim karsiligini bulmak icin veritabaninin tümünün taranmasi gerekmektedir. Bu ise indeksi olmayan daginik durumdaki milyonlarca kaydin taranmasi anlamina gelir ki imkansiza yakin bir ugrastir. Bu sorunun cözülebilmesi icin IP adreslerine icin de hiyerarsik bir yapinin kurulmasi gerektigi görülmektedir.
Bu yapiya gecmeden önce IP adreslemenin özelliklerinin hatirlanmasi yararli olacaktir. IP adresleri ilk oktetten son oktete (soldan saga dogru) en genelden en özele dogru siralanirlar. örnegin â193.140` hem â193.140.83.13`ü hem de â193.140.83.9`u icine alir.
Alan adlari ise buna ters olarak sagdan sola dogru en genelden en özele dogru siralanirlar. örnegin â.tr` hem ulak.net.tr`yi hem de âmetu.edu.tr`yi icine alir.
İki gösterim de genelden özele siralanabildigine göre mevcut hiyerarsik yapilandirmaya IP numaralari icin bir üst seviye alan adi eklenmesi mümkündür. Bu alan adi âin-addr.arpa` seklinde ifade edilir. Bu üst seviye alan adi 1`dan 255`e kadar cesitli alt alanlara bölünür. Bu bölümlemeye 4 okteti tamamlayacak sekilde devam edilebilir. Bu durumda ortaya cikan yapi sekil 5`te gösterilmistir.
sekil 5
üst seviye alan adlari arasina âarpa` adinda bir alan adi eklenmistir. Bu alan adinin altinda âin.addr` seklinde bir alan daha tanimlanmistir. Bu alan adinin altinda IP numarasinin ilk okteti alan adi olarak eklenmis, bunu sirayla IP numarasinin ikinci,ücüncü ve dördüncü oktetleri izlemistir.
Görüldügü gibi artik 193.140.83.13 ve 193.140.83.9 IP numaralarinin isim karsiliklarini bulmak son derce kolaylasmistir. İncelene isim sorgusuna benzer bir sekilde IP-isim sorgulari da bu yapinin yardimyila yapilabilmektedir. Ancak dikkat edilmesi gereken önemli birkac nokta bulunmaktadir.
Normal alan adi isimlendirme sisteminde isimler agacin en altindan en üstüne dogru okunulur. Bu durumda IP numaralari bilinenin aksine özelden genele dogru okunacaklardir. örnegin 193.140.83.13 IP numarasinin DNS agaci üzerinde okunusu 13.83.140.193.in-addr.arpa seklinde olacaktir.
Dikkat edilmesi gereken diger bir nokta ise isimden IP`ye yapilan tanimlama ile IP`den isime yapilan tanimlama arasinda herhangi bir baglanti bulunmayisidir. örnegin âwww.ulak.net.tr` adresi DNS üzerinde 193.140.83.9 olarak tanimliyken, â193.140.83.9` IP adresinin ismi âefe.ulakbim.gov.tr` seklinde tanimli olabilir.
5 DNS Cache
DNS cözümlemesinde anlatildigi sekilde isim cözümleme islemi ardisil olarak alan adi sunucularinin sorgulanmasini gerektirir. Bu islem oldukca vakit alici bir islem olabilir ve karsilikli olarak sistemler üzerinde yük olusturdugu gibi hatlar üzerinde yüksek miktarda bant genisligi harcayabilir.
Bunun engellenmesi ve sorgunun mümkün olan en kisa sürede sonuclandirilabilmesi icin alan adi sunuculara cache özelligi eklenmistir. Bu sayede bir alan adi sunucu daha önce sorguladigi alan adlarini kendi belleginde tutarak yeni sorgularda diger alan adi sunucularini sorgulamadan dogrudan cevap verebilir. Bu yukarida anlatilan olumsuzluklari belli bir derecede önleyecektir. Ancak burada önemli bir nokta gözden kacirilmamalidir.
Sorgulanan alan adinda son sorgulamadan sonra degisiklik yapilmis olabilir. Bu durumda bellekte tutulan bilgi güncelligini yitirmistir ve istemciye hatali bilgi geri döndürülecektir.
Bu ancak belli bir noktaya kadar kabul edilebilir bir durumdur. Alan adi tanimlari normalde cok **sansürlendi** degistirilen tanimlamalar degillerdir. Nadiren degitirildiklerinde de degisikligin aktive olmasi icin bir gün gibi bir süre cogu zaman yeterlidir. su halde bellekte tutulan bilgilerin bir süre sonra güncelligini yitirdigi kabul edilmelidir. Bunu belirleyen degere daha önceki konularda da deginildigi gibi TTL (Time To Live, Yasam Süresi) denilmektedir ve her alan adinin tanimlanmasinda bu alan adi icin gecerli TTL degeri belirtilir. Bu alan adindan sorgulanan bilgiler bellekte TTL süresince tutulduktan sonra güncelligini yitirdigi kabul edilir. TTL`in nasil tanimlandigi daha sonra incelenecektir.
