DNS Nasıl Çalışır: Özyinelemeli Çözümleme, Önbellek ve TTL'ler, Diyagramla

Bir A kaydını değiştirir, dig çalıştırır ve yeni adresi görürsünüz. Başka bir ofisteki iş arkadaşınız bir saat sonra hâlâ eskisini alır. Yeni bir alt alan adı sizde çalışır, bir müşteride NXDOMAIN döner. Bunların hiçbiri rastgele değildir: DNS çözümlemesinin ve önbelleğin nasıl çalıştığından kaynaklanır ve bir sorgunun izlediği yolu çizebildiğinizde bunu öngörebilirsiniz.

Bu yazı tek bir sorguyu tarayıcıdan yetkili sunucuya ve geri, bir diyagramla izliyor; ardından TTL'leri, negatif önbelleği, delegasyonu, taşıma katmanını ve üretimde karşılaşacağınız arıza biçimlerini ele alıyor.

Her sorgudaki dört rol

Bir sorgu en fazla dört tür sunucuya uğrar. Her biri yanıtın farklı bir parçasını bilir.

Root tek bir makine değildir. root-servers.org verilerine göre Kasım 2026 itibarıyla, a ile m.root-servers.net arasında 13 root sunucusu kimliği vardır; bunları 12 bağımsız kuruluş işletir ve anycast onları dünya genelinde 2.000'den fazla örneğe yayar.

Adım adım bir sorgu

Tarayıcınızın app.example.com adresine ihtiyacı olduğunu ve hiçbir yerde hiçbir şeyin önbellekte olmadığını varsayalım:

1. Tarayıcı kendi önbelleğine bakar, ardından işletim sisteminin stub çözümleyicisine sorar.
2. Stub, yapılandırılmış özyinelemeli çözümleyiciye “recursion desired” bayrağıyla bir sorgu gönderir: app.example.com için A kaydı nedir?
3. Çözümleyicinin önbelleğinde hiçbir şey yoktur, bu yüzden bir root sunucusuna sorar. Root yanıtı bilmez ama com bölgesini kimin işlettiğini bilir; bu yüzden bir yönlendirme (referral) döndürür: com için NS kayıtları ve bunların adresleri (glue).
4. Çözümleyici bir com TLD sunucusuna sorar; o da başka bir yönlendirme döndürür: example.com için ad sunucuları.
5. Çözümleyici bu yetkili sunuculardan birine sorar; o da yanıtı döndürür: app.example.com. 300 IN A 203.0.113.10.
6. Çözümleyici öğrendiği her kaydı TTL'i boyunca önbelleğe alır ve yanıtı stub'a döndürür; stub da onu tarayıcıya iletir.

Stub özyinelemeli bir sorgu yapar: Nihai bir yanıt ister. Çözümleyici yinelemeli sorgular yapar: Her sunucu ya yanıtı ya da yanıta daha yakın birine işaret eden bir yönlendirmeyi döndürür. Root ve TLD sunucuları sizin için asla yanıt peşine düşmez.

Yinelemeli kısmı, çözümleyicinizin önbelleğini kullanmak yerine root'tan başlayan dig +trace ile izleyebilirsiniz (çıktı kısaltılmıştır):

$ dig +trace app.example.com
.                  518400  IN  NS  a.root-servers.net.
com.               172800  IN  NS  a.gtld-servers.net.
example.com.       172800  IN  NS  ns1.example.net.
app.example.com.   300     IN  A   203.0.113.10

Modern çözümleyiciler ayrıca QNAME minimizasyonu (RFC 9156) uygular: Root'a yalnızca com hakkında, TLD'ye yalnızca example.com hakkında soru sorarlar; böylece yukarıdaki sunucular sorguladığınız tam adı hiç görmez.

Önbellek ve TTL'ler

Her kayıt saniye cinsinden bir yaşam süresi (TTL) taşır. app.example.com kaydını 300 TTL ile önbelleğe alan bir çözümleyici, sonraki beş dakika boyunca geri sayarak önbellekten yanıt verir ve ancak ondan sonra yetkili sunucuya yeniden sorar. Tarayıcılar ve işletim sistemleri bunun üzerine kendi kısa önbelleklerini tutar.

İnsanların yayılma (propagation) dediği şey budur. Bir kaydı değiştirdiğinizde hiçbir yere hiçbir şey itilmez. Eski değeri önbelleğe alan her çözümleyici, kopyasının süresi dolana kadar onu sunmaya devam eder; bu yüzden en kötü durum yeni TTL değil, kabaca eski TTL'dir. Çözümleyiciler çok uzun TTL'leri de kırpar: Örneğin Unbound, önbellekteki kayıtları varsayılan olarak bir günle sınırlar.

Değişiklikler için pratik kurallar:

• Planlı bir değişiklikten önce TTL'i düşürün. Bir kaydın TTL'i 86400 ise, taşımadan en az bir gün önce 300'e çekin, eski TTL'in geçmesini bekleyin, değişikliği yapın, sonra yeniden yükseltin.
• Kısa TTL'leri yalnızca hızlı failover'a ihtiyaç duyduğunuz yerde kullanın. 60 saniyelik bir TTL, sağlayıcınıza daha fazla sorgu ve kullanıcılar için daha fazla önbellek ıskalaması demektir; her ıskalama tam bir sorgu maliyetindedir.
• Ad sunucularını değiştirmek daha yavaştır. Üst bölgedeki example.com NS kayıtlarının kendi TTL'i vardır; com içinde bu 172800 saniyedir (iki gün) ve onu kısaltamazsınız.

DNS tabanlı failover bu rakamlara bağlıdır. AWS çok bölgeli mimari diyagramı ve felaket kurtarma mimari diyagramı, sağlık kontrolü yapılan bir DNS kaydının nereye oturduğunu ve TTL'inin neden kurtarma sürenizi sınırladığını gösteriyor.

Negatif önbellek: NXDOMAIN tuzağı

Çözümleyiciler “yok” yanıtını da önbelleğe alır. Bir ad bulunmadığında yetkili sunucu, bölgenin SOA kaydıyla birlikte NXDOMAIN döndürür ve çözümleyici bu negatif yanıtı SOA kaydının TTL'i ile MINIMUM alanından küçük olanı kadar önbelleğe alır (RFC 2308).

Klasik arıza şöyledir: Biri kayıt oluşturulmadan önce api.example.com adresini sorgular, bir çözümleyici NXDOMAIN'i bir saatliğine önbelleğe alır, siz kaydı oluşturursunuz ve o çözümleyici bir saat dolana kadar kaydın olmadığını söylemeye devam eder. Yeni bir ana bilgisayar adını duyurmadan önce negatif TTL'i dig example.com SOA ile kontrol edin ve kayıtları herkes test etmeden önce oluşturun.

Delegasyon, glue ve topal sunucular

Bir bölge DNS'te, üst bölgesi onu delege ettiği için vardır. com bölgesi, example.com için hangi sunucuların yetkili olduğunu söyleyen NS kayıtlarını tutar. Bu ad sunucuları ns1.example.com gibi hizmet ettikleri bölgenin içinde yaşıyorsa, üst bölge onların adreslerini de glue kayıtları olarak tutar; aksi hâlde çözümleyiciler onları bulamazdı.

Delegasyon iki yaygın şekilde bozulur. Topal delegasyon (lame delegation), üst bölgenin artık o bölgeye hizmet vermeyen bir sunucuyu göstermesidir; çoğu zaman bir sağlayıcı taşımasından sonra olur ve bazı kullanıcılarda zaman aşımlarına ya da SERVFAIL'e yol açar. Üst bölgedeki NS kayıtları ile bölgenin içindekiler arasındaki uyumsuzluk ise davranışı, bir çözümleyicinin hangi seti önbelleğe aldığına bağlı hâle getirir.

Taşıma ve gizlilik

DNS trafiğinin çoğu 53 numaralı porttan UDP'dir. Sığmayan yanıtlar kesilme (truncation) bayrağını ayarlar ve istemci TCP üzerinden yeniden dener; bu yüzden TCP 53 portu da açık olmalıdır. DNS Flag Day 2020'den beri büyük DNS yazılımları, IP parçalanmasını önlemek için varsayılan olarak 1.232 baytlık bir EDNS tampon boyutu kullanır; bu da DNSSEC imzalı kayıtlar gibi büyük yanıtlar için TCP'ye geri dönmeyi daha yaygın hâle getirir.

Klasik DNS şifresizdir. DNS over TLS (853 numaralı port), DNS over HTTPS ve DNS over QUIC, stub ile özyinelemeli çözümleyici arasındaki adımı şifreler; çözümleyiciden root, TLD ve yetkili sunuculara giden adımlar ise hâlâ çoğunlukla düz metindir.

DNSSEC farklı bir sorunu çözer: gizliliği değil, özgünlüğü. Her bölge kendi kayıtlarını imzalar ve üst bölge, doğrulayan çözümleyicilerin güvendiği root anahtarına kadar alt bölgenin anahtarına kefil olur. Root bölgesi 11 Ekim 2026'da yeni bir anahtar imzalama anahtarına, KSK-2024'e geçişi tamamladı. Yeni güven çapasını hiç almamış doğrulayan bir çözümleyici her sorguda SERVFAIL ile başarısız olur.

Sorgular başarısız olduğunda

Yetkili sunucuya dig @ns1.example.net app.example.com ile doğrudan sormak size gerçeğin ne olduğunu söyler; bir çözümleyiciye sormak ise kullanıcıların ne gördüğünü.

DNS çözümleme diyagramı

Nasıl okunur:

• Dizüstü bilgisayardan başlayın. Stub çözümleyicisi çözümleyiciye tek bir özyinelemeli sorgu gönderir (1. adım) ve tek bir yanıt alır (8. adım).
• Dolaşmayı çözümleyici yapar. 2. ile 7. adımlar yinelemeli sorgulardır: Root ve com sunucuları yönlendirme döndürür, example.com için yetkili sunucu kaydı döndürür.
• TTL'ler yanıtların üzerindedir. A kaydı 300 saniyelik bir TTL ile döner; çözümleyici onu yeniden sormadan bu kadar süre kullanır.
• Çerçeve, sizin işletmediğiniz hiyerarşiyi gruplar; istisnası sizin ya da DNS sağlayıcınızın olan yetkili sunucudur.
• Markdown bloğu önbellek katmanlarını ve bir değişikliğin kullanıcılara ne kadar hızlı ulaştığını belirleyen TTL'leri listeler.

Gerçek sorulara cevap veren DNS diyagramları çizmek

• Adımları numaralandırın. DNS soruları sırayla ilgilidir: kim kime soruyor ve ne zaman yanıtı önbellek veriyor.
• Özyinelemeli trafiği yinelemeliden ayırın. İstemciden bir sorgu, çözümleyiciden birkaç sorgu. İkisi aynı görünüyorsa diyagram en önemli fikri gizler.
• TTL'leri yanıtların üzerine yazın. Yayılmayı bir paragraftan daha iyi açıklarlar.
• Sahipliği gösterin. Hangi sunucuları kontrol ettiğinizi işaretleyin. Bir olay sırasında kimi arayacağınızı bu belirler.
• Kayıt değişikliğini ayrı bir diyagram olarak çizin. TTL'in düşürüldüğü, geçişin yapıldığı ve TTL'in yeniden yükseltildiği bir taşıma zaman çizelgesi, sorgu diyagramı üzerindeki notlardan daha anlaşılırdır.

Asıl önemli olan mesajların sırasıysa, çözümleyicinin ve her sunucunun yaşam çizgisi olduğu bir sekans diyagramı da işe yarar. Fiziksel taraf, yani çözümleyicilerin ağınızda nerede durduğu için ağ topolojisi diyagramı rehberine bakın.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Dizüstü bilgisayar için Ağ paketinden bir Cihaz düğümü, özyinelemeli çözümleyici için de bir DNS düğümü ekleyin.
3. DNS hiyerarşisi için adlandırılmış bir Temel Çerçeve ekleyin ve içine üç DNS düğümü daha koyun: root, com TLD ve example.com için yetkili sunucu.
4. Tarayıcının sorgudan sonra bağlandığı ana bilgisayar olan app.example.com için Ağ paketinden bir Sunucu düğümü ekleyin.
5. Kenarları sırayla çizin ve etiketlerini numaralandırın: istemcinin sorgusu ve yanıtı, ardından çözümleyici ile her sunucu arasında bir sorgu ve bir yanıt. TTL'i son yanıtın üzerine yazın.
6. Önbellek katmanları ve TTL kurallarıyla Temel paketinden bir Markdown bloğu ekleyin.

Örnek 8 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

DNS yayılması ne kadar sürer? Eski kaydı önbelleğe alan her çözümleyici için, eski kaydın TTL'ine kadar. Hiçbir şey itilmez; önbelleklerin süresi dolar. Ad sunucusu değişiklikleri daha uzun sürer, çünkü üst bölgenin NS kayıtlarının kendi TTL'i vardır; com içinde bu iki gündür.

Özyinelemeli ve yetkili DNS sunucusu arasındaki fark nedir? Özyinelemeli çözümleyici, istemciler adına yanıtları bulur ve önbelleğe alır. Yetkili sunucu ise bir bölgenin kayıtlarını tutar ve yalnızca o bölge için yanıt verir.

Bir kaydı değiştirdikten sonra neden hâlâ eski IP adresini görüyorum? Sizinle yetkili sunucu arasındaki bir önbellek eski kaydı hâlâ tutuyor: tarayıcınız, işletim sisteminiz ya da çözümleyiciniz. Değişikliği doğrulamak için yetkili sunucuyu doğrudan sorgulayın, sonra TTL'in dolmasını bekleyin.

Çok düşük bir TTL sorun mudur? DNS sağlayıcınıza daha fazla sorgu ve kullanıcılar için daha fazla tam sorgu demektir; bu da önbellek ıskalamalarında gecikme ekler. Failover yapmanız gerekebilecek kayıtlar için düşük, kararlı kayıtlar için daha uzun TTL'ler kullanın.

DNS trafiği şifreli midir? Varsayılan olarak hayır. DNS over TLS, HTTPS ya da QUIC, cihazınız ile çözümleyici arasındaki adımı şifreler. DNSSEC kayıtların özgün olduğunu kanıtlayan imzalar ekler, ama hiçbir şeyi şifrelemez.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.