Sistem Mimarisi logo Sistem Mimarisi Bilişim Blogu
Reklam Alanı
Ağ Mimarisi
Ağ Mimarisi

DNS Nasıl Çalışır: Çözümleme Akışı, Zone Yapısı ve Kayıt Türleri

11 Haziran 2026 · 4 dk okuma · 30 okunma

DNS (Domain Name System), insan tarafından okunabilir alan adlarını (ör. sistemmimarisi.com) IP adreslerine çeviren, dağıtık ve hiyerarşik bir isim çözümleme sistemidir. Bir web sitesi yavaş açıldığında ya da mail gitmediğinde sorunun kökü çoğu zaman DNS katmanındadır — bu yüzden çözümleme akışını ve zone mimarisini adım adım anlamak, ağ mimarisi çalışan her mühendis için temel bir gerekliliktir.

Çözümleme Akışı: Bir Sorgu Kök Sunucudan Yanıta Nasıl Ulaşır?

İstemci tarayıcıya anasayfa.sistemmimarisi.com yazdığında, işletim sistemi önce yerel çözümleyiciye (stub resolver), o da genellikle ISS'nin ya da 1.1.1.1 / 8.8.8.8 gibi genel bir recursive resolver'ın önbelleğine bakar. Kayıt önbellekte yoksa resolver, zincirleme bir sorgu süreci başlatır:

DNS çözümleme akışı: istemci, recursive resolver, kök sunucular, TLD ve yetkili sunucu arasındaki sorgu zinciri
Recursive resolver, önbellekte yanıt yoksa kök sunucudan başlayarak yetkili sunucuya kadar iner.
  1. Kök sunucular (root servers): Resolver'a ".com uzantısından kim sorumlu" sorusunun yanıtını, yani ilgili TLD sunucularının adreslerini verir.
  2. TLD sunucusu (.com): sistemmimarisi.com için yetkili (authoritative) sunucunun adresini döner.
  3. Yetkili sunucu: Zone dosyasında tutulan gerçek A/AAAA kaydını döner — çözümleme burada tamamlanır.

Yanıt resolver tarafından, kayıtla birlikte gelen TTL (Time To Live) süresi kadar önbelleğe alınır. TTL kısa tutulursa (ör. 300 sn) DNS değişiklikleri hızlı yayılır ama yetkili sunucuya giden sorgu sayısı artar; uzun TTL (ör. 86400 sn) ise yükü azaltır ama bir kayıt değişikliğinin dünyaya yayılması saatler sürebilir. Sunucu taşıma veya IP değişikliği öncesi TTL'i 24-48 saat önceden düşürmek, kesinti riskini büyük ölçüde azaltır.

Primary/Secondary Zone Mimarisi ve Zone Transfer

Tek bir DNS sunucusu tek hata noktasıdır (single point of failure). Bu yüzden kurumsal ortamlarda zone, bir primary (birincil) sunucuda düzenlenir ve bir veya daha fazla secondary (yedek) sunucuya kopyalanır.

Primary ve secondary DNS zone mimarisi, zone transfer ve forward/reverse lookup zone örneği
SRV-DNS01 üzerinde düzenlenen zone, AXFR/IXFR ile TSIG imzalı olarak SRV-DNS02'ye aktarılır.
  • SOA (Start of Authority): Zone'un yetki bilgisini, seri numarasını ve yenileme/geçerlilik sürelerini tutar; secondary sunucu bu seri numarasına bakarak zone'un güncellenip güncellenmediğini anlar.
  • NS kayıtları: Zone için yetkili sunucuların listesini tanımlar.
  • Zone transfer (AXFR/IXFR): AXFR tüm zone'un tam kopyasını, IXFR ise yalnızca değişen kayıtları aktarır. Transferin TSIG (paylaşılan anahtarla mesaj imzalama) ile korunması, zone verisinin araya girme (MITM) veya yetkisiz transferle sızdırılmasını engeller.
  • Secondary sunucu salt okunurdur — kayıtlar burada değil, primary'de düzenlenir; ama primary çöktüğünde sorguları yanıtlamaya devam eder.

Forward ve Reverse Lookup Zone Farkı

Forward lookup zone, isimden IP'ye gider — www.sistemmimarisi.com için A 203.0.113.10 gibi. Reverse lookup zone ise tam tersini yapar: IP'den isme döner ve in-addr.arpa formatında tutulur (ör. 113.0.203.in-addr.arpa zone'unda 10 PTR www.sistemmimarisi.com).

; Basitleştirilmiş forward zone örneği (sistemmimarisi.com)
@       IN  SOA   srv-dns01. hostmaster.sistemmimarisi.com. ( 2026092701 3600 900 604800 300 )
@       IN  NS    srv-dns01.sistemmimarisi.com.
@       IN  NS    srv-dns02.sistemmimarisi.com.
www     IN  A     203.0.113.10
mail    IN  A     203.0.113.11
@       IN  MX 10 mail.sistemmimarisi.com.
Mail sunucuları için doğru PTR kaydı isteğe bağlı bir detay değil, operasyonel bir zorunluluktur: birçok alıcı mail sunucusu, giden sunucunun ileri (forward) ve ters (reverse) kaydının birbirini doğrulamasını (FCrDNS) arar. PTR eksik veya yanlışsa gönderilen postalar sessizce spam klasörüne düşer ya da doğrudan reddedilir.

Sık Yapılan Hatalar ve Öneriler

  • Tek sunucuya bağımlılık: En az bir primary + bir secondary, tercihen farklı ağ segmentinde veya sağlayıcıda barındırılmalı.
  • Aşırı uzun TTL ile planlanmamış taşıma: Sunucu/IP değişikliği öncesi TTL düşürülmeden yapılan taşımalar saatlerce karışık trafiğe (bazı istemciler eski IP'de) yol açar.
  • PTR kaydının unutulması: Özellikle yeni mail sunucusu kurulumlarında reverse zone genelde ISS/barındırma sağlayıcısı tarafından yönetilir — bu kaydı talep etmeyi unutmayın.
  • Zone transferin herkese açık bırakılması: AXFR isteğini IP bazlı kısıtlamadan (allow-transfer) ve TSIG'den yoksun bırakmak, tüm iç ağ haritanızın (subdomain envanteri) dışarı sızmasına yol açabilir.

İlgili Yazılar