DNS Propagasyon: Neden Bu Kadar Sürer ve Hızlandırma Yolları
DNS değişikliklerinin neden bazen dakikalar bazen saatler sürdüğünü TTL, önbellek katmanları ve resolver hiyerarşisiyle açıklıyor; deploy öncesi TTL stratejisi, cache flush komutları ve propagasyon kontrol araçlarıyla süreci nasıl kısaltacağınızı anlatıyor.
DNS Propagasyon: Neden Bu Kadar Sürer ve Hızlandırma Yolları
DNS değişikliği yaptınız, saatler geçti ama siteniz hâlâ eski sunucuya gidiyor. Komşunuz yeni IP'yi görüyor, siz göremiyorsunuz. "Propagasyon bitmedi" diyorlar. Gerçek sebep bu mu?
Bu yazı DNS değişikliklerinin neden bazen dakikalarda, bazen saatlerce sürdüğünü teknik katmanlarıyla açıklıyor; TTL stratejisi, cache flush yöntemleri ve kontrol araçlarıyla süreci fiilen nasıl kısaltabileceğinizi anlatıyor.
Buyukweb perspektifi: cPanel Zone Editor'ından TTL ayarını istediğiniz değere çekebilirsiniz. Deploy öncesi TTL düşürme stratejisini uygulamak için tek yapmanız gereken Zone Editor'a girmek. Herhangi bir adımda takılırsanız 0850 302 60 70 destek hattımız yardımcı olur.
"Propagasyon" Aslında Ne Anlama Gelir?
"DNS propagasyonu" kavramı yaygın ama biraz yanıltıcı. Kulağa DNS değişikliğinin tüm sunuculara tek tek dağıtılması gibi geliyor — sanki yetkili DNS'ten dünyaya doğru aktif bir yayılma dalgası var. Oysa mekanizma bunun tam tersi.
DNS sistemi pull (çekme) modeliyle çalışır, push (itme) değil. Yetkili DNS sunucunuz değişikliği kimseye duyurmaz. Bunun yerine, dünyanın her yanındaki resolver'lar önbelleklerindeki (cache) kayıt süresi dolduğunda yetkili sunucunuza gelip güncel kaydı çeker.
Yani "propagasyon süresi" denilen şey aslında önbellek (cache) geçerlilik süresi. Her DNS kaydının bir TTL değeri var; bu süre dolmadan resolver eski cevabı sergilemeye devam eder. Değişiklik anında olmaz çünkü propagasyon diye aktif bir süreç yok — sadece TTL'nin dolmasını beklersiniz.
Bu ayrımı kavramak, süreci hızlandırmak için ne yapmanız gerektiğini de netleştirir.
DNS Resolver Hiyerarşisi: Sorgu Kimin Önbelleğine Düşüyor?
Bir kullanıcı tarayıcıya buyukweb.com yazdığında sorgu birkaç katmandan geçer:
Tarayıcı
↓ Kendi DNS önbelleğini kontrol eder (1–30 dakika)
İşletim Sistemi (stub resolver)
↓ /etc/hosts ya da hosts dosyasına bakar
↓ OS DNS önbelleğine bakar (systemd-resolved, dnsmasq, Windows DNS Client)
ISP / Kurumsal Recursive Resolver
↓ Kendi önbelleğini kontrol eder — en kritik katman
↓ Önbellekte yoksa sırasıyla sorar:
Root Name Server → .com TLD Name Server → buyukweb.com Yetkili DNS
↓ Gelen cevabı TTL kadar önbellekler
Yetkili DNS Sunucu (kayıt sahibi, Buyukweb / Cloudflare / Müşteri)
Neden bir kullanıcı yeni IP'yi görürken diğeri eski IP'yi görüyor? Çünkü farklı ISP'lerin recursive resolver'larının önbellekleri farklı zamanlarda doldu. Birinin resolver'ı kaydı 30 dakika önce çekti, henüz TTL bitmedi. Diğerinin resolver'ı TTL sınırına geldi, yetkili sunucuya gidip yeni kaydı aldı.
Bu, "propagasyon" değil; birbirinden bağımsız cache'lerin ayrı zamanlarda yenilenmesi.
TTL: Önbelleğin Ömrünü Belirleyen Sayı
TTL (Time To Live) DNS kaydı başına, saniye cinsinden tanımlanan bir süredir. Resolver bu süre boyunca cevabı önbelleğinden sunar, süre dolunca yeniden yetkili sunucuya sorar.
# dig ile mevcut TTL'yi okuma
dig +nocmd +noall +answer buyukweb.com A
# Örnek çıktı:
buyukweb.com. 3600 IN A 195.85.100.51
↑
TTL: 3600 saniye = 1 saat
Bu değer her saniye azalır; sıfıra gelince resolver yeniden sorar
# Farklı kayıt türleri için tipik TTL değerleri:
A record 3600 (1 saat) — standart web yönlendirme
AAAA record 3600 (1 saat) — IPv6
CNAME record 3600 (1 saat) — alias
MX record 3600 (1 saat) — e-posta sunucusu
NS record 86400 (24 saat) — yetkili DNS sunucu
SOA record 86400 (24 saat) — bölge başlık kaydı; negatif cache için MINTTL değerine bakılır
TXT record 3600 (1 saat) — SPF, DKIM, doğrulama
TTL büyük olunca ne olur? Önbellek uzun süre geçerli kalır — sorgular yetkili sunucuya daha az gider, yük düşer, ama değişiklik yavaş yayılır.
TTL küçük olunca ne olur? Önbellek sık yenilenir — değişiklik hızlı yayılır ama yetkili sunucuya giden sorgu sayısı artar. 60 saniyenin altı üretim kayıtları için önerilmez.
Önbellek Katmanları: Hangi Cache Ne Kadar Tutar?
DNS değişikliğinin neden gecikmeli göründüğünü anlamak için tüm katmanları saymak gerekir:
1. Tarayıcı DNS Önbelleği
Chrome, Firefox ve diğer tarayıcılar DNS sonuçlarını kendi içlerinde saklar. TTL'ye uymak zorunda değiller — bazıları kendi cache süresini uygular (1–30 dakika arası). Tarayıcıyı kapatıp açmak veya chrome://net-internals/#dns sayfasından temizlemek bu katmanı sıfırlar.
2. İşletim Sistemi Resolver Önbelleği
Windows'ta DNS Client servisi, Linux'ta systemd-resolved veya dnsmasq, macOS'ta mDNSResponder OS düzeyinde cache tutar. Bu katman da TTL'yi takip eder ama flush edilebilir (aşağıda komutlar var).
3. Router / Yerel Ağ DNS Önbelleği
Pek çok ev ve ofis router'ı DNS sorgu sonuçlarını önbellekler. Bu katman genellikle manuel flush gerektirmez; yeniden başlatmak temizler.
4. ISP Recursive Resolver Önbelleği
En kritik katman bu. Milyonlarca kullanıcının trafiği aynı ISP resolver'ından geçer. Resolver kaydı bir kez TTL süresiyle önbellekledi mi, o süre dolmadan güncel kaydı getirme şansınız yok. Flush yetkisi sizde değil. Tek çözüm: değişiklikten önce TTL'yi düşürmek.
5. Public Resolver Önbelleği
Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) gibi public resolver'lar TTL'ye uymaya çalışır. Cloudflare 1.1.1.1 ayrıca minimum TTL'yi uyguladığı için bazı durumlarda kaydı hafif daha uzun tutabilir — ancak bu fark genellikle dakika mertebesinde.
Negatif Cache: NXDOMAIN da Önbelleğe Alınır
Bir alan adı veya kayıt bulunamadığında (NXDOMAIN veya NODATA) bu olumsuz yanıt da önbelleğe girer. Süreyi SOA kaydının MINTTL alanı belirler — çoğu zaman 3600 saniye.
Bu neden önemli? Bir kayıt silinip tekrar eklediğinizde, resolver'ın "yoktu" cevabı hâlâ geçerliyse yeni kaydı göremezsiniz — TTL dolana kadar resolver yetkili sunucuya bile gitmez.
# SOA kaydını okuma — MINTTL alanı en sonda
dig +short buyukweb.com SOA
# Örnek çıktı:
# ns1.buyukweb.com. hostmaster.buyukweb.com. 2024010101 3600 900 604800 3600
# ↑
# MINTTL: 3600s
# Negatif cevaplar 3600 saniye (1 saat) önbelleklenir
Deploy Öncesi TTL Stratejisi: Süreci Dakikalara İndirmek
DNS değişikliği planlanıyorsa süreci minimize etmenin bilinen en iyi yöntemi şu:
T-48 saat: TTL'yi 300 saniyeye (5 dakika) düşür
→ Resolver'lar kaydı 5 dakikada bir yenileyecek
T-0: DNS değişikliğini yap (yeni IP, yeni kayıt)
→ Resolver'lar en fazla 5 dakika sonra yeni kaydı çeker
T+15 dak: Propagasyonu kontrol et (aşağıdaki araçlarla)
T+1 saat: TTL'yi tekrar 3600 veya 86400'e çek
→ Düşük TTL, yetkili sunucuya yük bindirir; gerek kalmayınca uzat
Neden 48 saat önce? Çünkü TTL'yi 3600'den 300'e düşürdüğünüzde, bu düşürme değişikliğinin kendisi de eski TTL (3600 saniye = 1 saat) boyunca önbelleklerde kalır. Resolver'lar 1 saat sonra yeniden sorduğunda yeni 300 saniyelik TTL'yi öğrenir. Güvenli tampon için 48 saat önceden ayarlamak mantıklı.
cPanel Zone Editor ile TTL Düşürme
cPanel → Domains → Zone Editor → Manage
İlgili kaydın yanındaki "Edit" butonuna tıkla
TTL alanını 300 yap → Kaydet
Glue Record ve NS Değişimi: En Uzun Süren İşlem
Nameserver (NS) değişikliği, A kaydı değiştirmekten çok farklı çalışır ve gerçekten 24–48 saat sürebilir.
Senaryo: buyukweb.com NS kayıtlarını değiştiriyorsunuz
Eski: ns1.eskidns.com, ns2.eskidns.com
Yeni: ns1.buyukweb.com, ns2.buyukweb.com
Sorun: ns1.buyukweb.com'un IP adresini kim biliyor?
→ Buyukweb.com'un yetkili DNS sunucusu ns1.buyukweb.com
→ Ama ns1.buyukweb.com'un IP'sini sormak için buyukweb.com NS'ini bilmek lazım
→ Döngüsel bağımlılık (circular dependency)
Çözüm: Glue Record
TLD registry (.com için Verisign) şunu saklar:
buyukweb.com NS ns1.buyukweb.com
ns1.buyukweb.com A 195.85.100.10 ← Glue record (TLD'de saklanır)
NS değişikliğinde registrar panelinden yeni glue record tanımlanır.
TLD registry'nin güncellemesi: 24–48 saat (EPP propagation).
Bu süre boyunca eski NS sunucuları da yanıt vermeye devam etmeli.
NS değişikliği sırasında dikkat edilmesi gerekenler:
- Yeni NS sunucusunda bölge dosyası (zone file) tam ve doğru olmalı — özellikle MX kayıtları
- Eski NS sunucusunu hemen kapatmayın; en az 48 saat aktif tutun
- SSL sertifikası doğrulama (HTTP-01 challenge) DNS değişikliği sırasında başarısız olabilir; önce tamamlayın
- TTL stratejisi NS değişikliğine uygulanamaz — NS TTL genellikle TLD'nin kontrolünde
Propagasyonu Kontrol Etme Araçları
Komut Satırı
# Belirli bir resolver'ı sorgulamak
dig +short buyukweb.com A @8.8.8.8 # Google Public DNS
dig +short buyukweb.com A @1.1.1.1 # Cloudflare Public DNS
dig +short buyukweb.com A @9.9.9.9 # Quad9
# Kalan TTL'yi görmek
dig +nocmd +noall +answer buyukweb.com A @8.8.8.8
# buyukweb.com. 2847 IN A 195.85.100.51
# ↑ kalan saniye
# Resolver'ın önbelleğe alıp almadığını test etmek:
# İlk sorgu: resolver yetkili DNS'e gider
# İkinci sorgu 5 saniye sonra: önbellekten gelir, TTL azalmış olur
dig +short buyukweb.com A @8.8.8.8
sleep 5
dig +short buyukweb.com A @8.8.8.8
# NXDOMAIN kontrolü
dig buyukweb.com MX @1.1.1.1
# NS ve glue record
dig +short buyukweb.com NS @a.root-servers.net
REM Windows — nslookup ile resolver testi
nslookup buyukweb.com 8.8.8.8
nslookup -type=MX buyukweb.com 1.1.1.1
Online Araçlar
whatsmydns.net — 20'den fazla coğrafi konumdan tek DNS sorgusu yapar, harita üzerinde gösterir. En sık kullanılan propagasyon kontrol aracı.
dnschecker.org — Dünya genelinde resolver'lardan sonuç toplar; hangi bölgede henüz yayılmadığını görmek için kullanışlı.
dnspropagation.net — Benzer işlev, farklı resolver havuzu.
Yerel DNS Önbelleğini Temizleme
Değişikliğin kendi bilgisayarınızda görünmemesinin sebebi çoğunlukla yerel önbellek. Flush işlemi sadece sizin cihazınızı etkiler, ISP resolver'ını değil.
Windows:
ipconfig /flushdns
macOS (Ventura ve sonrası):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux — systemd-resolved:
sudo systemctl restart systemd-resolved
# veya
sudo resolvectl flush-caches
Linux — dnsmasq:
sudo systemctl restart dnsmasq
Chrome tarayıcı DNS önbelleği:
chrome://net-internals/#dns
→ "Clear host cache" butonuna tıklayın
Firefox:
about:networking#dns
→ "Clear DNS Cache" butonuna tıklayın
Anycast DNS ve Hızlı Propagasyon
Bazı DNS sağlayıcıları anycast yönlendirme kullanır: aynı IP adresi dünya üzerinde onlarca farklı veri merkezinde duyurulur, sorgular coğrafi yakınlığa göre en yakın node'a gider.
Anycast DNS'te propagasyon nasıl çalışır?
Geleneksel DNS:
Resolver → yetkili sunucu (tek nokta)
Resolver önbelleği TTL dolunca güncellenir
→ Güncelleme gecikme = TTL değeri
Anycast DNS (Cloudflare gibi sağlayıcılar):
Değişiklik yapılır → tüm anycast node'larına anlık senkronize edilir
Resolver'lar hâlâ TTL bekler
→ Ancak TTL 300s ise 5 dakika sonra tüm dünya aynı yanıtı alır
Fark: Yetkili sunucunun kendisi saniyeler içinde tutarlı — resolver cache hâlâ kural
Cloudflare DNS (yetkili DNS hizmeti, 1.1.1.1 ile karıştırmayın) ve benzeri anycast sağlayıcılar zona değişikliklerini küresel node ağına 30–60 saniyede yayar. Bu, yetkili DNS tarafındaki gecikmeyi ortadan kaldırır. Resolver cache TTL hâlâ geçerliliğini korur — ama TTL'yi 300 yapıp anycast DNS kullanırsanız değişiklik pratikte 5–6 dakikada tüm dünyaya yayılır.
Geleneksel cPanel DNS kullanıyorsanız bu avantaj yok; ama TTL stratejisi aynı sonucu verir.
DNSSEC ve Propagasyon: Zincir Etkisi
DNSSEC, DNS kayıtlarına kriptografik imza ekler. Bir imzalı bölgede kayıt değiştirdiğinizde şunlar gerekir:
1. Değiştirilen kayıt yeniden imzalanır (RRSIG güncellenir)
2. RRSIG kaydının TTL'si sona ermeden eski imza doğrulanamaz hale gelir
3. Resolver'lar yeni RRSIG'i almadan DNSSEC validation başarısız olabilir → SERVFAIL
Güvenli DNSSEC kayıt değişikliği:
Önce yeni imzanın resolver'lara ulaşması beklenmeli
Sonra eski kayıt kaldırılmalı
Bu sıra bozulursa "bogus" yanıt → isim çözümlenmez
DNSSEC etkinse NS değişikliği daha karmaşık: DS kaydının TLD'de güncellenmesi gerekir. Bu süreç registrar desteği gerektirir ve birkaç saat sürebilir.
Detaylı DNSSEC yönetimi bu yazının kapsamı dışında; ayrı rehberde ele alınıyor.
CNAME Flattening ve ALIAS Kaydı: Apex Domain Propagasyonu
DNS standartlarına göre (RFC 1034) apex domain — buyukweb.com gibi kök alan adı — CNAME alamaz. Çünkü apex'te SOA ve NS kayıtları zorunlu, CNAME ise o isimde başka kayıt olmamasını gerektirir.
Peki CDN veya statik site barındırma hizmeti "kök domaininizi CNAME yapın" derse?
Geleneksel çözüm: A kaydı ile IP'yi doğrudan girin
Sorun: CDN IP'leri değişebilir; sabit IP garanti değil
Modern çözüm: CNAME Flattening / ALIAS / ANAME
- Cloudflare: CNAME flattening (otomatik, arayüzde normal CNAME gibi görünür)
- Bazı yönetilen DNS hizmetleri: ALIAS record (apex domain için CNAME alternatifi)
- Diğer yönetilen DNS hizmetleri: ALIAS veya ANAME tipi kayıtlar
Bu özel kayıtlar DNS sağlayıcısı tarafından çözümlenir:
Sağlayıcı, CNAME hedefini kendi içinde çözümler → A kaydı döndürür
Dışarıdan bakan resolver standart A kaydı görür
Propagasyon davranışı A kaydı gibi (TTL bağımlı)
cPanel standart DNS kullanıyorsanız apex'e CNAME ekleyemezsiniz — A kaydı girmeniz gerekir. External Cloudflare DNS kullanıyorsanız CNAME flattening otomatik çalışır.
Buyukweb Hosting'de DNS Propagasyonu
cPanel Zone Editor:
cPanel → Domains → Zone Editor üzerinden DNS kayıtları ekleyebilir, düzenleyebilir, TTL değerini ayarlayabilirsiniz. Değişiklik yaptıktan sonra cPanel'in yetkili DNS sunucusu anında güncellenir; gecikme yalnızca dışarıdaki resolver önbelleklerinden kaynaklanır.
Deploy planladığınızda 48 saat öncesinden TTL'yi 300'e düşürün, değişikliği yapın, sonra tekrar 3600'e alın.
Plesk DNS Server:
Plesk kullanan sunucularda DNS yönetimi Plesk → Domains → DNS Settings üzerinden yapılır. A, CNAME, MX kayıtları ve TTL aynı mantıkla çalışır.
External Cloudflare DNS:
cPanel hosting alıp Cloudflare'i yetkili DNS olarak kullanıyorsanız (Nameserver'ları Cloudflare'e yönlendirdiyseniz) DNS değişikliklerinizi Cloudflare panelinden yaparsınız. Cloudflare anycast altyapısı sayesinde zone güncellemeleri hızla yayılır; propagasyon süresi büyük ölçüde Cloudflare'in TTL'ne bağlı olur — varsayılan "Auto" TTL 300 saniyedir.
Herhangi bir DNS yapılandırma sorununda 0850 302 60 70 destek hattımızı arayabilirsiniz.
Sık Sorulan Sorular
"DNS değişikliğim 24 saat önceydi, neden hâlâ eski IP görüyorum?"
Büyük ihtimalle ISP resolver'ınız kaydı değişiklik öncesinde önbellekledi ve TTL süresi henüz dolmadı. dig buyukweb.com A @8.8.8.8 ve dig buyukweb.com A @1.1.1.1 ile farklı resolver'ların ne söylediğini karşılaştırın. Eğer public resolver'lar yeni IP'yi gösteriyorsa sorun ISP önbelleği veya yerel cache. Eğer public resolver'lar da eski IP veriyorsa yetkili DNS'te değişiklik tam yansımamış olabilir.
"TTL kaç saniye olmalı?"
Üretim A kaydı için 3600 (1 saat) standart ve makul. Değişiklik planlanmıyorsa 86400 (24 saat) yetkili DNS'e yük azaltır. Deploy öncesi 300 (5 dakika) geçici süre için idealdir. 60 saniye altı yalnızca aktif failover senaryolarında gereklidir; yetkili sunucunuza çok fazla sorgu gider.
"Cloudflare ile propagasyon gerçekten dakikalar mı?"
Cloudflare'i yetkili DNS olarak kullanıyorsanız, zone güncellemesi Cloudflare'in anycast ağına 30–60 saniyede yayılır. Ama resolver'lar hâlâ önbelleklerindeki eski kaydın TTL'sini bekler. Cloudflare'in varsayılan "Auto" TTL 300 saniye (5 dakika). Yani değişiklik sonrası en fazla 5–6 dakika içinde dünyada çoğu resolver yeni kaydı görür. Bu rakamı genel cPanel DNS'e uygulamak doğru olmaz.
"DNS flush gerçekten işe yarıyor mu?"
Yalnızca kendi bilgisayarınızda. ISP resolver önbelleğini temizleyemezsiniz — o çözüm siz yerine değil, TTL dolduğunda kendiliğinden olur. Flush yaptıktan sonra tarayıcınız ISP resolver'ına sormaya devam eder; ISP önbelleği hâlâ eskiyse aynı yanıtı alırsınız.
"Glue record nedir, neden gerekli?"
Bir alan adının yetkili DNS sunucusu aynı alan adı altındaysa (örneğin buyukweb.com için ns1.buyukweb.com), resolver döngüsel sorgu yapamaz. Glue record, TLD registry'de (örn. Verisign .com için) nameserver'ın IP adresini doğrudan saklar; döngü kırılır. NS değişikliğinde registrar panelinden glue record da güncellenmeli.
"Negatif cache (NXDOMAIN cache) neden var?"
Olmayan bir kaydı her sorguda yetkili DNS'e sormak gereksiz yük oluşturur. Resolver "yok" cevabını da önbellekler — süre SOA MINTTL'ye göre belirlenir. Pratikte yanlışlıkla silen ve hemen geri ekleyen biri için bu 1 saatlik görünmezlik anlamına gelebilir.
"Kendi bilgisayarımda görüyorum, müşteri görmüyor — ne yapmalıyım?"
Farklı resolver önbellekleri. Müşteriye whatsmydns.net adresinde alanınızı kontrol etmesini isteyin; hangi coğrafyada hâlâ yayılmadığını görebilirsiniz. Eğer birkaç ülkede hâlâ eski IP görünüyorsa TTL dolmamış demektir — bekleyin. Müşteri tarayıcısını kapatıp açmasını veya DNS flush yapmasını önermeyi deneyin.
İlgili Büyükweb Hizmetleri
- cPanel Web Hosting — Zone Editor ile TTL yönetimi, A/CNAME/MX kaydı
- VDS Sunucu — kendi DNS sunucunuzu çalıştırma, tam kontrol
- DNS Kayıtları Rehberi — A, CNAME, MX, TXT, TTL kavramsal hub
- Cloudflare DNS Entegrasyonu — Cloudflare yetkili DNS kurulumu
Propagasyon sorunlarında veya DNS yapılandırmasında yardım için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.
Domain & DNS İlgili Hizmetlerimiz
Bu yazıda anlatılan teknik konuyu profesyonel altyapıyla deneyimleyin
Etiketler:
