DNS çözümlemesinin tam yolculuğu — tarayıcıdan kök sunucuya kaç adım?

1. Eksiksiz 8 adımlı akış

┌─────────────────────────────────────────────────────────────┐
│  Tarayıcı (Chrome / Firefox) — google.com yazılır           │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Tarayıcının DNS önbelleği (Chrome ~60 sn)
                 ↓ önbellekte yok
┌─────────────────────────────────────────────────────────────┐
│  İşletim sistemi stub çözümleyicisi + sistem DNS önbelleği  │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Sistem önbelleğinde yok → yönlendiriciye UDP sorgusu gider
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Ev yönlendiricisi: DNS iletme + yönlendirici önbelleği     │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Yönlendirici önbelleğinde yok → İSS'nin özyinelemeli
                 │   çözümleyicisine iletilir
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  İSS / genel özyinelemeli çözümleyici                       │
│  (1.1.1.1 / 8.8.8.8 / 223.5.5.5)                            │
│  Önbellekte varsa: doğrudan döner, tüm süreç 1-5 ms         │
│  Önbellekte yoksa: aşağıdaki “tam sorgulama” akışı başlar   │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Kök NS'ye “google.com nerede?” diye sorulur
                 ↓
        13 kök ad sunucusu grubu (a~m.root-servers.net)
                 │ ⑤ Yanıt: “Bilmiyorum, .com NS'sine sor: a.gtld-servers.net”
                 ↓
        .com TLD yetkili sunucuları (Verisign)
                 │ ⑥ Yanıt: “Bende de tamamı yok, google.com NS'sine sor:
                 │   ns1.google.com”
                 ↓
        google.com yetkili sunucuları (Google'ın kendisi işletir)
                 │ ⑦ Yanıt: “google.com A kaydı = 142.250.x.x”
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ Özyinelemeli çözümleyici yanıtı önbelleğe alır (TTL'ye   │
│     göre) ve istemciye döndürür — yol üzerindeki her        │
│     katman da kendi kopyasını önbelleğe alır                │
└─────────────────────────────────────────────────────────────┘

Önemli nokta: gerçek hayatta 8 adımlık akışın tamamı neredeyse hiç yaşanmaz. Büyük sitelerin IP adresleri neredeyse her zaman özyinelemeli çözümleyicinin önbelleğinde durur; bu yüzden sıradan kullanıcılarda süreç en fazla ④. adıma kadar ilerler ve yanıt döner. Tam akışı yalnızca az bilinen alan adları, uzun süredir ziyaret edilmemiş siteler, TTL'si dolmuş kayıtlar veya yeni kaydedilmiş alan adları tetikler.

2. DNS önbelleğinin 5 katmanı

DNS 1983'te tasarlanırken şu gerçek zaten hesaba katılmıştı: sorgulamalar, değişikliklerden 100.000 kat daha fazladır. Bu yüzden önbellekleme her yerdedir ve her katman veriyi TTL (Time To Live) süresi boyunca tutar.

3. Özyinelemeli ve yinelemeli sorgular — temel kavramlar

3.1 Özyinelemeli (recursive)

İstemci (tarayıcı / işletim sistemi stub'ı), İSS'nin özyinelemeli çözümleyicisine şunu söyler: “Benim için google.com'un IP'sini bul — nasıl bulduğun umurumda değil.” Özyinelemeli çözümleyici sorgulamanın tamamını yürütüp nihai sonucu döndürmek zorundadır.

3.2 Yinelemeli (iterative)

Özyinelemeli çözümleyici kök, TLD ve yetkili sunucularla konuşurken bu alışveriş yinelemelidir — köke sorar, kök “.com'a sor” der; gidip .com'a sorar, .com “google'a sor” der; gidip google'a sorar. Her adımda yalnızca bir atlama geçilir — “köke sorarım, kök her şeyi benim için halleder” şeklinde işlemez.

4. Kendiniz test edin — dig +trace

dig +trace tam bir yinelemeli sorgulamayı zorunlu kılar ve her adımı gösterir:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① 1. atlama — kök (.) sorgulanır
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 kök NS kaydı)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② 2. atlama — .io TLD'si sorgulanır
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (.io için 4 NS)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ 3. atlama — cleanip.io'nun yetkili sunucuları sorgulanır
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Sonunda yanıt alınır
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Değerlendirme:

• Sürecin tamamı 5 + 121 + 53 + 12 = 191 ms sürdü — ilk soğuk sorgulama gerçekten yavaştır
• Ancak aynı alan adını bir saniye sonra yeniden sorgulamak yalnızca 1-2 ms sürer, çünkü kayıt İSS'nin özyinelemeli önbelleğinde zaten vardır (TTL 300 saniye)
• 104.21.x.x / 172.67.x.x Cloudflare CDN adresleridir — sitemizin gerçek kaynak sunucu IP'si CDN'in arkasında gizlidir

5. TTL ayrıntılı — önbellek gerçekte ne kadar sürer?

TTL (Time To Live), yetkili sunucunun tüm özyinelemeli çözümleyicilere “bunu en fazla bu kadar süre önbellekte tutabilirsin” dediği alandır; birimi saniyedir.

Not: TTL, “azami önbellek süresini” belirtir — çözümleyiciler önbelleklerini erken temizleyebilir ama süreyi asla uzatamaz. Bu yüzden yetkili TTL 1 saat olsa bile bazı çözümleyiciler 10 dakika sonra yeniden sorgulayabilir.

Tuzak: IP değiştirmeden önce TTL'yi kısaltın (1-5 dakika) ve geçişi yapmadan önce eski TTL'nin tamamen dolmasını bekleyin — aksi halde bazı kullanıcılar bir saatten uzun süre eski IP'ye gitmeye devam eder.

6. DNS kayıt türleri hızlı başvuru

7. DNS optimizasyonu — çözümleme nasıl hızlandırılır?

7.1 Yakın bir özyinelemeli çözümleyici seçin

Çin anakarası: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) Çin içi siteleri en hızlı çözer. Diğer bölgeler: 1.1.1.1 (Cloudflare, en geniş anycast ağı) / 8.8.8.8 (Google). Ayrıntılar için:genel DNS çözümleyici dizini.

7.2 DoH kullanın (DNS-over-HTTPS)

DNS sorgularını HTTPS üzerinden şifrelemek, İSS'lerin bunları görmesini veya değiştirmesini engeller (NXDOMAIN yanıtlarının ele geçirilmesini önler). Chrome, Firefox ve Edge'in hepsi destekler — ayarlardan açmanız yeterli.

7.3 Önceden ısıtın (DNS Prefetch)

Sitenizin <head> bölümüne <link rel="dns-prefetch" href="//api.example.com"> ekleyin; tarayıcı boştayken adı önceden çözer — gerçek istek geldiğinde yanıt doğrudan önbellekten gelir.

7.4 CDN + Anycast NS kullanın

Yetkili NS'nizi Anycast üzerinde çalıştırın (Cloudflare / Route 53); böylece dünyanın her yerindeki kullanıcılar en yakın kopyaya ulaşır ve ③. adımın gecikmesi 100 ms'den 10 ms'ye iner.

7.5 TTL'yi akıllıca ayarlayın

Nadiren değişen kayıtlar (NS / MX) için uzun TTL (1-7 gün), değiştirilmesi gerekebilecek A kayıtları için kısa TTL (5-60 dakika) ayarlayın.

8. Sıkça sorulan sorular

8.1 DNS'i değiştirdim ama bir şey olmadı — neden?

Önce mevcut TTL'yi düşünün. DNS'i değiştirdikten sonra eski TTL dolana kadar tüm özyinelemeli çözümleyiciler eski IP'yi döndürmeye devam eder. “Küresel yayılım” genellikle TTL'nin yaklaşık 2 katı kadar sürer (çözümleyicilerin birbirleriyle senkron olmamasını hesaba katmak için).

• İstemci: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Genel özyinelemeli çözümleyicinin önbelleğinin dolmasını beklemek: 1.1.1.1 / 8.8.8.8 elle temizleme için kendi “purge” araçlarını sunar

8.2 Bazı kullanıcılar erişebiliyor, bazıları erişemiyor — DNS zehirlenmesi

Çin anakarasından Çin dışındaki sitelere erişirken sık görülür — GFW sahte DNS yanıtları enjekte eder / İSS'ler sorguları ele geçirir. DoH kullanmak (tarayıcıda şifreli DNS) DNS zehirlenmesinin büyük bölümünü atlatabilir.

8.3 Alan adını kaydettirdikten ne kadar sonra kullanabilirim?

Kayıttan sonra TLD kayıt kuruluşu (registry), NS kayıtlarınızı .com / .net vb. üst düzey yetkili sunuculara iletir — bu genellikle 15 dakika ile 24 saat sürer. .cn / .com.cn alan adlarının Çin anakarasında çözümlenebilmesi için ICP kaydı gerekebilir.