Bir alan adının sunucu adresinin değiştiğini düşünün: evden yeni site açılırken telefonda hâlâ eski sunucuya bağlanılıyor. İki cihaz aynı adı yazsa bile farklı DNS önbelleklerinden geçiyorsa sonuçlar bir süre farklı olabilir. Sayfa yanıtlarını yeniden kullanan HTTP önbelleği ile bağlantı kurulacak adresi bulmaya yarayan DNS önbelleği farklı bilgileri saklar.
Ad çözümleme ile önbellek arasındaki ilişkiyi hayali bir kütüphane sunucusu olan www.library.example üzerinden inceleyeceğiz. Örnek ad ve zaman çizelgesi anlatım için oluşturulmuştur; gerçek bir hizmetin yanıtlarını ölçmedik. Amacımız DNS'in adresi nasıl verdiğini, değişikliklerin neden gecikmeli görünebildiğini ve ad çözümlendikten sonraki başarısızlıkları ayırmaktır.
1. Aynı ad için farklı türde yanıtlar vardır
DNS, alan adlarına bağlı bilgileri farklı kayıt türleriyle sunar. A kaydı IPv4, AAAA kaydı IPv6 adresini belirtir; bir adın birden fazla adresi olabilir. CNAME başka bir ada verilen takma addır, MX e-postayı alacak sunucuları, NS ise ilgili bölgenin yetkili ad sunucularını gösterir. Dolayısıyla aynı ad sorulsa da istenen kayıt türüne göre yanıt değişir.
Cloudflare'ın DNS kayıtları açıklamasında belirtildiği gibi CNAME değeri bir IP adresi değil, başka bir addır. Adres gerekiyorsa o adın çözümlenmesi devam edebilir. https://www.library.example/books adresinde DNS'in ele aldığı sunucu adı www.library.example'dır. /books yolu veya sayfa içeriği DNS'e kaydedilmez. CNAME ayarlamak, tarayıcının adres çubuğunu değiştiren bir HTTP yönlendirmesini kendiliğinden oluşturmaz.
2. Özyinelemeli çözümleyici yetkili sunucuyu nasıl bulur?
Cihazın ad çözümleme işlevi genellikle yapılandırılmış özyinelemeli çözümleyiciden yanıt ister. Çözümleyici gerekli bilgi önbellekte varsa onu kullanır; yoksa başka DNS sunucularına sorgular göndererek son yanıtı veya hatayı döndürür. DNS terimleri standardı RFC 9499, başkası adına çözümleme yapan rolü, kendi bölgesinin bilgilerini tutan yetkili sunucu rolünden ayırır. Yanıtın kaynağını anlamak için sunucunun hangi rolle yanıt verdiğine bakmak gerekir.
Önbellek ve aracı iletici bulunmayan basit bir akışta çözümleyici kökten üst düzey alan adının sunucularına, oradan hedef bölgenin yetkili sunucularına yönlendiren bilgiler alır. Son yetkili sunucudan istenen kayıt veya takma ad elde edilir. Tek bir kök sunucu tüm web sitelerinin IP adreslerini saklamaz. Gerçekte önceden saklanan yetki devri bilgileriyle başlanabilir ya da sorgu başka bir çözümleyiciye iletilebilir; bu yüzden her ziyarette bütün sıra mutlaka tekrarlanmaz.
3. TTL önbellekteki süredir, dünyanın ortak saati değildir
Bir kaydın TTL değeri önbellek ömrünü saniye cinsinden iletir. Normal önbellek yanıtlarında saklama süresi boyunca kalan süre azalır. Örneğin çözümleyici 10:00'da TTL değeri 300 saniye olan bir adresi saklarsa, aynı kopyanın 10:02'deki kalan TTL değeri yaklaşık 180 saniyedir. Aşağıdaki çizelge erken yeniden sorgulama, önceden yenileme veya süresi dolmuş veri sunma yapmayan tek bir çözümleyiciyi varsayar.
| Hayali saat | Yetkili sunucudaki adres | Bu çözümleyicinin işlemi |
|---|---|---|
| 10:00 | Eski adres | Eski adresi 300 saniyelik TTL ile saklar |
| 10:01 | Yeni adrese geçilir | Saklanan kopyada hâlâ 240 saniye vardır |
| 10:03 | Yeni adres | Kalan 120 saniye boyunca eski adresi kullanabilir |
| 10:05'ten sonraki ilk sorgu | Yeni adres | Süresi dolmuş kopya yerine yeniden sorgulayarak yeni adresi aldığı varsayılır |
Başka bir çözümleyici bu kaydı daha geç saklamış veya daha önce hiç görmemiş olabilir. Yenileme zamanları farklı olduğundan tek bir TTL, tüm dünyadaki kullanıcıların aynı anda değişeceği anı belirlemez. Önbellek veriyi süresi dolmadan da silebilir; web sayfasını yenilemek ortak çözümleyicinin önbelleğini temizlemez. TTL, DNS yanıtlarının yeniden kullanımını anlamaya yardımcı olur; web bağlantısının veya ekranın tümüyle güncellenmesinin zaman sınırı değildir.
4. TTL ne zaman düşürülmeli ve yokluk yanıtı nasıl saklanır?
Eski adresi 3.600 saniyelik TTL ile almış bir önbellek, işletmeci TTL'yi şimdi 60 saniyeye düşürse bile bundan anında haberdar olmaz. Planlanan adres değişikliğinde TTL önceden ayarlanmalı ve eski uzun ömürle saklanmış yanıtların ne kadar süre kalabileceği düşünülmelidir. Düşük TTL daha sık kontrol sağlayabilir, ancak sorgu yükünü ve yetkili sunuculara bağımlılığı da artırır. Her hizmete aynı kısa sayıyı uygulamak yerine değişiklik planını ve arıza yönetimini birlikte değerlendirin.
Adın bulunmadığını belirten NXDOMAIN ve ad var olduğu hâlde istenen kayıt türünün bulunmadığı NODATA durumu da önbelleğe alınabilir. Negatif önbellek standardı RFC 2308, yetkili SOA kaydının TTL değeri ile SOA içindeki MINIMUM alanından küçük olanını negatif yanıtın önbellek ömrü olarak tanımlar. Bu yüzden yeni bir sunucu adı eklendikten hemen sonra eski yokluk yanıtı hâlâ bulunabilir. Yalnızca yeni A kaydının TTL değerine bakmak, o negatif yanıtın ömrünü açıklamaz.
5. Aynı adı, kayıt türünü ve sunucuyu sabit tutarak karşılaştırın
Sorgulanan tam adı, A veya AAAA gibi kayıt türünü, sorgunun gönderildiği DNS sunucusunu ve saati birlikte kaydedin. dig kuruluysa dig example.com A gibi bir komut ad ve türü açıkça belirtir. Gerçek sorunu araştırırken example.com yerine incelemek istediğiniz sunucu adını kullanın. Bu komut bir işlem örneğidir; bu yazı için gerçekten çalıştırılmış bir komutun veya ölçülmüş yanıt süresinin kaydı değildir.
Yanıt durumunu ve ANSWER bölümündeki ad, tür, değer ve TTL'yi birlikte inceleyin. Aynı çözümleyiciye aynı sorguyu yeniden gönderince TTL'nin azalıp azalmadığına bakın; ancak artışı hemen hata saymayın. Veri önceden yenilenmiş veya başka bir önbellek düğümü yanıt vermiş olabilir. A ve AAAA sonuçlarını birbirine karıştırmadan ayrı kaydetmek, farkın hangi adres ailesinde olduğunu anlamayı kolaylaştırır.
İşletmeciler kullanılan özyinelemeli çözümleyicinin yanıtını, yönetilen bölgenin yetkili sunucusunun yanıtıyla aynı ad ve tür için karşılaştırabilir. Fark varsa sırasıyla önbellekte kalan süre, yetkili sunucular arasındaki veri tutarlılığı ve yetki devri ayarları kontrol edilebilir. Bir genel çözümleyicinin yanıtı bütün kullanıcıların durumunu temsil etmez. Şirket ağının iç DNS'i veya tarayıcının ayrı DNS ayarı sorgu yolunu değiştirebilir; bu nedenle bağlantı ortamını da karşılaştırma kaydına ekleyin.
6. DNS hatalarını, bağlantı hatalarını ve istisnaları ayırın
NXDOMAIN adın bulunmadığını bildirir; NODATA istenen kayıt türünün bulunmadığı durumu anlatır. SERVFAIL ise sunucunun sorguyu işleyemediğini, zaman aşımı da belirlenen bekleme süresi içinde yanıt alınmadığını gösterir. Bunların hepsini alan adının silindiği şeklinde yorumlamayın. Önce bir yanıt kodu gelip gelmediğini ve hangi sunucuya sorulduğunu kaydetmek, sonraki inceleme adımını belirlemeyi sağlar.
TTL geçtikten sonra eski yanıtı görmek her zaman kurala aykırılık değildir. RFC 8767'deki serve-stale yöntemi, yetkili sunucudan yenileme yapılamayan istisnai durumlarda kullanılabilirliği artırmak için süresi dolmuş bilginin kullanılmasını tanımlar. Bütün çözümleyiciler bunu aynı ayarlarla uygulamaz. Dolayısıyla değişikliğin ne zaman yansıyacağını tek bir TTL değerinden çıkarmak yerine gerçekten kullanılan çözümleyicinin davranışını kontrol edin.
Son olarak, bir adresin başarıyla çözümlenmesi web sitesine erişileceğini garanti etmez. O adrese giden ağ, TLS sertifikası, web sunucusu ve uygulama ayrı aşamalardır. DNS beklenen adresi veriyor ama sayfa açılmıyorsa incelemeyi sonraki bağlantı aşamasına taşıyın. DNS yanıtını ve web yanıtını ayrı kaydetmek, sayfa önbelleğini silmeden veya DNS ayarlarını gelişigüzel değiştirmeden önce başarısızlığın yerini daha doğru daraltır.