DNS: İnternetin Görünmez Mimarı

İnternet tarayıcınız her gün milyonlarca kez bir büyü yapıyor ve siz bunu hiç fark etmiyorsunuz. "example.com" gibi bir adresi yazınca, sistem bunu anlamlı bir sayı dizisine çeviriyor, dünyanın neresinde olursa olsun doğru sunucuyu buluyor ve sizi saniye kesirlerinde bağlantılı hale getiriyor. Bu büyünün adı DNS—Domain Name System—ve çoğu kişinin sandığından çok daha karmaşık bir sistem.

1983 yılında, internet daha çok modem üzerinde çalışıyor ve web sitelerinin sayısı avuç açısıyken, mühendis Paul Mockapetris DNS'i tasarladı. Amacı basitti: hızlı olması, büyüyebilmesi ve güvenilmez bağlantılara karşı dayanıklı olması gerekiyordu. Dört on yıl sonra, bu tasarım hala ayakta. Neden böyle başarılı olmuş, ona bakalım.

Hızlı Olmanın Sırrı: UDP'nin Tercih Edilmesi

DNS'i diğer sistemlerden ayıran ilk şey protokol seçimidir. DNS, TCP yerine UDP kullanır.

TCP bağlantısı kurmak için üç aşamalı bir el sıkışma gerekir. Yani sorunuzu sorabileceğiniz zamana gelmeden bile iki bilgisayar birbirini doğruluyor. Eğer her DNS sorgusu bu karmaşıklıktan geçseydi, internet salyangoz hızında çalışırdı. Bir web sayfası yüklediğinizde tarayıcı 50, 60 hatta daha fazla DNS sorgusu yapabilir. Şimdi bunu hesap edin: her biri TCP el sıkışması yaparsa, gecikme katlanarak artmış olur.

UDP ise bu sorunun üstesinden geliyor. Bilgisayarınız 53 numaralı porta bir paket gönderir—içinde sadece sorununuz var. Karşı taraf cevap paketini geri gönderir. Bitti. El sıkışma yok, anlaşmazlık yok—soru ve cevap.

Tabii ki bir bedeli var. UDP paketleri yolda kaybolabilir. Ama DNS bunu çok akıllı bir yolla çözer: eğer belirli bir sürede cevap gelmezse, soruyu tekrar sorar. Ayrıca DNS sorgularının %99'ından fazlası 512 baytlık tek bir UDP pakete sığdığı için paket kaybı son derece nadir.

Ancak istisnalar da var. Cevap çok büyük olduğunda—mesela DNSSEC imzaları eklendiğinde—sunucu TC (Truncated) bitini işaretler ve istemci TCP üzerinden yeniden bağlanır. Böylece hızlık ve güvenilirlik dengesini sağlamış olur: varsayılan olarak hızlı, gerekirse güvenilir.

Ağaç Yapısının Gücü: Merkezileşme Olmaksızın Ölçeklenme

DNS'in başarısının en önemli sırrı şudur: dünyada hiçbir merkezi veritabanında tüm domain'lerin listesi yoktur.

Bunun yerine DNS, ters bir ağaç yapısı gibi çalışır. www.example.com. adresi aslında sağdan sola okunur. Sorguyu yaptığınızda sistem en tepeden başlayarak aşağı doğru delegasyon yapıyor:

Root Sunucuları başlangıç noktasıdır. Adları A'dan M'ye kadar gider, mantıksal olarak 13 tane var ama Anycast yönlendirilmesi sayesinde dünya genelinde binlerce kez çoğaltılmıştır. Sorgunuz her zaman size en yakın olan kopyaya ulaşır. Root sunucuları sizin domain'inizi bilmez; sadece hangi nameserver'ların .com, .org, .uk ve benzeri TLD'leri yönettiğini bilir.

TLD Sunucuları (Top-Level Domain), kayıt defterleri tarafından işletilir. Verisign .com'u yönetir, Afilias .info'yu yönetir ve öyle devam eder. Onlara example.com hakkında sorduğunuzda, o domain'den sorumlu olan nameserver'ları belirtirler.

Yetkili Nameserver'lar ağacın en altında yer alır. Genellikle domain kayıt şirketiniz veya Cloudflare, Route 53, NameOcean gibi DNS sağlayıcısı tarafından yönetilir. Burada gerçek veriler durur—A record'ları, AAAA record'ları, CNAME'ler, MX record'ları ve daha birçok şey. Bu sunucular cevap verdiklerinde, cevaba aa (authoritative) bitini eklerler: "Ben bunu bilirim, bu kesin bilgi."

Burada komik bir paradoks ortaya çıkabilir: ya nameserver'ınız ns1.example.com ise? Bu durumda ns1'in IP adresini bulmak için önce example.com'un IP adresini bulmanız gerekir ki bu imkansız görünür. TLD sunucuları bunu glue record'ları ile çözer—NS delegasyonun yanında, nameserver'ın IP adresini kendi vermek suretiyle bu kısır döngüyü kırarak sorunu çözer.

Önbellekleme: İnternetin Gerçek Süper Gücü

Gerçek şu ki: eğer her DNS sorgusu root'tan başlayıp TLD'ye, sonra yetkili sunucuya gitseydi, internet çökerdi.

Sistem ayakta kalabiliyor çünkü DNS'in her seviyesinde agresif bir önbellekleme sistemi vardır.

Her DNS record'unun bir TTL (Time-to-Live) değeri vardır—saniye cinsinden. Bu bir sözdür: "Bu cevap X saniye geçerlidir. Bu süre içinde bana sorma." Caching dört yerde olur:

• Tarayıcınızda — Chrome'un kendi DNS önbelleği vardır, chrome://net-internals/#dns adresinde görebilirsiniz.
• İşletim sisteminizde — Linux'ta systemd-resolved, macOS'ta mDNSResponder, Windows'ta DNS Client.
• Recursive resolver'ınızda — Google'ın 8.8.8.8'i, Cloudflare'ın 1.1.1.1'i ya da İSS'nizin resolver'ları milyonlarca kullanıcı arasında bu önbelleği paylaşır. Bir kişinin cache miss'i, milyonların cache hit'i olur.

Bu nedenle domain transfer sırasında TTL yönetimi hayati önem taşır. Sitenizi yeni bir sunucuya taşıyorsak, transfer işleminden günler evvel TTL'yi 24 saattan 5 dakikaya düşürmeliyiz. Aksi takdirde dünyadaki resolver'lar tüm gün boyunca eski IP adresinize trafik göndermeye devam edecek ve yetkilendirilmiş değişikliği görmezden gelecektir. Kontrol edilmeyen caching, atalet haline gelir.

Bir Sihirbazlık Numarası: Anycast Yönlendirmesi

İşte burası gerçekten ilginç hale geliyor.

Google'ın 8.8.8.8 adresi, Tokyo'dan sorgulara 2 milisaniyede, Londra'dan da 2 milisaniyede cevap nasıl veriyor? On üç mantıksal root sunucusu, dünyanın dört bir yanında binlerce fiziksel sunucuya nasıl ölçekleniyor? Cevap DNS değil, Anycast yönlendirmesi.

Normal yönlendirmede bir IP adresi bir sunucuya denk gelir. Anycast ise bu varsayımı çiğneler: dünyanın dört bir yanında yüzlerce sunucu, aynı IP adresini eş zamanlı olarak BGP (Border Gateway Protocol) kullanarak duyurur. Sorgunuz o IP adresine gitse de, BGP algoritması paketinizi otomatik olarak sizi en yakın veri merkezine yönlendirir.

Bu sayede Cloudflare, DNS'i dünyanın her yerinde tek haneli milisaniye gecikmesi ile sunabilir. Bu sayede, root sunuculara yapılan DDoS saldırıları başarısız olur—saldırı trafiği, o IP adresini duyuran tüm noktalara dağılır. Altyapısı sade ama sonucu mucizevi görünür.

Hep Birlikte Çalışması

DNS, dağıtık sistem tasarımının bir şaheser'idir. Hızlı çünkü varsayılan olarak state'siz, bağlantısız UDP kullanır. Ölçeklenebilir çünkü yetki hiyerarşik bir ağaç boyunca delegasyon yapılır. Yükü kaldırabilir çünkü caching her seviyede gerçekleşir. Ve sana düşük gecikmeli ulaşabilir çünkü Anycast sunucuları coğrafya açısından sana yaklaştırır.

Tüm bu tasarım 1983'te, internetin henüz emekleme aşamasında iken yapıldı. Dört on yıl sonra, her gün trilyonlarca sorguya cevap vererek ağı çalışır halde tutması, o günkü tasarım ilkelerinin ne denli sağlam olduğunu gösterir.

NameOcean ile çalışıyor veya DNS'i büyük ölçekte yönetiyorsanız, bu temelleri anlamak domain yönetiminden taşıma işlemlerine, performans optimizasyonundan hepsine bakışınızı değiştirir. DNS sadece tesisattan ibaret değildir—internetin dolaşım sistemidir.