Authoritative ve Recursive DNS Farkı

DNS dünyasında en sık karıştırılan iki kavram vardır: recursive (çözümleyici) sunucu ve authoritative (yetkili) sunucu. İkisi de "DNS sunucusu" olarak anılır, ikisi de sorgu-cevap çalışır, ama görevleri birbirinden tamamen farklıdır. Recursive sunucu bir kurye gibidir; siz "clou.tr nerede?" diye sorduğunuzda cevabı bilmese bile kolları sıvar, doğru kaynağı bulana kadar birkaç sunucuyu dolaşır ve cevabı size getirir. Authoritative sunucu ise bir arşiv memuru gibidir; belirli bir alan adının kesin kayıtlarını elinde tutar ve yalnızca "kendi bölgesi" hakkında konuşur.

Bu ayrımı kavramak, DNS'in neden hızlı, dağıtık ve arıza toleranslı olduğunu anlamanın anahtarıdır. Bu rehberde iki sunucu tipinin ne iş yaptığını, bir alan adının kökten (root) TLD sunucusuna, oradan da yetkili sunucuya kadar uzanan sorgu zincirini adım adım, önbelleğin bu süreçteki kritik rolünü ve tüm bunları kendi terminalinizde dig ile nasıl gözlemleyeceğinizi gerçek örneklerle ele alacağız. DNS'in temel kayıt tiplerine henüz aşina değilseniz, önce DNS nedir yazımıza göz atıp buraya dönmenizi öneririz; burada işin "hangi sunucu ne yapar" tarafına odaklanacağız.

İki Sunucu Tipi, İki Ayrı Görev#

DNS'in tek bir dev veri tabanı olmadığını, milyonlarca alan adının sorumluluğunun hiyerarşik olarak dağıtıldığını hatırlayalım. Bu dağıtık yapının işlemesi için iki temel rol gerekir: cevabı arayan ile cevabı veren. Recursive sunucu arayan, authoritative sunucu verendir.

Bir benzetmeyle netleştirelim. Bir kütüphaneye gidip nadir bir kitabı sorduğunuzu düşünün. Danışma görevlisi (recursive) o kitabın nerede olduğunu ezbere bilmeyebilir; ama sistemi sorgular, önce genel bölümü, sonra ilgili rafı, sonunda tam kitabı bulur ve size teslim eder. Kitabın kendisini üreten ve "bu baskının kesin içeriği budur" diyen yayınevi ise authoritative kaynaktır. Danışma görevlisi hiçbir zaman kitabın içeriğine kendi kafasından karar vermez; yalnızca doğru kaynaktan alıp getirir.

Bu iş bölümü rastgele değildir. Recursive sunucular kullanıcıya yakın konumlanır (internet servis sağlayıcınızın altyapısında ya da 8.8.8.8, 1.1.1.1 gibi genel çözücülerde) ve tek işi, kullanıcıların sorularını en hızlı biçimde yanıtlamaktır. Authoritative sunucular ise alan adı sahibinin kontrolündedir; bir alan adının A, MX, TXT gibi kayıtlarının "resmî gerçeğini" barındırır. Bir kaydı değiştirdiğinizde onu authoritative sunucuda değiştirirsiniz; recursive sunucular o değişikliği er ya da geç arayıp öğrenir.

Recursive (Çözümleyici) Sunucu Ne Yapar?#

Recursive sunucunun tek amacı vardır: kendisine sorulan bir alan adı için, gerekiyorsa birden fazla sunucuyu dolaşarak nihai cevabı bulmak ve istemciye tek bir yanıt olarak dönmek. "Recursive" (özyinelemeli) adı buradan gelir — bir sorunun cevabını bulmak için gereken tüm ara sorguları kullanıcı adına o üstlenir. Kullanıcı yalnızca bir kez sorar; arkadaki tüm koşuşturmayı görmeden hazır cevabı alır.

Bir istemci recursive çözücüye sorduğunda, sorgu paketinde RD (Recursion Desired) bayrağı 1'dir; yani "bu işi sen hallet" der. Çözücü işini bitirip cevabı döndüğünde ise cevap paketinde RA (Recursion Available) bayrağı bulunur. Authoritative sunucular tam tersine özyineleme yapmaz; onlara tanımadıkları bir alan adını sorarsanız "burası benim bölgem değil" tarzında bir yanıt (referral veya ret) alırsınız.

Recursive sunucu, kullanıcı deneyiminin ilk milisaniyelerini belirlediği için performans açısından hayati önemdedir. İyi bir çözücü, sık sorulan kayıtları önbellekte tutarak aynı soruyu ikinci kez soranı kök sunuculara kadar yürütmez. Kendi sunucunuzda bir recursive çözücü çalıştırmak istediğinizde, tipik seçenekler unbound veya bind9'un recursive kipidir. Örneğin unbound için sade bir yapılandırma şöyle görünür:

# /etc/unbound/unbound.conf — sade bir recursive çözücü
server:
  interface: 127.0.0.1
  access-control: 127.0.0.0/8 allow
  # Önbellek TTL sınırları — çok kısa TTL'leri biraz uzat
  cache-min-ttl: 60
  cache-max-ttl: 86400
  # Yalnızca yerel ağa hizmet ver; açık çözücü olma
  do-ip6: no
  hide-identity: yes
  hide-version: yes

Buradaki en kritik kural, çözücünüzü açık (open resolver) bırakmamaktır: access-control ile yalnızca güvendiğiniz ağa hizmet vermelisiniz. Açık recursive çözücüler, DNS amplifikasyon saldırılarında kötüye kullanılan klasik hedeflerdir ve internete açık şekilde bırakmak hem sizi hem de başkalarını riske atar.

Authoritative (Yetkili) Sunucu Ne Yapar?#

Authoritative sunucu, bir veya daha fazla zone'un (DNS bölgesinin) resmî kayıtlarını barındıran ve o bölge hakkında kesin cevap veren sunucudur. ornek.com'un yetkili sunucusu, bu alan adının A, AAAA, MX, TXT, NS kayıtlarının "tek doğru kaynağı"dır. Bir recursive çözücü bu sunucuya ornek.com'un IP'sini sorduğunda, aldığı cevap tahmini ya da önbellekten değil, doğrudan kaynaktandır ve cevap paketinde AA (Authoritative Answer) bayrağı 1'dir.

Yetkili sunucular özyineleme yapmaz. Görevi cevabı gidip başka yerden bulmak değil, yalnızca kendi tuttuğu bölgeler hakkında konuşmaktır. Kendi bölgesinde olmayan bir şey sorulursa ya bir üst/alt yetkiye yönlendirme (referral) verir ya da hiç cevap vermez. Bu "dar kapsamlı ama kesin" tavır, DNS'in güvenilirliğinin temelidir: her kaydın net bir sahibi ve net bir kaynağı vardır.

Bir bölgenin yetkili kaynağını tanımlayan kayıt SOA (Start of Authority) kaydıdır; onu NS kayıtları izler ve bölgenin hangi sunucular tarafından yayınlandığını belirtir. Tipik bir yetkili zone dosyasının başı şöyledir:

$TTL 3600
@   IN  SOA  ns1.saglayici.com. hostmaster.ornek.com. (
             2026071001  ; seri numarası (her değişiklikte artır)
             7200        ; refresh
             3600        ; retry
             1209600     ; expire
             300 )       ; negatif önbellek TTL

@       IN  NS    ns1.saglayici.com.
@       IN  NS    ns2.saglayici.com.
@       IN  A     203.0.113.10
www     IN  CNAME ornek.com.
@       IN  MX 10 mail.ornek.com.

Genellikle bir bölgenin birden fazla yetkili sunucusu (ns1, ns2, hatta farklı ağlarda) bulunur. Bunlardan biri primary (master) olup kaydın düzenlendiği kaynaktır; diğerleri secondary (slave) olup zone'u primary'den zone transfer (AXFR/IXFR) ile kopyalar. Bu çokluk, tek bir yetkili sunucu çökse bile alan adının çözülmeye devam etmesini sağlar. Bir hosting ya da alan adı hizmeti aldığınızda, çoğu zaman yönetimi kolay bir panelle birlikte gelen bu yetkili sunucuları hosting paketlerimiz veya alan adı tarafında hazır bulursunuz.

Sorgu Zinciri Adım Adım — Kök, TLD ve Yetkili#

Şimdi iki sunucu tipini bir araya getirip tam bir çözümlemeyi izleyelim. Tarayıcınıza ilk kez blog.ornek.com yazdığınızı ve hiçbir yerde önbellek olmadığını varsayalım. Sorgu zinciri, recursive çözücünün üç kademeli yetkili hiyerarşiyi sırayla dolaşmasıyla ilerler:

1. İstemci → Recursive çözücü. Bilgisayarınız çözücüye sorar: "blog.ornek.com hangi IP'de?" Çözücünün önbelleğinde cevap yoksa arayışa başlar.
2. Recursive → Kök (root) sunucu. Çözücü bir kök sunucuya sorar. Kök sunucu cevabı bilmez ama ".com bölgesinden sorumlu TLD sunucuları şunlar" diyerek yönlendirir (referral). Kök sunucular a ile m arasında etiketli 13 mantıksal kümedir ve her biri anycast ile dünyaya yayılmış yüzlerce kopyadan oluşur.
3. Recursive → TLD sunucu. Çözücü bu kez .com TLD sunucusuna sorar. O da kesin cevabı vermez ama "ornek.com'un yetkili sunucuları ns1.saglayici.com ve ns2.saglayici.com" diyerek bir adım daha aşağı yönlendirir.
4. Recursive → Authoritative sunucu. Çözücü nihayet ornek.com'un yetkili sunucusuna sorar. Bu sunucu bölgenin sahibi olduğundan kesin cevabı verir: blog.ornek.com → 203.0.113.10, AA bayrağı 1.
5. Recursive → İstemci. Çözücü cevabı size döndürür ve TTL süresince önbelleğe alır.

Bu zincirdeki hiyerarşiyi bir tablo hâlinde görmek, "kim kime yönlendiriyor" mantığını netleştirir:

Dikkat edilecek nokta şudur: kök ve TLD sunucuları da birer authoritative sunucudur — ama yalnızca kendi katmanları için. Kök, TLD'lerin yetkilisidir; TLD, o uzantıdaki alan adlarının yetkilisidir. "Kesin cevap" her katmanda bir alt katmanın adresini vermek anlamına gelir; zincir, aradığınız alan adının kendi bölgesine ulaşana kadar sürer.

Önbelleğin Bu Süreçteki Rolü#

Yukarıdaki beş adımlık zincir, her ziyaret için baştan çalışsaydı internet dayanılmaz derecede yavaş olurdu. Neyse ki recursive çözücüler öğrendikleri her cevabı, kaydın TTL (Time To Live) değeri kadar süre önbellekte tutar. İlk sorgu birkaç yüz milisaniye sürerken, aynı kaydı soran ikinci kullanıcı çözücünün önbelleğinden neredeyse anında yanıt alır; kök ve TLD sunucuları hiç rahatsız edilmez.

Önbellek yalnızca nihai cevabı değil, ara adımları da kapsar. Çözücü bir kez .com TLD sunucularının adresini öğrendiğinde, o uzantıdaki başka bir alan adı sorulduğunda doğrudan TLD'ye atlar; kök adımını atlar. Benzer şekilde, bir bölgenin NS kayıtları da önbelleğe alınır. Bu katmanlı önbellekleme, DNS'in ölçeklenebilirliğinin temel sırrıdır: milyarlarca sorgunun büyük çoğunluğu, hiçbir zaman kök sunuculara kadar inmez.

Önbelleğin bir de "kalıcılık" yüzü vardır ve DNS değişikliklerinin neden hemen yansımadığını buradan anlarız. Bir kaydın IP'sini yetkili sunucuda değiştirseniz bile, o kaydı TTL dolmadan önce sorgulamış bir recursive çözücü, süre bitene kadar eski değeri döndürmeye devam eder. Bu yüzden IP değişikliği veya sunucu taşıma planlarken, değişiklikten birkaç gün önce ilgili kaydın TTL'ini düşürmek (örneğin 300 saniyeye) profesyonel bir alışkanlıktır. Bulunamayan kayıtlar da kısa süre "negatif önbelleğe" alınır (SOA kaydındaki minimum TTL bunu belirler). Bu mekanizmanın ayrıntılarını ve tıkanan bir önbelleği nasıl temizleyeceğinizi DNS önbellek temizleme rehberimizde adım adım anlatıyoruz.

Recursive ve Authoritative Karşılaştırması#

İki sunucu tipinin farklarını tek bir tabloda toplamak, kavramı kalıcı hâle getirir. Aşağıdaki karşılaştırma, günlük hayatta hangi sunucuyla neden uğraştığınızı anlamanıza yardımcı olur:

Pratikte bir bilgisayar/telefon her zaman bir recursive çözücüye konuşur; authoritative sunucularla doğrudan konuşan taraf, sizin adınıza koşuşturan o recursive çözücüdür. Son kullanıcı olarak 1.1.1.1 veya 8.8.8.8 gibi bir çözücü ayarlarsınız; alan adı sahibi olarak ise authoritative tarafı (NS kayıtları ve zone içeriği) yönetirsiniz. İkisi farklı katmanlardır ve karıştırıldıklarında "DNS ayarımı değiştirdim ama site hâlâ eskisini gösteriyor" gibi kafa karışıklıkları doğar — ki bunun nedeni genellikle recursive tarafın önbelleğidir, authoritative tarafın hatası değil.

dig ile Farkı Kendiniz Görün#

Teoriyi somutlaştırmanın en iyi yolu, farkı kendi terminalinizde gözlemlemektir. dig (Linux/macOS) ile hem recursive hem authoritative davranışı ayrı ayrı test edebilirsiniz. Önce klasik recursive sorgu — çözücüden cevabı bulmasını isteriz:

# Recursive sorgu: çözücü tüm zinciri gezip cevabı getirir
dig @1.1.1.1 blog.ornek.com A

# Zinciri kökten yetkiliye kadar adım adım izle
dig +trace ornek.com

# Sorgu süresini ve hangi sunucunun cevapladığını gör
dig @8.8.8.8 ornek.com A +stats

Şimdi authoritative tarafı test edelim. Doğrudan bir yetkili sunucuya sorduğumuzda, cevabın "kaynaktan" geldiğini bayraklardan anlarız. +norecurse ile çözücüye "kendin dolaşma" deriz; authoritative bir sunucu buna zaten yetkili cevap verir, recursive bir çözücü ise yalnızca önbelleğindekini döner:

# Doğrudan yetkili sunucuya sor — cevapta "aa" bayrağını ara
dig @ns1.saglayici.com ornek.com SOA

# Özyineleme istemeden sor; yetkili sunucu yine kesin cevap verir
dig @ns1.saglayici.com ornek.com A +norecurse

# Bir alan adının yetkili sunucularını (NS) öğren
dig ornek.com NS +short

Cevabın flags: satırına bakın. Bir authoritative sunucudan gelen yanıtta aa (authoritative answer) bayrağını görürsünüz; bir recursive çözücüden gelen normal yanıtta ise ra (recursion available) bayrağı bulunur ama aa bulunmaz. Bu tek satır, elinizdeki cevabın "kaynaktan" mı yoksa "önbellekten/dolaşarak" mı geldiğini kesin biçimde söyler:

# Authoritative cevap (dig @ns1 ... çıktısından)
flags: qr aa rd        ; aa = authoritative answer VAR

# Recursive çözücü cevabı (dig @1.1.1.1 ... çıktısından)
flags: qr rd ra        ; ra = recursion available, aa YOK

Bir kaydı değiştirdikten sonra "yayıldı mı" diye kontrol ederken, en sağlam yöntem doğrudan authoritative sunucuya sormaktır (dig @ns1 ...): orada yeni değeri görüyorsanız kaynak güncel demektir, gecikmenin nedeni yalnızca recursive çözücülerin önbelleğidir ve TTL dolunca kendiliğinden düzelir.

Kendi Yetkili Sunucunuzu Çalıştırmak#

Çoğu kullanıcı authoritative sunucuyu hosting ya da alan adı sağlayıcısından hazır alır; ama işleyişi tam kavramak veya özel senaryolar (kendi anycast ağınız, iç ağ bölgeleri) için kendi yetkili sunucunuzu kurmak isteyebilirsiniz. En yaygın seçenek BIND9'dur. Yetkili kipte çalışan bir BIND yapılandırmasının çekirdeği şöyledir:

# named.conf.local — ornek.com için yetkili (master) bölge
zone "ornek.com" {
    type master;
    file "/etc/bind/zones/db.ornek.com";
    allow-transfer { 198.51.100.53; };   # secondary sunucuya izin
    notify yes;                           # değişince secondary'yi uyar
};

Buradaki type master, bu sunucunun bölgenin birincil yetkili kaynağı olduğunu söyler. allow-transfer yalnızca güvendiğiniz secondary sunucuya zone kopyalamasına izin verir — internete açık zone transferi bir bilgi sızıntısıdır ve mutlaka kısıtlanmalıdır. Değişiklik yaptığınızda notify yes sayesinde secondary sunucular haberdar olur ve IXFR ile yalnızca değişen kayıtları çeker.

Kurulumu doğrularken iki şeye bakın: yapılandırma söz dizimi ve bölgenin doğru yüklenip yüklenmediği. BIND bunun için hazır araçlar sunar:

# Genel yapılandırmayı denetle
named-checkconf

# Zone dosyasını söz dizimi + tutarlılık açısından denetle
named-checkzone ornek.com /etc/bind/zones/db.ornek.com

# Servisi yeniden yükle ve yerelden yetkili cevabı test et
systemctl reload bind9
dig @127.0.0.1 ornek.com SOA +norecurse

Üretimde tek bir yetkili sunucuyla yetinmemek önemlidir: farklı ağlarda en az bir secondary bulundurmak, DNS'in tek arıza noktasına dönüşmesini engeller. DNS altyapısı DDoS saldırılarının favori hedefidir; çünkü authoritative sunucularınız düşerse, arka plandaki web sunucusu sapasağlam olsa bile kimse alan adınızı IP'ye çeviremez ve site "ölmüş" görünür. Bu yüzden kendi yetkili sunucularınızı çalıştıracaksanız, onları bir VDS sunucu üzerinde dağıtık kurmayı ve önüne DDoS koruma katmanı eklemeyi ihmal etmeyin; yönetim yükünü devretmek isterseniz sunucu yönetimi hizmetimiz bu kurulumu sizin adınıza sürdürür.

Sıkça Sorulan Sorular#

Recursive ve authoritative DNS arasındaki en temel fark nedir?#

Recursive sunucu cevabı bilmediğinde onu sizin adınıza arayıp getiren "kurye", authoritative sunucu ise belirli bir alan adının kesin kayıtlarını tutan "kaynak"tır. Recursive çözücü kök, TLD ve yetkili sunucular arasında dolaşarak nihai cevaba ulaşır ve sonucu önbelleğe alır; authoritative sunucu ise yalnızca kendi bölgesi hakkında, doğrudan kaynaktan ve aa bayrağı ile kesin cevap verir. Kısacası biri arar, diğeri söyler.

Bilgisayarım hangi sunucu tipiyle konuşur?#

Bilgisayarınız ya da telefonunuz her zaman bir recursive çözücüyle konuşur; authoritative sunucularla doğrudan iletişim kurmaz. Ağ ayarlarınızdaki DNS adresi (örneğin 1.1.1.1 veya ISP'nizin sunucusu) bir recursive çözücüdür. O çözücü, arka planda kök, TLD ve yetkili sunucuları sizin yerinize gezer ve size tek bir hazır cevap döndürür. Yani zincirin karmaşık kısmını görmezsiniz; yalnızca sonucu alırsınız.

Bir sunucu hem recursive hem authoritative olabilir mi?#

Teknik olarak mümkündür ama günümüzde şiddetle önerilmez. Aynı sunucuyu her iki role birden koymak, "önbellek zehirleme" ve açık çözücü suistimali gibi güvenlik risklerini artırır; ayrıca yük profilleri farklı olduğu için performans yönetimini zorlaştırır. İyi bir pratik, authoritative sunucuları yalnızca yetkili kipte (özyineleme kapalı) çalıştırmak, recursive çözümlemeyi ise ayrı, erişimi kısıtlı sunuculara bırakmaktır. BIND gibi yazılımlar bu ayrımı recursion no; gibi direktiflerle yapmanıza izin verir.

DNS kaydımı değiştirdim ama neden hemen görünmüyor?#

Çünkü değişikliği yetkili (authoritative) sunucuda yaptınız, ama dünyadaki recursive çözücüler eski değeri hâlâ önbelleğinde tutuyor olabilir. Bir çözücü, kaydı önceki TTL süresi boyunca yeniden sormadan eski cevabı döndürmeye devam eder. En doğru kontrol, doğrudan yetkili sunucuya dig @ns1.saglayici.com alanadi.com A ile sormaktır; orada yeni değer görünüyorsa kaynak güncel demektir ve beklemeniz gereken tek şey recursive önbelleklerin TTL süresince tazelenmesidir.

Kök ve TLD sunucuları da authoritative midir?#

Evet, ama yalnızca kendi katmanları için. Kök sunucular TLD'lerin (yani .com, .tr, .org gibi uzantıların) yetkilisidir ve "bu uzantının sunucuları şunlar" bilgisini kesin olarak verir. TLD sunucuları ise o uzantı altındaki alan adlarının yetkilisidir ve "bu alan adının NS kayıtları şunlar" der. İkisi de kesin cevap verir ama bu cevap, aradığınız alan adının IP'si değil, zincirin bir alt katmanına yönlendirmedir. Nihai IP'yi yalnızca alan adının kendi authoritative sunucusu verir.

Açık (open) recursive çözücü neden tehlikelidir?#

Açık recursive çözücü, internetteki herkesin sorgu yapabildiği, erişimi kısıtlanmamış bir çözücüdür ve DNS amplifikasyon saldırılarında silah olarak kullanılır. Saldırgan, kurbanın IP'sini kaynak gösterip küçük bir sorgu gönderir; çözücü büyük bir cevabı kurbana yollar ve trafiği kat kat büyütür. Bu yüzden bir recursive çözücü çalıştırıyorsanız, access-control ya da güvenlik duvarı kurallarıyla yalnızca kendi güvendiğiniz ağınıza hizmet vermeli, çözücüyü asla tüm internete açık bırakmamalısınız.

Kapanış#

Recursive ve authoritative DNS, aynı adı taşımalarına rağmen birbirinin tamamlayıcısı iki ayrı rolü üstlenir: biri cevabı arayan çözümleyici, diğeri cevabın kesin kaynağı olan yetkili sunucu. Bir sorgunun kökten TLD'ye, oradan yetkili sunucuya uzanan zincirini ve bu zinciri hızlandıran önbellek mantığını kavradığınızda, "DNS değiştim ama yansımadı" gibi gündelik sorunları tereddütsüz teşhis eder, dig ile hangi katmanda ne olduğunu net biçimde okursunuz. Bu ayrım, ileri konuların — DNSSEC, anycast, yük devretme — hepsinin oturduğu temeldir.

Alan adınızın yetkili DNS'ini sağlam, yönetimi kolay bir altyapıya taşımak isterseniz hosting paketlerimiz ve alan adı hizmetlerimiz işi baştan doğru kurar; kendi yetkili sunucularınızı çalıştıracaksanız VDS sunucu ve sunucu yönetimi çözümlerimizle dağıtık, dayanıklı bir DNS mimarisini birlikte oturtabiliriz. Doğru katmanda doğru sunucuyu konumlandırmak, hızlı ve kesintisiz bir internet varlığının ilk adımıdır.