Türkiye mi, Malawi mi? DNS Sistemi Üzerine Düşünceler

Üniversiteye hazırlanan bir yeğenim var. Bendeniz dayısını gözünde çok büyüttüğü için olsa gerek bilgisayar bilimleri okumak istiyor. Ben de onun çok okuyan ve işini anlayarak yapan bir mühendis veya bilim kadını olmasını istiyorum. “Ayinesi iştir kişinin lafa bakılmaz” düsturundan hareketle, Malawi nerede öğrenip, üniversiteye orada gitmesini tavsiye
edeceğim. Çünkü Malawili bilgisayarcıların yaptıklari işe baktım ve beğendim! Niye Türkiye degil de Malawi? Devam edelim:

TR mi MW mi?

Aşağıda vereceğim kaynaklar okunduğunda ortaya çıkacağı üzere DNS altyapısı dağılmış (distributed), çoklu (redundant) ve dayanıklı (robust) bir sistemdir. Düzgün kurulduğunda çökmesi zor ve kesintisiz hizmet vermesininin sağlanması kolaydır. Düzgün kurulmadığında ise tasarımın dayanıklılık özelliğinden dolayı yine de çalışması mümkündür.

Bunu arabanızın frenlerinin hidrolik sistemi gibi düşünebilirsiniz; tamirciniz yedekli sistemin yedeğini bozsa bile siz farketmeyebilirsiniz. “Duruyor işte olmuş” dersiniz, tamirciniz de “yaptım abla” der, Allah sizi biraz gözetiyorsa hiçbir şey olmaz. Tabi lüzumsuz yere işinizi Allah’a bırakmış olursunuz, tamirciniz de üç dört müşteriye böyle yaptıktan sonra, yaptığının doğru olduğuna iyice inanır. Birisi çıkıp ‘yahu bu iş böyle yapılmaz’ derse, bendenizin de işitmesi muhtemel olan cevabı verir: “ben kaç senedir fedakarlıkla çalışıp, kaç arabayı tamir
ettim biliyor musun? sen kimsin?”. Sonra birgün birisi hayatını kaybeder, ve biz de ‘kader’ deriz.

Çok şükür DNS ile adam öldürmenin yolu bulunmadı henüz! Ama siteniz, e-mailiniz ve geçiminiz Allah’a kalmış olabilir. Tabi Malawi’de değil Türkiye’de yaşıyorsanız.

Aşağıda bugün (16 Subat 2004, sabah 8:30 itibariyle) .tr/.mw ccTLDlerini ve com.tr/com.mw yi kısaca karşılaştırdım.

(b) Yetkili sunucu sayısı com.mw (5) com.tr (2) a’da bulunan sunuculara sorulmuştur (Örnek dig ns com.mw. @domwe.leland-mw.org). Malawililer işi şansa bırakmayı sevmiyorlar belli ki.

(c) Ek yetkili sunucu sayısı com.mw (0) com.tr (1). b’de bulunan sunuculara sorulmuştur (ornek dig ns com.tr. @ns1.metu.edu.tr). Biz galiba yabancılarla konuşmaya çekindiğimiz için üçüncü sunucuyu bildirmemişiz.

(d) Yetkili sunucuların bulunduğu ağlar com.mw (5) com.tr (2). b ve c de bulunan sunucu IPlerine bakılarak bulunmuştur. En azından ağ sayımız birden fazla gibi duruyor ama ikinci ağdaki makinenin ayarlı olmadığı ortaya çıkıyor.

(e) Yetkili olarak ayarlanmış yetkili sunucu sayısı com.mw (4) com.tr (1) (dig çıktısına bakılarak). Bir önceki şık yani d’de söyledigim gibi. Tek makinemiz ve dolayısıyla tek ağımız var.

(f) Yetkili olarak ayarlanmış ek sunucu sayısı com.mw (1) com.tr (0). (dig çıktısına bakarak). Bizim sadece kendi sunucularımızın bildiği makinemiz kendini yetkili görmüyor. (e’deki sayidan f’deki sayı çıkartılmış)

(g) Yetkili oldugunu bilmese de cevap veren sunucu sayısı com.mw (5/5) com.tr (2/3) (dig ns com.tr. @ns3.nic.tr diye bakılmıştır).

Görüldüğü üzere, tek yetkili makinemiz var, o makineye birşey olursa yahut
o ağa ulaşım aksarsa, com.tr için yetkili makine kalmıyor. com.mw’nin dünya
üzerinden kaybolması için 5 makinenin yahut 5 bağımsız ağ parçasının
bozulması gerekiyor. Com.mw için yetki kayıtlarının ulaşılamaz olması için de bu sayı 4’e iniyor. Com.tr için bu sayılar sırasıyla 1 ve 1.

Asağıda com.tr icin notlarım var. Meraklı okuyucular makine başında aynı
denemeleri yapabilirler.

Yani “.” için sorumlu sunuculardan birine .xx’i sorduğumuzda .xx için şu listedeki şunlar sorumludur ve IP adresleri şunlardır diye cevap alırız. Soralım:

cubx:~# dig ns tr. @a.ROOT-SERVERS.NET

; <<>> DiG 9.2.3 <<>> ns tr. @a.ROOT-SERVERS.NET
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46956 ;; flags: qr rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 7 ;; QUESTION SECTION: ;tr. IN NS ;; ANSWER SECTION: tr. 172800 IN NS NS.UU.NET. tr. 172800 IN NS NS1.METU.EDU.tr. tr. 172800 IN NS NS2.METU.EDU.tr. tr. 172800 IN NS MUNNARI.OZ.AU. tr. 172800 IN NS NS.RIPE.NET. tr. 172800 IN NS NS1-AUTH.SPRINTLINK.NET. ;; ADDITIONAL SECTION: NS.UU.NET. 172800 IN A 137.39.1.3 NS1.METU.EDU.tr. 172800 IN A 144.122.199.90 NS2.METU.EDU.tr. 172800 IN A 144.122.199.93 MUNNARI.OZ.AU. 172800 IN A 128.250.1.21 MUNNARI.OZ.AU. 172800 IN A 128.250.22.2 NS.RIPE.NET. 172800 IN A 193.0.0.193 NS1-AUTH.SPRINTLINK.NET. 172800 IN A 206.228.179.10

Burada “ADDITIONAL SECTION” verilen cevapların içinde tutkal kayıtları olduğunu ve bunlara niye tutkal dendiğini de farkedebiliriz. .tr için sorduğumuz sorunun cevapları için de .tr makineleri var! Daha bunların IP’lerini bulacak bilgimiz olmadığı için bunların IP’leri de verilmiş.

Tutkal olmasaydı .tr’li isimleri bakmak için .tr’li makinenin adresini bulmak durumunda ve çaresiz kalabilirdik.

Devam edelim….. .tr’yi bulduk, şimdi com.tr’a bakalım, .tr için yetkili sunuculardan birinden:

; <<>> DiG 9.2.3 <<>> ns com.tr. @137.39.1.3
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2926 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;com.tr. IN NS ;; ANSWER SECTION: com.tr. 8640 IN NS ns1.metu.edu.tr. com.tr. 8640 IN NS ns2.metu.edu.tr. ;; ADDITIONAL SECTION: ns1.metu.edu.tr. 86400 IN A 144.122.199.90 ns2.metu.edu.tr. 86400 IN A 144.122.199.93

Görüldüğü gibi, com.tr’dan iki sunucu sorumlu. Farkettiyseniz şu anda tamirciniz yedek hidrolik hatlarını kesti!

Bunlar aynı subnet’in üzerinde oturan iki tane makine. Ethernet kablosu çıkarsa, ya da 144.122.199/32 bir şekilde ulaşılamaz hale gelirse, com.tr ortadan kayboluyor.

Peki bu makineler nasıl ayarlı? Bakalım:

; <<>> DiG 9.2.3 <<>> ns com.tr. @ns1.metu.edu.tr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49280 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;com.tr. IN NS ;; ANSWER SECTION: com.tr. 65000 IN NS ns3.nic.tr. com.tr. 65000 IN NS ns1.metu.edu.tr. com.tr. 65000 IN NS ns2.metu.edu.tr. ;; ADDITIONAL SECTION: ns3.nic.tr. 600 IN A 81.8.4.10 ns1.metu.edu.tr. 86400 IN A 144.122.199.90 ns2.metu.edu.tr. 300 IN A 144.122.199.93

Bir de başımıza ns3.nic.tr çıktı. Hııımmmmm. Bu esasında bir hata değil,
belli ki idareciler en azından evvelce bakılmış kayıtların hatırlanabileceğinden hareketle ns1 veya ns2’ye ulaşabilmiş makinelerin bir üçüncü makine (ns3.nic.tr) hakkında bilgili olmalarını arzu etmişler.

Hepsini deneyelim:

; <<>> DiG 9.2.3 <<>> ns com.tr. @ns2.metu.edu.tr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63106 ;; flags: qr rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;com.tr. IN NS ;; ANSWER SECTION: com.tr. 65000 IN NS ns2.metu.edu.tr. com.tr. 65000 IN NS ns3.nic.tr. com.tr. 65000 IN NS ns1.metu.edu.tr. ;; ADDITIONAL SECTION: ns2.metu.edu.tr. 300 IN A 144.122.199.93 ns3.nic.tr. 600 IN A 81.8.4.10 ns1.metu.edu.tr. 86400 IN A 144.122.199.90

Eyvah! Yukarida ‘flags’ bölümüne bakarsaniz ‘aa’ göremiyoruz! Bundan ns2.metu.edu.tr’nin kendisinin com.tr için yetkili olduğundan bihaber olduğu ortaya çıkıyor. Yani gitmiş başka yerden bakmış.

ns3’ü deneyelim:

; <<>> DiG 9.2.3 <<>> ns com.tr. @ns3.nic.tr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39876 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 9 ;; QUESTION SECTION: ;com.tr. IN NS ;; AUTHORITY SECTION: tr. 105086 IN NS ns1.metu.edu.tr. tr. 105086 IN NS NS2.metu.edu.tr. tr. 105086 IN NS MUNNARI.OZ.AU. tr. 105086 IN NS NS.RIPE.NET. tr. 105086 IN NS NS1-AUTH.SPRINTLINK.NET. tr. 105086 IN NS NS.UU.NET. ;; ADDITIONAL SECTION: ns1.metu.edu.tr. 105086 IN A 144.122.199.90 NS2.metu.edu.tr. 105086 IN A 144.122.199.93 MUNNARI.OZ.AU. 115053 IN A 128.250.1.21 MUNNARI.OZ.AU. 115053 IN A 128.250.22.2 MUNNARI.OZ.AU. 4303 IN AAAA 2001:388:c02:4000::1:21 NS.RIPE.NET. 108341 IN A 193.0.0.193 NS.RIPE.NET. 124636 IN AAAA 2001:610:240:0:53::193 NS1-AUTH.SPRINTLINK.NET. 30261 IN A 206.228.179.10 NS.UU.NET. 126384 IN A 137.39.1.3

Görüldüğü gibi ns3’un hiçbirşeyden haberi yok! Başka yerden de bakmıyor, ‘git .tr için yetkili olan yerlere sor, hadi bir iyilik edip listesini veriyorum’ diyor. Hıımmmmmm….. Peki ns2 nasıl ayarlanmış? Normal bir ISP DNS sunucusu gibi:

; <<>> DiG 9.2.3 <<>> www.isbank.com.tr. @ns2.metu.edu.tr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3624 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.isbank.com.tr. IN A ;; ANSWER SECTION: www.isbank.com.tr. 29396 IN A 213.161.144.97 ;; AUTHORITY SECTION: isbank.com.tr. 84173 IN NS ank.isbank.net.tr. isbank.com.tr. 84173 IN NS istasr.isbank.net.tr. ;; ADDITIONAL SECTION: ank.isbank.net.tr. 65000 IN A 212.98.2.245 istasr.isbank.net.tr. 65000 IN A 212.98.2.225

Yani herhangi bir adresi memnuniyetle gidip bizim yerimize öğreniyor. Kendisine verilen önemli vazifeden haberi yok, ama amme hizmeti yapmaya hazır.

Kaynaklar:

Dil bilen teknik elemanların, eger DNS idaresi ile alakaları varsa bunları
okumalarını şiddetle tavsiye ederim.

RFC 1034 (Domain names – concepts and facilities) tek birsey okuyacaksanız bunu okuyun. www.faqs.org/rfcs/rfc1034.html
DNS and BIND, Paul Albitz, Cricket Liu ISBN: 0-596-00158-4. Bu kitabın yarısını bile okusanız DNS’e hakim olursunuz. www.oreilly.com/catalog/dns4/
Running An Authoritative-Only BIND Nameserver, Duane Wessels, ISC Technical Note Series ISC-TN-2002-2. Kısa, öz ve doğru yazılmış bir döküman. Kitabı alamıyorsanız, bunu okuyarak da bir ISS DNS’i yahut ccGTLD’yi idare edebilirsiniz. www.isc.org/pubs/tn/?tn=isc-tn-2002-2.html
RFC 2870 (Root Name Server Operational Requirements) ccGTLD için de geçerli birçok tavsiye var bunda. www.faqs.org/rfcs/rfc2870.html
Üniversiteye hazırlanan bir yeğenim var. Bendeniz dayısını gözünde çok büyüttüğü için olsa gerek bilgisayar bilimleri okumak istiyor. Ben de onun çok okuyan ve işini anlayarak yapan bir mühendis veya bilim kadını olmasını istiyorum. “Ayinesi iştir kişinin lafa bakılmaz” düsturundan hareketle, Malawi nerede öğrenip, üniversiteye orada gitmesini tavsiye
edeceğim. Çünkü Malawili bilgisayarcıların yaptıklari işe baktım ve beğendim! Niye Türkiye degil de Malawi? Devam edelim:
TR mi MW mi?
Aşağıda vereceğim kaynaklar okunduğunda ortaya çıkacağı üzere DNS altyapısı dağılmış (distributed), çoklu (redundant) ve dayanıklı (robust) bir sistemdir. Düzgün kurulduğunda çökmesi zor ve kesintisiz hizmet vermesininin sağlanması kolaydır. Düzgün kurulmadığında ise tasarımın dayanıklılık özelliğinden dolayı yine de çalışması mümkündür.
Bunu arabanızın frenlerinin hidrolik sistemi gibi düşünebilirsiniz; tamirciniz yedekli sistemin yedeğini bozsa bile siz farketmeyebilirsiniz. “Duruyor işte olmuş” dersiniz, tamirciniz de “yaptım abla” der, Allah sizi biraz gözetiyorsa hiçbir şey olmaz. Tabi lüzumsuz yere işinizi Allah’a bırakmış olursunuz, tamirciniz de üç dört müşteriye böyle yaptıktan sonra, yaptığının doğru olduğuna iyice inanır. Birisi çıkıp ‘yahu bu iş böyle yapılmaz’ derse, bendenizin de işitmesi muhtemel olan cevabı verir: “ben kaç senedir fedakarlıkla çalışıp, kaç arabayı tamir
ettim biliyor musun? sen kimsin?”. Sonra birgün birisi hayatını kaybeder, ve biz de ‘kader’ deriz.
Çok şükür DNS ile adam öldürmenin yolu bulunmadı henüz! Ama siteniz, e-mailiniz ve geçiminiz Allah’a kalmış olabilir. Tabi Malawi’de değil Türkiye’de yaşıyorsanız.
Aşağıda bugün (16 Subat 2004, sabah 8:30 itibariyle) .tr/.mw ccTLDlerini ve com.tr/com.mw yi kısaca karşılaştırdım.
Görüldüğü üzere, tek yetkili makinemiz var, o makineye birşey olursa yahut
o ağa ulaşım aksarsa, com.tr için yetkili makine kalmıyor. com.mw’nin dünya
üzerinden kaybolması için 5 makinenin yahut 5 bağımsız ağ parçasının
bozulması gerekiyor. Com.mw için yetki kayıtlarının ulaşılamaz olması için de bu sayı 4’e iniyor. Com.tr için bu sayılar sırasıyla 1 ve 1.
Asağıda com.tr icin notlarım var. Meraklı okuyucular makine başında aynı
denemeleri yapabilirler.
Burada “ADDITIONAL SECTION” verilen cevapların içinde tutkal kayıtları olduğunu ve bunlara niye tutkal dendiğini de farkedebiliriz. .tr için sorduğumuz sorunun cevapları için de .tr makineleri var! Daha bunların IP’lerini bulacak bilgimiz olmadığı için bunların IP’leri de verilmiş.
Tutkal olmasaydı .tr’li isimleri bakmak için .tr’li makinenin adresini bulmak durumunda ve çaresiz kalabilirdik.
Devam edelim….. .tr’yi bulduk, şimdi com.tr’a bakalım, .tr için yetkili sunuculardan birinden:
Görüldüğü gibi, com.tr’dan iki sunucu sorumlu. Farkettiyseniz şu anda tamirciniz yedek hidrolik hatlarını kesti!
Bunlar aynı subnet’in üzerinde oturan iki tane makine. Ethernet kablosu çıkarsa, ya da 144.122.199/32 bir şekilde ulaşılamaz hale gelirse, com.tr ortadan kayboluyor.
Peki bu makineler nasıl ayarlı? Bakalım:
Bir de başımıza ns3.nic.tr çıktı. Hııımmmmm. Bu esasında bir hata değil,
belli ki idareciler en azından evvelce bakılmış kayıtların hatırlanabileceğinden hareketle ns1 veya ns2’ye ulaşabilmiş makinelerin bir üçüncü makine (ns3.nic.tr) hakkında bilgili olmalarını arzu etmişler.
Hepsini deneyelim:
Eyvah! Yukarida ‘flags’ bölümüne bakarsaniz ‘aa’ göremiyoruz! Bundan ns2.metu.edu.tr’nin kendisinin com.tr için yetkili olduğundan bihaber olduğu ortaya çıkıyor. Yani gitmiş başka yerden bakmış.
ns3’ü deneyelim:
Görüldüğü gibi ns3’un hiçbirşeyden haberi yok! Başka yerden de bakmıyor, ‘git .tr için yetkili olan yerlere sor, hadi bir iyilik edip listesini veriyorum’ diyor. Hıımmmmmm….. Peki ns2 nasıl ayarlanmış? Normal bir ISP DNS sunucusu gibi:
Yani herhangi bir adresi memnuniyetle gidip bizim yerimize öğreniyor. Kendisine verilen önemli vazifeden haberi yok, ama amme hizmeti yapmaya hazır.
Kaynaklar:
Dil bilen teknik elemanların, eger DNS idaresi ile alakaları varsa bunları
okumalarını şiddetle tavsiye ederim.
- RFC 1034 (Domain names – concepts and facilities) tek birsey okuyacaksanız bunu okuyun. www.faqs.org/rfcs/rfc1034.html
- DNS and BIND, Paul Albitz, Cricket Liu ISBN: 0-596-00158-4. Bu kitabın yarısını bile okusanız DNS’e hakim olursunuz. www.oreilly.com/catalog/dns4/
- Running An Authoritative-Only BIND Nameserver, Duane Wessels, ISC Technical Note Series ISC-TN-2002-2. Kısa, öz ve doğru yazılmış bir döküman. Kitabı alamıyorsanız, bunu okuyarak da bir ISS DNS’i yahut ccGTLD’yi idare edebilirsiniz. www.isc.org/pubs/tn/?tn=isc-tn-2002-2.html
- RFC 2870 (Root Name Server Operational Requirements) ccGTLD için de geçerli birçok tavsiye var bunda. www.faqs.org/rfcs/rfc2870.html
  Etiketler: Alan Adı(Domain Name)Bilgi

Türkiye mi, Malawi mi? DNS Sistemi Üzerine Düşünceler

Siz Malawi nerede bilir misiniz? Ben bilmem. Ama şunu biliyorum ki DNS alt yapıları bizden daha üstün! Neden mi? Bakın size neler anlatacağım..

Bülent Murtezaoğlu

GÜNLÜK BÜLTEN ABONELİĞİ

HAFTANIN ÖNE ÇIKANLARI

HAFTANIN KELİMESİ

3GPP

İNTERNET HIZI

Bildirimler

Son Yorumlar

Tekrar Hoşgeldiniz!

Şifrenizi geri alın