DNS Kayıtlarının Dünya Genelinde Yayılması

Bir A kaydını güncelliyor, tarayıcınızı yeniliyorsunuz ve hâlâ eski sunucuyu görüyorsunuz. Başka bir şehirdeki iş arkadaşınız ise yenisini görüyor. Birisi size “DNS’in yayılmasını bekle” diyor ve bunun 48 saate kadar sürebileceğini ekliyor. Bu ifade o kadar yaygın ki çoğu kişi DNS değişikliklerinin gezegen boyunca bir dalga gibi yavaşça yayıldığını hayal ediyor. Gerçek ise daha basit ve bir kez anladığınızda kontrol etmesi çok daha kolay.

Bu rehberde DNS’i değiştirdiğinizde gerçekte ne olduğunu, aynı anda farklı kişilerin neden farklı yanıtlar gördüğünü, ad sunucusu değişikliklerinin sıradan kayıt değişikliklerinden nasıl ayrıldığını ve süreci nasıl kontrol edip hızlandırabileceğinizi anlatıyoruz. Önce kayıt türlerini hatırlamak isterseniz DNS kayıtlarının temelleri rehberimizi okuyun.

Yayılma aslında önbellek süresinin dolmasıdır

Hiçbir şey, dünya genelinde sunucudan sunucuya kopyalanma anlamında “yayılmaz”. DNS sağlayıcınızda bir kaydı düzenlediğinizde değişiklik neredeyse anında yetkili ad sunucularınıza ulaşır (çoğu sağlayıcı kendi sunucularını saniyeler ile birkaç dakika içinde eşitler). O andan itibaren doğru yanıt soran herkes için hazırdır.

Gecikme özyinelemeli çözümleyicilerden kaynaklanır: internet sağlayıcılarının, şirketlerin ve Google Public DNS, Cloudflare 1.1.1.1 ya da Quad9 gibi genel hizmetlerin işlettiği DNS sunucuları. Bir çözümleyici alan adınızı sorguladığında yanıtı, kaydın TTL (time to live, yaşam süresi) değerinin izin verdiği süre boyunca önbelleğinde saklar. Bu süre dolana kadar ad sunucularınıza yeniden sormadan saklanan yanıtı vermeye devam eder.

Yani insanlar yayılmadan söz ederken aslında şunu kastediyor: “Eski yanıtı önbelleğe almış her çözümleyicinin onu unutması ne kadar sürer?” Her çözümleyici kaydınızı farklı bir zamanda önbelleğe aldığı için her biri farklı bir zamanda unutur. Bir değişiklik sırasında sonuçların rastgele ve dağınık görünmesinin nedeni budur. TTL değerlerini seçmeye daha ayrıntılı bakmak için DNS TTL ayarlarının rolü yazımıza göz atın.

Sizinle yanıt arasındaki önbellek katmanları

Tek bir sorgu birkaç önbellekten geçebilir ve bunlardan herhangi biri eski değeri tutuyor olabilir:

• Tarayıcı önbelleği – tarayıcılar kendi kısa ömürlü DNS önbelleklerini tutar.
• İşletim sistemi önbelleği – Windows, macOS ve birçok Linux kurulumu (örneğin systemd-resolved ile) yanıtları yerel olarak önbelleğe alır.
• Yönlendirici ya da yerel ağ – ev yönlendiricileri ve ofis DNS yönlendiricileri de çoğu zaman önbellek tutar.
• Özyinelemeli çözümleyici – ISS’inizin ya da birçok kullanıcının paylaştığı genel bir çözümleyici.
• Negatif önbellek – biri bir adı o ad var olmadan önce sorguladıysa, “mevcut değil” yanıtı bölgenin SOA ayarlarına göre önbelleğe alınır.

Bazı çözümleyiciler kendi minimum ya da maksimum TTL’lerini de uygular ve birkaçının kayıtları söylenenden daha uzun tuttuğu bilinir. Okuduğunuz her zaman çizelgesini bir garanti değil, tipik bir aralık olarak görmeniz gerekmesinin bir nedeni de budur.

Kayıt değişiklikleri ve ad sunucusu değişiklikleri

Tüm DNS değişiklikleri aynı şekilde davranmaz. Asıl soru, önbellekteki verinin nerede durduğudur.

Bölgenizdeki bir kaydı değiştirmek

Bir A, AAAA, CNAME, MX ya da TXT kaydını düzenlemek yalnızca kendi yetkili sunucularınızdaki veriyi etkiler. Bekleme süresini, o kaydın siz değiştirmeden önceki TTL’si belirler. Eski A kaydının TTL’si 3600 saniye idiyse, düzenlemenizden hemen önce onu önbelleğe alan çözümleyiciler bir saate kadar tutabilir.

Ad sunucularını değiştirmek

Yeni bir DNS sağlayıcısına geçmek, kayıt firmanızdaki NS kayıtlarını değiştirmek demektir; kayıt firması da güncellemeyi TLD’nizin (örneğin .com ya da .de) kayıt otoritesine gönderir. Kayıt otoritesi ardından yeni yetkilendirmeyi üst bölgede yayımlar. Burada iki gecikme üst üste biner:

1. Kayıt firması ve kayıt otoritesinin değişikliği işleyip yayımlaması için geçen süre. Birçok kayıt otoritesi dakikalar içinde yayımlar, ancak bu TLD’ye göre değişir.
2. Üst bölgedeki yetkilendirme NS kayıtlarının, sizin kontrol edemediğiniz TTL’si. .com ve .net için bu genellikle iki gündür (172800 saniye); diğer TLD’ler kendi değerlerini kullanır.

Çözümleyiciler eski sağlayıcınızın sunucularının verdiği NS kayıtlarını da önbelleğe alabilir. Ad sunucusu değişikliklerinin klasik “48 saate kadar” örneği olmasının, düşük TTL’li basit bir kayıt değişikliğinin ise dakikalar içinde tamamlanabilmesinin nedeni budur. Bir sağlayıcı taşıması sırasında trafik tamamen geçene kadar eski ve yeni ad sunucularında aynı kayıtları tutun.

Bu aralıklar söz değil, genel eğilimlerdir. Çözümleyici davranışı, kayıt otoritesinin işlem süresi ve her çözümleyicinin adınızı en son ne zaman sorguladığı gerçek sonucu etkiler.

Hızlı olması için bir değişikliği nasıl planlarsınız?

Bekleme süresini eski TTL belirlediğinden, işin püf noktası onu değişikliği yapmanız gerekmeden önce düşürmektir:

1. Değiştirmeyi planladığınız kayıtların mevcut TTL’sini kontrol edin.
2. TTL’yi en az bir tam eski TTL süresi öncesinden 300 saniye gibi kısa bir değere düşürün (TTL 86400 idiyse bunu bir günden daha önce yapın).
3. Eski, uzun TTL’nin her yerde dolmasına zaman tanıdıktan sonra değişikliği yapın.
4. Yeni yanıtları birkaç çözümleyiciden doğrulayın.
5. Sorgu yükünü azaltmak ve dayanıklılığı artırmak için her şey oturduğunda TTL’yi yeniden yükseltin.

Ad sunucusu taşımalarında üst bölge TTL’sini kısaltamazsınız, ancak her iki sağlayıcıyı aynı kayıtlarla paralel çalıştırarak kesintiden kaçınabilirsiniz.

İlerlemeyi birden fazla çözümleyiciden kontrol etmek

Kendi dizüstü bilgisayarınızdan yapacağınız tek bir test, size yalnızca yerel önbellek zincirinizin ne düşündüğünü söyler. Gerçek bir tablo görmek için birkaç kaynağı karşılaştırın. dig ile belirli bir çözümleyiciyi, adresini @ işaretinden sonra yazarak sorgulayabilirsiniz:

dig example.com A +short @1.1.1.1
dig example.com A +short @8.8.8.8
dig example.com A +short @9.9.9.9

Tüm önbellekleri atlayarak kendi sunucularınızın ne dediğini görmek için doğrudan yetkili bir ad sunucusuna sorun:

dig example.com NS +short
dig example.com A @ns1.your-dns-provider.net

Normal bir dig yanıtındaki TTL sütunu, bir çözümleyicinin önbellek kopyasını yenilemesine kaç saniye kaldığını da gösterir; ne kadar daha beklemeniz gerektiğini tahmin etmenin pratik bir yoludur. Ad sunucusu değişikliklerinde yetkilendirmeyi kökten itibaren dig example.com +trace ile izleyebilirsiniz. Kayıt otoritesinin şu anda hangi ad sunucularını listelediğini TLDix alan adı WHOIS/RDAP sorgulama aracıyla da doğrulayabilirsiniz.

Birçok ülkedeki çözümleyicileri sorgulayan çevrim içi “yayılma kontrol” araçları hızlı bir genel bakış için yararlı olabilir; ancak yalnızca tek bir anda bir çözümleyici örneklemini gösterdiklerini unutmayın.

Yerel önbellekleri temizlemek

Genel çözümleyiciler yeni yanıtı zaten döndürüyor ama makineniz döndürmüyorsa, eski kopya büyük olasılıkla yereldir. Temizlemenin yaygın yolları:

• Windows: bir terminalde ipconfig /flushdns çalıştırın.
• macOS: sudo dscacheutil -flushcache ve ardından sudo killall -HUP mDNSResponder çalıştırın.
• systemd-resolved kullanan Linux: resolvectl flush-caches çalıştırın.
• Chrome: chrome://net-internals/#dns adresini açın ve ana makine önbelleğini temizleyin.
• Yönlendirici: yeniden başlatmak genellikle önbelleğini temizler.

ISS’inizin çözümleyicisini kendiniz temizleyemezsiniz. Google ve Cloudflare dahil bazı genel çözümleyiciler, önbellekteki bir adı temizlemek için web formları sunar; bu da test sırasında işe yarayabilir.

Yavaş yayılma gibi görünen yaygın sorunlar

“Yayılma” şikâyetlerinin birçoğu yapılandırma hatası çıkar. Daha uzun beklemeden önce şunları eleyin:

• Yanlış bölgeyi düzenlemek – alan adı başka ad sunucuları kullanıyorsa kayıt firmasının DNS panelinde yapılan değişiklikler hiçbir işe yaramaz.
• Kayıtlarda yazım hataları – eksik bir nokta ya da yanlış bir IP adresi, önbellekteki eski bir yanıtla tıpatıp aynı görünür.
• DNSSEC uyuşmazlığı – sağlayıcı taşımasından sonra kayıt otoritesindeki güncel olmayan bir DS kaydı, doğrulama yapan çözümleyicilerin tamamen başarısız olmasına yol açabilir.
• CDN ya da proxy katmanları – trafik bir CDN üzerinden geçiyorsa DNS doğru olabilir ama CDN hâlâ eski kaynak sunucuya işaret ediyor olabilir.
• Uygulama önbelleği – bazı yazılımlar ve uzun süre çalışan süreçler bir adı bir kez çözümler ve yeniden başlatılana kadar sonucu tutar.

Pratik örnek: Bir web sitesini yeni hostinge taşımak

Somut bir senaryo üzerinden gidelim. Sitenizi eski hosting firmasından yenisine taşıyacaksınız ve DNS sağlayıcınız değişmeyecek; yani yalnızca A kaydı güncellenecek. Mevcut TTL 14400 saniye, yani dört saat. Taşımadan en az bir gün önce TTL’yi 300 saniyeye düşürün. Bu sırada dosyaları ve veritabanını yeni sunucuya kopyalayın ve bilgisayarınızın hosts dosyasına geçici bir satır ekleyerek siteyi yeni sunucuda test edin; böylece DNS’e dokunmadan her şeyin çalıştığını görürsünüz.

Taşıma günü, eski sunucuda içerik değişikliklerini dondurun, son veritabanı kopyasını aktarın ve A kaydını yeni IP adresine güncelleyin. Yetkili sunucunuzu doğrudan sorgulayarak yeni değerin orada olduğunu, ardından birkaç genel çözümleyiciyi sorgulayarak geçişin ilerlediğini doğrulayın. Beş dakika içinde trafiğin büyük bölümünün yeni sunucuya geçtiğini görmelisiniz. Eski sunucuyu en az bir-iki gün açık tutun ve günlüklerinde gelen istek kalmadığında kapatın. Hosts dosyasına eklediğiniz test satırını silmeyi unutmayın; aksi hâlde aylar sonra neden farklı bir sunucu gördüğünüzü merak edebilirsiniz. Son olarak TTL’yi yeniden birkaç saatlik bir değere çıkarın.

Alan adı ve DNS ayrıntılarını takip etmek

DNS değişiklikleri çoğu zaman başka olaylarla birlikte gerçekleşir: hosting taşıma, alan adı yenileme ya da SSL sertifikası değiştirme. Bir alan adının hangi ad sunucularını kullandığını, kimin barındırdığını ve ne zaman sona ereceğini bilmek, bir şeyler ters gittiğinde zaman kazandırır. TLDix kayıt verilerini sorgulamanıza ve yenileme tarihlerini takip etmenize olanak tanır; hosting sorgulama aracı da bir sitenin şu anda nereden sunulduğunu görmenize yardımcı olur ki bu, bir taşımanın hemen ardından oldukça kullanışlıdır.

Ana ders basit: DNS değişiklikleri dünyaya eski önbelleklerin dolduğu hızda ulaşır. TTL’leri önceden planlayın, birkaç çözümleyiciden doğrulayın; tam 48 saat beklemeniz nadiren gerekecektir.