Bölüm 3: İsimden Adrese

Her kutu paketin üstündeki hedefe bakıyordu. O hedefin ne olduğunu ise atladım: bir isim değil, bir sayı.

Adres çubuğuna yazdığın metinde sayı yok. Aradaki dönüşüm kitabın omurga sorularından birini de cevaplıyor: bir isim nasıl adrese dönüşüyor ve bunu sana kim söylüyor?

Bu listeyi tek bir yerde tutamazsın

Akla ilk gelen çözüm bir tablo: solda ad, sağda sayı duruyor ve herkes aynı tabloya bakıyor.

Bu çözüm gerçekten denendi ve birkaç yüz makine için işe yaradı. 1980’lerin ortasına kadar ağdaki bütün makinelerin adı HOSTS.TXT adlı tek bir dosyada duruyordu. Dosyayı Kaliforniya’daki SRI’ın ağ bilgi merkezi tutuyordu ve herkes onu düzenli aralıklarla oradan indiriyordu. Bugün her işletim sisteminde duran hosts dosyası o düzenin kalıntısı. Milyarlarca kayıt için ise işe yaramıyor ve sebepleri tek tek sayılabilir. Tek bir kopya varsa o kopyanın çöktüğü an ağın tamamı isimden anlamaz hâle gelir. Tek bir makine, saniyede milyonlarca soruyu da karşılayamaz. Üstelik o makine dünyanın bir yerinde durmak zorunda ve ötekilere uzak kalır.

Asıl sorun ise teknik değil. Kayıtların sahibi tek bir kurum değil; milyonlarca ayrı kuruluş kendi adlarından sorumlu. Merkezî bir tablo, her küçük değişiklik için herkesin aynı masaya başvurması demek olurdu. Böyle bir masa kurulmadı.

Bunun yerine veritabanı bölündü ve bölünme adın kendi yapısını izledi. Ortaya çıkan sisteme DNS (Domain Name System, alan adı sistemi) deniyor. Noktalar süs değil; her nokta bir sorumluluk sınırı. ornek.com.tr adını sağdan sola okuyunca üç ayrı sahip görürsün: en sağda ülke alanı, onun içinde ticari alan, onun içinde de kurumun kendi adı.

Adın kendisi de serbest biçimli bir metin değil. Noktalar arasındaki her parçaya etiket deniyor ve standart iki üst sınır koyuyor: tek bir etiket 63 karakteri, adın tamamı ise 255 karakteri aşamıyor. Sınırlar keyfî değil, kaydın telde kapladığı yerle ilgili. Telde her etiketin önünde uzunluğunu söyleyen tek bir bayt duruyor ve o baytın en üst iki biti başka bir işe, adların tekrarını kısaltan bir sıkıştırma işaretine ayrılmış. Geriye kalan altı bit en fazla 63 sayabiliyor. Büyük-küçük harf ayrımı da burada yok; adı nasıl yazarsan yaz aynı yere gidiyor.

Adres çubuğundaki metni katmanlı bir zarf adresine benzetmiştik. Benzetme burada bir kat daha işe yarıyor: posta da adresi genelden özele, şehirden kapıya doğru okur; alan adı da sağdan sola, en genel parçadan başlayarak okunuyor. Fark şu: zarftaki bütün durakları tek bir kurum işletir, burada her durağın sahibi ayrı.

Adın sağ ucunda görünmeyen bir nokta daha var: tam yazılmış bir alan adı kökün kendisiyle biter. Adres çubuğuna yazdığın adın sonuna nokta koyup denersen çoğu sitede aynı sayfa gelir.

Zincirin en tepesinde kök duruyor. Tek bir işi var: hangi üst düzey alanın nerede sorulacağını bilmek. Bir alt basamakta üst düzey alan sunucuları var; com, org, net ve ülke uzantıları buradan yönetiliyor. En altta ise yetkili sunucu var ve bir adın gerçek karşılığını yalnızca o biliyor.

Sistem okumak için tasarlandı, yazmak için değil: kayıt değişikliği seyrek, sorgu ise sürekli; neredeyse her internet işlemi işe bu soruyla başlıyor.

Soruyu senin makinen sormuyor

Makinende bu zinciri yürüten bir program yok. Onun yerine stub resolver denen çok küçük bir parça var ve bildiği tek şey sorulacak yerin adresi.

O adresi de genellikle sen yazmıyorsun. Ağa bağlandığın anda yapılandırma bilgisiyle birlikte geliyor; bu bilgiyi kimin dağıttığını 36. bölümde göreceğiz. Elle değiştirmek mümkün ama çoğu kişi hiç dokunmuyor. İşte o adresteki makineye resolver diyoruz.

Bu adres genellikle bağlandığın ağı işleten kurumu gösteriyor; herkesin kullanabildiği açık resolver’lar da var. Hangisini kullandığın performansı da, gördüğün cevapları da değiştirebiliyor.

Resolver’ın ilginç yanı, anlattığım hiyerarşinin parçası olmaması. Üç basamağın hiçbirine ait değildir; zincirin dışında durur ve zinciri senin adına yürür.

Sorunun kendisi küçük bir paket ve varsayılan hâlde 53 numaralı porta, bağlantısız taşımayla, yani UDP ile gidiyor: tek paket gidiyor, tek paket dönüyor, el sıkışma yok. Neden el sıkışmadığını ve bunun neyi kazandırıp neyi feda ettiğini 7. bölümde açacağız.

Cevap sığmazsa ne oluyor? Standart, bağlantısız taşımadaki mesajı 512 bayta sınırlıyor. Sığmayan cevap “kesildi” işaretiyle dönüyor ve resolver aynı soruyu bu kez bağlantı kurarak yeniden soruyor. EDNS(0) adlı bir uzantıyla bu sınır pazarlıkla büyütülebiliyor; 5. bölümde göreceğimiz imzalı cevaplar 512 bayta sığmadığı için o uzantı olmadan imzalama pratikte çalışmıyor. Bugün yaygın değer 1.232 bayt. 2020’de resolver ve sunucu yazılımlarının ortak kararıyla seçildi, çünkü bu boydaki bir cevap IPv6’nın en küçük paket boyuna bile bölünmeden sığıyor.

Sorunun ve cevabın ortak iskeleti

Soru ile cevap aynı biçimi paylaşıyor. İkisinin de başında 12 baytlık sabit bir başlık var ve o başlığın ardından dört bölme geliyor. Başlığın tamamı şu:

Dört sayaç, dört bölmenin uzunluğunu veriyor. Bölmelerin adları da işlerini söylüyor: soru sorulanı tekrar eder, cevap karşılığı taşır, yetki bu cevaba kimin kefil olduğunu, ek ise işine yarayabilecek fazladan kayıtları.

Bayrak alanının içi de sabit ve her parçası bir soruyu cevaplıyor:

Son satır arıza ararken en çok baktığın yer. Dört bitin taşıdığı değerler kısa bir liste:

İki kodu birbirinden ayırmak arızanın yerini de ayırıyor. NXDOMAIN “ad yanlış yazılmış” demek; SERVFAIL ise “ad doğru olabilir ama ben sana söyleyemiyorum” demek. Birincisinde yazım hatası ararsın, ikincisinde resolver’ı ya da imzayı.

Kendi makinende hepsini bir arada görebilirsin:

$ dig ornek.com

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24601
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

İkinci satır yukarıdaki tablonun kendisi: qr cevap olduğunu, rd özyineleme istendiğini, ra resolver’ın bunu yapabildiğini söylüyor. aa yok, demek ki cevabı alanın sahibi değil, aradaki resolver verdi. Resolver cevabı ister önbelleğinden bulsun ister o an zinciri yürüyerek, bu işareti hiçbir zaman koymuyor.

Sormanın iki biçimi var. Özyinelemeli sorguda soruyu sorup bekliyorsun; karşı taraf gerekirse başkalarına sorar ama sana dönerken elinde hazır cevap olur. Yinelemeli sorguda ise cevap değil yön veriliyor: bende yok, şuraya sor.

Pratikte ikisi arka arkaya kullanılıyor. Senin makinen resolver’a özyinelemeli soruyor; resolver ise hiyerarşiye yinelemeli soruyor. Bölünme keyfî değil: bütün dünyanın yükünü kök sunucuların üstlenmesi ölçek olarak mümkün olmazdı.

Bu düzenin bir bedeli var ve şimdiden söylemek gerek. Resolver’ı kim işletiyorsa, senin baktığın her adı da o görüyor.

Zincir nasıl yürüyor?

Resolver’ın elinde hiçbir bilgi olmadığını varsayalım. Soru geldi ve baştan başlaması gerekiyor.

İlk durak kök. Resolver köke www.ornek.com adresini soruyor ama cevap almıyor; kökün verdiği şey, com alanına bakan sunucunun adı. Sonra o sunucuya aynı soru gidiyor ve bu kez ornek.com alanının yetkili sunucusunun adı dönüyor. Üçüncü soruda ise zincir bitiyor: yetkili sunucu adın gerçek karşılığını veriyor.

Her adımda dönen şeyin bir ad olduğuna dikkat et. Ama resolver bir sonraki sunucuya bağlanmak için sayıya ihtiyaç duyuyor ve elinde yalnızca ad var. Aynı çıkmaz bir kat aşağıda tekrar doğuyor. Çözüm, sunucu adını veren kaydın yanına o sunucunun adresini de iliştirmektir; böylece zincir kendi kendini kilitlemez.

Bu iliştirilen adres kaydının adı tutkal kaydı (glue record) ve gerçekten de zinciri yapıştıran şey o. Ne zaman gerekli olduğunu bir örnek net gösteriyor. ornek.com alanının yetkili sunucusu ns1.ornek.com ise, ornek.com adresini öğrenmek için ns1.ornek.com adresini bilmen gerekiyor, ama o adresi de yalnızca ornek.com sunucusu biliyor. Kısır döngü. com sunucusu bu yüzden NS kaydının yanına, cevabın ek bölmesine, ns1.ornek.com için bir de A kaydı koyuyor ve döngü kırılıyor. Yetkili sunucu alanın dışında, mesela ns1.baskadns.net olsaydı, tutkala hiç gerek kalmazdı, çünkü o adı bağımsız olarak çözebilirdin.

Aynı sorunun bir kat yukarısı da var: resolver köke soru sorabilmek için kökün adresini bilmek zorunda ve bunu DNS’e sorarak öğrenemez. Cevap yazılımın içinde gömülü duruyor; dosyanın adı kök ipuçları (root hints) ve içinde on üç kök sunucunun adı ile adresi yazılı. Resolver açılışta bu listedeki bir sunucuya bağlanıp güncel listeyi ister; işlemin adı hazırlık sorgusu (priming). Bütün hiyerarşinin altında, ağdan öğrenilmeyen tek bir sabit dosya duruyor.

Sekiz mesajın tamamını sırayla izlemek istersen:

Zincirin her adımı başarılı olmak zorunda da değil. Sorulan sunucu adı hiç tanımıyorsa “böyle bir ad yok” diye kesin bir cevap dönüyor ve arama orada bitiyor. Sunucu hiç cevap vermezse durum başka: resolver bir süre bekliyor, sonra aynı alanın öteki sunucusunu deniyor. Alan adı kaydettirirken birden fazla yetkili sunucu istenmesinin sebebi bu.

Peki bir ad bu sisteme nasıl giriyor? Kaydettirdiğinde kayıt kuruluşuna (registrar) yetkili sunucularının adlarını ve adreslerini veriyorsun. Kuruluş da bu bilgileri üst düzey alan sunucusuna yazıyor. Zincirin sana çıkan halkası o an kuruluyor.

Bu yüzden yeni kaydedilen bir ad bir süre çalışmayabiliyor; kimi resolver’lar adı bilir, kimileri bilmez. Sebebini 5. bölümde açacağız.

Zincirin bir de bedeli var ve bu bedel gecikme bileşenleri cinsinden ödeniyor. Her soru ayrı bir gidiş dönüş demek: kök, üst düzey alan ve yetkili için üç tur, üstüne senin makinenle resolver arasındaki tur. Sayfa daha ilk baytını almadan bunların hepsi bitmiş olmak zorunda. Uzaktaki bir resolver seçmenin açılışı fark edilir biçimde geciktirmesinin sebebi de bu.

Gerçekte bu zincir çok daha kısa yürüyor, çünkü resolver öğrendiklerini bir süre elinde tutuyor. Bunu şimdilik böyle bırakıyorum: zincirin neden kısaldığını ve elindeki cevabın ne kadar taze sayıldığını 5. bölümde ölçeceğiz.

Böylece omurga sorularından ilkini kapatabiliriz.

Omurga sorusu 1: Bir isim nasıl adrese dönüşüyor ve bunu sana kim söylüyor?

Ad, sağdan sola okunan bir yol olarak çözülüyor: kök hangi üst düzey alana bakılacağını, üst düzey alan hangi yetkili sunucuya gidileceğini, yetkili sunucu ise gerçek karşılığı söylüyor. Sana söyleyen ise bunların hiçbiri değil; resolver. Zinciri o yürüyor, cevabı o getiriyor ve senin ondan başka konuştuğun kimse yok.

Özet

• Ad-adres listesi tek bir yerde tutulamıyor ve sebep yalnızca ölçek değil: kayıtların sahibi milyonlarca ayrı kuruluş.
• Bölünme adın kendi yapısını izliyor. Her nokta bir sorumluluk sınırı; kök, üst düzey alan ve yetkili sunucu bu sınırların üstüne oturuyor.
• Zinciri senin makinen yürümüyor, resolver yürüyor ve resolver hiyerarşinin parçası değil, müşterisi.
• Sormanın iki biçimi var: özyinelemeli sorgu cevabı getiriyor, yinelemeli sorgu bir sonraki adresi veriyor.
• Mesajın başlığı 12 bayt ve dört bölme sayacı taşıyor. Bayraklardaki AA cevabın sahibinden mi geldiğini, RCODE ise işin nasıl bittiğini söylüyor; NXDOMAIN ile SERVFAIL arasındaki fark arızanın yerini de ayırıyor.
• Zincir kendi kendini kilitlemiyor: sunucu adının yanına iliştirilen tutkal kaydı ile yazılıma gömülü kök ipuçları, bir adı çözmek için önce başka bir adı çözme zorunluluğunu ortadan kaldırıyor.

Resolver zinciri yürüdü ve cevabı sana getirdi. Getirdiği şey çıplak bir sayı değil, türü ve ömrü olan bir satırdı. Peki aynı ada adresten başka neler yazılabiliyor?