DNS
Daha önceki dokümanlarda açıklandığı şekilde bir IP ağı üzerinde
çeşitli servislere ulaşmak için bu servislerin çalıştığı sistemlerin 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. Bu sorunun
nasıl aşıldığı bu dokümanda ele alınacaktır.
1 DNS’in 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 tanımlayan RFC 882 ve 883’ü yayınladı. Bunlar daha sonra halen
geçerli olan RFC 1034 ve 1035 tarafından güncellendiler.
2 DNS’in 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 icenlenirse 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 detaylarını içeren tabloları işaret eder. Aynı şekilde
bu tablolar da kendi altlarında bulunan alan adlarını içerir ve
detaylarını gösteren tablolara işaret eder.
Açıklana 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).
Yukarıdaki açıklamaların paralelinde oluşan hiyerarşik alan adı ağacı Şekil 2’de gösterilmiştir.
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’ 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 adı verilen en üst seviye alan adı sunucuları üzerinde
tanımlanmış durumdadır. Dikkat edilmesi gereken nokta alan adları
alındıktan sonra bu alan adındaki isimlendirmenin lokalde yapıldığıdır.
Bu daha önce de değinilen yönetimin dağıtık olarak yapılabilmesini
sağlar.
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.
3 DNS Çözümlemesi
DNS’in 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ını 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
sunucualr birincil alan adı sunucularının verilerini periyodik olarak
kendi veritabanına kopyalarlar. Birincil sunucuda herhangi bir problem
yaşandığında sorgulama ikinci 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, 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
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.
Benzer bir sorgulamayı Amerika kıtasında ‘ns.digex.net’ adlı alan adı
sunucuyu kullanan bir istemcinin yaptığı 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 detaylı olarak açıklanacaktır) bu adresi sorar. Bu sunucu
(a.root-servers.net) da ‘
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.ne.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.