DNS Yayılması Nedir? Ne Kadar Sürer?

DNS yayılması çoğu zaman birkaç dakika ile TTL süresi arasında tamamlanır; nameserver değişikliklerinde süre birkaç saate, bazı durumlarda daha uzun bir pencereye çıkabilir. Kesin süre TTL, resolver önbelleği, DNSSEC, negatif önbellek ve A/AAAA kayıtlarının tutarlılığına bağlıdır. Farklı resolver'ları sorgulamadan yalnızca beklemek doğru teşhis değildir.

DNS yayılması aslında ne anlama gelir?

Bir alan adının IP adresi, DNS kayıt türü veya nameserver bilgisi değiştirildiğinde tek bir merkezdeki kayıt güncellenmez. Yetkili DNS sunucusu yeni cevabı vermeye başlar; internet servis sağlayıcıları, işletim sistemleri, tarayıcılar ve kurumsal ağlar bu cevabı TTL süreleri boyunca önbellekte tutabilir. Bu nedenle aynı alan adı, farklı ağlardan bir süre farklı IP adreslerine çözülebilir.

DNS yayılması, yeni kaydın dünyanın her noktasına gönderilmesi değildir. Sorgu yapan çözümleyicilerin eski önbellekleri bırakıp yetkili sunucudan yeni cevabı almasıdır. DNS çözümlemesi; kayıt operatörü, yetkili nameserver ve recursive resolver katmanlarının birlikte çalışmasına dayanır.

Yetkili sunucu ile recursive resolver farkı

Yetkili DNS sunucusu alan adının gerçek kayıtlarını barındırır. Recursive resolver ise sizin bilgisayarınız veya VPS’iniz adına DNS sorgusunu yapar; internet servis sağlayıcınızın resolver’ı, Google Public DNS ve Cloudflare Resolver bu role örnektir.

Bir A kaydının TTL değeri 3.600 saniyeyse resolver, aldığı cevabı normal şartlarda bir saate kadar saklayabilir. TTL dolmadan yeniden sorgu yapılmayabilir. DNS panelinde kayıt güncel görünürken bazı kullanıcıların eski IP’ye gitmesi bu yüzden mümkündür.

Ne yapılmalı – Değişiklikten önce TTL değerini, yetkili nameserver’ları ve yeni kaydın doğrudan cevap verip vermediğini kontrol edin.

DNS yayılması ne kadar sürer?

Çoğu A, AAAA veya CNAME kaydında değişiklik birkaç dakika ile TTL süresi arasında farklı ağlarda görünür; tüm internet kullanıcıları için kesin bir saat vermek mümkün değildir. 300 saniyelik TTL, değişikliğin tam 5 dakikada herkes tarafından görüleceği anlamına gelmez. Resolver sorguyu değişiklikten hemen önce yaptıysa eski cevap TTL dolana kadar kullanılabilir.

Nameserver değişiklikleri yalnızca A kaydı değiştirmekten farklıdır. Alan adının üst bölgesindeki NS delegasyonu ve eski nameserver cevapları da devreye girdiği için geçiş süresi daha değişken olabilir. Düşük TTL belirlenmiş olsa bile daha önce yüksek TTL ile önbelleğe alınmış cevapların süresi geriye dönük kısalmaz.

Pratikte kayıt türünü ve TTL değerini bilmeden saat vermek doğru değildir. Normal bir kayıt için TTL süresini, nameserver değişikliğinde ise en az birkaç saatlik geçiş penceresini planlayın. 48 saat boyunca tutarlı biçimde eski kayıt görülüyorsa yalnızca beklemek yerine delegasyon, DNSSEC ve resolver davranışını araştırın.

Ne yapılmalı – TTL süresini bir son tarih değil, resolver’ın eski cevabı tutabileceği yaklaşık üst sınır olarak değerlendirin.

TTL değeri değişikliği nasıl etkiler?

TTL, DNS cevabının saniye cinsinden ne kadar süre önbellekte tutulabileceğini bildirir. RFC 1035, DNS kaynak kayıtlarındaki TTL alanını bu amaçla tanımlar. 300 saniye 5 dakikaya, 86.400 saniye ise 24 saate karşılık gelir.

Planlı bir sunucu taşımasından önce TTL değerini 300 veya 600 saniyeye düşürmek geçişi kolaylaştırabilir. Fakat bu değer, taşıma başlamadan önce resolver’lar tarafından görülmelidir. Değişiklikten hemen önce TTL’yi düşürürseniz bazı resolver’lar hâlâ eski, yüksek TTL’li cevabı kullanıyor olabilir.

dig +noall +answer example.com A

dig @1.1.1.1 +noall +answer example.com A
dig @8.8.8.8 +noall +answer example.com A

İlk komut yerel resolver’ın cevabını gösterir. Sonraki iki komut farklı public resolver’ların cevabını karşılaştırır; satırdaki sayı kalan TTL değeridir. TTL değeri her sorguda yeniden yükselmiyorsa önbelleğin yaşlandığını görebilirsiniz.

Çok düşük TTL her zaman iyi değildir. DNS sorgu sayısı artar, resolver önbellek verimliliği düşer ve yetkili DNS altyapısına daha fazla istek gelebilir. Sık değişmeyen bir web sitesi için 3.600 saniye veya daha yüksek değerler makul olabilir; kritik geçişlerde TTL geçici olarak düşürülüp işlem tamamlandıktan sonra yükseltilebilir.

DNS kaydı değişti, neden hâlâ eski site açılıyor?

Eski sitenin açılması tek bir nedene işaret etmez. Önce hangi katmanın eski cevabı verdiğini ayırın:

• Yerel önbellek: İşletim sistemi veya tarayıcı daha önce aldığı DNS cevabını saklıyor olabilir.
• İSS resolver’ı: İnternet servis sağlayıcısının recursive resolver’ı TTL dolana kadar eski IP’yi döndürebilir.
• Yetkili DNS: Paneldeki değişiklik yanlış nameserver üzerinde yapılmış veya kayıt yanlış bölgede oluşturulmuş olabilir.
• Uygulama katmanı: Yeni IP’ye gidiliyor olsa bile HTTP yönlendirmesi, CDN önbelleği veya web sunucusu eski içeriği servis ediyor olabilir.
• Hosts dosyası: Linux’ta /etc/hosts, Windows’ta C:\Windows\System32\drivers\etc\hosts dosyası DNS’ten önce dikkate alınabilir.

Yalnızca tarayıcıyı yenilemek güvenilir test değildir. Önce alan adının hangi IP’ye çözüldüğünü, sonra o IP’nin hangi HTTP cevabını verdiğini kontrol edin. Alan adı çözümleme hatası için DNS_PROBE_FINISHED_NXDOMAIN Hatası Nasıl Çözülür? başlıklı içerikteki yaklaşım da bu ayrımı temel alır.

dig +short NS example.com
dig +short A example.com
curl -I --resolve example.com:443:203.0.113.20 https://example.com/

dig +short NS yetkili nameserver listesini, dig +short A ise kullanılan resolver’ın IP cevabını gösterir. curl --resolve DNS’i geçici olarak atlatarak belirli IP’deki HTTPS servisini test eder. Böylece sorunun DNS’te mi, web sunucusunda mı olduğu daha net anlaşılır.

Ne yapılmalı – Tarayıcıdaki sonucu tek başına kanıt saymayın; NS, A/AAAA ve HTTP katmanlarını ayrı ayrı sorgulayın.

Nameserver değişikliği neden daha uzun sürer?

Bir A kaydını değiştirdiğinizde yetkili DNS bölgesindeki tek bir kaynak kaydı güncellenir. Nameserver değişikliğinde ise alan adının hangi DNS sunucularından cevap alacağını belirleyen delegasyon değişir. Bu bilgi, alan adının bağlı olduğu üst seviye kayıt sisteminde ve resolver önbelleklerinde tutulur.

Geçiş sırasında eski ve yeni DNS sağlayıcısının aynı kayıtları sunması gerekir. Eski NS delegasyonunu gören bir resolver eski sağlayıcıya, yeni delegasyonu gören başka bir resolver yeni sağlayıcıya gidebilir. Eski DNS bölgesini hemen kapatmak risklidir; geçiş tamamlanana kadar eski ve yeni tarafta A, AAAA, MX, TXT ve CNAME kayıtlarını karşılaştırın.

Alan adı taşıma süreçlerinde yalnızca web sitesini düşünmeyin. MX kaydı e-posta teslimini, TXT kayıtları SPF, DKIM veya doğrulama akışlarını, CAA kaydı ise sertifika yetkilendirmesini etkileyebilir. Nameserver geçişi öncesi DNS bölgesini dışa aktarmak ve kritik kayıtları satır satır kontrol etmek daha güvenlidir.

Bir alan adını yeni bir sunucuya taşırken Buluta Geçiş Rehberi: 10 Adımda Taşıma Planı içindeki aşamalı geçiş yaklaşımı uygulanabilir: önce yeni altyapıyı hazırlayın, düşük riskli testler yapın ve DNS değişikliğini planlı bakım penceresinde gerçekleştirin.

DNS yayılmasını nasıl kontrol edebilirsiniz?

Tek bir çevrim içi DNS kontrol sitesine güvenmek yerine farklı resolver’ları doğrudan sorgulayın. Her araç aynı resolver havuzunu kullanmayabilir; bazı araçlar sonucu birkaç dakika önbellekte tutabilir.

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

dig +trace example.com A

İlk üç sorgu farklı recursive resolver’ları karşılaştırır. +trace kök sunuculardan başlayarak delegasyon zincirini izler; yerel resolver önbelleğini doğrudan ölçmez, fakat yetkili sunucuya giden yolda sorun olup olmadığını anlamaya yardımcı olur.

Yetkili sunucuyu ayrıca sorgulayın. Önce NS listesini alın, ardından listelenen sunuculardan birine doğrudan sorun:

dig +short NS example.com
dig @ns1.example-dns.com example.com A +noall +answer

Yetkili sunucu yeni IP’yi veriyor, fakat public resolver eski IP’yi döndürüyorsa değişiklik büyük ihtimalle önbellek sürecindedir. Yetkili sunucu da eski IP’yi veriyorsa panelde yanlış bölge düzenlenmiş, kayıt kaydedilmemiş veya DNS sağlayıcısı beklenenden farklı olabilir.

IPv6 kaydı da kontrol edilmelidir. A kaydı yeni sunucuyu, AAAA kaydı eski sunucuyu gösteriyorsa IPv6 kullanan istemciler farklı bir hedefe gidebilir. Bazı ağlarda görülen bu durum yanlış biçimde DNS yayılması sorunu sanılabilir.

Ne yapılmalı – A ve AAAA kayıtlarını en az iki public resolver ile ve doğrudan yetkili nameserver üzerinden karşılaştırın.

DNSSEC, negatif önbellek ve diğer istisnalar

DNSSEC etkin bir alan adında kayıt imzaları ve DS bilgileri de uyumlu olmalıdır. Nameserver değişikliği sırasında eski DS kaydı ile yeni DNS bölgesinin imzaları eşleşmezse bazı resolver’lar cevabı doğrulayamaz ve SERVFAIL döndürebilir. Bu, sıradan TTL beklemesinden farklıdır.

Bir kayıt mevcut değilken alınan NXDOMAIN cevabı da önbelleğe alınabilir. RFC 2308, negatif cevapların önbelleklenmesinde SOA kaydındaki değerlerin kullanılmasını tanımlar. Önce olmayan bir alt alan adını sorgulayıp kısa süre sonra bu adı oluşturduysanız, bazı resolver’lar kayıt eklenmesine rağmen bir süre daha NXDOMAIN döndürebilir.

dig example.com SOA +noall +answer
dig example.com DNSKEY +dnssec +noall +answer
dig example.com A +dnssec +noall +answer

SOA cevabındaki serial değeri DNS bölgesinin sürümünü, minimum TTL ve diğer alanlar ise bölge davranışını değerlendirmeye yardımcı olur. DNSSEC sorgusunda RRSIG ve ilgili doğrulama kayıtları görülebilir; sonuç SERVFAIL ise DNSSEC zinciri ayrıca incelenmelidir.

CDN kullanılıyorsa iki ayrı önbellek katmanı bulunur: DNS cevabı ve CDN’in HTTP içeriği. DNS yeni IP’yi gösterse bile CDN, Cache-Control veya kendi cache süresi nedeniyle eski içeriği servis edebilir. CDN Nedir? Web Sitesini Nasıl Hızlandırır? başlıklı içerikte açıklanan edge önbelleği ile DNS önbelleğini birbirine karıştırmayın.

Taşıma öncesi ve sonrası uygulanacak yöntem

Değişiklikten önce

1. Mevcut A, AAAA, CNAME, MX, TXT, CAA ve NS kayıtlarını dışa aktarın.
2. Yetkili nameserver listesini dig +short NS alanadiniz.tld ile doğrulayın.
3. Yeni sunucuda web, e-posta, TLS ve uygulama erişimini doğrudan IP veya geçici hostname ile test edin.
4. Planlı geçişten önce kritik kayıtların TTL değerlerini uygun şekilde düşürün.

Değişiklikten sonra

1. Yetkili DNS sunucusundan yeni cevabı kontrol edin.
2. 1.1.1.1, 8.8.8.8 ve yerel resolver gibi farklı kaynakları karşılaştırın.
3. A ve AAAA kayıtlarının aynı geçiş planına uyduğundan emin olun.
4. E-posta, doğrulama TXT kayıtları ve CDN davranışını ayrıca test edin.

Bir web sunucusunu DNS değişiminden önce hazırlamak için Ubuntu’da Nginx Kurulumu ve İlk Yapılandırma rehberindeki temel sanal host ve TLS kontrolleri kullanılabilir. DNS doğru IP’yi gösterse bile Nginx’te yanlış server_name tanımı varsa istemci beklenmeyen siteyi görebilir.

Ne yapılmalı – Eski DNS sağlayıcısını, e-posta kayıtlarını ve izleme kontrollerini geçişten hemen sonra silmeyin; en az bir tam TTL döngüsü boyunca gözlemleyin.

DNS Değişikliğinden Önce ve Sonra Kontrol Edin

• Mevcut DNS bölgesindeki A, AAAA, MX, TXT, CAA ve CNAME kayıtlarını dışa aktarın.
• Yetkili nameserver listesini dig ile doğrulayın.
• Taşıma öncesinde kritik kayıtların TTL değerlerini kontrol edin.
• Yeni sunucuyu DNS değişikliğinden önce doğrudan IP üzerinden test edin.
• Değişiklikten sonra en az iki public resolver'ı karşılaştırın.
• A ve AAAA kayıtlarının aynı hedefe veya planlanan hedeflere gittiğini doğrulayın.
• DNSSEC, e-posta, CDN ve TLS kontrollerini ayrı ayrı tamamlayın.

DNS yayılmasını değerlendirirken domain ile URL kavramlarını karıştırmamak önemli; ben bu iki terimin farkını örneklerle açıkladığım Domain ve URL farkı rehberine de göz atmanızı öneririm.

Sık Sorulan Sorular

Kaynaklar

• ICANN – Domain Name System — icann.org
• RFC 1035 – Domain Names: Implementation and Specification — rfc-editor.org
• RFC 2308 – Negative Caching of DNS Queries — rfc-editor.org
• RFC 4033 – DNS Security Introduction and Requirements — rfc-editor.org