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. İş biter.

Birkaç yüz makine için gerçekten işe yarardı. Milyarlarca kayıt için 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. 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. 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: postacı zarfı kabaca sağdan sola okur, alan adı da öyle. Fark şu — zarfta bütün adımları tek kurum yürütür, burada her adımın sahibi ayrıdır.

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 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, ve 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 ç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; 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ı kapıya, bağlantısız taşımayla 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 6. 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. Bir uzantıyla bu sınır pazarlıkla büyütülebiliyor; imzalı cevaplar 512 bayta sığmadığı için o uzantı olmadan imzalama pratikte çalışmı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 biti 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 tam olarak yukarıdaki tablodur: qr cevap olduğunu, rd özyineleme istendiğini, ra resolver’ın bunu yapabildiğini söylüyor. aa yok — demek ki cevap yetkili sunucudan değil, önbellekten geldi.

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 ns1.ornek.com için bir de A kaydı koyuyor ve döngü kırılıyor. Yetkili sunucu alanın dışında olsaydı — mesela ns1.baskadns.net — 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.

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ı bir sonraki durakta ölçeceğiz.

Cevap tek çeşit değil

Zincir boyunca dönen her satır aynı kalıptadır. Dört alan var: adın kendisi, karşılığı olan değer, kaydın türü ve ne kadar süre geçerli sayılacağı. Bu satırlara kaynak kaydı diyoruz.

Satırlar gerçekte şöyle görünüyor:

ornek.com.        300     IN   A       203.0.113.9
ornek.com.        3600    IN   NS      ns1.ornek.com.
ornek.com.        3600    IN   MX      10 posta.ornek.com.
www.ornek.com.    300     IN   CNAME   ornek.com.

Soldan sağa: ad, yaşam süresi, sınıf, tür, değer. Adın sonundaki nokta yukarıda anlattığım gizli kök; burada gizlenmiyor. Sınıf alanı bugün pratikte hep IN çıkıyor — sistem başka ağ aileleri için de tasarlanmıştı ama internetten başkası kalmadı. Posta satırındaki baştaki sayı ise öncelik: birden fazla sunucu varsa küçük olan önce deneniyor.

Kendi makinende görmek istersen dig ornek.com ANY ya da Windows’ta nslookup -type=A ornek.com aynı satırları döküyor.

Türü bilmek işe yarıyor, çünkü aynı ada farklı türlerde farklı cevaplar durabiliyor. Tür alanı 16 bit ve yüzlerce değer tanımlı; gündelik hayatta karşına çıkanlar bir sayfaya sığıyor:

Son üçü genç ve üçü de kitabın başka bölümlerine bağlanıyor.

SRV kaydı DNS’in tek başına yapamadığı bir şeyi yapıyor: port numarasını da söylüyor. A kaydı sana yalnızca makineyi verir, portu uygulamanın bilmesi gerekir — 5. bölümde iyi bilinen port numaralarının niçin ezberlendiğini göreceğiz. SRV bu ezberi kaldırıyor ve adı _hizmet._protokol.alan biçiminde yazıyor: _sip._tcp.ornek.com.

CAA kaydı bir yasak listesi. Her sertifika makamı teknik olarak her ad için sertifika üretebiliyor; CAA alan sahibine “benim adıma yalnızca şu makam sertifika verebilir” deme imkânı veriyor. Makamlar sertifikayı basmadan önce bu kaydı sorgulamak zorunda.

HTTPS kaydı ise tarayıcıya bağlantıyı kurmadan önce yol gösteriyor: hangi protokol sürümleri destekleniyor, hangi port, ve varsa şifreli istemci merhabası için gereken açık anahtar. HTTP/3’e geçişin bir gidiş-dönüşü nasıl kısalttığını konuşurken bu kayda geri döneceğiz.

Adres kaydının iki ayrı türü olması da tesadüf değil: internette iki ayrı adres ailesi kullanılıyor ve çoğu makine ikisini birden istiyor. Farkı ve neden hâlâ ikisinin birden yaşadığını 35. bölümde açacağız.

Ters yön ayrı bir ağaçta yürüyor

Elinde bir adres var ve hangi ada ait olduğunu öğrenmek istiyorsun. DNS bu soruyu doğrudan cevaplayamaz, çünkü ağaç adlara göre bölünmüş — adresleri arayacak bir dizin yok.

Çözüm zarif: adres bir ada çevriliyor. IPv4 adresinin dört sayısı ters sırada dizilip in-addr.arpa alanının altına asılıyor.

203.0.113.9   →   9.113.0.203.in-addr.arpa.   PTR   sunucu.ornek.com.

Ters sıralamanın sebebi hiyerarşi. Alan adlarında en genel parça sağdadır (com), adreslerde ise soldadır (203). Sırayı çevirince adresin de en genel parçası sağa geçiyor ve DNS’in olağan yetki devri mekanizması hiç değiştirilmeden çalışıyor: bir kuruluşa 203.0.113.0/24 bloğu tahsis edildiğinde ona 113.0.203.in-addr.arpa alanının yetkisi devrediliyor.

IPv6’da aynı numara dörtlük bit gruplarıyla yapılıyor ve ağaç ip6.arpa altında duruyor; adres 32 basamağa açıldığı için ters kayıt adı da 32 etiketten oluşuyor.

Kritik ayrıntı şu: iki yön birbirini doğrulamak zorunda değil. A kaydı bir adı bir adrese bağlarken PTR kaydı adresi bambaşka bir ada bağlayabilir, çünkü ikisinin sahibi farklıdır — ileri yön alan adının sahibine, ters yön adres bloğunun sahibine aittir. Posta sunucuları bu yüzden ikisinin uyuşmasını ayrıca kontrol eder; uyuşmayan bir gönderici spam sayılır.

Aynı ada birden çok adres kaydı da konabiliyor. Cevapta birden fazla sayı döndüğünde istemciler farklı makinelere dağılıyor ve yük paylaşılıyor. Tek bir ad, tek bir makine demek değil.

ornek.com.  3600  IN  SOA  ns1.ornek.com. yonetici.ornek.com. (
                          2026082201 ; seri numarası
                          7200       ; yenileme  (refresh)
                          900        ; yeniden deneme (retry)
                          1209600    ; süre bitimi (expire)
                          3600 )     ; asgari — negatif önbellek süresi

Dönen cevabın kendisi de tek bir satırdan ibaret değil. Paket üç bölmeye ayrılıyor: sorulan şeyin cevabı, o cevaba kimin yetkili olduğu, ve işine yarayabilecek ek kayıtlar. Sunucu adresinin ada iliştirilmesi işte bu üçüncü bölmede oluyor. Resolver böylece bir sonraki adımı ayrı bir soru sormadan öğreniyor.

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

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

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

Peki, ne öğrendik?

• 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.
• Cevap tek çeşit değil. Adres, sunucu, posta ve takma ad kayıtlarının yanında SRV portu, CAA sertifika iznini, HTTPS ise bağlantı parametrelerini taşıyor.
• 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.
• Ters yön ayrı bir ağaçta yürüyor: adres ters çevrilip in-addr.arpa altına asılıyor, ve iki yönün uyuşması zorunlu değil çünkü sahipleri farklı.

Elinde artık bir sayı var ve soket açılabilir. Ama o sayıyı sana bir yabancı söyledi ve sen sorgulamadan kabul ettin. Sana bir sayı söylediler; peki söyleyenin doğruyu söylediğini nereden biliyorsun?