Bölüm 4:Önbellek, Tazelik ve Güven

Sorgu bir sayı getirdi ve iki şeyi hiç sınamadık: söyleyenin doğru söylediğini, ve cevabın ne kadar taze olduğunu.

İkisi de aynı yerde, resolver’ın sana gösterdiği yüzün arkasında duruyor. Peki orada ne var?

Cevap büyük ihtimalle hiyerarşiden gelmedi

Zinciri kökten yetkili sunucuya kadar yürütürken resolver’ın elinde hiçbir şey olmadığını varsaymıştık. O varsayım anlatmak için gerekliydi. Ölçmek için değil.

Gerçek hayatta zincir nadiren baştan yürür.

Sebep basit: her isim sunucusu öğrendiği eşlemeyi bir süre saklıyor. Aynı ad tekrar sorulduğunda kimseye danışmadan, elindeki kopyayla cevap veriyor. Bu depoya önbellek diyoruz ve zincirin kısalmasının tek sebebi o.

Kısalma tek bir yerde de olmuyor. Cevap sana ulaşana kadar birkaç ayrı depodan geçme ihtimali var ve her biri ötekinden habersiz çalışıyor.

En üstteki depo tarayıcının kendi ad deposu: 1. bölümde yokladığı ceplerin yanında duran ayrı bir bölme. Orada cevap varsa istek makineden hiç çıkmıyor. Yoksa bir alt basamağa düşüyor. Ancak hepsi boş çıktığında hiyerarşiye soru gidiyor.

Kazancın nerede olduğunu gecikme bileşenleriyle ölçmek gerekiyor. Kısalan şey iletim süresi değil, yapılan gidiş dönüş sayısı. Depodan gelen bir cevap sıfır tur harcıyor. Zincirin tamamı ise dört tur.

Saklanan şey yalnızca başarılı cevaplar da değil. Bir ad yoksa, o yokluk da bir süre saklanıyor ve buna olumsuz önbellekleme deniyor. Yeni kaydedilen bir adın neden hemen çalışmadığını sormuş ve sebebini buraya bırakmıştım: adı sen kaydetmeden önce birinin sorduğu ve “yok” cevabı aldığı bir resolver, o yokluğu hâlâ elinde tutuyor olabilir.

Katmanların birbirinden habersiz olması da başlı başına bir sorun kaynağı. Bir kaydı değiştirdiğinde makinendeki depo tazelenmiş, tarayıcınınki eskide kalmış olabiliyor. Aynı adres iki farklı programda iki farklı yere gidiyor ve hangi katmanın yanıldığını dışarıdan görmek kolay olmuyor.

Depoların büyüklüğü de aynı değil. Tarayıcınınki yalnızca sana hizmet ediyor, resolver’ınki binlerce kişiye; bu hem kazancı hem riski büyütüyor. O depoya giren tek bir yanlış kayıt, aynı resolver’ı kullanan herkesi birden yanıltıyor.

Bunun görünmeyen bir sonucu daha var. Üst düzey alan sunucularının adresleri neredeyse her resolver’da saklı duruyor, dolayısıyla kök çoğu sorguda hiç devreye girmiyor. Kökün yükünü hafifleten şey ek donanım değil, bu depolama.

Tazeliğin ölçüsü kaydın içinde

Bir kaydın ne kadar süre saklanabileceğini kimse tahmin etmiyor. Süre kaydın kendi alanlarından biri olarak yazılı geliyor ve adı yaşam süresi.

Bu süreyi senin resolver’ın da yazmıyor; alanın sahibi yazıyor. Kaydı yayımlarken “bu değeri şu kadar süre saklayabilirsin” demiş oluyor. Süre dolduğunda kayıt depodan düşüyor. Bir sonraki soru zinciri yeniden başlatıyor.

Buradaki seçim gerçek bir ödünleşim. Süreyi uzun tutarsan sorgu sayısı düşer, cevaplar hızlanır, sunucuların yükü azalır. Kısa tutarsan bir değişiklik dünyaya çabuk yayılır ama her şey daha sık sorulur.

Ödünleşimin ne kadar sert olduğu sayılabilir ve sonuç sezgiye ters çıkıyor. Mantık basit: her yaşam süresi penceresinde yetkili sunucuya tek bir soru gidiyor, o pencerede gelen diğer bütün sorular depodan karşılanıyor. Yani isabet oranını belirleyen şey sürenin kendisi değil, süre boyunca kaç soru geldiği.

Çok sorulan bir adı düşün: saniyede on soru, süre beş dakika. Pencerede üç bin soru birikiyor ve yalnızca biri dışarı çıkıyor — isabet oranı on binde 9.997. Şimdi süreyi otuz saniyeye indir: oran hâlâ %99,67, kullanıcı hiçbir şey hissetmiyor. Ama yetkili sunucuya giden soru sayısı on katına çıktı. Aynı değişiklik, iki tarafta iki ayrı hikâye.

Şimdi az sorulan bir adı düşün: on yedi dakikada bir soru. Beş dakikalık pencere, ikinci soru gelmeden doluyor ve neredeyse her soru ıskalıyor. Yaşam süresini uzatmak bu ada hiçbir şey kazandırmıyor.

Buradan iki pratik sonuç çıkıyor. Büyük siteler kısa süreleri neredeyse bedelsiz kullanabiliyor ve hızlı taşınma esnekliğini bedavaya alıyorlar. Küçük siteler ise süreyi uzatarak bir şey kazanmıyor, yalnızca kendi değişikliklerini yavaşlatıyor.

Bedelin nerede ortaya çıktığını bir taşınmada görürsün. Sunucunu başka bir makineye taşıdığında kaydı güncellersin, ama eski değer hâlâ binlerce depoda duruyordur. Yeni adres herkese ancak eski kayıtların süresi dolduğunda ulaşır. O zamana kadar bazı ziyaretçiler yeni makineye, bazıları eskisine gider.

Deneyimli yöneticiler bu yüzden taşımadan önce süreyi kısaltır, taşımayı yapar, sonra tekrar uzatır. Ama kısaltma da anında etkili olmuyor: eski uzun süreyle saklanmış kayıtlar kendi süreleri dolana kadar yerinde kalıyor.

Sürenin nasıl işlediği de sezgiye ters. Kaydı ilk alan resolver geri saymaya başlıyor ve sana cevabı verirken kalan süreyi bildiriyor. Yani elindeki kayıt, yayımlandığı andaki tam süreyi değil ondan geriye kalanı taşıyor.

Bunu kendin ölçebilirsin: aynı adı kısa aralıkla iki kez sor ve dönen süreye bak.

$ dig +noall +answer example.com A        # ilk sorgu
example.com.   132   IN   A   ...

$ sleep 7 && dig +noall +answer example.com A
example.com.   125   IN   A   ...

Aradaki fark tam olarak beklediğin kadar. Kayıt yeni sorulmuyor; resolver’ın deposunda duran aynı kayıt, üstündeki sayaç azalmış hâlde veriliyor. Sayaç sıfıra indiğinde kayıt düşüyor ve bir sonraki soru zinciri yeniden başlatıyor.

Tarayıcılar ise bu sayıya her zaman uymuyor. Kendi depolarında adları çoğu kez kaydın söylediğinden farklı bir süre tutuyorlar; bazen daha uzun, bazen bağlantı kapanana kadar. Sebep performans: her sekmede yeniden sormak pahalı. Sonuç ise şu — kaydın yaşam süresini kısaltmak, tarayıcı tarafında beklediğin etkiyi yaratmayabiliyor.

Yokluk cevapları için de ayrı bir süre yazılıyor ve bu süre genellikle çok daha kısa tutuluyor. Sebebi asimetrik bir maliyet: var olan bir kaydı bayat tutmak yalnızca eski adrese göndermekle sonuçlanıyor, olmayan bir kaydı bayat tutmak ise yeni kurulan her şeyi görünmez kılıyor. Sistem, iki hatadan daha ucuz olanı seçmiş.

Süreyi kimin belirlediği bir sorumluluk sorusu da doğuruyor. Kaydı yayımlayan taraf uzun bir süre yazarsa, kendi değişikliğinin gecikmesine kendisi razı olmuş oluyor. Ama aynı kaydı kullanan başka kimseye bu tercih sorulmuyor.

Buradan çıkan sonuç, sistemin kendi hakkında verdiği sözü de belirliyor. Ad-adres çevirisi kesin tazelik vaat etmiyor. Elinden gelenin en iyisini yapıyor ve elindeki cevabın bayat olma ihtimalini hep taşıyor.

Bu cevaba neden güveniyorsun?

Şimdi ertelediğim ikinci soruya gelelim. Resolver sana bir sayı söyledi. Peki doğru söylediğini nereden biliyorsun?

Kısa cevap rahatsız edici olacak: varsayılan hâlde bilmiyorsun. Sorgu ve cevap, kendi başlarına ne imzalı ne de gizli. Cevabın gerçekten yetkili sunucudan geldiğini kanıtlayan hiçbir şey yok. Sen ilk gelen cevaba inanıyorsun.

Bunun iki klasik sömürüsü var. Birincisinde araya giren taraf sorguyu görüp sahte bir cevap yetiştiriyor. İkincisi daha sinsi ve adı zehirleme saldırısı: sahte cevap resolver’ın deposuna yerleşirse aynı yalan, süresi dolana kadar o resolver’ı kullanan herkese servis ediliyor. Tek bir başarılı saldırı, binlerce kişiyi yanlış makineye gönderiyor.

Sahteciliğin nasıl yürüdüğünü bilmek, çözümün neden imza olduğunu da açıklıyor. Saldıran taraf gerçek cevabı beklemiyor; kendi cevabını daha önce yetiştirmeye çalışıyor. Ama uydurduğu cevabın kabul edilmesi için sorgunun kimlik numarasını ve hangi porttan sorulduğunu da doğru bilmesi gerekiyor.

Bu yöntemin en bilinen biçimi 2008’de yayımlandı ve bulanın adıyla Kaminsky saldırısı diye anılıyor. Numarası kısaydı: saldırgan var olan bir adı değil, o alanın altında var olmayan rastgele adları soruyor. Her soru yeni bir tahmin hakkı veriyor ve sahte cevaba alanın yetkili sunucusunu değiştiren bir kayıt iliştiriliyor. Tek bir tutturma, alanın tamamını ele geçiriyor.

Savunma bu iki sayıyı tahmin edilemez kılmak üzerine kuruldu. Kimlik numarası 16 bit, yani 65.536 olasılık — tek başına yetersiz. Kaynak portunun da rastgele seçilmesi olasılığı milyarlara çıkardı; kuralı RFC 5452 yazıyor. Üstüne iki ucuz hile daha eklendi: sorulan adın harflerini rastgele büyük-küçük yazıp cevapta aynen geri beklemek, ve soruyu üst basamaklara sorarken adın yalnızca gereken kadarını göstermek. Üçü birden tahmini pratikte imkânsız kılıyor — ama yalanı matematiksel olarak imkânsız kılmıyor. Bunu ancak imza yapıyor.

Çözüm olarak kayıtları imzalamak öneriliyor. İmza zinciri kökten aşağı iniyor ve doğrulayan bir resolver, cevabın gerçekten o alanın sahibinden geldiğini matematiksel olarak sınayabiliyor. Adı DNSSEC ve tek bir şey yapıyor: kaynağı ve bütünlüğü doğruluyor. Gizlemiyor.

Yayılımına baktığında garip bir dengesizlik göreceksin. Kullanıcıların yaklaşık %36’sı imzayı doğrulayan bir resolver’ın arkasında. Buna karşılık imzalanmış bölge oranı yıllardır %8 civarında takılı. Uçtan uca gerçekten doğrulanan sorgu oranı ise Temmuz 2026 ölçümünde %0,62.

İmza da ayrı kayıt türleriyle taşınıyor ve adlarını bilmek işe yarıyor. DNSKEY alanın açık anahtarını yayımlıyor, RRSIG bir kayıt kümesinin imzasını taşıyor, DS ise üst basamakta duruyor ve bir alt alanın anahtarının özetini gösteriyor. Zincir böyle kuruluyor: kökün anahtarına güveniyorsun, kök com alanının DS kaydını imzalıyor, com da bir alt alanınkini. Güven aşağı doğru akıyor.

Zincirin en tepesinde doğrulanacak bir şey değil, baştan bilinen bir şey duruyor: kökün açık anahtarı. Adı güven çıpası ve doğrulayan her resolver’ın içine gömülü geliyor. Bu anahtar 2010’da yayımlandı ve ilk kez 2018’de değiştirildi; değişim, dünyadaki bütün doğrulayıcıların aynı anda yeni anahtarı tanımasını gerektirdiği için yıllarca hazırlandı.

İmzalamanın neden bu kadar geride kaldığı da anlaşılır bir hikâye. İmza, düzenli olarak yenilenmesi gereken anahtarlara dayanıyor ve yenileme kaçırılırsa imza geçersiz oluyor. Geçersiz imzanın cezası da ağır: doğrulayan bir resolver o cevabı kabul etmiyor ve alan, yanlış adrese gitmek yerine tamamen erişilemez hâle geliyor. Yani imzalamanın hatası, hiç imzalamamanın hatasından daha görünür sonuç veriyor. Bu asimetri, isteksizliğin büyük kısmını tek başına açıklıyor.

Aradaki uçurum tek bir cümleyle özetlenebilir: doğrulayacak taraf hazır, imzalayacak taraf değil. Alan sahibi imzalamadığı sürece doğrulayıcı resolver’ın sınayacağı bir şey olmuyor.

Sorguyu kim görüyor?

İmza bir sorunu çözüyor, ötekini hiç ele almıyor. Cevabın doğru olduğunu kanıtlasan bile soruyu sorduğun herkesin gözü önünde soruyorsun.

Sorgu düz metin gittiği sürece yolun üstündeki taraflar hangi adlara baktığını görebiliyor. Sayfanın içeriğini görmeleri de gerekmiyor. Ad tek başına yeterli oluyor; ne yaptığın hakkında hatırı sayılır bilgi taşıyor.

Buna karşı birkaç taşıma önerildi ve hepsine birden şifreli DNS diyoruz.

Fark son sütunda. İlkinin kendi kapısı olduğu için trafiği tanınabiliyor; bir ağ yöneticisi 853’ü kapatarak şifreli sorguyu engelleyebiliyor. İkincisi ise web trafiğinin içine karışıyor, o yüzden engellenmesi çok daha zor — ama aynı sebeple kurumsal ağlarda tepki çeken de o oluyor.

Şifreleme neyin görünmediğini değiştiriyor, neyin göründüğünü tamamen kapatmıyor. Resolver’ın kendisi her şeyi görmeye devam ediyor; şifre onunla senin aranda. Adı çözdükten sonra o makineye bağlanıyorsun ve bağlantının hedef adresi paketin üstünde açıkça yazıyor. Aynı adreste tek bir site duruyorsa, adı gizlemek gittiğin yeri gizlemiyor. Üstelik şifreli bağlantıyı kurarken sunucuya hangi siteyi istediğini de söylüyorsun; o adım 10. bölümün konusu.

Şifrelemenin ikinci sonucu ise ölçekle ilgili ve teknik olmaktan çok yapısal. Tarayıcılar şifreli sorgu için genellikle kendi seçtikleri birkaç büyük sağlayıcıyı varsayılan yapıyor. Böylece sorgu, ağını işleten kurumun gözünden çıkıp dünya çapında birkaç şirketin gözüne giriyor. Kimin göreceği değişiyor, kaç kişinin göreceği azalıyor, ama görenin elindeki resim büyüyor. Şifreleme bir tehdit modelini kapatıyor, hepsini birden değil. Tehdit modeli, “kime karşı korunuyorum” sorusunun cevabı; hangisini kapattığı söylenmeden hiçbir şifreleme kararı değerlendirilemez.

Kendi durumunu görmek de zor değil. Tarayıcıların ayarlarında şifreli sorgunun açık olup olmadığı yazılı duruyor ve çoğu tarayıcı bugün bunu varsayılan olarak açıyor. Ağın buna izin vermediği durumlar da var: bazı kurumsal ağlar şifreli sorguyu kapatıp bütün soruları kendi resolver’ına yönlendiriyor.

Yayılım burada da mütevazı. Ölçümlerde ilk yöntem %6,33, ikincisi %5,75 paya sahip; ikincisi bir yılda yaklaşık üçe katlandıktan sonra tırmanışı duraksadı. Yani sorguların büyük çoğunluğu hâlâ açık gidiyor.

Özet

Peki, ne öğrendik?

• Gelen cevap çoğu zaman hiyerarşiden gelmiyor; tarayıcıdan resolver’a uzanan bir depo dizisinin ilk dolu olanından geliyor.
• Tazeliği kaydın içindeki yaşam süresi belirliyor ve o süreyi resolver değil, alanın sahibi yazıyor.
• Süre seçimi gerçek bir ödünleşim: uzun süre yükü azaltıyor, kısa süre değişikliği hızlandırıyor, ve taşıma sırasında bedeli okur değil yönetici ödüyor.
• Cevap varsayılan hâlde imzasız. İmzalama kaynağı doğruluyor ama gizlemiyor, ve imzalayan taraf doğrulayan taraftan çok geride.
• Şifreli taşıma gözlemciyi değiştiriyor, yok etmiyor; resolver hâlâ her şeyi görüyor ve merkezileşme ayrı bir tartışma başlatıyor.

Elinde artık bir sayı var ve o sayının nereden geldiğini de biliyorsun. Ama sayı yalnızca makineyi gösteriyor. Bir makinede aynı anda onlarca program çalışıyor ve hepsi ağ kullanabiliyor. Adres elinde; şimdi o makinenin hangi kapısını çalacaksın?