Alan Adı & DNS

    DNS Propagasyon Kontrol Araçları

    DNS değişikliğinin küresel yayılımını gösteren propagasyon kontrol araçları.

    14 dk okuma Güncellendi: 10 Temmuz 2026

    Bir A kaydını güncellediniz, alan adınızı yeni bir sunucuya taşıdınız ya da nameserver'larınızı değiştirdiniz. Kendi bilgisayarınızda her şey doğru görünüyor, ama bir arkadaşınız hâlâ eski siteyi gördüğünü söylüyor. Bu noktada aklınıza gelen ilk soru şudur: "Değişiklik gerçekten dünyaya yayıldı mı, yoksa hâlâ bekliyor muyum?" İşte bu soruyu tahmine dayanmadan yanıtlamanın yolu, DNS propagasyon kontrol araçlarıdır.

    Bu araçlar, alan adınızın DNS kayıtlarını dünyanın farklı bölgelerindeki onlarca DNS sunucusundan aynı anda sorgular ve her birinin hangi değeri döndürdüğünü tek bir ekranda gösterir. Böylece "İstanbul'daki resolver yeni IP'yi görüyor mu, Frankfurt görüyor mu, Singapur hâlâ eskisinde mi kalmış?" gibi soruların yanıtını saniyeler içinde alırsınız. Bu rehberde bu araçların ne işe yaradığını, dnschecker gibi çevrim içi servislerin nasıl kullanıldığını, sonuçların TTL ve önbellekle nasıl ilişkilendiğini ve "yeşil tik" görene kadar ne kadar beklemeniz gerektiğini kıdemli bir sistem yöneticisinin gözünden anlatacağız. Propagasyonun neden zaman aldığını daha temelden merak ediyorsanız, önce DNS propagasyonu neden 24-48 saat sürer yazımızı okumanızı öneririm.

    Propagasyon Kontrol Aracı Tam Olarak Ne Yapar?#

    Bir DNS propagasyon kontrol aracı, özünde çok basit bir iş yapar: sizin adınıza, dünyanın çeşitli noktalarına dağılmış DNS çözücülerine (resolver) aynı sorguyu gönderir ve dönen cevapları yan yana dizer. Siz ornek.com yazıp "A kaydı" seçersiniz; araç bu sorguyu Amsterdam, New York, Tokyo, São Paulo gibi konumlardaki resolver'lara iletir ve her birinin döndürdüğü IP adresini bir liste ya da harita üzerinde gösterir.

    Bu neden değerlidir? Çünkü kendi bilgisayarınızdan yapacağınız tek bir sorgu, yalnızca sizin internet sağlayıcınızın (ISP) resolver'ının o an ne düşündüğünü söyler. Oysa siteniz tüm dünyadan ziyaret ediliyor ve her ziyaretçi farklı bir resolver kullanıyor. Propagasyon kontrol aracı, tek bir bakış açısı yerine küresel bir fotoğraf sunar: değişikliğiniz nerelerde yayıldı, nerede hâlâ eski değer önbellekte duruyor.

    Kısacası bu araçlar bir "durum panosudur". Size şunu söyler:

    • Yeni kayıt hangi bölgelerde görünür oldu (genellikle yeşil bir onay işaretiyle).
    • Hangi bölgeler hâlâ eski değeri döndürüyor (kırmızı bir işaretle).
    • Farklı konumlar arasında henüz bir tutarsızlık var mı, yani değişiklik "yarı yolda" mı.

    Bir uyarı: bu araçlar yalnızca okuma yapar, hiçbir şeyi hızlandırmaz. Bir kontrol sitesine defalarca girmek propagasyonu bir saniye bile kısaltmaz; yalnızca mevcut durumu gözlemlersiniz. Yayılmayı hızlandırmanın gerçek yolu, değişiklikten önce TTL'i düşürmektir — buna birazdan geleceğiz.

    Bu Araçlar Perde Arkasında Nasıl Çalışır?#

    Propagasyon kontrol araçlarının sihri, "coğrafi olarak dağıtılmış sorgulama" fikrinden gelir. Servis sağlayıcı, dünyanın farklı veri merkezlerinde çalışan sunuculara ya da farklı bölgelerdeki genel resolver'lara (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9 gibi) erişim sağlar. Siz bir sorgu başlattığınızda, aracın altyapısı aynı DNS sorgusunu bu noktaların hepsine paralel olarak gönderir.

    Her bir konum, kendi yerel önbelleğinin durumuna göre cevap verir. Bir bölgedeki resolver kaydı yeni sorguladıysa güncel değeri; kaydı hâlâ eski TTL süresi içinde tutuyorsa eski değeri döndürür. Araç, bu cevapları toplayıp size gösterir. Yani aslında gördüğünüz şey, "internetin farklı köşelerindeki önbelleklerin anlık durumudur".

    Burada kritik bir ayrım vardır. Bu araçların çoğu, yetkili nameserver'ınızı değil, önbellekli (recursive) resolver'ları sorgular. Bu bilinçli bir tercihtir: amaç, gerçek ziyaretçilerin deneyimini taklit etmektir. Gerçek bir kullanıcı da sitenize eriştiğinde yetkili sunucuya değil, kendi ISP'sinin önbellekli resolver'ına sorar. Dolayısıyla propagasyon aracının "hâlâ eski IP görünüyor" demesi, o bölgedeki ziyaretçilerin de büyük olasılıkla eski siteyi göreceği anlamına gelir.

    Sorgu türüNeyi sorarNe zaman kullanılır
    Önbellekli resolver (recursive)ISP/genel çözücülerin önbelleğiniGerçek ziyaretçi deneyimini görmek için — propagasyon durumu
    Yetkili nameserver (authoritative)Doğrudan DNS'inizi yöneten sunucuyuKaydın gerçekten doğru kaydedildiğini doğrulamak için

    Bu iki sorgu farklı sorulara yanıt verir. Propagasyon araçları birincisini gösterir; kaydın yetkili sunucuda gerçekten doğru olup olmadığını ise ikinci yöntemle, dig ile doğrularsınız.

    dnschecker ve Benzeri Araçları Adım Adım Kullanmak#

    Çevrim içi kontrol siteleri (dnschecker türü servisler) neredeyse hepsi aynı akışla çalışır. Tipik bir kontrol şöyle ilerler:

    1. Alan adını girin. Sorgulamak istediğiniz alan adını yazarsınız, örneğin ornek.com. Bir alt alan adını (subdomain) kontrol edecekseniz onu da tam olarak yazın: www.ornek.com ya da mail.ornek.com. www ile wwwsuz sürüm farklı kayıtlar olabilir; hangisini değiştirdiyseniz onu sorgulayın.
    2. Kayıt tipini seçin. Açılır menüden hangi kaydı kontrol edeceğinizi seçersiniz. Doğru tipi seçmek çok önemlidir; yanlış tip seçerseniz "değişiklik yayılmadı" gibi yanıltıcı bir sonuç görürsünüz.
    3. Sorguyu başlatın. Araç, dünyanın farklı konumlarındaki resolver'lardan gelen cevapları bir liste ya da harita olarak gösterir. Her satırda konum, resolver'ın döndürdüğü değer ve bir durum işareti bulunur.
    4. Sonuçları yorumlayın. Yeşil işaretli konumlar yeni değeri, kırmızı işaretliler eski değeri görüyordur. Amacınız tüm (ya da neredeyse tüm) konumların yeni değeri göstermesidir.

    Hangi kayıt tipini seçeceğiniz, ne değiştirdiğinize bağlıdır:

    Değiştirdiğiniz şeyKontrol edilecek kayıt tipi
    Sitenin IP adresi (IPv4)A
    Sitenin IPv6 adresiAAAA
    Bir alt alan adının yönlendirmesiCNAME
    E-posta sunucusu / MX değişikliğiMX
    Nameserver (yetkili sunucu) değişimiNS
    Alan doğrulama, SPF, DKIM gibi metin kayıtlarıTXT

    Örnek bir senaryo üzerinden gidelim. Diyelim ki ornek.com alan adının IP adresini 203.0.113.10'dan yeni sunucunuzun IP'si olan 203.0.113.99'a taşıdınız. Kontrol aracında alan adını ornek.com yazar, kayıt tipini A seçer ve sorgularsınız. Sonuç listesinde şöyle bir tabloya benzer bir şey görürsünüz:

    Konum          Cevap            Durum
    Frankfurt      203.0.113.99     yeni  (yeşil)
    Amsterdam      203.0.113.99     yeni  (yeşil)
    Istanbul       203.0.113.10     eski  (kırmızı)
    Singapur       203.0.113.99     yeni  (yeşil)
    New York       203.0.113.10     eski  (kırmızı)
    

    Bu tablo size şunu anlatır: değişiklik Avrupa ve Asya'nın bir kısmında yayılmış, ama İstanbul ve New York'taki resolver'lar hâlâ eski IP'yi önbellekte tutuyor. Bu tamamen normaldir; o bölgelerdeki resolver'ların TTL süresi dolduğunda onlar da yeni değeri öğrenecektir. Panik yok — beklemeniz yeterli.

    Aynı işi tek bir araca bağlı kalmadan farklı servislerle tekrarlamak iyi bir alışkanlıktır. Bir sitenin altyapısı bir bölgede sıkışmış olabilir; ikinci bir araçla teyit ederseniz sonucun aracın kendi sorunundan değil, gerçek propagasyon durumundan kaynaklandığından emin olursunuz.

    Sonuçları Doğru Okumak: Yeşil, Kırmızı ve Karışık Tablolar#

    Kontrol sonuçlarını yorumlarken en sık yapılan hata, "hepsi yeşil olmadan hiçbir şey çalışmıyor" sanmaktır. Oysa gerçekte karışık bir tablo, sürecin sağlıklı ilerlediğinin işaretidir. Üç tipik durumu ayıralım.

    Tüm konumlar eski değeri gösteriyor (hepsi kırmızı veya eski). Bu, ya değişikliğinizin henüz yetkili sunucuya işlenmediği ya da kaydı yaptığınızın üzerinden çok az zaman geçtiği anlamına gelir. Eğer değişikliği yaptıktan hemen sonra kontrol ettiyseniz bu beklenen bir durumdur. Ama saatler geçmesine rağmen hiçbir konum yeni değeri görmüyorsa, kaydı doğru yerde ya da doğru tipte kaydetmemiş olabilirsiniz. Bu noktada mutlaka yetkili sunucuyu dig ile kontrol edin (aşağıda anlatıyoruz).

    Bazı konumlar yeni, bazıları eski (karışık tablo). Bu, propagasyonun tam ortasında olduğunuz anlamına gelir ve en yaygın durumdur. Bazı resolver'ların TTL süresi dolmuş, bazılarınınki henüz dolmamıştır. Yapılacak tek şey beklemektir. Karışık tablo, sistemin doğru çalıştığının kanıtıdır.

    Tüm konumlar yeni değeri gösteriyor (hepsi yeşil). Tebrikler, değişikliğiniz küresel olarak yayılmıştır. Yine de "hepsi yeşil" bile mutlak bir garanti değildir; araç sınırlı sayıda resolver'ı sorgular ve dünyada bunun dışında binlerce resolver vardır. Ama pratikte örneklenen konumların tamamı yeni değeri gösteriyorsa, ziyaretçilerinizin ezici çoğunluğu da yeni siteyi görüyordur.

    Bir noktaya dikkat: eğer bazı resolver'lar bir alt alan adı için "cevap yok" ya da boş dönüyorsa, bu iki şey olabilir. Ya kayıt henüz o bölgeye ulaşmamıştır, ya da o resolver daha önce "böyle bir kayıt yok" cevabını negatif önbelleğe almıştır. Yeni bir kaydı oluşturmadan önce yanlışlıkla sorguladıysanız bu tuzağa düşebilirsiniz; bu durumda o resolver, kaydı gerçekten eklemenizden sonra bile bir süre "yok" demeye devam eder.

    Sonuçların TTL ve Önbellekle İlişkisi#

    Propagasyon aracının gösterdiği her satırın arkasında tek bir kavram vardır: TTL (Time To Live). TTL, bir DNS kaydının resolver'lar tarafından kaç saniye önbellekte tutulacağını belirten değerdir. Aracın neden bazı konumları "eski", bazılarını "yeni" gösterdiğini anlamak, tamamen TTL'i anlamaktan geçer.

    Bir örnekle netleştirelim. ornek.com'un A kaydı şu şekilde tanımlıysa:

    ornek.com.   3600   IN   A   203.0.113.10
    

    Buradaki 3600, TTL değeridir — yani bir saat. Bir resolver bu kaydı öğrendiğinde, tam bir saat boyunca yetkili sunucuya tekrar sormaz; elindeki 203.0.113.10 cevabını kullanır. Siz bu bir saat içinde IP'yi 203.0.113.99 yapsanız bile, o resolver kalan süre boyunca eski adresi döndürmeye devam eder. İşte propagasyon aracında o bölgeyi "kırmızı/eski" gösteren şey budur.

    Her resolver kaydı farklı bir anda önbelleğe almıştır; dolayısıyla hepsinin TTL sayacı farklı anlarda dolar. Propagasyon aracındaki karışık tablo tam olarak bunun görüntüsüdür: erken tazelenmiş resolver'lar yeni değeri, henüz süresi dolmamış olanlar eski değeri gösterir. Değişikliğin "tam" yayılması, örneklenen en yavaş önbelleğin süresinin dolması demektir.

    Buradan çıkan pratik sonuç çok önemlidir: propagasyonu hızlandırmanın tek gerçek yolu, TTL'i değişiklikten önce düşürmektir. Sunucu taşıma ya da IP değişikliği planlıyorsanız, işlemden en az 24-48 saat önce ilgili kaydın TTL'ini düşük bir değere çekin:

    # Geçişten önce: TTL'i 5 dakikaya düşür
    ornek.com.   300   IN   A   203.0.113.10
    

    Mantık şudur: eski, yüksek TTL'in tüm resolver'larda sona ermesini beklersiniz. Düşük TTL bir kez yayıldığında, resolver'lar artık kaydı yalnızca 5 dakika saklar. Böylece asıl IP değişikliğini yaptığınızda, propagasyon aracındaki tüm konumlar en fazla birkaç dakika içinde yeşile döner. Geçiş bittikten sonra TTL'i tekrar 3600 gibi normal bir değere yükseltebilirsiniz. Bu tekniğin ayrıntısını ve neden "TTL'i şimdi düşürmek anında yaymaz" tuzağını propagasyon süresi rehberimizde bulabilirsiniz.

    Komut Satırıyla Kesin Doğrulama: dig ve nslookup#

    Çevrim içi araçlar pratik ve görseldir, ama en kesin sonucu komut satırından alırsınız. Özellikle "kayıt gerçekten yetkili sunucuda doğru mu?" sorusunu yalnızca dig net biçimde yanıtlar. Ben taşıma işlerinde daima önce yetkili sunucuyu dig ile kontrol eder, sonra çevrim içi araçla küresel yayılımı izlerim.

    Linux ve macOS'te bulunan dig, DNS sorgulamanın en esnek aracıdır:

    # Google resolver'ından A kaydını sorgula
    dig @8.8.8.8 ornek.com A +short
    
    # Cloudflare resolver'ından aynı sorgu — cevaplar farklıysa henüz yayılmamış
    dig @1.1.1.1 ornek.com A +short
    
    # Doğrudan yetkili sunucuyu sorgula (önbelleği atlar — gerçek güncel değer)
    dig @ns1.saglayici.com ornek.com A +short
    
    # Kaydın kalan TTL'ini gör (ANSWER SECTION'daki ikinci sütun)
    dig ornek.com A
    
    # Nameserver kayıtlarını doğrula
    dig ornek.com NS +short
    

    Burada püf noktası şudur: yetkili sunucuyu (dig @ns1.saglayici.com ...) sorguladığınızda dönen değer, kaydın gerçek halidir, çünkü orada önbellek yoktur. Eğer yetkili sunucu yeni IP'yi döndürüyorsa ama çevrim içi araç hâlâ eski değeri gösteriyorsa, sorun sizin tarafınızda değildir — sadece uzak resolver önbelleklerinin süresinin dolmasını bekliyorsunuz demektir. Bu ayrım, gereksiz panikten sizi kurtarır.

    Windows kullanıcıları, ek bir araç kurmadan nslookup ile benzer bir kontrol yapabilir:

    # Varsayılan resolver ile sorgu
    nslookup ornek.com
    
    # Belirli bir resolver belirterek sorgu
    nslookup ornek.com 1.1.1.1
    
    # Yalnızca nameserver kayıtları
    nslookup -type=NS ornek.com
    

    nslookup çıktısında "Non-authoritative answer" ibaresi görmek normaldir; bu, cevabın bir önbellekten geldiğini gösterir. Değişikliğin yayılıp yayılmadığını görmek için sorguyu farklı resolver IP'leriyle (8.8.8.8 ve 1.1.1.1) tekrarlayıp cevapları karşılaştırın. Nameserver değişimini takip ediyorsanız, nameserver değiştirme rehberimizdeki adımlarla birlikte NS kaydının hem eski hem yeni sunucularda ne döndürdüğünü ayrı ayrı doğrulamanızı öneririm.

    Ne Kadar Beklemeli? Gerçekçi Süreler#

    Herkesin sorduğu asıl soru budur: "Ne kadar bekleyeceğim?" Dürüst yanıt, "değiştirdiğiniz kaydın türüne ve TTL'ine bağlı" olmasıdır. Yine de gerçekçi bir tablo çizebiliriz.

    Değişiklik türüTipik yayılma süresiBelirleyici etken
    Düşük TTL'li A / CNAME değişikliği5-30 dakikaYeni TTL (örn. 300 sn)
    Standart TTL'li A / CNAME değişikliği1-4 saatEski TTL (örn. 3600 sn)
    MX (e-posta) kaydı değişikliği1-4 saatKayıt TTL'i
    Nameserver (NS) değişimi2-48 saatTLD tarafındaki yüksek TTL
    .tr uzantısında NS değişimiDaha uzun olabilirRegistry yenileme aralıkları

    Nameserver değişiminin neden en yavaş işlem olduğunu bilmek önemlidir. Tek bir A kaydını değiştirdiğinizde yalnızca o kaydı önbelleğe almış resolver'ları beklersiniz. Ama nameserver'ları değiştirdiğinizde, alan adının uzantısından sorumlu TLD sunucularındaki NS kayıtları güncellenir ve bunların TTL'i genellikle çok yüksektir (24 saat ve üzeri). Bu değeri siz kontrol edemezsiniz; registry belirler. Bu yüzden nameserver değişimlerinde çevrim içi araçta uzun süre karışık tablo görmek olağandır.

    Pratik bir tavsiye: propagasyon aracını dakikada bir yenilemek yerine, mantıklı aralıklarla kontrol edin. Düşük TTL'li bir değişiklikte 15-20 dakikada bir, nameserver değişiminde birkaç saatte bir bakmak yeterlidir. Sürekli yenilemek ne yayılmayı hızlandırır ne de yeni bilgi verir; yalnızca kaygıyı artırır. Bu arada eski sunucuyu propagasyon tamamlanana kadar kapatmayın — henüz güncellenmemiş resolver'ları kullanan ziyaretçiler o süre boyunca eski adrese düşmeye devam eder.

    Kendi Cihazınızda Hâlâ Eski Değer Görünüyorsa#

    Bazen çevrim içi araç değişikliğin yayıldığını söyler, ama sizin bilgisayarınız hâlâ eski siteyi gösterir. Bunun nedeni neredeyse her zaman yerel önbellektir — kendi işletim sisteminizin, yönlendiricinizin ya da tarayıcınızın DNS önbelleği. Bu durumda önce kendi tarafınızı temizleyin:

    # Linux (systemd-resolved)
    sudo resolvectl flush-caches
    
    # macOS
    sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
    
    # Windows (yönetici komut istemi)
    ipconfig /flushdns
    

    Tarayıcılar da adresleri kendi içlerinde ayrı bir önbellekte tutar. İşletim sistemi önbelleğini boşalttıktan sonra bile eski değeri görüyorsanız tarayıcıyı tamamen kapatıp açın; Chrome tabanlı tarayıcılarda chrome://net-internals/#dns sayfasından tarayıcının kendi DNS önbelleğini de temizleyebilirsiniz. Ondan sonra hâlâ eski değer geliyorsa, gecikme büyük olasılıkla kendi cihazınızda değil, ISP'nizin resolver önbelleğindedir; orada süre dolana kadar beklemekten başka çare yoktur. Bu yüzden yayılmayı değerlendirirken kendi tarayıcınıza değil, çevrim içi araca ve farklı resolver'lara güvenin.

    Sıkça Sorulan Sorular#

    DNS propagasyon kontrol aracı yayılmayı hızlandırır mı?#

    Hayır, bu araçlar yalnızca mevcut durumu okur, hiçbir şeyi hızlandırmaz. Kontrol sitesine defalarca girmek propagasyonu bir saniye bile kısaltmaz; çünkü yayılma süresini uzak resolver'ların TTL sayaçları belirler ve onları uzaktan sıfırlayamazsınız. Yayılmayı gerçekten hızlandırmanın tek yolu, değişiklikten en az bir gün önce ilgili kaydın TTL'ini düşürmektir. Araç size sadece sürecin ne aşamada olduğunu gösterir.

    Araç bazı konumlarda eski, bazılarında yeni değer gösteriyor; bir sorun mu var?#

    Hayır, bu tamamen normaldir ve aslında sürecin sağlıklı ilerlediğinin işaretidir. Her resolver kaydı farklı bir anda önbelleğe aldığı için TTL süreleri de farklı anlarda dolar. Bu yüzden yayılmanın ortasında bazı bölgeler yeni, bazıları eski değeri gösterir. Yapmanız gereken tek şey biraz daha beklemek; süresi dolan resolver'lar da sırayla yeni değere geçecektir. Saatlerdir hiç değişmiyorsa, o zaman kaydı doğru yerde tanımladığınızı dig ile yetkili sunucudan doğrulayın.

    Çevrim içi araç mı yoksa dig mi daha güvenilir?#

    İkisi farklı sorulara yanıt verir, bu yüzden ikisini birlikte kullanmak en doğrusudur. Çevrim içi araçlar, dünyanın farklı bölgelerindeki ziyaretçilerin ne göreceğini gösteren küresel bir fotoğraf sunar. dig ise özellikle yetkili sunucuyu doğrudan sorgulayarak kaydın gerçekten doğru kaydedilip kaydedilmediğini kesin biçimde söyler. Ben genelde önce dig @yetkili-sunucu ile kaydın doğru olduğunu teyit eder, sonra çevrim içi araçla küresel yayılımı izlerim.

    Nameserver değiştirdim ama araç hâlâ eski nameserver'ı gösteriyor, neden?#

    Çünkü nameserver değişimi propagasyonun en yavaş türüdür. Alan adının uzantısından sorumlu TLD sunucularındaki NS kayıtlarının TTL'i genellikle 24 saat ve üzeridir ve bu değeri siz değil, registry belirler. Dolayısıyla NS kayıt tipini sorguladığınızda uzun süre karışık ya da eski tablo görmek olağandır. Bu süreçte en önemli şey, yeni nameserver'da tüm A, MX ve TXT kayıtlarınızı geçişten önce hazırlamaktır; aksi halde bazı ziyaretçiler eksik kayıtlı yeni sunucuya düşerek siteye erişemez.

    Tüm konumlar yeşil göründü, artık kesinlikle güvende miyim?#

    Büyük ölçüde evet, ama "kesinlikle" demek için küçük bir pay bırakmak gerekir. Araç, dünyadaki binlerce resolver'ın yalnızca örneklenmiş bir alt kümesini sorgular; örneklenen tüm konumlar yeni değeri gösteriyorsa ziyaretçilerinizin ezici çoğunluğu da yeni siteyi görüyordur. Yine de bazı ISP'ler TTL'e uymayıp kayıtları fazladan tutabilir, dolayısıyla nadir birkaç kullanıcı biraz daha eski değeri görebilir. Güvenli tarafta kalmak için eski sunucuyu birkaç saat daha çalışır tutmak iyi bir alışkanlıktır.

    Yeni eklediğim alt alan adı hiçbir konumda görünmüyor, ne yapmalıyım?#

    Önce kaydı doğru tipte ve doğru yerde oluşturduğunuzu dig @yetkili-sunucu altalan.ornek.com ile doğrulayın; yetkili sunucu doğru değeri döndürüyorsa kayıt aslında hazırdır. Bazı resolver'ların hâlâ "kayıt yok" demesinin sık bir nedeni negatif önbelleklemedir: kaydı oluşturmadan önce yanlışlıkla sorguladıysanız, resolver "böyle bir kayıt yok" cevabını bir süre saklamış olabilir. Bu durumda yapılacak tek şey, SOA kaydındaki minimum süre dolana kadar beklemektir; yeni kayıt zamanla o resolver'larda da görünür hale gelir.

    Kapanış#

    DNS propagasyon kontrol araçları, bir zamanlar "24-48 saat bekle ve dua et" olan belirsiz süreci, ölçülebilir ve öngörülebilir bir işleme dönüştürür. Bu araçların ne gösterdiğini — dünyaya dağılmış resolver önbelleklerinin anlık durumunu — ve bu durumun tamamen TTL tarafından belirlendiğini kavradığınızda, karışık bir tabloya bakıp paniklemek yerine sürecin neresinde olduğunuzu net biçimde okuyabilirsiniz. Çevrim içi aracı küresel yayılımı izlemek için, dig'i ise kaydın yetkili sunucuda gerçekten doğru olduğunu teyit etmek için birlikte kullanmak, sizi hem gereksiz endişeden hem de "kaydı unutmuşum" türü hatalardan korur.

    Bir alan adını taşımayı, IP'nizi değiştirmeyi ya da yeni bir sunucuya geçmeyi planlıyorsanız, hosting paketlerimiz ve VDS sunucularımız TTL yönetimini kolaylaştıran anlaşılır bir DNS paneliyle gelir. Geçişi kendiniz yönetmek istemez, propagasyon sürerken kesinti riskini bize devretmek isterseniz site taşıma ekibimiz tüm kayıtları önden hazırlayıp yayılımı baştan sona takip eder. Yeni bir alan adı almak ya da mevcut alan adınızın DNS'ini yönetmek için de alan adı sayfamıza göz atabilir, propagasyonu takip ederken işinize yarayacak diğer yardımcıları araçlar bölümünde bulabilirsiniz.

    DNSPropagasyonAraçlar

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.