Alan Hattı editoryal ekibi ·
Bir alan adının IP adresini, e-posta sunucusunu ya da nameserver bilgisini değiştirdiğinizde sonuç bütün dünyada tek bir düğmeye basılmış gibi aynı anda yenilenmez. Günlük dilde buna “DNS yayılımı” denir. Gerçekte merkezden kenarlara kopyalanan tek bir veri paketi yoktur: özyinelemeli DNS çözümleyicileri daha önce aldıkları cevapları kayıt üzerindeki TTL süresi boyunca önbellekte tutar, süre dolduğunda yetkili sunucudan yeniden sorar. Bu ayrım önemlidir; çünkü yalnızca “bekleyin” demek, yanlış kaydı veya tutarsız nameserver'ı gözden kaçırabilir.
Önce DNS zincirini doğru okuyun
Tarayıcı alan adını doğrudan barındırma sunucusuna sormaz. Cihaz çoğunlukla internet sağlayıcısının, kurumun ya da kullanıcının seçtiği bir çözümleyiciye başvurur. Çözümleyici elinde geçerli bir önbellek yoksa kök, üst düzey alan adı ve yetkili nameserver zincirini izleyerek cevabı bulur. Alan adının DNS bölgesindeki A, AAAA, CNAME, MX veya TXT kaydı asıl kaynak; çözümleyicide tutulan kopya ise süreli bir cevaptır.
TTL, kaydın saniye cinsinden ne kadar süre önbellekte tutulabileceğini belirtir. Örneğin TTL değeri 3600 olan bir A kaydı yaklaşık bir saat saklanabilir. Ancak değişiklikten hemen önce sorgu yapan çözümleyicinin elinde neredeyse tam süreli eski cevap varken, başka bir çözümleyicinin önbelleği az sonra bitebilir. Bu nedenle farklı ağlarda geçiş anı aynı olmaz. Tarayıcı, işletim sistemi ve yerel ağ cihazları da kısa süreli ek önbellekler kullanabilir.
“48 saat sürer” kuralı neden tek başına yeterli değil?
DNS değişiklikleri için sıkça 24–48 saatlik sabit bir süre söylenir; oysa gerçek bekleme, eski kaydın TTL değerine, değişikliğin türüne ve yetkili sunucuların tutarlılığına bağlıdır. TTL 300 saniyeyse birçok çözümleyici birkaç dakika içinde yeni cevabı alabilir. Nameserver delegasyonu değişikliği ise üst bölgedeki NS ve glue kayıtları da devreye girdiği için daha uzun ve farklı davranabilir. Ayrıca TTL'yi değişiklikle aynı anda düşürmek, daha önce önbelleğe alınmış yüksek TTL'li cevabı geriye dönük olarak kısaltmaz.
Adım adım DNS yayılımı teşhisi
1. Değişikliği doğru DNS bölgesinde yaptığınızı doğrulayın
İlk olarak alan adının gerçekten hangi nameserver'ları kullandığını kontrol edin. Kayıt kuruluşunun panelindeki nameserver listesi ile DNS kaydını düzenlediğiniz sağlayıcı aynı hizmeti göstermiyorsa yaptığınız değişiklik internete hiç sunulmayabilir. Alan Hattı domain sorgulamasında görünen NS kayıtlarını panelinizdeki değerlerle karşılaştırın. Bir sağlayıcıdan diğerine geçerken eski panelde değişiklik yapmak yaygın bir hatadır.
2. Yetkili sunucuyu doğrudan sorgulayın
Önbellek etkisini ayırmak için yetkili nameserver'a doğrudan sorun. Komut satırında örneğin dig @ns1.ornek.net www.ornek.com A kullanılabilir. Windows'ta nslookup www.ornek.com ns1.ornek.net benzer amaçla çalışır. Her yetkili sunucuyu ayrı ayrı test edin. Biri yeni IP'yi, diğeri eski IP'yi döndürüyorsa sorun “yayılım” değil, DNS sağlayıcısındaki bölge eşitlemesi veya ikincil sunucu aktarımıdır.
3. Birden fazla çözümleyiciyi karşılaştırın
Yetkili cevap doğruysa Google Public DNS, Cloudflare ya da internet sağlayıcınız gibi farklı özyinelemeli çözümleyicilerden sonuç alın. Alan Hattı'nın DNS Yayılımı aracını kullanarak sonuçları yan yana görebilirsiniz. Farklı cevaplar ve azalan TTL değerleri, eski önbelleklerin henüz sona ermediğini gösterebilir. Tek bir konum etiketi “o ülkedeki herkes” anlamına gelmez; ölçüm yalnızca kullanılan çözümleyicinin o andaki cevabıdır.
4. Kayıt türünü ve ana bilgisayar adını karıştırmayın
ornek.com ile www.ornek.com ayrı adlardır. Kök alan adındaki A kaydını değiştirmek, www alt alanındaki CNAME kaydını otomatik değiştirmez. E-posta için MX kaydını, doğrulama için TXT kaydını, IPv6 için AAAA kaydını ayrıca sorgulayın. Eski IPv6 kaydı kalırsa bazı kullanıcılar yeni IPv4 adresi doğru olmasına rağmen eski sunucuya gidebilir.
5. Yerel önbelleği ve uygulama katmanını ayırın
Yetkili ve genel çözümleyici cevapları yeni olduğu hâlde yalnızca bir cihazda eski site açılıyorsa işletim sistemi DNS önbelleğini yenileyin, tarayıcıyı tamamen kapatıp açın ve farklı bir ağda deneyin. Ancak önbellek temizleme, yetkili DNS'teki hatayı düzeltemez. Ayrıca CDN, ters proxy, yük dengeleyici ve web sunucusunun sanal ana bilgisayar ayarları doğru değilse DNS yeni IP'yi gösterse bile yanlış içerik ya da sertifika görülebilir.
Pratik senaryo: siteyi yeni sunucuya taşıma
Örneğin www.ornek.com 192.0.2.10 adresinden 198.51.100.20 adresine taşınsın. Önce yeni sunucuda siteyi ve TLS sertifikasını hazırlayın. Planlanan geçişten önce A kaydının TTL'sini düşürün ve bu düşük değerin eski önbelleklerde geçerli hâle gelmesi için yeterince bekleyin. Geçiş anında A kaydını değiştirin, bütün yetkili nameserver'ların 198.51.100.20 döndürdüğünü doğrulayın ve eski sunucuyu bir süre erişilebilir bırakın. Günlükleri izleyerek trafiğin azaldığını görün; sonra TTL'yi yükseltin. Bu yaklaşım kesintiyi azaltır fakat sıfır kesinti garantisi vermez.
Sık karşılaşılan belirtiler ve olası nedenler
- Bazı ağlarda yeni, bazılarında eski site: Çözümleyici önbelleklerinin TTL'si farklı zamanlarda doluyor olabilir.
- Her yerde eski kayıt: Yanlış DNS paneli düzenlenmiş, kayıt kaydedilmemiş veya yetkili sunucu eski bölgeyi sunuyor olabilir.
- Aralıklı iki farklı cevap: Yetkili nameserver'lar tutarsız olabilir ya da bilerek birden fazla A/AAAA kaydı yayınlanıyor olabilir.
- DNS doğru, tarayıcıda yanlış site: Web sunucusu, CDN önbelleği, yönlendirme veya sanal ana bilgisayar yapılandırmasını kontrol edin.
- Sadece e-posta etkileniyor: MX hedefinin A/AAAA kaydı, SPF politikası veya posta sağlayıcısındaki yapılandırma ayrıca incelenmelidir.
- SERVFAIL görülüyor: DNSSEC imza zinciri, yetkili sunucu erişimi ya da hatalı bölge verisi söz konusu olabilir; yalnızca beklemek çözmeyebilir.
Sınırlamalar: bir yayılım aracı neyi kanıtlayamaz?
Çevrim içi araçlar belirli çözümleyicilerden örnek alır; dünyadaki bütün kullanıcıları ölçmez. “Yeşil” sonuç sitenin HTTP, uygulama veya veritabanı katmanının sağlıklı olduğunu kanıtlamaz. Benzer biçimde boş bir DNS cevabı alan adının kayıtsız olduğunu göstermez. DNS'te negatif cevaplar da SOA kaydındaki kurallara göre önbelleğe alınabilir. Son kararı verirken yetkili cevap, kayıt türü, TTL ve uygulama testi birlikte değerlendirilmelidir.
Değişiklik öncesi ve sonrası kontrol listesi
- Alan adının etkin nameserver'larını ve DNS panelini doğrulayın.
- Mevcut bölge kayıtlarının dışa aktarımını veya ekran görüntüsünü saklayın.
- TTL'yi geçişten yeterince önce düşürün; eski TTL'yi hesaba katın.
- Yeni sunucuyu DNS değişmeden önce hosts dosyası veya geçici adresle test edin.
- A, AAAA, CNAME, MX ve TXT kayıtlarını ayrı ayrı gözden geçirin.
- Tüm yetkili nameserver'ların aynı SOA seri numarası ve kayıtları sunduğunu kontrol edin.
- Farklı çözümleyicilerde yeni cevap görülürken eski altyapıyı hemen kapatmayın.
- Web, e-posta, TLS ve yönlendirme testlerini DNS kontrolünden ayrı yapın.
Kısa SSS
DNS yayılımını hızlandırabilir miyim?
Önceden düşük TTL planlamak geçişi hızlandırabilir. Değişiklikten sonra üçüncü taraf çözümleyicilerin geçerli önbelleğini merkezi olarak silmek genellikle mümkün değildir. Google Public DNS kendi hizmeti için bir önbellek temizleme aracı sunar; bu yalnızca o çözümleyiciyi etkiler.
Bilgisayardaki DNS önbelleğini temizlemek yeterli mi?
Yalnızca sorunun cihazdaki önbellekten kaynaklandığı durumda yardımcı olur. İnternet sağlayıcısının çözümleyicisindeki veya yetkili sunucudaki eski veriyi değiştirmez.
TTL sıfır yapılmalı mı?
Çözümleyici davranışı ve sağlayıcı sınırları değişebilir; sıfır TTL güvenilir bir genel çözüm değildir. Planlı geçişte sağlayıcınızın desteklediği ölçülü bir düşük değer seçin.
Resmî ve teknik kaynaklar
- IETF RFC 1034: Domain Names — Concepts and Facilities
- IETF RFC 1035: Domain Names — Implementation and Specification
- Google Public DNS sorun giderme belgeleri
- Google Public DNS önbellek temizleme açıklaması
DNS kayıt türlerini tazelemek isterseniz DNS kayıtları rehberini, mevcut alan adınızı bütüncül incelemek için Domain Sağlık Raporu'nu açabilirsiniz.