Logic
New member
- Katılım
- 19 Haz 2005
- Mesajlar
- 137
- Reaction score
- 0
- Puanları
- 0
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.
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.
